SEO Site Architecture

Your architecture is the set of links between your pages. Not the folders those pages sit in. Google says so in one sentence in its ecommerce documentation, and that sentence is the single most useful thing published about this subject: it generally does not look at URL structure to work out the structure of a site, and analyzes the linkages between pages instead.

The mechanism is worth understanding rather than accepting, because it explains everything downstream. A crawler arrives at a page, extracts every anchor element with an href, and adds those URLs to a queue. It does that recursively. What it ends up with is a directed graph of your site, and the shape of that graph is the only structural information it has. A folder name is a string in a URL. It is not an edge.

Google’s own statement on discovery makes the same point from the other direction: the vast majority of new pages it finds every day are found through links. Not through folders, and not primarily through your sitemap. Links are the transport layer for the entire index, and your architecture is either made of them or it is a drawing.

Here is the same nine URLs twice. Identical folders, identical slugs, identical sitemap. On the left nothing links along them, on the right everything does. To a URL audit those two columns are the same site.

Now the receipt, because a page arguing this has no business making you take it on faith. I ran the link graph of this site twice, a day apart, with a tool that lives in a public repository. Both readings are below and one of them is embarrassing.

The important thing about that pair of readings is not the 97. It is that the post-to-hub number went from 1 of 13 to 11 of 11 in a day, and the money-page number did not move by a single page. Fixing relationships you already have is an afternoon. Routing attention to 118 commercial pages means finding, for each one, a page that already earns attention and has an honest reason to mention it. There is no plugin for the second thing, and every plugin that claims to be one produces links nobody meant.

One clarification before the rest of the page, because I am about to spend a chapter on URLs and I do not want it read as a contradiction. Folders are not worthless. Google documents one specific benefit: grouping similar topics into directories helps it learn how often the URLs in each directory change, so a /policies/ folder and a /promotions/ folder can be crawled at different rates. That is real, it is useful, and it is about crawl scheduling. It is not a relevance mechanism and it is not worth a migration.

Information architecture, site architecture, URL structure, navigation and internal linking are five different objects, and almost every argument about architecture is two people diagnosing different rows.

The reason to separate them is not tidiness, it is diagnosis. "Our site architecture is fine, look at the URL structure" is not an argument, it is a category error, and it is the sentence that gets a team to spend six weeks renaming folders while the pages nobody links to stay unlinked. Each layer owns different decisions and fails in a different way, and the failure column is the one worth memorizing.

Rows two and five are the expensive ones and row three is the one that gets fixed first, which is most of what is wrong with how this subject gets taught. Ugly URLs are visible in a screenshot. An unlinked commercial page is visible in an export nobody runs.

One more distinction, and it is the one beginners most often collapse. An SEO site map is a planning diagram: the pages that should exist and how they relate. An XML sitemap is a machine-readable list of URLs. They are not the same document, they are not produced by the same activity, and the second one is not evidence that you did the first. I have watched teams generate the XML file, believe the architecture work was done, and never draw the diagram that would have shown them the orphans. This site’s own build even prunes noindex URLs out of its sitemap, because eighteen category pages were being advertised in there while asking Google to ignore them.

Architecture belongs between deciding what would satisfy a searcher and deciding what to write, because it is the last step that can still say no cheaply.

Run the chain out. Keyword research gives you what people want. Search intent gives you what would satisfy them, as a page type with a count behind it. Architecture asks where that page belongs, what will link to it, and how important the site should treat it. Content then fills it in. Every step narrows, and the cost of reversing a decision goes up at every stage: deleting a row from a spreadsheet is free, deleting a published page costs a redirect and a small amount of trust.

The usual order is keyword research, then write, then technical SEO. That order has one structural flaw and it is fatal: the page and its place are decided by the same person at the same moment, which means the place is decided by whatever folder was convenient. Do it a hundred times and you have a redirect file. Mine has 47 rules in it.

And a caveat I would rather give you than have you discover: this is not the highest-impact step in the roadmap for most sites. Google says in its own starter guide, immediately after the site organization advice, that search engines will likely understand your pages as they are right now regardless of how the site is organized. That sentence is almost never quoted by anybody selling a restructure. It does not mean architecture is worthless. It means the gains are in discovery, prioritization and human navigation rather than in Google failing to comprehend you, and a restructure sold on comprehension is sold on the wrong thing.

The unit that becomes a URL is a need, and several clusters routinely share one. That sentence is the whole bridge between the previous lesson and this one, and getting it wrong is the most common way a keyword list turns into architecture debt.

Watch the failure happen. Six keywords come out of research. Six rows in a spreadsheet, six lines in a content calendar, six articles. Nobody decided that; the spreadsheet decided it, because a row looks like a page. Six weeks later there are six URLs, four of them answering the same question slightly differently, and Google is picking between them on evidence you did not choose.

