Site Architecture for SEO: How to Plan, Audit and Repair Your Site Structure Step by Step

Site architecture for SEO is the structure that decides which pages exist, how they are grouped into topics, what their URLs look like and which pages link to which. It is the map that lets a visitor move from a broad page to a specific one and lets a crawler discover every page that deserves to be found.

Google's SEO Starter Guide treats this as ordinary hygiene rather than a ranking lever: search engines will generally understand your pages however the site is organised, but a logical structure helps people and lets Google learn how often different sections change. That framing is useful. You are not arranging pages to please an algorithm; you are removing the ways a good page can go unfound or be confused with another.

In practice a structure has to answer three questions for every page. Can a crawler reach it through ordinary links? Is it the only address for that content, or one of several? Does its position tell a reader and a search engine what it belongs to? When the answer to any of them is no, the page underperforms for reasons no amount of copy editing will fix. Architecture is the part of SEO you can often repair once and benefit from for years, which makes it worth doing before a content push rather than after.

Neither shape wins on its own. A flat structure keeps important pages a few clicks from the home page, which suits small sites and keeps everything close to the pages that attract links. A deep structure nests pages inside categories and subcategories, which suits large catalogues where a single level would be an unreadable list. The right depth is whatever lets a person reach a specific page without guessing.

The documentation we reviewed does not name a maximum click depth, and any rule such as three clicks is a heuristic rather than a Google requirement. Use depth as a diagnostic instead. If a page that matters commercially sits six clicks down behind a filter, that is worth fixing. If a long-tail archive page sits six clicks down, it probably does not matter. Importance should decide proximity.

A hub is a page that sits above a group of related pages, introduces the topic and links to each of them, and is linked back to by them. For a services firm that is usually one page per service area with its supporting guides, case material and questions beneath it. The URL path can mirror that grouping, so the address reads as the hierarchy: the service area, then the specific page.

Google's URL guidance is plain about the mechanics. Use readable words rather than long ID numbers, separate words with hyphens instead of underscores, use as few parameters as you can, and keep a consistent case, because URLs are case sensitive and /Apple and /apple are treated as different addresses. The Starter Guide adds that keywords in a domain name or path have hardly any ranking effect beyond appearing in breadcrumbs. So choose URLs for readability and stability. Renaming paths later creates redirects and risk, which is a strong argument for deciding the pattern once.

The common failure is the thin hub: a page that lists its children as bare titles and says nothing. It passes readers along but gives them no reason to land there. A useful hub explains the topic in a few paragraphs, says who each child page is for, and links to the ones a newcomer should read first. If you cannot write that page, you probably do not yet have a topic, only a pile of posts, and merging some of them may be the better fix.

The structure only exists for crawlers if it is expressed in links. Google states that it can generally follow a link only when it is an anchor element with an href attribute, so links built some other way, such as script click handlers, may not be crawled. Navigation built from buttons or click handlers can look perfect in a browser and hide whole sections from a crawler. Test with the rendered HTML rather than the screen.

Anchor text carries meaning too. Google's guidance asks for descriptive, reasonably concise link text, and warns that generic phrases like read more tell neither readers nor crawlers what is on the other side. A practical test is to read only the anchor text out of context and ask whether it still identifies the destination. Navigation should list your main hubs; contextual links inside body copy should connect sibling pages and point upward to their hub; the footer is for utility pages, not for a second copy of the whole site.

Navigation on a phone is the practical constraint. A menu that fits twelve items on a wide screen collapses into a drawer on mobile, and visitors rarely open every branch. That is an argument for a short top level of perhaps five or six hubs, with the second tier reached from the hub page itself. It also means a page that appears only in a mega-menu has a single fragile route to it; give every important page at least one contextual link from related copy as well.

Filters create a new URL for each combination of options, and the number of combinations grows far faster than the number of products or articles. Google's documentation describes the consequences as overcrawling of near-useless URLs and slower discovery of new, useful pages. Its first recommendation is to block crawling of filter URLs with robots.txt when you do not need them indexed.

When a filtered view deserves to rank, such as a category plus one popular attribute that people actually search for, make it a deliberate page with its own heading and copy and a clean URL. Google lists conditions for such URLs: use the standard ampersand to separate parameters, keep path-based filters in one fixed order with no duplicates, and return a real 404 status for combinations that have no results rather than redirecting to a generic error page. Canonical tags and nofollow attributes are described as generally less effective in the long term than blocking crawling. This section does not apply to a site with no filters, and a small services site can safely skip it.

Plan on paper before touching the CMS. List the topics buyers ask about, sort them into three to seven groups, name the page that will act as the hub for each, and mark every page as revenue, support or utility. Then draw the links: each supporting page links up to its hub and across to one or two siblings, and each hub is reachable from the main navigation. A page you cannot place is either a candidate for merging into another page or a sign the topic has no home yet.

To audit an existing site, crawl it with a desktop crawler and export three lists: pages by click depth from the home page, pages that receive no internal links, and URLs with parameters. Compare the crawl against your sitemap and against Search Console's page indexing report. Pages in the sitemap but absent from the crawl are orphans; pages deep in the crawl that matter commercially need a link from a hub. Google's crawl budget guide is explicit that it is aimed at sites of roughly a million pages, or ten thousand with daily changes. If you are far below that, treat discovery and duplicate paths as the issue rather than budget.

An illustrative example: a consultancy with 40 pages finds its four service pages are linked only from a drop-down that fails when script is blocked, and three of its guides are reachable only from the blog archive. The repair is plain. Make the service links standard anchors, give each service a short hub section listing its guides, and add a link from each guide up to its service. No new content is needed.