Site architecture and internal linking

Separate the decisions before changing navigation

Architecture work usually contains three different decisions: what deserves its own page, where that page belongs in a journey, and which links expose it. Resolve them in that order. A new category cannot repair an unclear product proposition, and changing folder names does not create missing links. Record the intended audience, task and owner for every important page family before discussing menus.

The overview should help you choose a narrower investigation. Use website architecture planning when categories overlap or publishing rules are unclear. Investigate discovery when valuable pages are absent from a navigation crawl. Investigate URL generation when the crawler finds thousands of combinations that editors never intended to publish. These problems can coexist, but their fixes differ.

Define a useful outcome in observable terms: every active service has a relevant parent, every retained product has a browsing route, and filter controls cannot generate unlimited duplicate states. Avoid promising a ranking uplift from a structural change alone.

Build an evidence checklist that exposes disagreement

Collect a navigation crawl from the homepage, an inventory from the CMS or catalogue, current XML sitemaps, sampled server responses and a rendered inspection of each major template. Add Search Console page and query evidence where available. Preserve the date, hostname, rendering mode and exclusions for every export. Without that context, two perfectly reasonable datasets can appear to contradict each other.

For each page family, check whether representative URLs return the intended status, can be crawled, declare a sensible canonical and receive links from live pages. Record where links occur: primary navigation, category grids, editorial copy, pagination or a footer. A thousand repeated footer links describe a different journey from ten well chosen links in buying guides.

Also capture deliberate exclusions: account areas, campaign variants, expired inventory and internal search results. They need operating rules, but they do not all belong in organic search. The evidence checklist should distinguish an intentional boundary from an accidental publishing failure.

Choose page families around real tasks

Group content around the decisions a visitor needs to make. A service business might separate diagnosis, implementation and ongoing support because each requires different evidence and a different next step. A retailer might separate category browsing, product comparison and individual product specifications. Internal department names rarely provide a useful organising principle unless customers already understand them.

Write a short inclusion rule for each family. For example, a category needs a stable assortment and a meaningful selection task; a guide needs a question it can answer better than a listing. If two proposed pages need essentially the same introduction, products and next action, challenge whether both should exist. That is a content decision before it becomes a canonicalisation problem.

Assign one durable identity to each retained entity. Categories can change without forcing a product URL change. Keep the content model distinct from the URL path so that a merchandising reorganisation does not automatically become a migration.

Diagnose weak discovery against competing explanations

A page found late in a crawl may sit behind a long pagination chain, but it may also be linked only after interaction, excluded by crawl settings or temporarily unavailable. Test these hypotheses separately. Open the referring page, inspect its actual anchor and request the destination directly. Compare source HTML with rendered HTML when links depend on JavaScript.

An apparently shallow page can still have a weak route if its only parent is a utility index that few people would use. Conversely, a detailed archive may legitimately sit deeper than a core commercial category. The crawl depth workflow explains how to compare page families without turning a shortest path into a universal quality score.

When a sitemap contains URLs missing from the crawl, do not immediately add them all to navigation. Verify that they remain useful, current and canonical. A stale sitemap can manufacture an orphan-page backlog that should instead be retired.

Control breadth as carefully as depth

Making everything one click from the homepage creates an unhelpful index, not a coherent architecture. Use broad navigation for stable choices, category pages for narrowing and contextual links for the next question. Breadcrumbs can explain a page’s location, but they should complement routes into the page rather than serve as its only structural evidence.

Listing systems deserve separate rules. Decide which filtered combinations have an enduring search purpose and which exist only to support on-site selection. Then define finite, retrievable routes through longer collections. The faceted navigation guide addresses filter policy; pagination requires its own treatment because later pages often expose different items.

Review mobile navigation independently. A desktop mega menu may conceal a missing category route on a smaller screen. The test is whether a visitor can complete the journey through ordinary links, with clear labels and a predictable way back, rather than whether both layouts contain equal numbers of anchors.

Worked example: repairing a growing knowledge centre

Illustrative example: a software knowledge centre contains setup instructions, integration references and product announcements in one chronological feed. Older setup material is reachable only through many archive pages. The initial hypothesis is excessive depth. A competing explanation is that outdated and current instructions compete for the same task.

Inventory the documents by product version and supported task first. Retain current setup pages, mark historical instructions clearly and create task hubs for installation, configuration and troubleshooting. Link each hub to its current procedures and link procedures to relevant prerequisites. Keep useful archive routes for users maintaining older versions.

The acceptance evidence is a before-and-after journey map, not an invented traffic forecast. A clean homepage crawl must reach every supported procedure through its task hub; archived instructions must remain distinguishable; no retained URL should change merely because a hub was added. Compare new discovery paths and sampled search landing behaviour after release before claiming the original diagnosis was correct.

Give developers behaviour they can test

Specify the source and destination of each required relationship. A ticket saying “improve internal linking” cannot establish whether the work is complete. A better requirement says that every published integration guide must appear on its integration hub as a normal anchor whose destination is the final canonical URL. Define what happens when a guide is unpublished or an integration is renamed.

Acceptance criteria should cover server responses, rendered links, mobile journeys and catalogue edge cases. Test an empty category, one item, multiple pages, a retired item and a newly published item. Confirm that invalid page numbers do not create endless successful responses. Check that new links do not inherit campaign parameters or create redirect chains.

Use the internal linking audit to verify the deployed graph. Require an export of changed templates and representative URLs so another person can reproduce the checks without access to the original planning discussion.

Release in stages and retain a safe reversal

Prefer a contained family of pages over a simultaneous navigation, taxonomy and URL rewrite. Keep the previous menu configuration and the mapping between old and new parent assignments. If the new journey hides essential content or produces an unmanageable URL space, those records make reversal practical. A rollback that restores a menu but leaves new redirects in place is not a complete recovery plan.

Monitor useful discoveries, broken destinations, filter growth and publishing exceptions. Search data changes slowly and has several possible causes; immediate clicks are a poor acceptance test for a navigation release. Check technical behaviour first, then assess the commercial and search effects over an appropriate period.

Document limitations. A crawl is a snapshot, link counts do not measure usefulness, and a smaller URL inventory is not automatically better. Architecture succeeds when important content has clear, maintained routes and unwanted states stay controlled. Keep those rules in the publishing process so the next content batch does not undo the repair.

Maintain a short exceptions register for pages that deliberately sit outside normal navigation. Include the reason, owner and next review date. That makes later audits faster and stops temporary campaign decisions becoming unexplained structural weaknesses.