The architectural version of the same six keywords looks like this instead:

SEO Tools                       Comparisons
│                               │
├── Keyword Research Tools      ├── Ahrefs Alternatives
├── Rank Tracking Tools         └── Ahrefs vs Semrush
├── Technical SEO Tools
└── Free SEO Tools

Same demand. Now it is a structure, and two decisions have been made that the spreadsheet could not make: that four of the six are slices of one taxonomy, and that the two comparisons are a different job and therefore a different parent. Neither decision came out of a volume column.

What arrives from step four is a page type with a count on it. "Tool, five of eight" is a usable input to this step. "Commercial" is not, and neither is a volume number, because neither tells you how many destinations the demand supports.

Four questions decide it, and a keyword tool will hand you a fifth for free in a column most people scroll past.

The rule is not one keyword, one page. It is one intent, one destination, and the difference is worth thousands of pounds a year to anybody publishing at volume. Two phrasings of one need share a page. Two needs that happen to share vocabulary do not.

The fifth test is the one nobody teaches, so here it is properly. Ahrefs computes a parent topic by taking the number one ranking page for your keyword and finding the keyword that sends that page the most traffic. So it is not a clustering heuristic invented by a tool. It is an observation about what currently wins, which makes it a direct answer to the question this chapter asks, published free, in a column next to the volume figure everybody reads instead.

Run it on the subject of this page and it makes my argument better than I can.

Eight phrasings, 8,550 searches a month, four parent topics. A volume-first process produces eight pages from that list and every one of them competes with three siblings. The parent topic column produced four destinations without being asked, and it took one request.

You are allowed to overrule it, and I do twice in the drill above. What you are not allowed to do is overrule it silently. A tool that observes what currently ranks cannot know that two vocabularies grew up around one idea a decade apart, which is exactly the case with "topic clusters" and "silos". Write the override down with the reason, and the next person who opens your map does not undo it.

Nothing is being punished. You built two destinations for one need, so your site cannot say which one it means, and Google decides on its own evidence rather than on your intentions.

The mechanism is canonicalization, not penalty. When several URLs answer the same need, Google picks one to represent the set, using signals it can see: internal links, external links, sitemap presence, redirects, content similarity. Your preference is one input among several and it is often the weakest one. So the page it picks is the page your architecture actually endorsed, which is frequently not the one you would have chosen.

Which makes this an architecture chapter rather than a technical one. The four fixes are all structural: merge into the strongest page and redirect, differentiate so each answers a genuinely different job, redirect the weaker one and stop, or reposition one of them onto a need you were not covering. Canonical tags are how you tell Google about the decision. They are not the decision.

This site prevents the case rather than fixing it, and it is the most useful thing in this chapter. Every depth page under a tool listing declares in its frontmatter the one query it exists for, and the build compares every claim across every collection at once. Two pages claiming the same query is a build error naming both owners, so it cannot ship. That is a twenty-line function and it has caught more cannibalization than any amount of editorial care would have at page fifty.

primaryQuery: "semrush pricing"     ← /seo-tools/semrush/pricing/
primaryQuery: "semrush pricing"     ← a new post
                                      build fails, both owners named

You do not need my stack to do this. A shared spreadsheet with one row per query and one owner per row does the same job, as long as somebody checks it before publishing rather than after. The mechanism that matters is that the check happens before the URL exists.

Search intent picks the page type before content picks a single word, and there are far more types than most content operations can produce.

This is the highest-cost mistake in the whole subject, and it hides behind a process that feels rigorous. Research produces a cluster. The cluster goes into a content calendar. The content calendar produces a brief. The brief produces an article. At no point does anybody ask whether the market wanted an article, and if it wanted a free tool or a category page or a comparison, no length of article gets into it. The previous lesson has the receipt for that: ten of ten results for "mortgage calculator" are calculators.

So here is the register. 29 types, grouped by what they are for, with the query shape that asks for each one.

The column that turns this from a taxonomy into a decision table is "wanted by". A query beginning "best" wants a ranked list with stated criteria. A query ending "checker" wants an input box. A query of the shape "X vs Y" wants two named things side by side, and a guide that mentions both is not the same object.

Nine of the 29 types have no example on this site, and I left that visible rather than filling the gaps with something plausible. It tells you what this site can currently produce, which is the same finding the exercise below will produce about yours.

The output of this step is a table, not a tree. Cluster, intent, page type, existing URL, parent, verb. The tree comes later and it is generated from the parent column.

