B2B Website Architecture

Three different things called structure

Arguments about site structure go wrong because three separate things share the word.

• Information architecture is how content is grouped, labelled, and related — the conceptual model of what exists and what belongs with what.
• Navigation is the subset of that model exposed as menus, hubs, breadcrumbs, and in-page links. It is a presentation of the architecture, not the architecture itself, and can change without restructuring anything.
• URL structure is the set of addresses. To a person it signals hierarchy; to a crawler each URL is a distinct address that resolves, redirects, or does not.

These can be fixed independently. A site with a sound model and terrible menus needs a navigation project. A site with sensible URLs and no conceptual model needs content work, not a migration. A site whose URLs encode a defunct divisional structure can usually be left alone; reorganising addresses is the most expensive of the three. Google documents that simple, readable URLs help users; it does not document directory depth as a ranking mechanism, and rebuilding URLs in pursuit of one is a costly mistake.

Organise by what buyers search for, and the duplication the matrix creates

The default architecture of a corporate site mirrors the company: divisions at the top, product families beneath, individual products below. It is easy to approve and it fails, because buyers do not search by your divisional structure. They search for a problem, an application, a specification, or a competitor's product name.

The reframe is to build entrance pages around buying situations and keep the catalogue behind them. A sensor manufacturer has product pages by part number, which serve people who already know the part number, and needs application pages — the process being monitored — for everyone else. Gartner's model describes six buying jobs, from problem identification through consensus creation, with buyers looping back rather than progressing; nobody in problem identification searches for your part number.

The complication in B2B is the matrix: several product lines, several industries, several regions, several languages, and often acquired companies merged in badly. What it multiplies is near-duplicate pages — two divisions publishing near-identical pages for overlapping products and competing for the same queries, country sites repeating the same English text at a dozen addresses, datasheet PDFs ranking instead of the pages they duplicate.

• One page per concept. If two pages would answer the same query, they are one page with better content.
• Every variant needs a reason a buyer would recognise — different price, availability, regulation, certification, or language.
• Regional and language variants belong in hreflang clusters, each carrying a self-referential canonical pointing at itself rather than at the primary-language version. A canonical pointing across languages defeats the cluster, and Google documents that it prefers URLs in hreflang clusters when selecting a canonical.

Crawl depth, orphans, and internal links as a priority signal

Internal linking is the clearest statement a site can make about its own priorities, and unlike external links it is entirely under your control. Pages nothing links to have been declared irrelevant, whatever the strategy deck says.

• Excessive click depth. Pages reachable only after five or six clicks from an entrance are crawled less often and found by people less reliably.
• Orphan pages. Pages with no internal links pointing at them, present only in a sitemap. Google documents sitemap inclusion as a weak canonicalisation signal — it is not a substitute for being linked.

Auditing this is mechanical. Crawl the site with a tool such as Screaming Frog or Sitebulb, then compare four lists: URLs found by crawling, URLs in your sitemaps, URLs Search Console reports as indexed, and pages GA4 records as landing pages. The gaps between those lists are your architecture defects. Then add links deliberately — contextual links from related pages, hubs that gather a topic, and breadcrumbs reflecting the real hierarchy.

Faceted navigation, parameters, and pagination

Faceted navigation — filtering a catalogue by attribute — is where large B2B sites generate URLs faster than anyone can manage them. Five facets with a handful of values each produce thousands of combinations, nearly all crawlable if you link to them.

The decision is which combinations deserve to be indexable. The defensible answer is those with real search demand: often a single facet, sometimes a pair such as material plus size. Everything else should stay reachable by a person and unattractive to a crawler. Note the limit of robots.txt: it prevents crawling, not indexing of a URL discovered elsewhere, so a disallowed URL that other sites link to can still appear in results. Where exclusion must be certain, use noindex on a crawlable URL.

Keep parameter order consistent, strip tracking parameters from internal links, and do not let sort order create a new indexable page. Pagination is simpler than its reputation: keep paginated pages crawlable through ordinary links, give each content that differs, and do not rely on rel=next and rel=prev, which Google has said it no longer uses as an indexing signal.

Subdomains versus subfolders: what is actually known

The strong claims on both sides of this argument outrun the evidence. Google's public position has been that it can handle either arrangement; practitioners widely report better results after moving content from a subdomain into a subfolder, but those reports are observational, usually confounded by the redesign that accompanied the move, and never properly controlled.

What is documented, and does have consequences, is more mundane — and it favours subfolders in most cases.

• Search Console properties differ. A domain property covers subdomains; a URL-prefix property does not, which is how a blog's performance goes unnoticed for two years.
• robots.txt is per host. A subdomain needs its own file and configuration.
• The Change of Address tool does not move subdomains, including www variants — relevant the day you consolidate.

Most subdomains exist because a hosted platform — a help centre, a documentation tool, a careers system — cannot be reverse-proxied into a path. That is a legitimate constraint. Choosing a subdomain when a subfolder was available rarely is.

Canonicals are a hint, and what to use when you need certainty

Google's canonicalisation documentation states that "indicating a canonical preference is a hint, not a rule" and that "Google may choose a different page as canonical than you do, for various reasons." A canonical tag is a request, and it is regularly declined.

The documented factors in canonical selection are whether the page is served over HTTP or HTTPS, redirects, presence of the URL in a sitemap, and rel=canonical annotations.

Where the outcome must be deterministic, use a redirect rather than a canonical tag; where a page must be excluded, use noindex. And never combine noindex with a rel=canonical pointing at the page you want kept — the signals conflict and the result is unpredictable.

Planning architecture before a migration, not after

Most catastrophic traffic losses are migrations where URL mapping was left to the final week. Architecture work belongs before the build.

1. Inventory every URL that exists — from a crawl, sitemaps, server logs, Search Console, analytics, and backlink data, since logs and backlinks catch what a crawl misses.
2. Map old to new, one row per URL, each with a destination or an explicit decision to let it go, then build and test the redirects before launch against the full list, checking for chains and loops.
3. Use the right status codes. Google classifies 301 and 308 as permanent — the target is shown in results and the redirect is a strong canonicalisation signal — and 302, 303, and 307 as temporary, with the source shown.
4. Leave redirects in place for at least a year. Google documents that duration as what allows signals to transfer, including reassigning links from other sites.
5. Use the Change of Address tool for domain moves. It needs both domain properties in one account and the redirects already live, covers all paths and both protocols but not subdomains including www variants, maintains the relationship for 180 days, and cannot be used for HTTP to HTTPS or www to non-www on the same domain.

Google's redirects documentation does not discuss PageRank or link equity at all. One honest exception: if your site is thirty pages and one product line, an afternoon with a sheet of paper is the whole project.

Frequently Asked Questions