SEO site architecture: structuring a website around how people search

Why SEO is an architecture problem

BizCredX is where this clicked for me. I had research mapping dozens of real search questions to a 74-URL site. The obvious move was a page per question. The research pointed the other way: answer the questions inside the existing hubs, and use those answers as bridges to deeper guides, comparisons, and tools.

SEO doesn't create pages. Search questions reveal the relationships between pages.

A question about what business credit is belongs near the educational foundation. A question about which vendors report belongs near the vendor database. Search behavior was telling me how the product should be organized. The BizCredX story goes through it in detail.

This page is the search-engine side of website architecture. The human side, labels, journeys, and flows, is on UX and information architecture. In practice the two point the same way far more often than they conflict.

Structure the site by search intent

Every search has an intent behind it. The type of intent decides what kind of page should answer it. Matching those two is the first structural decision.

The mistake I see most is answering a comparative search with an informational page. When someone asks which Net-30 vendors report to which bureau, they don't want an essay. They want a table they can sort. When the question becomes which one, the format usually needs to change.

Topic clusters and content hubs

A topic cluster is a hub page plus the supporting pages around it. The hub covers the subject broadly and links to every supporting page. Each supporting page goes deep on one question and links back up.

HUB PAGE  (broad topic, one intent)
   │
   ├── Supporting page: question A ──┐
   │                                 │ cross-links where
   ├── Supporting page: question B ──┤ readers cross over
   │                                 │
   └── Supporting page: question C ──┘

Every supporting page links back up to the hub.

HSAMaxGuide works this way now. Instead of a separate page for every product someone searches, an OTC eligibility hub holds the products together and connects out to HSA versus FSA and the wider eligible-expenses guide. Tools belong inside clusters too. A contribution calculator is the natural next step from an article about contribution limits, not a page sitting alone in a tools folder.

One intent, one destination page

This is the rule that prevents keyword cannibalization. Closely related keywords reinforce one page instead of each getting their own. Here's the actual map behind this part of GardySpace, as an example:

Six destination pages carry dozens of keywords between them. Where two could plausibly overlap, like website information architecture, one page gets it as primary and the other links to it. The Journal and Analysis pages support these hubs with stories and lessons, but they don't compete for the same searches.

Internal linking architecture

Internal links are how both visitors and crawlers move through a cluster. The rules I follow:

• Hub to every child, every child to the hub. This is the spine of the cluster and shouldn't be left to chance.
• Link to the next question, not just the parent. An answer about a symptom should link to what it costs to fix, not only back to the category.
• Use descriptive anchor text. Link text should say what the destination is about. Click here tells a search engine nothing.
• Connect across clusters where readers cross. On FixRN, troubleshooting guides link to cost pages, cost pages link to local service, and state hubs link back into guides.
• Hunt orphans. Any page with no internal links pointing to it is invisible to visitors and weak for crawlers.

The best internal link usually isn't the one an SEO tool suggests. It's the page that answers the next question a reader is likely to have at that exact point.

Crawling and indexing: the technical foundation

None of the structure above matters if search engines can't reach it. This layer is invisible until it breaks, which is why it breaks quietly.

One pattern worth knowing: when the same crawl problem shows up on several sites built from similar templates, it's rarely several bugs. It's usually one shared file, set wrong once and inherited everywhere. I wrote about finding exactly that.

Reading Search Console as architecture feedback

Search Console is usually treated as a report card. I've started treating it as a design tool. Two real snapshots:

Neither is a traffic success story, and I'm not presenting them as one. They're useful because of what they reveal. HSAMaxGuide was getting impressions for products I hadn't built pages around, which told me Google already connected the site to a wider cluster. That called for a hub, not fifty new pages. SavedNest's large Discovered, currently not indexed group pointed at internal linking into those pages, not at the content itself.

The questions I ask of every property's data: which queries show up that I didn't plan for, which pages trade places for the same query, and which sections sit unindexed. Each one is an architectural answer waiting to be found. These snapshots are from September 2026 and aren't a statement of current performance.

The full HSAMaxGuide follow-up, including the title fixes, the www duplicate behind 12 unindexed pages, and the honest AdSense math, is in 8,739 impressions, 13 clicks, and why AdSense was never the problem.

SEO site architecture checklist

See it in real projects

Each of these is shaped by search data as much as by the original plan.

SEO site architecture FAQ