SEO & GEO/AEO

Verified against ChatGPT · 2026-08-10

Design a pillar-and-cluster topical map for a subject you're not yet ranking for, sized to what you can actually publish

Builds a full pillar page plus supporting cluster-article architecture for a new topic area, deliberately scoped to a realistic publishing capacity instead of an idealized 40-article map nobody will finish.

ChatGPT (GPT-5.1)4 fillable variables

The prompt

Ready to copy — highlighted parts are example details you can swap.

You are architecting a pillar-and-cluster topical map for a subject area we want to build authority in but don't currently rank for at all.

SUBJECT AREA
Remote-team payroll compliance across US states

WHAT WE CAN REALISTICALLY PUBLISH
One 1,500-word article every two weeks, one writer, no dedicated legal reviewer.

COMPETITORS ALREADY STRONG HERE
Gusto and Deel each have upward of 150 pages covering state-by-state payroll compliance in depth.

BUSINESS GOAL FOR THIS TOPIC
We want to rank for the handful of states our actual customer base is concentrated in, not compete nationally.

DESIGN THE MAP IN THIS ORDER

1. Pillar page: define the single broad page that will anchor this topic, its target keyword, and the scope it needs to cover to plausibly earn topical authority signals — broad enough to link out to every cluster piece, specific enough to actually rank on its own.
2. Cluster articles: list the supporting articles that link into the pillar, each with its own long-tail target keyword, and explicitly state how each one links back — the internal-linking relationship is what makes this a topical cluster instead of a pile of unrelated blog posts, so name it for every single cluster piece, not just describe the concept once.
3. Sequencing: given the stated publishing capacity, order the cluster articles into a realistic build sequence — which ones should go first because they're both high-opportunity and needed to make the pillar page's internal links non-empty on day one, versus which can wait.
4. Reality check: if the full map as designed exceeds what's realistically publishable in a reasonable timeframe given the stated capacity, cut it down explicitly rather than handing back an aspirational map that assumes unlimited output — say what got cut and why, and offer a phase-two list for the cut items instead of dropping them silently.

WHAT NOT TO DO
Do not produce a topical map so large it functions as a wish list rather than a plan — if publishing capacity is one article every two weeks, a 30-piece map is not useful even if every piece is individually well-chosen. Do not treat established competitor coverage as something to simply out-list; if a competitor has 200 pages on this subject and we can publish 12, name the realistic subset of the topic where 12 well-chosen pages can plausibly compete, rather than a shallow imitation of their full breadth.

OUTPUT FORMAT
1. Pillar page: title, target keyword, scope summary.
2. Cluster table: Article title | Target keyword | Links to pillar via (anchor text / context) | Build order.
3. One paragraph on what was cut from an idealized version of this map and why, plus a phase-two list.

Customize

Optional — swap in your own details for the highlighted parts above.

Why this works

Asked for a topical map without a stated capacity constraint, GPT-5.1 defaults to an idealized, comprehensive-looking structure — often 20 to 40 cluster articles — because that pattern matches what "complete topical coverage" looks like in its training data, regardless of whether anyone requesting it can actually produce that volume; forcing the reality-check step as a required final stage is what makes the model reconcile the aspirational map against the stated constraint instead of handing back a plan that was never buildable. Requiring an explicit internal-linking relationship for every single cluster article, not just a general statement that clusters link to the pillar, matters because topical authority signals depend on the actual link graph existing on the site, and a map that names the concept once but doesn't specify per-article anchor context produces a list of loosely related articles that a team will publish without ever actually wiring the internal links between them. Naming the build sequence explicitly addresses a real launch-order problem specific to pillar pages: a pillar page published with links to cluster articles that don't exist yet either ships with dead links or gets delayed waiting on content that isn't finished, so sequencing which cluster pieces need to exist before the pillar goes live is a genuine dependency question, not a nice-to-have. The instruction to name a realistic competitive subset rather than imitate a competitor's full breadth matters because a smaller site trying to out-publish an established competitor's 150-page topic cluster on volume alone is simply not a winnable strategy, and the model needs an explicit constraint to recommend a narrower, winnable wedge instead of an imitation of scale it has no way to actually assess as achievable.

What you get back

Pillar: "Remote Payroll Compliance by State: A Practical Guide" (target: remote team payroll compliance). Cluster: "California Remote Employee Payroll Rules" — target keyword: california remote payroll compliance — links to pillar via "see our full state-by-state guide" in intro — build order: 1st (highest customer concentration).

Verified against

ChatGPT GPT-5.1 · 2026-08-10

Changelog

  • 2026-08-10 Initial publish, verified against ChatGPT GPT-5.1.

Building this for real?

This is a free starting point. If you'd rather have SEO built and running for your business, that's Scult's day job.

EXPLORE SEO
All SEO & GEO/AEO prompts

Check your AI visibility

One URL in, a 0–100 score and the exact fixes out.

RUN THE CHECK

Browse all the tools

15 tools across six categories
13 of them never send your data anywhere

Free · No signup · No trial clock

SEE THE DIRECTORY