Site Architecture and URL Structure for SEO

What Google Says Structure Does

The SEO Starter Guide gives three reasons to organize a site deliberately:

• Relationships. A logical organization “can help search engines and users understand how your pages relate to the rest of your site.”
• Crawl patterns on larger sites. “If you have more than a few thousand URLs on your site, how you organize your content may have effects on how Google crawls and indexes your site.” Grouping similar topics in directories “can help Google learn how often the URLs in individual directories change”, so a rarely changing /policies/ folder and a frequently changing /promotions/ folder can be crawled at different frequencies.
• Readers. Parts of the URL can appear in results as breadcrumbs, “so users can also use the URLs to understand whether a result will be useful for them.”

It also warns against overreacting, telling site owners not to “drop everything and start reorganizing” and noting that the suggestions “can be helpful long term (especially if you’re working on a larger website)”. For a small site that already links its pages sensibly, a restructure can cost more than it returns.

Links are what make the structure real. Google’s link documentation says: “Generally, Google can only crawl your link if it’s an <a> HTML element (also known as anchor element) with an href attribute.” A menu built from click handlers without href values is a structure readers can use and Google may not follow.

URL Rules From Google’s Documentation

Google’s URL structure best practices cover what to do and what to avoid:

Rule	Google's guidance	Example
Descriptive words	"use readable words rather than long ID numbers in your URLs"	<!–INLINECODE4–>, not <!–INLINECODE5–>
Audience's language	"Use words in your audience's language in the URL"	German words for a German audience
Hyphens	Google recommends "using hyphens ( – ) instead of underscores ( _ ) to separate words"	<!–INLINECODE6–>
Few parameters	Trim "parameters that don't change the content"	Drop session IDs from links
One case	Google treats <!–INLINECODE7–> and <!–INLINECODE8–> "as distinct URLs with their own content"	Lowercase everything
Standard parameter encoding	<!–INLINECODE9–> between key and value, <!–INLINECODE10–> between parameters	<!–INLINECODE11–>
No fragments for content	Google "generally doesn't support URL fragments"	Use the History API for JavaScript views
Percent encoding	Non-ASCII characters "should be percent encoded" in links	<!–INLINECODE12–>

The same page explains the risk of parameter sprawl: overly complex URLs “can cause problems for crawlers by creating unnecessarily high numbers of URLs that point to identical or similar content on your site.” When that happens, Googlebot may use more bandwidth than needed, or Google “may be unable to completely index all the content on your site.”

Length is not on Google’s list. Short URLs are easier to read, share and keep stable, which is reason enough to prefer them; Google’s guidance sets no character limit to aim for.

Choosing a Structure

Three patterns are worth knowing, and the choice follows how the content relates, not a preferred theory:

• Flat. Every page linked from the main navigation. It suits a site with a handful of services and pages, and becomes unusable once the menu can’t list everything.
• Hierarchical. Categories and subcategories, mirrored in folders such as /camping/tents/. It suits catalogs and large reference sites, and it is where Google’s point about directories and crawl frequency applies.
• Hub and spoke. A hub page covers a topic broadly and links to detailed pages that link back. It suits content sites with clusters of related questions; building them is covered in pillar pages and topic clusters.

Larger sites combine them, for example product categories as a hierarchy with guide clusters inside each category. Test any structure against one question: can a reader who lands on the homepage reach each important page by following links that make sense, without using site search?

Click Depth as a Check, Not a Rule

Click depth is the number of links between the homepage and a page. Google doesn’t publish a depth limit, so treat depth as a diagnostic: if an important page sits many clicks down, or can only be reached through paginated archives, it is probably also weakly linked from the rest of the site.

Google’s own description of discovery explains why links matter here. Its guide to how Search works says some pages are discovered “when Google extracts a link from a known page to a new page”, giving the example of a category page that links to a new blog post. A page that is linked only from deep archive pages depends on those archive pages being crawled. Reducing depth is a linking task:

• Link important pages from the homepage, category pages or hubs that Google already crawls.
• Give category pages direct links to their best content, not only paginated lists.
• Add related-content links across sections where readers would want them.
• Keep paginated series crawlable with plain links, as described in pagination and infinite scroll.

