Website architecture for SEO

Define the task each level must support

Start with a list of tasks rather than the current navigation labels. Visitors may need to choose a service, check eligibility, compare products or resolve a fault. Map the pages required for those tasks and identify where people need a choice. A category earns its place by helping someone narrow a meaningful set, not by giving every internal department a landing page.

Describe what each level contributes. A top-level hub sets scope, a subcategory supports a specific selection and a detail page resolves the final question. If several levels merely repeat the same introduction and links, remove an unnecessary decision. If one page mixes incompatible tasks, split the model before making a visual sitemap.

The broader site architecture framework helps separate hierarchy decisions from discovery faults. This guide concentrates on designing and maintaining the hierarchy, including the rules that stop it becoming inconsistent as the website grows.

Inventory entities, relationships and ownership

Export content identifiers, current URLs, titles, page types, publication states and assigned categories. Join product or service identifiers where possible. A URL is a location; an entity identifier is usually a safer basis for deciding whether two records describe the same thing. Preserve both so the redesign does not accidentally create duplicate detail pages.

The evidence checklist should include active and retired records, pages with several parents, categories with no useful children and records without an accountable owner. Compare the editorial inventory with a navigation crawl to find relationships the CMS stores but the frontend never exposes. Sample the rendered result rather than assuming every category assignment becomes a link.

Ask who can create categories and what checks happen before publication. A technically tidy hierarchy deteriorates quickly if contributors can create near-identical labels without reviewing existing choices. Architecture needs an editorial decision process as much as a routing implementation.

Write inclusion and exclusion rules

For each proposed category, state its audience, selection criterion, expected content and next action. A useful rule might allow a materials category only when the assortment supports a distinct buying decision and someone will maintain the explanation. Do not turn every database attribute into an indexable landing page.

Specify what stays outside the hierarchy. Private account screens, transient search states and campaign tracking variants need functional access but not necessarily a permanent browsing position. Searchable support archives may require their own hierarchy rather than competing with current commercial navigation. Document these boundaries so missing links can be judged against intent.

Consider competing hypotheses when two categories overlap. The labels may be unclear, the products may genuinely serve two tasks, or the underlying product model may be wrong. Multiple relevant parent links can be sensible; duplicate product URLs for each parent usually add complexity. Diagnose the relationship before using redirects or canonical tags to hide a modelling problem.

Keep URL identity separate from menu placement

A category reassignment should not automatically rename a detail page. Stable URLs reduce the number of moving parts when the business changes its navigation. Decide whether category names must appear in detail paths and what happens when an item belongs to several categories. Make one documented choice rather than letting the active browsing route generate different identities.

Use readable paths, consistent casing and predictable encoding. The exact directory depth is less useful than a clear rule that the routing layer applies reliably. If existing URLs are working, a cosmetic shortening exercise rarely justifies a migration on its own. Retain old locations when adding a better parent route is sufficient.

When a URL change is necessary, inventory old references, map appropriate destinations and test final status codes. Use the redirect mapping workflow for that work. A hierarchy proposal is incomplete if it shows only the new pages and ignores how existing visitors reach them.

Prototype journeys before building the menu

Take representative tasks and walk through a plain list of proposed links. Include first-time visitors, returning users who know a product name and users arriving on a detail page from search. Ask what each page needs to explain and which next step belongs nearby. This reveals missing hubs and ambiguous labels before design effort makes them expensive to change.

Test the longest plausible path as well as the shortest. A visitor should not need to return to the homepage to compare adjacent services. Add breadcrumbs and related links where they clarify real relationships. Avoid creating a dense web of links solely to make every node technically close to every other node.

Run the same exercise on mobile, with keyboard navigation and with direct entry to a deep URL. A menu that works only with hover interaction is an incomplete browsing system. Record failures as specific missing decisions or routes, so developers can implement behaviour rather than interpret an abstract instruction to improve usability.

Worked example: a supplier with overlapping ranges

Illustrative example: an equipment supplier places the same pump under industry, material and pressure categories, creating a different product URL in each path. The redesign proposal is to choose one industry and discard the others. That would simplify the tree while removing useful browsing routes for buyers who start with a technical requirement.

A better model keeps one product identity and allows several maintained category relationships. Industry hubs explain applications; technical categories support specification-led selection. All product cards link to the same retained detail URL. Breadcrumbs follow a deliberate stable policy rather than changing canonical identity according to the entry route.

Before release, test products belonging to one category, several categories and no active category. Check that discontinued items follow the agreed retirement policy. The expected result is consistent routing and understandable choice, not an assumed ranking improvement. If the technical categories have no useful selection role, retire those categories on evidence rather than forbidding all multiple-parent relationships.

Translate the model into developer acceptance criteria

Define required relationships at the data layer and confirm their visible output. Publishing a child page should create a link on its assigned parent. Unpublishing it should remove that link without leaving a broken destination. Renaming a category should update the label without changing unrelated detail URLs. Duplicate category slugs should trigger an explicit validation error.

For each template, list the expected parent link, child listing, pagination behaviour and canonical policy. Test empty, small and large collections, plus unusual characters in labels. A crawl from the public entry point must reach all intended active detail pages without relying on a private API or internal search submission.

Use internal link auditing to verify the implementation against the model. Keep acceptance separate from traffic outcomes: the engineering contract is about correct links and identity, while search performance also depends on content, demand and competing results.

Plan governance, limitations and reversal

Give each category a maintenance owner and review trigger. A collection with a stable purpose may remain useful during a temporary stock shortage, while an abandoned campaign category may not. A numerical minimum child count cannot decide that on its own. Review the task, available alternatives and expected return of content.

Retain the previous category assignments, menu configuration and routing map before deployment. If the new model hides key products, restore their routes without blindly reversing permanent redirects. URL migrations require a separate recovery decision because old and new locations may already have been crawled or bookmarked.

Architecture diagrams omit behaviour. They do not prove that links render, that filters stay bounded or that every supported locale has equivalent journeys. Recheck the live site after publication and after the next substantial content import. The orphan-page reconciliation process is particularly useful for catching records that passed the CMS checks but never received a public browsing route.

Record unresolved choices alongside the model, including who will decide them and which evidence is missing. This prevents an untested assumption about category demand or product ownership becoming a permanent routing requirement simply because it appeared in the first diagram.