Two columns do almost all the work and both get skipped. The existing URL column is asked for before the verb, which is the only thing that reliably stops somebody creating a page the site already has. And the verb column is what makes the document a plan: a row with no verb is research, and research does not get built.

Here is mine, from this site, with the rows that say no in it.

An invented example would have been tidier and would have taught you nothing, because the only interesting rows in a map like this are the ones where the answer is not "write it". Two of mine decline traffic on purpose. One merges a post I wrote. One redirects a pillar I spent weeks on. One deletes a lesson page I shipped four days earlier, which had zero organic keywords and zero traffic on the day I pulled it, and which was roadmap step four for exactly one day.

A note on the honest cost of "keyword mapping" being a chapter here rather than its own page. It has its own parent topic, difficulty 23, and a genuinely different deliverable from this page, which by my own rules in chapter five means it should be a separate URL. It is queued and not built, so this chapter is a deliberate interim answer, and saying that out loud is cheaper than pretending the decision was principled.

Five hundred clusters is not five hundred pages. A page now costs almost nothing to produce and the same as ever to maintain, which makes the filter worth more than it was two years ago.

Six questions. Any one of them can kill a row, and a map where none of them ever does is a map nobody applied a filter to.

1. Is there distinct demand? Not demand for the topic. Demand for this page, after the parent topic column has collapsed the phrasings. "Click depth" has sixty US searches a month and a traffic potential of ten, and it is chapter twenty-four here rather than a URL.
2. Is the intent meaningfully different from a page I have? If the job is the same job, this is an improvement to an existing page wearing a new URL.
3. Can I add something? Not "cover it thoroughly". Add. A number nobody has, a test nobody ran, a decision nobody published. If the honest answer is that you would be summarizing the current top three, the page is a retelling and retellings are what the results page already has too many of.
4. Does the business need it? The question no results page can answer. You can match an intent perfectly and gain nothing, and the pages where that happens are usually the ones with the best volume.
5. Do I already have something that satisfies it? Search your own site for the job rather than for the words. This is the question the existing URL column exists to force.
6. Will this create architecture debt? A page with no obvious parent, no obvious inbound link and no obvious next step is debt on the day it publishes. If you cannot name its parent and one page that will link to it, you are not ready to build it.

The sixth question is the one this era needs most. AI made the marginal page cheap to write and did not make it cheaper to maintain, link, route or eventually delete. A hundred pages generated in a week is a hundred parents to assign, a hundred routes to design, and eventually a hundred lines in a redirect file. The generation was the cheap part.

There is no universal tree. A local service business, a software product, a catalog and a curriculum are four different shapes, and the shape follows the business model rather than a best practice.

Semrush says as much: structure depends on site size, goals and users. That sentence is correct and it is usually the last line of the section, immediately before one pyramid diagram that assumes an ecommerce catalog. "It depends" is only useful advice if somebody tells you what it depends on, so here are four shapes with the load-bearing decision named in each.

The catalog shape is the one Google documents directly, and the chain is specific: links from menus to category pages, category to subcategory, and subcategory to every product you want indexed. It also says Googlebot generally does not submit searches into a search box while crawling, which is the sentence that quietly invalidates a lot of "you can find it by searching" architectures.

This site is the fourth shape, which is why the sequencing between lessons is the product rather than a nicety. A curriculum whose lessons do not know their own order is a blog.

One question decides whether a parent deserves to exist: if somebody lands on it, does having these children collected here help them finish something?

That test fails a surprising number of pillar pages, and it fails them for a specific reason. A page created because a framework says a topic needs a pillar has no job of its own, so nobody links to it voluntarily, so it accumulates no authority to pass down, so it becomes a table of contents with a URL. The children were fine. The parent was scaffolding.

A parent that passes the test is doing one of three things. It is orienting somebody who does not yet know what they need, like a roadmap. It is helping somebody choose between siblings, like a category or a directory. Or it is answering the head question while routing the specific ones, like a good guide. If your parent is doing none of those, its children should be siblings and the parent should be a nav item.

Now the part that is not transferable by explanation. Placement instinct comes from being wrong about a placement and hearing why, so here are eight pages and three of them have a tidy wrong answer.

The first two items are the whole chapter. "Best keyword research tools" and "how to do keyword research" share almost every word and belong in different sections, because one is somebody acquiring a skill and the other is somebody about to spend money. Group by job. Topic overlap is not job overlap, and a taxonomy built on topic overlap puts purchasing decisions inside curricula and wonders why they do not convert.

A taxonomy is the rule you use to decide where a new page goes. If you cannot write that rule down in a sentence, you do not have a taxonomy, you have a habit, and two people will apply it differently within a month.

