Growth Notes

URL Structure

Tags: web-dev concept

URL Structure

Date: 2026-08-16

Design it once. A URL is a permanent public interface — every link, bookmark, ad, email and analytics record points at it — so changing one is a migration, and changing thousands is the most destructive routine event in ecommerce.

What it is

URL structure is the scheme by which content is addressed: path hierarchy, naming conventions, parameter handling, and what varies.

The reason it deserves architectural attention is that it’s the one part of your system other people depend on and you can’t update. You can refactor a database schema. You cannot refactor someone’s bookmark.

Principles

  • Lowercase, hyphen-separated, no trailing punctuation. /collections/merino-wool-socks
  • Readable. A URL is shown in results, shared in messages, and read aloud. /p/4471-b tells nobody anything
  • Stable identifiers over mutable ones. A slug derived from a product title changes when merchandising renames the product. Either accept redirects as routine, or include a stable ID: /product/4471-merino-wool-socks, where the ID is authoritative and the slug is decoration
  • Shallow. Depth doesn’t carry meaning for a crawler and long paths are fragile. Three segments is plenty
  • No parameters where a path will do for anything indexable
  • One canonical path per item, decided up front — see below

The ecommerce decision

The recurring one: should a product live under its category?

A   /products/merino-wool-socks
      one URL per product, categories are separate listings

B   /collections/socks/products/merino-wool-socks
      /collections/wool/products/merino-wool-socks
      the same product at multiple URLs

Option A is almost always right. Option B produces duplicate content by construction, requires canonical tags on every variant, splits link equity across paths, and breaks the moment merchandising re-categorises anything.

If the platform forces B — several do — then pick one canonical path, declare it consistently, and make sure internal links use it. See Canonicalisation.

The same question for variants: a colour or size should not usually be its own URL unless someone would plausibly search for it specifically. Use parameters or client-side state, and canonicalise to the parent product.

Parameters

/collections/socks?sort=price-asc          sorting — no unique content
/collections/socks?page=2                  pagination — real, distinct content
/collections/socks?colour=charcoal         filtering — sometimes worth indexing
/collections/socks?utm_source=email        tracking — never indexable

Rules that hold:

  • Tracking parameters must never create indexable URLs. Canonicalise them away and strip them from the CDN cache key, or hit rate collapses — CDN Caching
  • Sort parameters produce identical content in a different order. Canonical to the unparameterised URL
  • Filters are a judgement call — a genuinely searched-for combination may deserve indexing; the other ten thousand do not. See Faceted Navigation and Crawl Budget
  • Keep parameter order and casing consistent, or you generate variants of variants

Other decisions to settle early

  • Trailing slash or not. Pick one, redirect the other. Both serving 200 is duplicate content
  • www or apex. Same — one canonical, the other redirects
  • HTTPS only, with HTTP redirecting once, not through a chain
  • Case sensitivity. Paths are technically case-sensitive; force lowercase and redirect
  • Internationalisation. Subdirectory (/en-gb/), subdomain, or country domain — a decision that’s very hard to reverse and interacts with hreflang

When you must change them

Sometimes unavoidable — a replatform, a restructure, a rebrand.

  • Map every old URL to its closest new equivalent. Not to the homepage; a blanket redirect to the homepage is treated as a soft 404 and loses everything
  • 301, not 302. Permanent, single hop, no chains
  • Keep redirects indefinitely. They’re cheap; the links pointing at them are not
  • Redirect before launch, not after someone notices traffic fell
  • Expect a dip regardless. Even a perfect migration loses some, temporarily

See Redirects and Link Equity and Site Migrations and SEO.

Beyond SEO

URL structure also decides:

  • Cache granularity. What can be cached and purged independently — CDN Caching
  • Analytics grouping. A sane path structure means page groups fall out for free; a flat structure means regex forever — Event Taxonomy Design
  • Access control boundaries. /account/* is a natural rule; scattered paths aren’t
  • Routing complexity. Deeply nested optional segments are where routing bugs live

Graph View

Backlinks