How internal links carry pages up and across the structure is covered in internal linking strategy, and listing important URLs in the sitemap supports discovery as described in XML sitemaps.

Navigation, Breadcrumbs and Footers

The header menu is linked from every page that carries it, so it should hold the categories readers actually need. A mega menu with hundreds of links tells neither readers nor search engines which pages matter; keep it to sections a reader would choose between.

Breadcrumbs show where a page sits and give it links up the hierarchy. Mark them up with BreadcrumbList as covered in BreadcrumbList schema, and set expectations correctly: on January 22, 2025, Google updated its breadcrumb documentation “to state that they only appear on desktop search results, not mobile.” The markup is still worth adding for desktop results and for the navigation itself.

Footers are for links readers look for at the bottom of a page: contact, policies, key sections. A footer stuffed with keyword-anchored links to location or service pages helps no reader, and keyword stuffing is, in the Starter Guide’s words, “against Google’s spam policies.”

Faceted Navigation

Filters for size, color, price and sort order can generate URLs in very large numbers. Google’s faceted navigation guide describes the cost: crawlers access “a very large number of faceted navigation URLs” before determining they are useless, which leaves less time for new, useful URLs. It offers two paths:

• “If you don’t need the faceted navigation URLs potentially indexed, prevent crawling of these URLs”, with robots.txt rules or by putting filters in URL fragments.
• “If you need the faceted navigation URLs potentially indexed,” follow its best practices for those URLs.

Google adds that rel="canonical" and rel="nofollow" are “generally less effective in the long term” for this purpose than the first two methods. Which filter combinations deserve indexing is a separate decision, covered in faceted navigation SEO.

Subdomain or Subdirectory

Google’s Starter Guide addresses this directly: “From a business point of view, do whatever makes sense for your business. For example, it might be easier to manage the site if it’s segmented by subdirectories, but other times it might make sense to partition topics into subdomains, depending on your site’s topic or industry.”

So decide on operational grounds:

• Subdirectory (example.com/blog/) when the content is part of the same site, runs on the same platform and is managed by the same team.
• Subdomain (blog.example.com) when it runs on a different system, belongs to a separate product or brand, or hosts content you want administered separately.

Whichever you choose, link the sections to each other where readers need it, and avoid moving between them without a reason, because the move itself is the risky part.

URLs That Survive Change

Every URL change needs a redirect and creates a chance to lose a page’s signals through a missing, chained or misdirected redirect. Plan URLs that won’t need to change:

• Leave dates out of URLs unless the date is part of what the page is, such as an annual report.
• Use stable category words. A folder named after a campaign, a price tier or a product line you might rename will need redirects later.
• Add depth only when the content needs it. /services/roof-repair/ can gain a /services/roof-repair/storm-damage/ child later without changing the parent.
• Keep one form of each URL: one protocol, one host, one trailing-slash rule, one case. Redirect the others, and support it with canonicals as covered in canonical tags.

Changing the Architecture

When a restructure is necessary, Google’s guide to site moves with URL changes sets out the order:

1. Map every old URL to a new one. Google: “Don’t redirect many old URLs to one irrelevant single URL destination, such as the home page of the new site. This can confuse users and might be treated as a soft 404 error.” Consolidated content can redirect to the consolidated page.
2. Use server-side permanent redirects. Google recommends them, with client-side redirects only “as a last resort.” Status codes are covered in HTTP status codes.
3. Update the new site. Change internal links to the new URLs, update canonical and other annotations, and prepare a sitemap of the new URLs.
4. Keep the redirects. Google says to keep them “for as long as possible, generally at least 1 year”, because that timeframe “allows Google to transfer all signals to the new URLs”.
5. Expect a transition. Google: “for medium-sized websites, it can take a few weeks or more for Google to gradually start showing the new URLs instead of the old ones (and for larger sites, even longer).”

After the switch, watch the Page indexing report for new 404s and the redirects for chains, as described in redirect chains and loops. A protocol change follows the same steps; see HTTPS migration.

Before restructuring, apply the homepage test to the site you have: if a reader can already reach each important page through sensible links without site search, add the missing links instead of moving URLs, since every moved URL needs a redirect that Google says to keep for as long as possible, generally at least a year.