Most information architectures are inherited.
The original site was built around how the business was organised at the time. Departments became website categories, and products were mapped to internal team structures. The navigation reflected what leadership wanted to say, in the order they wanted to say it to every possible customer that exists within its ICP.
Over time, more pages were added, designs shifted (menus had an extra column, in-page sub-headers were removed), and acquisitions changed the product mix, along with new propositions being bolted on. The site ends up becoming a living document of internal decisions made over the years, lightly adjusted at each rebuild but never fundamentally questioned. You can inherit the foundations of an architecture for 10 – 15 years, even after going through replatforms, redesigns and SEO website migrations.
How most sitemaps actually get built
When a new site is decided upon, the sitemap is workshopped internally between stakeholders and the marketing team. It is reviewed, refined, signed off and handed to a developer. The build begins.
The new site launches; Cleaner, faster, better looking and modern – the visual upgrade is genuine, and the technical performance is improved.
Structurally, though, two common outcomes tend to play out.
The new architecture mirrors the old one, carrying forward the same internal logic in a new wrapper. Or it is modelled on competitor sites (sometimes not even the same ICP/size/brand equity level), often through a process of benchmarking that confirms what feels familiar rather than what would serve customers best.
Either way, the foundation of the site has been built around how the business sees itself or how it wants to be perceived when some larger brands have a lot more brand search demand/goodwill to inherit bad journeys (studies show people will persevere on a website with a high “brand love” and will work through any CRO/UX issues).
The questions during a sitemap rebuilt that rarely get asked
A customer-led architecture starts somewhere different. It is built around questions that most internal stakeholder workshops never get to.
What do customers actually search for on Google/LLMs, and what language do they use when they search? What do they need to understand before they are ready to buy, and in what order does that understanding need to come? Where does the current site create friction because the structure assumes knowledge the visitor does not yet have? What categories or content do prospects expect to find that the existing site does not offer?
When the IA is interrogated against questions like these, the gaps become obvious quickly.
Common issues: pages that should exist and do not, categories buried three or four clicks deep when they should be the first thing a prospect finds, content written in company language for problems that customers describe in completely different terms and use cases bundled inside product pages when they would perform better as standalone entry points for search.
These are not minor refinements. They are structural decisions that shape how every visitor experiences the site and how every search engine/LLM understands it.
Why this matters more in 2026/27
The shift toward AI-powered search makes customer-led architecture even more important. LLMs and AI search engines surface content based on how well it matches the actual intent of a query. Structures built around internal organisation tend to fragment that intent across multiple pages, none of which answer the question fully.
Architecture built around how customers think creates content that aligns with how they search. That alignment is what AI search rewards.
What changes when IA is built around the customer
The site that emerges from a customer-led IA process performs differently from one built around an internal structure.
- Pages match the language of search behaviour, so they rank for terms the business was previously missing.
- Navigation moves visitors toward conversion paths that reflect how they actually make decisions.
- Content gaps that have existed for years get identified and filled.
- Commercial pages that were previously buried get the prominence their commercial value justifies.
The result is a site that converts better because it was built around how its audience moves through a buying decision, not how the business is structured internally.
The honest question to ask yourself before undertaking a site migration
Before any new migration, one question is worth answering by marketing stakeholders.
Is the proposed architecture built around how the business is organised?
Is it a place designed to house every existing page?
Or is it built around how customers think, what they search for and how they move through their journey?
The answer determines whether a migration becomes a visual upgrade or a commercial step change.
The key to getting the Information Architecture and Website Sitemap designed to answer these questions often happens at the discovery, design and scoping phase – added into a migration plan as the first stage in a pre-migration process. The POLARIS website migration checklist sets out every critical checkpoint a pre-launch SEO process should cover, from planning through to post-launch monitoring.
Next in our SEO Migration series
Next up: A migration is often framed as a defensive exercise; protect the rankings, preserve the traffic and hold position on what has been built. The next article makes the case for treating a migration as an offensive move instead. A chance to build something more valuable than what came before, rather than simply replicating it in a new wrapper.
