URL structure you can maintain for ten years

Start with what stays constant

URL structure decisions ripple forward. A good pattern survives three redesigns, two CMS migrations, and the departure of whoever thought categorizing by year was clever.

Identify what remains stable in your organization. Product lines change slowly. Service categories endure. Geographic coverage rarely shifts overnight. Build your URL hierarchy around these anchors.

Avoid dating mechanisms in paths. `/blog/2024/01/post-title` creates maintenance debt. When you redesign, those date folders become archaeological layers. Use `/writing/post-title` or `/updates/post-title` instead.

Two or three levels, maximum

Deep hierarchies break. `/services/consulting/digital/strategy/workshops` suggests organization that probably doesn't match how users think or how your business actually operates.

Target structure:

• Top level: major content type (`/services`, `/products`, `/writing`)
• Second level: specific item or logical subdivision
• Third level: only when absolutely necessary

Each level should represent a meaningful boundary, not just a filing preference.

Slug conventions that scale

Pick a slug format and enforce it everywhere. Mixing conventions creates confusion during content audits and migration.

Standard approach:

• Lowercase only
• Hyphens between words, never underscores
• No articles (a, an, the) unless critical to meaning
• No stop words (of, for, with) when removable without confusion
• Keep under 60 characters when possible

Document this. Put it in your CMS documentation. Make it part of publishing checklists.

Handle special cases consistently

Decide now how you'll treat:

**Version numbers**: `/product-name` with versions handled via parameters or subdomains, not `/product-name-v2` in URLs.

**Locations**: If you serve multiple regions, use subdomains (`london.example.com`) or subdirectories (`/uk/`) consistently. Don't mix approaches.

**Temporary content**: Campaigns, seasonal offers, event pages — give these a dedicated top-level container like `/campaigns/` so they're easy to archive or redirect in bulk later.

**File downloads**: Keep PDFs and resources under `/resources/` or `/downloads/`, not scattered through content folders.

Plan for redirects from day one

Maintain a simple redirect map from the start. When you change a URL, document the old path and new destination immediately.

Spreadsheet format: ``` Old URL | New URL | Date Changed | Reason ```

This pays off during migrations and makes redirect rules straightforward to implement. Most CMS platforms and static site generators can consume this format directly.

Test against real scenarios

Before committing to a URL structure:

1. Map 20 actual or planned pages to your proposed pattern
2. Simulate adding a new content type or service line
3. Check if logical groupings remain clear when you have 200 pages instead of 20
4. Verify your CMS can enforce the structure without manual vigilance

If the pattern feels awkward at 20 pages, it becomes unmanageable at scale.

Keep parameters minimal

Query parameters (`?sort=date&filter=topic`) serve functional purposes — sorting, filtering, tracking. They don't belong in canonical URL structure.

Core content should have clean paths. Parameters handle state and options.

Exception: Search results and filtered views. These earn their parameters because they represent dynamic queries, not persistent content.

Document the system

Write down your URL structure rules. Include:

• Top-level categories and their purposes
• Slug formatting standards
• How to handle special cases
• When redirects are required
• Who approves exceptions

This document prevents drift. New team members follow existing patterns instead of inventing their own.

When to break your own rules

Sometimes a URL needs to violate pattern for good reason — brand recognition, established external links, legal requirements. These exceptions must be explicit decisions, documented in your URL rules.

Never break pattern quietly. Each exception sets precedent.