Site architecture is how your URLs are organized, how your pages link to one another, and how many clicks separate any page from the home page. That’s it, and that’s also why it’s cheap. It decides what gets crawled, which pages accumulate internal authority, and what a search engine concludes your site’s actually about.
It’s also the most underrated work available on a large established site. New content takes months and a budget.
New external links take a campaign and a bit of luck, and they don’t always land. Redistributing the authority you already hold takes a crawl, a decision and a template change, and on a strong domain it frequently moves more revenue than either.
Site architecture distributes the authority you already have
Internal links pass authority the same way external links do, with the difference that you control every single one of them. A page’s internal link profile (how many pages link to it, from how deep, with what anchor text) is the strongest ranking input you can change unilaterally, and on most enterprise sites nobody has ever designed it.
Authority enters mostly at the home page and a handful of link-earning pages, then flows outward, diluted by the number of links on each page it passes through and by distance from the source.
Which leads to an unpopular implication. A 200-link mega menu on every template doesn’t prioritize anything. It spreads the same allocation across everything equally, which is arithmetically identical to having no priorities at all.
So the rule worth adopting is that a genuine priority page gets linked from more than the navigation. From body copy on related pages, from relevant hubs, with descriptive anchor text, and somebody can report the count. If nobody can tell you how many internal links point at your top revenue category, that’s your finding and you got it in the first meeting.
Internal linking is the only part of your link profile you fully control, and it’s the part almost nobody has ever audited.
Taxonomy and URL structure for a large site
One concept per URL. If two URLs would be described with the same sentence, you have one page and a canonicalization decision to make.
Folders that mirror the hierarchy somebody would draw on a whiteboard. Google recommends readable words rather than long ID numbers, so /category/subcategory/product, not /p/48192.
Lowercase and hyphenated, with no dates in evergreen paths and no session or tracking parameters in canonical URLs.
Don’t encode facets in the path unless the facet is a page you’ve decided to index. /shoes/running/ yes. /shoes/running/size-10/blue/ almost certainly not.
Stable. Every taxonomy change is a migration with a redirect map, whether or not anybody calls it one.
Although contentious, URL structure is arguably a weak direct ranking factor, and restructuring URLs for the ranking benefit alone is rarely worth what it’ll cost. Google frames its own URL guidance around crawling efficiency rather than ranking, warning that sites failing its criteria get crawled inefficiently or not at all.
There are good reasons to fix URL structure anyway. It forces the hierarchy decision to get made explicitly, it makes rules and log analysis tractable at scale, and it makes reporting segmentable. Those hold. “Keywords in the URL” doesn’t.
What does matter directly is depth from the home page, which is a linking property rather than a path property. A page at /a/b/c/d/e/ reachable in two clicks is fine. A page at /product/ only reachable through page 40 of a category is not.
Hub and spoke as an internal linking model
The model is straightforward. A hub page owns a topic and links to every page covering part of it, and the spokes link back to the hub and across to genuinely related siblings. It concentrates authority where the commercially valuable term lives, and it gives crawlers a dense, coherent region to work through instead of a scatter.
On a commerce site the hub is usually the category, with editorial hubs (buying guides, comparison pages) alongside, linking into the commercial pages. On a B2B SaaS site the hubs are use cases, industries or integrations, and the spokes are the feature pages, documentation and comparison content supporting them.
Use descriptive anchors, and use real ones. Google’s guidance is that anchor text tells users and Google something about the page you’re linking to, and that it can only crawl an <a> element with an href attribute in the first place. “Enterprise crawl budget management” tells a crawler what the target page covers. “Learn more” tells it nothing, and a click handler tells it less than nothing.
The received wisdom about over-optimized anchor text applies to external link building. Internally it doesn’t, and being explicit is both normal and expected.
One concession. Hub-and-spoke is a linking model, not a content strategy. Deciding you need twelve spokes because the diagram has twelve is how you end up with eight good pages and four written to fill a slot. Build the spokes demand justifies, link them properly, and let content strategy decide the count.
Faceted navigation is a site architecture decision
Faceted navigation is where architecture and crawl control meet, and the mistake is treating it as a robots.txt problem rather than a component problem. Google’s own description of the damage is unambiguous: crawlers can’t tell whether faceted URLs are useful without crawling them first, so they fetch a very large number of them before concluding they’re useless, and that’s time not spent on new, useful URLs.
Sort your facets into three buckets. Combinations with real standalone demand get crawlable, indexable, internally linked pages. Combinations with occasional demand stay crawlable but canonicalize to the parent. Everything else never renders as a crawlable link.
That third bucket has to get solved in the front-end component, because not linking is the only control operating before a fetch gets spent. The crawl budget mechanics are worth reading in full, and the architectural point stands on its own. The decision about which combinations exist as links belongs in the design of the navigation, not in a directive applied afterwards by somebody who wasn’t in the room.
Orphan pages and click depth
Orphan pages exist, sometimes take traffic, and have nothing linking to them. They’re common and almost always accidental.
Retired campaign pages, products pulled from a category but still sitting in the sitemap, content only reachable through internal search, pages left behind by a template change two redesigns ago. Nobody decided any of it.
Finding them takes several sources combined, because a crawler can’t find what nothing links to. Take the union of your XML sitemaps, GA4 landing pages, Search Console URLs and server logs, then subtract everything a full crawl discovered. What’s left is orphaned.
For depth, the working target on most sites is that anything commercially important sits within three or four clicks of the home page.
Pagination is the usual offender. A category with 80 pages of results makes the products on page 60 unreachable in practice, however many are technically linked.
The fixes are structural rather than clever. More granular subcategories, related-item modules, editorial hubs pointing into the deep set, and sorting defaults that surface a different slice over time.
How to get started with site architecture work
Run a full crawl and plot the distribution of pages by click depth. The shape of that chart is usually the whole diagnosis and it fits on one slide. Then list your top 50 revenue pages against the number of internal links pointing at each, and expect the correlation to be weaker than you’d like.
Find the orphans by union-and-subtract and decide page by page whether to link it, consolidate it or remove it. Fix the structure itself (navigation, hubs, related modules) rather than adding links one at a time, because manual insertion never survives the next redesign. Re-crawl after release and confirm the depth distribution moved.
This is unglamorous work that rarely earns a slide in a board deck. On a site with real domain authority and a tangled structure it’s also the highest-return thing I’m usually able to recommend, which is why it’s a standing part of my audit work.