Test it on your own site right now. Take two of your categories and write the rule that decides which one a new page belongs to. If the honest rule is "whichever feels more relevant", those are one category with two names, and the version of that failure I lived through is in the next chapter with a price on it.

The other failure is mixing classification axes inside one hierarchy. Topic, format, audience, industry, location and product are all legitimate ways to classify pages, and stacking three of them as though they were levels of one tree produces a structure nobody can navigate or extend. Under a "Blog" folder, "SEO" is a topic, "Marketing" is a discipline and "Guides" is a format. Three different kinds of thing pretending to be a hierarchy. One axis per level.

Here is the same twelve pages filed badly and filed well. Look at the left column first and try to name what is wrong before you read the list. There are five distinct problems and none of them is a spelling mistake.

Three of those five defects were on this domain in the week I wrote this page, which is why the left column is not a strawman. And notice what the rebuild does not do: it does not move a single working URL. It changes parents and links. That distinction is chapter twenty and it is the difference between a restructure and a migration.

Then the working example, which is this site with the arguable groupings argued rather than asserted. Any diagram looks obvious once drawn; the four questions underneath it are the part worth reading.

A hub earns its place by being somewhere useful to arrive, not by sitting above things. Three pages is a legitimate cluster and so is fifty, and any framework that arrives with the number already filled in has not looked at your demand.

The useful version of a hub is concrete. Take keyword research. A hub for it might route to a guide, a page on search volume, one on difficulty, one on long-tail queries, one on competitor research, one on clustering and one on tools. Seven children, and each one earns its URL because it has its own demand and its own answer. The hub earns its URL because somebody arriving on the head term needs to be shown the shape of the subject before they can pick.

The mythological version is a pillar page of four thousand words that mentions each subtopic in a paragraph and links to a full article about it, published because a framework said a topic needs a pillar. That page competes with its own children, gets linked to by nobody, and exists to satisfy a diagram.

My own site has the asymmetry that this argument predicts. One tool listing has eighteen depth pages under it. The other 101 have one between them. That looks like neglect and it is mostly correct: one tool has eighteen sub-queries with their own measurable demand and the rest do not, and forcing symmetry would produce a hundred thin pages that each need a parent, a route and eventually a redirect.

A topic cluster is a hub plus its spokes, treated as one unit. It is a good way to arrange pages. It is not a mechanism by which arranging pages produces authority.

The version that works is boring: the pages genuinely relate, each one answers something distinct, the hub routes to all of them and every spoke links back. Technical SEO with crawling, indexing, canonical tags, robots.txt and XML sitemaps under it is a real cluster, because a person working on any one of those five is plausibly about to need another.

The version that does not work is a hundred pages generated because a tool called them semantically related. Semantic adjacency is not the same as a reader needing both, and no number of adjacent URLs adds up to expertise. The claim that it does is graded inference on this page, which is chapter twenty-four.

The honest test for a cluster: could you write one sentence explaining why somebody reading spoke three might want spoke five? If yes, they are in the same cluster. If the only connection is that both contain the same noun, you have a keyword group rather than a cluster, and keyword groups do not deserve a parent page.

Architecture creates organization, not walls. A link between two sections that a reader genuinely needs is not a leak, and refusing it because the pages are in different folders is siloing turned into superstition.

Search Engine Land says this directly, and it is worth quoting because it comes from a guide that otherwise recommends silos: tightly isolating silos can backfire, because if related topics are not linked across categories, users miss out on helpful content and search engines may struggle to index orphaned pages. Two failures, one of them about humans and one about crawlers, from over-tightening the thing you were told to tighten.

The useful half of siloing is that a topic has a home, which means a reader knows where they are and a crawler can infer a grouping. The harmful half is treating the folder boundary as a rule about links. On this site, keyword research and search intent are separate lessons and they link to each other repeatedly, because you cannot read a results page without a cluster and you cannot brief a page without both.

The practical rule I use: a link is justified by a reader needing it, and by nothing else. Not by folder proximity, not by anchor text opportunity, and not by a related-posts algorithm. If you cannot write the sentence the link sits in, it is not a link, it is a widget.

Everything in your primary navigation appears on every page of your site, which makes it the most repeated statement your domain makes about what matters. Fifty links in a header says nothing is important.

The mechanism is the one from chapter one. Google infers relative importance partly from how many internal links point at a page, and a header link points at that page from every single URL you own. That is a lot, and the total is fixed: a twentieth item does not create a twentieth share of something new, it takes a twentieth share of what the other nineteen were getting. Which is why "put important things in the header" is not advice. Everybody thinks their thing is important. A budget is advice.

