Good site architecture starts with a simple question: what job should this URL do, and what other URL should not be competing with it?
Map decisions, not just keywords
Keyword lists are useful raw material, but a site cannot have one page for every phrase. Group queries by the decision behind them. Someone comparing two approaches needs a different page from someone ready to request a quote, even if both queries contain the same core noun.
I like to write the intended job of a page in one sentence before writing the title: “This page helps a business owner choose between a custom build and WordPress,” for example. If two URLs get the same sentence, you probably have an architecture problem.
Choose one primary page for each important intent
Cannibalization is often a symptom of indecision. A company publishes a service page, a location page, three blog posts, and a landing page that all chase the same broad query with almost the same angle. Internal links then point to all of them interchangeably.
Pick the page that should own the intent. Supporting pages can answer narrower questions and link back with descriptive anchors. The goal is not to delete useful content; it is to make the relationship between the pages clear.
Let the site hierarchy reflect how a person explores
A sensible hierarchy usually moves from broad context to specific choices. A services hub introduces the offer, individual service pages explain outcomes and process, case studies show proof, and guides answer questions that arise before or after the sale.
You do not need a deep folder structure to create this relationship. Navigation, breadcrumbs, contextual links, and clear page copy can communicate the hierarchy even when URLs are relatively flat.
Use internal links as editorial decisions
An internal link should answer “what would be useful next?” rather than “where can I insert this keyword?” Link from a technical term to the guide that explains it, from a guide to the service that solves the problem, and from a case study to the relevant capability.
Anchor text should be descriptive enough to make sense in the sentence. Repeating the same exact anchor across every page is rarely necessary and often reads badly.
Watch what happens after the architecture is live
Search behavior will show you where your map was wrong. A page may start ranking for an adjacent intent you did not expect. Two pages may alternate for the same query. Visitors may land on an article and immediately look for pricing.
Use Search Console queries, landing-page data, internal search, and conversion paths to refine the architecture. Information architecture is not a one-time diagram; it is a hypothesis you keep testing.
Know when not to create a page
A new URL has a maintenance cost. It needs a reason to exist, enough unique value, links, and a place in the site. Thin location pages, tiny keyword variants, and near-duplicate comparison pages often create more ambiguity than coverage.
Before publishing, ask what this page will contain that the existing best page cannot contain cleanly. If the answer is “the keyword is slightly different,” improve the existing page instead.
Before you move on, check these
- Write the user decision or job for each important page in one sentence.
- Choose one primary URL for each major intent and make supporting pages subordinate to it.
- Use hubs, breadcrumbs and contextual links to show relationships between topics.
- Write internal links for the reader’s next useful step, not for anchor-text repetition.
- Review query and landing-page data for cannibalization or unexpected intent.
- Do not create a new URL unless it can provide distinct, maintainable value.
Keep reading
Paste a public URL into AEO & GEO Insights and compare the article with what the crawler actually finds: structure, indexing signals, evidence, entities and extractable answers.
