Information Architecture for SEO
Information architecture is not the menu and not tidy URLs. It answers two questions: how Google reaches a page at all, and why that page rather than another should answer a query. This lesson covers what makes a structure work for search, why nesting depth is almost never the real problem, and what actually breaks catalogues.
It rests on the documentation about which links Google can crawl and on the description of crawl budget.
First: a link has to be a link
The most expensive architectural mistake is not depth, it is a path that does not technically exist. The documentation puts it directly: "Generally, Google can only crawl your link if it's an <a> HTML element with an href attribute". Links in other formats are usually not parsed by the crawlers.
Hence the classic gap: a script-driven menu, filters that reveal products without links, a "load more" with no href. For a person the catalogue exists; for a crawler it does not. A crawl settles it: the site crawler shows what it reached by following links, and that list rarely matches expectations.
Second: depth is not the main problem
"Three clicks from the home page" is a convenient rule, not a documented requirement. What matters is not the number of levels but whether a clear path exists and how visible it is. A page on the fourth level with links from its category and from related material is discovered better than one on the second with a single link in the footer.
The hierarchy is shown to both people and the results by breadcrumbs with structured data: they say where the page sits without asking anyone to read the URL.
Third: catalogues break on filters, not on nesting
Crawl budget is determined by two main elements: crawl capacity limit and crawl demand, and it is counted per hostname. The same page adds something people skip: not every page that is crawled will necessarily be indexed — after crawling, each page still has to be assessed.
Faceted navigation turns a finite catalogue into an unbounded set of addresses: every combination of filters and sort orders is its own URL. Google has a separate guide for it, and that is where crawling goes on large sites — not into menu depth.
The practical symptom is the number of URLs Google knows about being far larger than the number of real pages. That lives in the indexing cleanup report, and whether the sitemap matches reality is what sitemap monitoring answers.
Fourth: one topic, one page
Architecture decides not only reachability but which page owns a topic. When two categories or two articles claim the same query, the results choose for you, and the choice changes between crawls. That is cannibalisation, and it is fixed structurally — by merging, canonicalising or re-aiming one of the pages — not by rewriting copy.
The consolidation rules are in the duplicate URL guide, and finding the conflicting pairs in your own data is what keyword cannibalization does. Which sections actually earn impressions shows in folder performance — that is your architecture as search sees it.
Fifth: the URL describes the structure, it does not create it
A readable address helps: the URL structure guide recommends simple, readable URLs with words rather than identifiers. But a URL is a consequence of the architecture, not the architecture itself. Renaming addresses without changing the relationships fixes nothing and costs a set of redirects.
A short architecture audit
- Crawl the site and compare the URLs found with the ones that should exist.
- Find the pages the crawl never reached: how does a person get there, and why does a crawler not.
- Check whether the number of known URLs exceeds the number of real pages several times over. If it does, look at the filters.
- For three key queries, name the one page that should rank. If you name two, that is a structural task.
- Check the internal links into key pages: how many and from where. Internal link audit shows the donors and the anchors.
Mistakes you can see immediately
- A menu without href: for a crawler there are no paths.
- Every filter an indexable URL with no consolidation rules.
- The sitemap and the navigation describing different sites.
- Two pages on one topic, created "to cover both queries".
- Renaming URLs instead of fixing the relationships.
What comes next
Architecture gets checked with the same data as everything else: first the first-pass diagnosis from the lesson on site triage, then a comparison with what the results reward, as in the lesson on competitive analysis. And keep the timescale in mind: changes do not show up at once, and rebuilding a structure is among the slowest of them.