The tier most sites neglect is the fourth one, contextual links inside the content, and it is the only tier where the anchor text can be specific to the page it sits on. Leaving that tier to a plugin is how a site ends up with a considered header and a link graph nobody designed, which is precisely the state mine was in when I measured it.

Google indexes the mobile rendering. If your desktop menu links to twenty category pages and your mobile menu links to ten, ten of those links effectively do not exist.

The mechanism is unglamorous and total. Mobile-first indexing means the mobile version is the version Google crawls and evaluates. A link present only in a desktop-width menu is not a link Google has, so whatever crawl route and importance signal it was carrying is gone, and nothing in any report tells you, because both menus render fine to a human checking them one at a time.

The cause is nearly always the same, and it is an engineering cause rather than an SEO one: two hand-maintained lists. Somebody built a desktop nav component and a mobile nav component, each with its own array of links, and the two drifted. They always drift. This site had exactly that bug. There was a NAV_MOBILE array separate from NAV, it had already fallen out of step with the desktop panels, and the fix was to delete it and render both menus from one list. Now a link cannot exist in one menu and not the other, because there is only one menu described in one place.

If you take one thing from this chapter, take the check rather than the principle. Open your site’s source, find both menus, and count the anchors in each. If the numbers differ, you have found something worth more than the rest of this page.

Google states it can only crawl a link that is an anchor element with an href attribute. Everything else in your navigation is a route for humans only.

Its own documentation gives the bad examples, and they are the exact patterns a modern front end produces by default: an anchor carrying a framework routing attribute instead of an href, and an element with an onclick handler that navigates. Both work perfectly in a browser. Neither puts a URL into a crawler’s queue, which means the pages behind them enter the index only if something else happens to link to them.

crawlable    <a href="/technical-seo/">Technical SEO</a>

not          <a routerLink="/technical-seo/">Technical SEO</a>
not          <a onclick="goto('/technical-seo/')">Technical SEO</a>
not          <span data-href="/technical-seo/">Technical SEO</span>
not          a "load more" button that fetches the next twenty products

That last one is the expensive case, because it is where the products live. A category page that shows twenty items and loads the rest on click has, as far as a crawler is concerned, twenty products in it. The fix is not clever: paginate with real URLs, and let the button be an enhancement on top of links that already exist.

I am deliberately stopping here rather than going into JavaScript rendering, because that is technical SEO and it is a different lesson. The architectural point is narrow and worth having on its own: your structure is made of anchors in the HTML, so read the HTML.

Readable words, hyphens, no pointless parameters, one trailing-slash shape, and then stop. This is the shortest chapter on the page on purpose, because URLs are the layer people fix first and the one carrying the least structural weight.

What Google actually recommends is modest and worth following: readable words rather than long ID numbers, hyphens rather than underscores, and trimming parameters that do not change the content. It also warns that additive filtering, session identifiers and dynamic calendars create unnecessarily high numbers of URLs and can generate infinite spaces, which is a crawling problem rather than a naming one and belongs to chapter twenty-three.

The last two rules in that table are worth more than the first five and neither is about the words in the URL. Stop changing URLs that work, and map retired URLs one at a time. A bulk redirect of dead pages to your home page is treated as a soft 404, so the equity you were preserving is discarded and you have added a rule to your redirect file that does nothing except make the file harder to read.

One habit worth the five minutes: pick a trailing-slash shape and enforce it in the build rather than in a review. This site pins trailingSlash: 'always' in its Astro config, so the sitemap, the canonical tags and every internal link agree by construction. The alternative is a navigation whose every click goes through a redirect, which nobody notices and everybody pays for.

Conceptual hierarchy and URL hierarchy are separate things, and only one of them is expensive to change. This is the chapter that saves people from unnecessary migrations, and it follows directly from Google reading links rather than folders.

The situation is common enough to be predictable. You draw a curriculum, and the folder tree does not match it. Keyword research lives at /keyword-research/ and your diagram says it should be at /learn-seo/keyword-research/. The diagram is right about the relationship. It does not follow that the address has to carry it.

Navigation states the parent. Breadcrumbs state the parent. A contextual link from the hub states the parent. All three are things Google reads, and all three cost nothing. The URL is the one mechanism that costs a migration, and it is the one that Google says it does not use to work out your hierarchy.

This site does exactly that, and I would rather show you than tell you. The five roadmap lessons all live at the root: /seo-basics/, /seo-keyword-research/, /search-intent/, and this page. Their parent is /seo-roadmap/ and every one of them is a child of it in the navigation, in the breadcrumbs and in the links between them. Nothing about the addresses says so and nothing needs to.

