SEO is usually introduced to a project late, as a checklist applied to pages that already exist. By then the decisions that matter most have been taken: what pages there are, what each one is about, and how they relate. Those decisions were made in a workshop about navigation.

This is about what the shape of a site settles, and why fixing it afterwards is a migration rather than an optimisation.

One page, one job

The rule that prevents most structural SEO problems: every page should be the best answer to exactly one question, and no two pages should answer the same one.

When two pages answer the same question, neither wins. Search engines have to choose, they choose inconsistently, links and relevance signals split between the two, and the fix is a merge and a redirect rather than more content. This is the most common structural fault we find, and it is almost always created by an organisational chart rather than by a content decision - one page written by the product team, another by marketing, about the same thing.

The test is quick. Take the ten queries that matter commercially. For each, name the one page that should rank. If you cannot, or if two qualify, you have found the work.

Depth is a budget, not a hierarchy

How many clicks a page sits from the homepage predicts how often it is crawled and how much internal relevance reaches it. That is not a rule search engines publish; it is a consequence of how linking works.

On a small site this rarely matters. On a large one it decides which half of your catalogue is effectively invisible. If a product is six clicks deep because the taxonomy is elegant, the taxonomy is costing you money.

Practical target: anything commercially important within three clicks of the homepage. Achieving that is usually a linking problem rather than a navigation problem - hub pages, curated cross-links and sensible related content do more than adding a menu level.

Categories are the product, not a filing system

On most commercial sites the category pages, not the detail pages, carry the search traffic. They match how people actually search - by need, not by product name - and they are the pages a competitor with better structure beats you on.

Which means the category set should be derived from how customers describe what they want, not from how the business is organised internally. A manufacturer arranging categories by production line is describing their factory to people shopping for a solution.

The same applies to services. Grouping by internal team produces pages nobody searches for; grouping by the problem the client has produces pages that match real queries.

Faceted navigation, and where it goes wrong

Filters are useful to customers and dangerous to crawlers. Every combination of facets can generate a URL, and a handful of filters multiply into hundreds of thousands of near-identical pages that consume crawl and dilute everything.

  • Decide deliberately which facet combinations deserve an indexable URL. Usually a small set - the ones people actually search for, like a brand within a category.
  • Everything else should not generate a crawlable, indexable URL at all. Preventing the link is better than blocking it afterwards.
  • Sort order, view mode and pagination parameters are never a separate page.
  • If a filtered view is indexable, it needs its own title, description and enough content to justify existing. If that sounds like too much work for that combination, it should not be indexable.

URLs are structure made visible

A URL should describe the page and survive. Short, lowercase, hyphenated, and free of anything that will change - dates, internal identifiers, campaign names, the year in a guide title.

Whether the URL mirrors the category hierarchy is a genuine trade-off. Nesting communicates structure and breaks when a product moves category. Flat URLs survive reorganisation and say less. For catalogues that change shape, flat is usually the safer answer, with breadcrumbs carrying the hierarchy instead.

What is not a trade-off: changing URLs without redirects. If the structure is wrong, fixing it is a migration, with all the work that implies.

Bringing it into the design process

None of this requires an SEO specialist in every meeting. It requires three questions asked during information architecture, before wireframes.

What single question does this page answer? Does another page already answer it? How does someone reach it from the homepage in three clicks?

Pages that cannot answer the first question do not need to exist. Pages that fail the second should be merged. Pages that fail the third need a link, not a menu item. That is most of technical SEO, decided at the point where it is still free.