← Back to work
Case study

Search and information architecture

Designing one customer-led model for a catalogue's navigation, search visibility and permanent URLs, and a plan to migrate to it safely.

The situation

A large catalogue had grown over many years. Categories, landing pages and campaign routes were added as commercial needs came up, with no model governing the site as a whole. The content management system wrote the catalogue hierarchy straight into the URLs, so pages inherited every layer of classification above them:

/services/consulting/operations/process-automation/

What was missing

Navigation, search visibility, content hierarchy and URLs had grown up as separate concerns, with no single model tying them together. The site reflected how the business classified its range, not how customers searched for it. Similar needs were spread across several pages that competed for the same searches, while other needs had no page at all.

Because URLs mirrored internal placement, reorganising a category changed the address of every page beneath it, even though the pages themselves hadn't changed. The information model, the navigation and the permanent addresses were tied too closely together.

My role

I reviewed the catalogue as one connected information system rather than page by page: the language customers searched with, the intent behind each page, pages competing for the same searches, gaps with no destination, unnecessary levels in the hierarchy, and URLs inheriting the full path. From that I designed a revised information architecture and the principles for a wider URL migration, separating the customer experience from the technical legacy that had been shaping it.

What got written down

One model, with rules for applying it. Each meaningful customer intent gets one authoritative page. Overlapping pages are consolidated, gaps get a defined destination, and names, headings, labels and URLs all use the same customer language. Addresses become flatter and stable, so /services/consulting/operations/process-automation/ becomes /process-automation/, or /services/process-automation/ where the grouping genuinely means something.

Alongside it went a migration plan, because changing established URLs badly can damage the visibility it's meant to improve: a full URL inventory, a one-to-one redirect map, permanent redirects, updated internal links and canonicals, a clean sitemap, and monitoring after launch.

The rules for a new page and its address

  • A new page needs a customer intent that no existing page already serves.
  • Its address is concise, descriptive and in customer language: lowercase, with words separated by hyphens.
  • The address stays the same if the navigation changes later.
  • No inherited categories that add nothing.
  • One primary page per customer intent.

URL structure

One structure, two outcomes

Inherited category hierarchy vs. a stable, customer-led address

Inherited structure

  1. Homepage
  2. /services
  3. /services/consulting
  4. /services/consulting/operations
  5. /services/consulting/operations/process-automation
  • Deep hierarchy Too many levels to reach content
  • Single inherited route Only one way in
  • Fragile structure Changes are risky and hard to scale
  • Buried page Low visibility, low discoverability
/services/consulting/operations/process-automation/

Long path. Hard to change. Hard to find.

Stable URL + customer-led routes

  • By need
  • By challenge
  • By service
  • By industry
  • By use case
/process-automation/ Stable destination
  • Multiple entry paths More ways in, more opportunities
  • Customer-led navigation Aligned to how customers think and search
  • Resilient & scalable Easier to maintain, safer to evolve
/process-automation/

Simple, stable, and easy to find.

What changed

This one ended as a plan rather than a finished migration: the full technical change depended on wider business and development decisions. What it gave the business was a complete model for replacing the inherited hierarchy safely, covering the information architecture, URL conventions, consolidation rules and migration requirements, and a clear route away from fixing URLs one page at a time. It also showed why changing isolated URLs without redirects, canonical updates and a full migration map would create new search problems.

This is the same discipline Context Design describes, applied years before AI made the argument easier to see. The same logic, applied to a discovery journey rather than a URL structure, is Helping customers find the right option.

Find the one model that should govern the system, not the twentieth local patch.

---
title: Search and information architecture
slug: search-and-information-architecture
updated: 2026-10-03
summary: Designing one customer-led model for a catalogue's navigation, search visibility
  and permanent URLs, and a plan to migrate to it safely.
---

If a problem like this sounds familiar, the audit is where I'd start: one workflow, one 90-minute session, and a written brief on what's missing and what to fix first.

Book the audit

Prefer to talk first? Get in touch — no obligation.