When is a migration justified? When the URL actively misrepresents the page, when you are consolidating genuine duplicates, or when a folder has to exist for a technical reason like a different template or a different language. "So the folders match the nav" is not on that list. Google has a video specifically on whether URL structure changes affect SEO, and the honest summary is that every migration spends real risk to buy something, so the something had better not be tidiness.

Use a subfolder unless an engineering constraint forces a subdomain. I believe that, I would do it every time, and I am following practitioner consensus rather than evidence, which I would rather say than dress up.

Here are both sides properly. Google has said repeatedly, including in a video from its own channel on exactly this question, that it handles subdomains and subdirectories and that the choice should be made on operational grounds. Practitioners keep reporting real gains from moving a blog off a subdomain onto a path. Both of those things can be true, and the reason nobody has settled it is that almost every one of those migrations rebuilt the internal linking at the same time. Nobody has published a version with the linking held constant, so the variable is not isolated and everybody quoting either side as settled is overstating it.

The reasons I would still use a subfolder are ones I can defend without a ranking claim. Analytics is one property rather than two, so you can see a journey from a guide to a pricing page without stitching sessions. Internal linking between the blog and the commercial pages is unremarkable rather than cross-domain. And nobody has to have the conversation again in two years.

A subdomain is genuinely right for a separate application, where you do not want a marketing CMS and a product sharing a deployment, and for large user-generated platforms that behave like their own site. Those are engineering answers, which is what Google said in the first place.

The related habit worth more than either: stop putting every page at the root. Not because folders concentrate anything, but because a directory is a unit you can measure, audit and prune. Filter analytics to /seo-tools/ and you learn something about a section. A hundred pages at the root are a hundred pages.

A breadcrumb tells somebody where they are and lets them move up. Ahrefs says the rest plainly: it is not a replacement for your main navigation.

What they are genuinely good at is the case where somebody arrives from a search result three levels deep with no idea what the site around them is. A trail reading Home, SEO Tools, Semrush, Pricing does two useful things at once: it orients the reader, and it states a parent relationship in crawlable anchors on a page where the URL might not.

Home  ›  SEO Tools  ›  Semrush  ›  Pricing

Two failure modes worth naming. The first is a trail that disagrees with the navigation, which is worse than no trail because the site is now making two contradictory claims about where a page belongs. The second is treating breadcrumb markup as the architecture: the markup describes a hierarchy, it does not create one, and a beautiful trail on an orphan page is a page describing a parent that never links to it.

A page can legitimately have two parents, and Google has a short video on whether you can place multiple breadcrumbs on a page for exactly that case. It is a real architectural situation rather than a mistake, and it usually means you should pick a primary parent for the trail and express the second relationship as a contextual link.

Filters multiply. Three filters with five options each is a hundred and twenty-five URL combinations before anybody has sorted anything, and the architecture created that problem before technical SEO had a chance to contain it.

Google warns about this in its URL documentation in almost those words: additive filtering, irrelevant parameters such as session identifiers, and dynamic calendars can create unnecessarily high numbers of URLs, and in some cases an infinite space. Which is the architectural point, and it is the only part that belongs on this page. You are choosing, when you design a filter set, how large a URL space your site will generate.

/tools/?category=seo&price=free&platform=windows&sort=name
        ↑            ↑           ↑                ↑
        real slice   real slice  real slice       changes nothing

The decision to make here is which filter combinations correspond to a real need somebody searches for. "Free SEO tools" is a real need and deserves a real, linked, indexable URL. "Free SEO tools for Windows sorted by name descending" is not, and generating it as a crawlable link is volunteering your crawl budget for nothing.

Pagination is the same shape of problem with a different cause. Large categories need it, the pages need real URLs, and the architecture has to make sure the items stay discoverable without generating enormous depth. Chapter twenty-four has the example of what happens when pagination becomes the navigation.

Everything past this point is technical SEO: parameter handling, robots rules, canonical strategy, the PRG pattern. I am deliberately not covering it, and I would be suspicious of an architecture lesson that did, because the implementation follows the decision rather than replacing it. Google’s crawl budget guide is the reference, and read its opening line before you lean on it: it says it applies to sites with over a million pages, or over ten thousand pages changing daily. Almost nobody reading this is in either bracket, and citing it anyway is one of the ways this subject gets oversold.

Important pages should generally be easy to reach. That is the whole documented claim, and the version you have heard is a threshold that no Google document contains.

What Google actually says is about two quantities, not one: the number of links needed to reach a page, and the number of links pointing at it, both contribute to inferring that page’s relative importance within your site. A gradient, not a cliff, and it names inbound links alongside depth. Semrush recommends three clicks or fewer as a target, which is sensible advice and a different sentence from "anything deeper will not rank".

