What you'll learn

By the end of this you'll understand how Baseline's URL taxonomy and hub structure were designed with search in mind from day one — before a single article was written. You'll see the decisions that shaped the IA, the ones we'd change, and the signals that told us we were on track.

Who this is for

  • Content strategists and developers building topic-authority sites from scratch
  • SEOs working on fast-moving niches where keyword landscapes change weekly
  • Product owners trying to understand why information architecture matters for organic growth

You can skip this if you're building a single-topic blog. IA decisions matter most when you have multiple topic clusters and you need search engines to understand the relationships between them.

What is SEO IA? Plain English

Information architecture (IA) is the structure of your URLs, categories, and links — how you decide where things live and how they relate to each other. SEO IA is IA designed with search crawler behaviour in mind. It affects which pages get indexed, how authority flows between them, and which queries each page can realistically rank for.

Plain English version: IA is how you organise your site; SEO IA is organising it so search engines can also navigate it.

Prerequisites

  • Familiarity with basic on-page SEO (titles, canonicals, meta descriptions)
  • Some experience with a content site, even a small one
  • No coding required for this guide, though we reference Next.js implementation decisions

Setup from zero

Step 1 — Define topic clusters before writing content

Before Baseline published anything, we mapped the topic space into clusters:

  • AI tools — reviews, comparisons, news, tutorials, alternatives
  • Developers — Next.js, React, MERN, Node.js, AWS, system design
  • Career — job search, interviews, salary, remote work
  • Resources — downloadable tools, templates, case studies

Each cluster became a hub. Each hub got a namespace: /ai/, /developers/, /career/, /resources/. Within each hub, content types got sub-paths: /ai/reviews/, /ai/tutorials/, /developers/nextjs/.

The decision to use explicit sub-paths (rather than tags or facets) was deliberate: sub-paths signal topical depth to crawlers. /ai/reviews/ is a category page. A tag page at /tag/ai-review is not.

Step 2 — Design the URL taxonomy

Rules we set:

  1. All slugs lowercase, hyphen-separated. No underscores, no camelCase.
  2. Slugs include the primary keyword. /ai/reviews/cursor-editor-review — not /ai/reviews/post-142.
  3. No dates in URLs. /ai/news/gpt5-release ages better than /ai/news/2026-07-gpt5-release.
  4. Hub index pages at their root. /ai/ is a real page with curated content, not a redirect.

Rule 3 required a small fight. The instinct when covering fast-moving news is to date your URLs. Don't. The URL outlives the article's newsworthiness. Dateless URLs accumulate links without expiring.

Every article gets three types of internal links:

  • Hub link — a link back to its hub index (/ai/)
  • Type link — a link to its type index (/ai/reviews/)
  • Related links — two to four links to sibling content in the same cluster

The related links are pre-computed at content generation time and stored on the document. We don't use dynamic sidebar widgets that generate links at render time — those don't get crawled as reliably on JS-heavy pages.

Step 4 — Handle canonicals for near-duplicate content

AI tools get reviewed at launch and then revisited six months later. The revisit is a substantial update, not a new article. We update in place and refresh the updatedAt date. We don't create a new URL.

For case studies that reference earlier articles heavily, we add an explicit canonical to the original:

alternates: { canonical: "https://baseline.sh/ai/reviews/cursor-editor-review" }

Step 5 — Manage crawl budget on the index pages

Index pages with pagination create crawl surface. We set:

  • Page 1: indexable, canonical to itself
  • Pages 2+: robots: "noindex", rel=next/prev removed (Google deprecated this but some crawlers still use it)
  • All hub indexes: in sitemap with changefreq: "daily"
  • Individual articles: in sitemap with changefreq: "weekly"

This keeps the crawl budget on the most valuable pages — the hub indexes and the articles.

The mental model

Think of your URL taxonomy as a filing system that both humans and crawlers navigate. Crawlers follow links in the same way users do. If a page is three clicks from the homepage and has no inbound links from other content, it will be crawled infrequently. If it's one click from the hub index and linked from ten related articles, it will be crawled often and weighted more heavily.

Your IA goal is to ensure that every published article is reachable in two clicks from the homepage and has at least two inbound internal links.

Key terms

Topic cluster — a group of semantically related content around a central hub page. The hub targets a broad keyword; spokes target long-tail variations.

Crawl budget — the finite number of pages a search engine will crawl on your site in a given period. Pagination, query strings, and low-value pages consume it.

Canonical — the URL you designate as the "real" version of a page. Prevents duplicate content issues when the same content is accessible at multiple URLs.

Authority flow — PageRank (or equivalent) passing through internal and external links. Internal links distribute authority; orphaned pages receive none.

Step-by-step

These are the three IA problems we hit after launch — each with a clear problem, approach, and measurable outcome.

Early drafts linked to hub indexes but not to sibling articles. Search Console showed articles indexed within days but ranking nowhere — crawl worked, authority didn't flow.

Approach: pre-compute two to four related links at seed/rewrite time and store them on the document. Every article template renders them in static HTML.

Outcome: median time-to-first-page-one impression dropped from ~11 weeks to ~6 weeks on long-tail AI tool queries.

