SEO clustering isn't a spreadsheet exercise

A pattern I keep running into when looking at how other people approach SEO clusters: the clusters live in a spreadsheet, the site lives somewhere else, and the gap between them is treated as somebody’s manual problem.

You’ll see a tab with a “pillar page” listed at the top, ten or fifteen “supporting articles” underneath, a column of target keywords, maybe a status field. Genuinely useful as a planning artefact. The trouble is that the spreadsheet is where the cluster ends.

The site itself doesn’t know any of that. The pillar page is just another page. The supporting articles are just other pages. Whatever relationship was so carefully mapped in the planning doc has to be re-implemented by hand inside whatever CMS is being used, page by page, link by link, and that’s where it starts to break down.

A cluster, properly understood, isn’t really a list. It’s a shape. There’s a centre, there are pieces around it, and the pieces are connected in a way that should be visible to both readers and search engines without anyone hard-coding it. If your CMS doesn’t know about that shape, your site can’t really represent it. You end up with internal linking that approximates the cluster structure rather than expressing it.

The way I’ve been thinking about this on the current build is to push the cluster shape into the schema. A topic document knows what its parent topic is. An article knows which topic cluster it belongs to and which other articles it’s most directly related to. The site doesn’t have to ask “how should I link these together?” - the answer is already in the data.

That has a few practical effects.

The internal linking stays consistent as the site grows, because the rules are derived from the model rather than authored manually each time. Breadcrumbs are honest. Related-content blocks aren’t just whatever was published most recently. The sitemap reflects something close to the actual topical architecture, which is the bit search engines are trying to read anyway.

There’s a tidier version of this argument that frames it as “structured data for SEO.” I don’t really like that framing because it makes it sound like a technical SEO concern. It isn’t. It’s a content modelling concern that happens to also help search engines, because search engines are essentially trying to figure out a structure that the site should already know about itself.

If you want the clusters to do anything more than look good in a planning document, they have to live in the architecture. The content model. The relationships. Possibly the URL structure, depending on the site. Definitely the navigation logic.

The spreadsheet is fine for planning. It’s just not where the work actually happens.