Four real paths from this site, and the fourth is why the threshold version is a distraction.

A page at depth two that nothing links to has perfect depth and no architecture. I have 97 of those. Depth measures the shortest route and says nothing about how many routes exist, which means the metric everybody optimizes is the weaker half of a claim nobody reads carefully.

Since this is the chapter where the evidence gets thin, here is every load-bearing claim on this page with a grade on it. Seven are documented and quoted. Four have no source at all, and those four are the ones you will hear stated most confidently.

Every internal link is your site asserting that a page is worth reading. Add them up and you have a ranked list of what your site thinks is important, and on most sites that list contradicts what the owner would say out loud.

The useful thing is that the contradiction is measurable in an afternoon. List your five most linked-to pages. Separately, list the five pages your business most needs to work. Compare. Whatever gap you find is not an opinion, it is what your site is currently claiming, and Google is reading the claim rather than your intentions.

Mine, from the audit in chapter one. The most linked-to page on this domain is a free technical SEO checklist with 28 inbound editorial links. Second is a Semrush pricing page with 22. Both of those are correct and I am glad about them. Then nothing commercial appears again for a long way down, and 118 of 122 money pages have no link from any post at all. Two out of five agreeing is not a disaster and it is not an architecture either.

The comparison that makes this vivid is a page’s route rather than its depth:

Home  →  SEO Tools  →  Semrush  →  Pricing          22 links in
Home  →  Blog  →  Archive  →  2019  →  page 14  →  a post     0

Both pages are reachable. Only one of them is being argued for. The second is a page the site has said nothing about except that it is old, and no amount of flattening the folder tree changes that.

An orphan page has no route in. A dead end has no route out. Google says every page you care about should have a link from at least one other page on your site, which is also the sentence that kills the idea that a sitemap entry is a fix.

The mechanism for orphans is the one from chapter one. Discovery runs on links, so a page nothing links to enters the index only if you asked for it directly, and it accrues no importance signal from anywhere because there is nothing pointing at it to signal with. It is not penalized. It is unargued for, which on a large site is functionally the same thing.

A sitemap does help discovery and you should have one. What it does not do is create a route, pass anything, or tell Google that a URL matters relative to your other URLs. My own build has a small object lesson in this: it strips noindex URLs out of the sitemap automatically, because eighteen category pages were being advertised in there while simultaneously asking Google to ignore them. Two contradictory signals, and a crawler resolves that by trusting neither fully.

Dead ends are the mirror image and they get almost no attention, because they cost you the reader rather than the crawler. A page with inbound links, a good answer and no useful next step is a page where somebody finishes and leaves. Architecture is not only "can this be found". It is also "can this person continue", and the second question is the one that decides whether a well-ranked page earns anything.

The check is one export and almost nobody runs it. Every crawler has an orphan or "no inbound internal links" report. Screaming Frog is free to 500 URLs. If you have nothing but Search Console, the indexing report plus a sitemap count gets you most of the way.

Discovery, relationship and importance. Any advice about internal linking that does not serve one of those three is decoration, and only one of the three has a documented lever.

Discovery. A crawlable link is how a URL enters the system. This is the job with no ambiguity and no debate, and it is why the orphan report matters more than any other architecture metric.

Relationship. Anchor text and the sentence around it tell both a reader and Google what the target page is about. Google documents this directly: anchor text helps people and Google understand what the linked page is about. "Click here" throws that away for nothing, on both audiences, forever.

Importance. More internal links to a page means higher relative importance within your site. Google's words, and note the word relative: it is about ordering your own pages, not about competing with somebody else's domain.

What I am deliberately not going to do is put a number on the third job. PageRank flow inside a site is real in direction and unpublished in magnitude, and every internal-link equity model in circulation is an inference dressed as arithmetic. The honest version: linking from a page that already gets traffic to a page that needs it is a sound bet, and you should measure the target page rather than the model.

Two practical notes that come straight from Google rather than from folklore. Do not nofollow your internal links; there is a video on it and the answer is short. And varying anchor text is fine and mostly about readability, because the question of whether repeated internal anchors hurt has also been answered on that channel and the answer is less dramatic than the advice built on top of it.

The rest, internal PageRank analysis, link opportunity automation, anchor distribution modelling, belongs to a dedicated internal linking lesson. Here you need the three jobs and the habit of routing one link deliberately, with the date written next to it.

Architecture gets exponentially more expensive to change after growth, and growth is exactly when people notice they need to change it.

Search Engine Land makes the point about designing taxonomy and navigation for future scaling, and Backlinko makes the complementary observation from the other end: complicated architectures usually emerge from sites adding categories, subdomains and pages over time rather than from one bad initial plan. Nobody designs a mess. It accretes, one convenient decision at a time.