Problem: pagination eating crawl budget

The news archive generated 40+ indexable paginated URLs. Crawlers spent cycles on page 47 of old news instead of fresh reviews.

Approach: page 1 indexable; pages 2+ get robots: "noindex". Hub indexes stay in the sitemap with changefreq: "daily".

Outcome: Coverage report "Crawled — currently not indexed" count fell 34% in six weeks without losing traffic to deep archive pages (they weren't converting anyway).

Problem: near-duplicate review updates

Revisiting a tool six months later tempted us to publish a second URL. That would split link equity and confuse canonical signals.

Approach: update in place, refresh updatedAt, add a "Last updated" line in the body, keep the original slug.

Outcome: the Cursor review URL accumulated links across two editorial cycles instead of competing with itself.

Working examples

A hub index URL and its canonical setup:

// app/ai/page.tsx — generateMetadata excerpt
return {
  title: "AI Tools, Reviews & Tutorials | Baseline",
  description: "Curated AI tool reviews, comparisons, and tutorials…",
  alternates: { canonical: "https://baseline.sh/ai" },
};

Internal link block rendered on every article:

<nav aria-label="Related on Baseline">
  <h2>Related on Baseline</h2>
  <ul>
    {related.map((slug) => (
      <li key={slug}><Link href={contentPath(slug)}>{titleFor(slug)}</Link></li>
    ))}
  </ul>
</nav>

Patterns

Hub-and-spoke IA — one pillar page per topic cluster (the hub), surrounded by detailed articles on subtopics (the spokes). Each spoke links back to the hub. The hub links to every spoke.

Dated content, undated URLs — use publishedAt and updatedAt in the article body and structured data, never in the URL.

Computed related content — pre-compute related article links at seed/rewrite time. Don't rely on runtime tag queries for related content — they're slow and render after the crawlable HTML.

Common mistakes

Putting the same article in multiple hubs. You split internal link authority between two URLs for the same content. Pick the primary hub; use related links to surface it in secondary contexts.

Deep pagination without noindex. Page 47 of your news archive consumes crawl budget and is almost never the landing destination for organic search. Noindex anything beyond page 3.

Thin hub index pages. A hub index that just lists titles with no editorial content is a weak page. Give each hub index a short intro, curated featured articles, and its own unique meta description.

Little tip

Check your sitemap.ts output against your actual indexed pages using Google Search Console's Coverage report. Mismatches (pages in sitemap but not indexed, or pages indexed but not in sitemap) always signal an IA problem.

Little tip

Use rel="canonical" on every page, even when the canonical is the page's own URL. It prevents accidental duplicate signals from query strings that crawlers sometimes append.

Troubleshooting

Hub index not ranking despite strong spoke articles. Check internal links — are all spokes linking back to the hub? Is the hub in the sitemap with changefreq: "daily"? Does the hub have unique, substantive content or just a list of titles?

Articles indexed but not ranking. Crawl is working; authority is the gap. Count inbound internal links. Articles with zero inbound links from other content rank poorly regardless of content quality.

Duplicate content signals. Run a screaming frog crawl and look for near-identical meta descriptions across category pages. Each index page should have a unique description with cluster-specific language.

Checklist

  • [ ] Topic clusters defined before first article
  • [ ] Hub namespaces in /hub/ format, not flat
  • [ ] All slugs: lowercase, hyphenated, keyword-first
  • [ ] No dates in URLs
  • [ ] Hub indexes are real content pages, not just lists
  • [ ] Every article has: hub link, type link, 2–4 related links
  • [ ] Pagination pages 2+: noindex
  • [ ] Sitemap includes hub indexes with daily frequency
  • [ ] Canonicals on every page, including self-referencing

Practice task

Audit one section of your own site. List every article's inbound internal link count. Identify any articles with fewer than two inbound links. Add them to related-content sections on appropriate hub or spoke pages.

FAQ

How many articles does a hub need before it competes in search?
A hub with five to ten genuinely useful articles on distinct sub-topics starts to see crawl consistency. Ranking traction on competitive queries typically takes 20+ quality articles plus six months of index age.

Should every content type have its own sitemap?
Not necessarily. A single sitemap under 50,000 URLs is fine. Split by hub or type only if you hit that limit or want granular crawl reporting per section.

Does IA matter if I have strong backlinks?
Yes — strong backlinks to one page don't automatically distribute authority to sibling pages without good internal linking. IA determines how external authority flows internally.

What to learn next

  • Google Search Console Coverage and Index reports — hands-on crawl analysis
  • Schema.org BreadcrumbList markup — reinforces IA signals to crawlers
  • Topic authority building through content clustering
  • [Building the Baseline content hub](/case-studies/building-baseline-content-hub)
  • [MERN performance pass](/case-studies/mern-app-performance-pass)
  • [Sitemap and robots.ts guide](/developers/nextjs/sitemap-robots-nextjs)

Takeaways

Good IA is invisible to users and obvious to search engines. Every URL decision compounds: the ones you make on day one will constrain or enable every article you publish for the next five years.

If you remember only one thing: every published article should be reachable in two clicks from the homepage and have at least two inbound internal links. That one constraint enforces good IA better than any checklist.