Website Architecture Rebuild for SEO
Websites rarely become disorganised overnight.
They accumulate pages.
New services are added. Blog posts multiply. Categories evolve. Teams create content independently. Navigation changes. Old URLs remain. New topics are introduced without considering where they belong.
Eventually, the website contains plenty of information but lacks a coherent system connecting it.
I rebuild website architecture around page purpose, search intent, topic relationships, user journeys and business priorities.
The objective is not merely to produce a prettier sitemap.
It is to establish a defensible reason for where important pages exist and how they relate.
When Website Growth Becomes an Architecture Problem
This solution may be appropriate when:
- the website contains hundreds or thousands of URLs;
- nobody can clearly explain the current hierarchy;
- similar pages exist in several areas;
- important commercial pages are difficult to reach;
- content categories have become inconsistent;
- internal linking has developed without a clear model;
- important pages appear isolated;
- new content has nowhere obvious to live;
- navigation no longer reflects the website’s priorities;
- or a redesign requires the existing structure to be reconsidered.
These are not necessarily isolated content or technical problems.
They can be symptoms of a weak information architecture.
Website Architecture Is More Than a Sitemap
A sitemap can show where URLs sit.
It does not necessarily explain why those URLs should exist.
A useful SEO architecture needs to account for several relationships simultaneously.
Business Relationships
Which products, services or commercial areas matter to the organisation?
Search Intent
What distinct information needs justify individual pages?
Topic Relationships
Which topics are broad, narrow, supporting or closely related?
Page Purpose
What specific job does each important page perform?
User Journeys
How should people move between related information?
Search Relationships
How should search systems discover and interpret the relationships between those pages?
Architecture connects these considerations.
My Architecture Model
I use a progression such as:
Business → Audience → Topics → Search Intent → Pages → Hierarchy → Relationships → Navigation → Internal Links → Validation
Each stage informs the next.
What I Analyse
Existing URL Inventory
Understand what already exists before proposing new pages.
Page Purpose
Determine what each important URL is intended to accomplish.
Search Intent
Evaluate whether separate pages satisfy genuinely distinct search needs.
Query-to-Page Relationships
Identify which pages currently appear for relevant queries and whether page ownership is clear.
Topic Architecture
Map broader subjects and their supporting topics.
Website Hierarchy
Determine where pages should sit relative to one another.
Navigation
Evaluate whether global and sectional navigation reflects meaningful user and information relationships.
Internal Linking
Examine how contextual and navigational links reinforce architecture.
Crawl Depth and Discoverability
Investigate whether important pages are reasonably discoverable within the site’s structure.
Content Overlap
Identify areas that warrant consolidation or clearer differentiation.
I Do Not Create a Page for Every Keyword
Different query wording does not automatically justify different URLs.
Several related queries may represent the same underlying search intent and information need.
Conversely, similar language can sometimes represent genuinely different intentions.
The architecture therefore begins with meaning and purpose, not keyword count.
How the Solution Works
01. Inventory
Build a reliable picture of the existing website.
02. Classify
Group URLs according to page type, topic, business function and intended purpose.
03. Map Search Intent
Determine which search needs existing pages address and where ownership is unclear.
04. Model Relationships
Establish parent, child, sibling, hub and supporting relationships.
05. Design the Architecture
Define the recommended hierarchy, page relationships and navigation model.
06. Define Internal Linking
Determine how important relationships should be reinforced through links.
07. Plan Consolidation and Change
Identify pages that should remain, change purpose, merge, move or redirect where supported by the evidence.
08. Validate
Review the proposed architecture against search intent, technical requirements, user journeys and business priorities.
What You Receive
Depending on scope:
- URL inventory;
- page classification;
- page-purpose matrix;
- search-intent map;
- query-to-page map;
- topic architecture;
- recommended website hierarchy;
- hub and supporting-page relationships;
- navigation recommendations;
- internal-link model;
- consolidation recommendations;
- URL recommendations;
- redirect requirements;
- and an implementation roadmap.
What the Finished State Looks Like
The objective is a website where:
important pages have clear purposes;
topics have understandable relationships;
search intent has logical page ownership;
users can move naturally between related information;
internal links reinforce meaningful relationships;
and future content has an obvious place within the system.
Architecture and Cannibalisation
Similar content does not automatically mean two pages are cannibalising one another.
Before recommending consolidation, I look for evidence from page purpose, intent, queries and actual search behaviour.
Cannibalisation is a diagnosis.
Keyword overlap is only an observation.
Related Expertise
Rebuild the System Behind the Website
If the website has grown faster than its structure, adding more pages can make the problem worse.
The stronger starting point is determining what should exist, where it belongs and how everything should connect.