So ask the questions at twenty pages that you will be forced to ask at two hundred. What is the rule for adding a category? What happens when a category has ninety children? Which filter combinations get a real URL? Who decides, and where is that decision written down?

The specific case worth planning for is programmatic. If you intend to publish ten thousand tool pages, fifty categories, a comparison matrix and an alternatives page per product, every one of those decisions has to exist before the generator runs, because a generator applies your taxonomy ten thousand times whether or not the taxonomy was any good. Architecture precedes programmatic SEO, and the order is not negotiable in the way most of this page's advice is.

My own version of learning this: /seo-tools/{tool}/ was the right call and I made it before there were a hundred listings, which is the only reason the section is coherent today. The part I got wrong was not planning how a listing earns depth pages, which is why one tool has eighteen and the rest have one, and why the routing problem in chapter one exists at all.

Look at competitor architecture after keyword research, the way Ahrefs recommends, and read it as evidence about a market rather than as a template. A competitor’s structure encodes their business model, and copying it means inheriting a business model you do not have.

What to look for: their categories, which commercial page types they bothered to build, where the hierarchy is deep and where it is flat, what is in their navigation, and which patterns repeat across many URLs. That last one is the most informative, because a repeated pattern is a decision somebody made deliberately at scale.

And now the demonstration, because I made exactly this call about this page and the evidence is worth showing at full size. Two results pages. One is the query this page targets. The other has fifteen times the volume at lower difficulty, and I declined it.

Four of the eight results on the bigger query belong to design software, sitemap software and website builders, and its AI Overview cites Figma, MDN and a sitemap tool with no SEO source at all. The titles on the two results pages are nearly interchangeable. The publishers are not, and the publisher column is where the audience lives. Copying that architecture as an SEO consultant would mean copying somebody else’s product.

The finding I did not expect is the one that makes chapter five real. Not one of the eight pages ranking for "seo site architecture" was built for that phrasing. Every single one has a different phrasing as its own top keyword, 6 distinct ones between them, and position eight is a page whose top keyword is Moz’s own product name. Eight pages, eight different primary targets, all collecting the same need. The market has already made the one-page-per-need decision and none of those eight built the extra pages.

Do not build a second architecture for AI. Build one clear information system, and be honest that the case for it is clarity rather than a measured retrieval effect.

Here is what is actually true and useful. A well-organized site states relationships: product has feature, product integrates with X, product serves job Y, this person wrote that page, this case study proves that service. Those relationships are asserted by having both pages and a link between them, which is the same mechanism as the rest of this lesson. A buyer comparing two products needs exactly that information and most sites make them assemble it from a features page and a pricing table.

What I will not claim is that this makes you more likely to be cited. Search Engine Land now frames a clear hierarchy and consistent signals as making topical expertise easier for people, algorithms and LLMs to interpret, which is a reasonable claim about clarity and not a retrieval finding. This page grades it as inference and it stays inference until somebody isolates the variable, which nobody outside a lab can.

And there is one measurement on this page that argues against the simple version. On the query this page targets, the AI Overview cited 6 sources and only 3 of them were in the visible top ten. Whatever is happening inside that box is not a straightforward function of your folder tree, and anybody selling you an "AI-ready architecture" should be asked what they measured.

The practical conclusion is boring and I stand behind it. Build one information system that humans, crawlers and retrieval systems can all follow, because you would have wanted it for the humans anyway and building it twice is how a good idea becomes a budget line.

Architecture debt is what accrues when pages get published without anybody deciding where they belong. It compounds quietly, it is invisible in any report that counts pages rather than links, and it comes due as a redirect file.

Nobody designs a bad architecture. The mechanism is always the same: a page does not fit an existing category, so somebody makes a new one, and the new one has no rule attached. Do that eight times over four years and you have eight categories, no rules, and every new page is a coin toss.

Here is my bill, from the file in this repository, dated.

Nine of the 47 rules retire one category, /seo-guides/, which existed for four years and could never answer the question "what goes in this one and not the other one". The blog category enum went from 5 values to 2 in three days. That correction was not a project. It was writing down, once, what each of the two survivors means.

The reassuring half: this is normal, and the fix is a habit rather than a rebuild. Before publishing anything, name its parent and one page that will link to it. That is the whole habit. Sites that do it accumulate structure. Sites that do not accumulate a redirect file, and I have both a redirect file and the habit now, in that order.

Twelve claims I have been told about this subject, four of them with no source anywhere, and those four are the ones stated with the most confidence.

Sixteen questions. Six of them quote a sentence Google published, four are answered by measurements of this site, and none of them is a definition you could have looked up.