Map one topic into a content plan where every page answers a different question
Turns one topic into a map of pages, gives each page the single question it answers, and refuses to plan a page that would only rephrase another one.
- Works in
- ChatGPT, Claude, Gemini
- You need
- One topic, narrow enough to describe in a few words · Who the reader is · Your existing URL list, if you have one
- Written for
- seo main topics
Scored by our own engine
This page, run through the audit we sell. Measured 4 August 2026.
A content plan fails from having too many pages, not too few. The prompt below plans one page per question and refuses to plan a second page that answers the same question in different words, which is the failure that produces twenty rows, four published articles and no ranking for any of them.
The unit of a plan is a question
Most planning prompts return article titles, and titles hide duplication beautifully. “How to improve internal linking”, “internal linking best practices” and “internal linking tips” look like three pages in a spreadsheet and are one page written three times. Ask instead for the single question each page answers, phrased the way a person would ask it, and the duplication becomes obvious before anybody writes 1,200 words.
Rule 3 is the other half of the same idea. If a proposed page cannot be filled with three distinct sub questions, it is not a page, it is a section. Enforcing that at planning time is the cheapest quality control available, because the alternative is finding out during the second draft, after a writer has been paid.
What the plan should refuse to do
The instruction most people delete is the one telling the model not to predict rankings or estimate volume. Keep it. Asked to prioritise, a model with no data produces plausible figures, and a plan sequenced on invented numbers is harder to argue with than one sequenced on reasoning you can read.
The other constraint worth keeping is rule 8, which forces the model to name the pages that need evidence you do not have. Some pages are only worth publishing with a real example, a real number or a customer story behind them. Knowing which ones those are is the difference between a plan you can staff and a plan that quietly assumes somebody will invent the proof later.
Two things follow. Run the plan through the keyword clustering prompt afterwards rather than before, so a real export is checked against your map instead of dictating it. And when the pillar page ships, confirm the outline survived the CMS with the heading structure checker. The sub questions in the plan are the H2s, the H2s are where a model chunks the page, and an outline that drifted between the plan and the markup is a plan that never reached the reader.
You are a content strategist. I am going to give you one topic. Map it into
the set of pages a site would need to cover that topic properly. Do not give
me a list of article titles.
Rules you must follow:
1. The unit of this plan is a question, not a keyword. Every page you propose
must answer a question that no other page in the plan answers. If two pages
would answer the same question in different words, merge them and say so.
2. Give each page the one question it answers, written the way a reader would
actually ask it, plus three to five sub questions that become its H2s.
3. If you cannot fill a page with at least three distinct sub questions, it is
not a page. Demote it to a section of another page and name that page.
4. Mark each page as pillar or supporting. Every supporting page names the
pillar it links up to, and every pillar names the supporting pages it links
down to. A page with no link in either direction is a loose end, not a plan.
5. If I gave you a URL list, match each planned page to an existing URL where
one is close and mark it "update" rather than "new". Only write "new" when
nothing I already have covers the question.
6. Do not pad the plan to a round number. If the topic honestly supports nine
pages, give me nine and tell me the topic is smaller than it looked.
7. Do not invent search volume, difficulty, traffic estimates or statistics,
and do not predict rankings. You have no data on any of that. Reason from
reader intent and from what somebody needs to understand first.
8. Where a page would need original data, a real example or a customer story
to be worth publishing, say what is needed and who has to produce it. Do
not plan a page whose whole value rests on evidence nobody has yet.
Output a markdown table with these columns:
Page | Pillar or supporting | The one question it answers | Sub questions | Intent | New or update (URL) | Links to
After the table, give me four things:
- The pages you merged or rejected, with one line each on why.
- What is adjacent to this topic that you deliberately left out, and why it
belongs to a different plan.
- The build order for the first three pages, chosen on what a reader needs
first and on commercial value, with one sentence of reasoning each.
- The pages that need evidence I have not given you, and exactly what evidence.
If the topic is too broad to plan as one connected set of pages, say so and
name the two or three narrower topics it should be split into, instead of
producing a plan of forty pages.
My business: [ONE SENTENCE ON WHAT YOU SELL AND TO WHOM]
My topic: [THE TOPIC, IN THREE TO SIX WORDS]
Who reads it: [WHO THE READER IS AND WHAT THEY ALREADY KNOW]
My existing pages: [PASTE URL LIST, OR WRITE "none"]What to change
Everything in square brackets is yours to replace. Nothing else needs editing.
[ONE SENTENCE ON WHAT YOU SELL AND TO WHOM]- The plan changes completely depending on what the pages are for. "We sell payroll software to accountancy firms" produces a map aimed at people who already understand payroll. "We sell payroll software" produces a map that starts by explaining what payroll is, which is nine pages you will never sell anything from.
[THE TOPIC, IN THREE TO SIX WORDS]- One topic, not a market. "SEO" is a market and the model will return a plan the size of a textbook. "Internal linking for ecommerce category pages" is a topic, and the plan that comes back is a set of pages one team could actually build this quarter.
[WHO THE READER IS AND WHAT THEY ALREADY KNOW]- This is the variable that decides how many pages you get. "Marketing managers who have run campaigns but have never briefed a developer" tells the model which explanations to skip, and every explanation it skips is a page that does not get planned and then written for nobody.
[PASTE URL LIST, OR WRITE "none"]- Your existing indexable URLs, one per line, straight out of sitemap.xml. Without it every page in the plan comes back as new, and most teams find that a third of the plan is a page they already published in 2024 and forgot about. Updating one of those beats writing a fresh one.
How to run it
- 01Narrow the topic until it is genuinely one topic
Write the topic in six words or fewer and check that you could explain what it excludes. If you cannot name something obviously adjacent that is out of scope, the topic is still a market and the plan will come back unbuildable. Splitting it now is cheaper than pruning forty rows later.
- 02Describe the reader in one honest sentence
Say what they already know, not what you wish they knew. The difference between a reader who has never heard of the problem and one who has already tried two solutions is roughly half the pages in the plan, because everything explanatory drops out for the second reader.
- 03Export your URL list
Open sitemap.xml and copy the URLs, or export them from the CMS. Drop pagination, tag archives and anything noindexed. If you genuinely have nothing published on the topic, write "none" and expect every row to come back marked new.
- 04Run the prompt and read the rejected pages first
The merged and rejected list is where the thinking is. A plan that rejects nothing has not been filtered, it has been generated, and the usual sign is three rows that are the same page with the words reordered. If nothing was rejected, run it again and say so.
- 05Cut the plan yourself before anybody writes
Take the table and delete the rows you know you will not build. A plan of twenty pages that produces four is a worse artefact than a plan of six that produces six, because the unbuilt rows sit in the sheet making the topic look covered. Keep what has a date against it.
- 06Build the pillar first and check the outline you shipped
Write the pillar page from its sub questions, then run it through the heading structure checker to confirm the H2s you planned are the H2s that made it into the markup. Outlines drift in the CMS, and headings are where both search engines and assistants decide what a page covers.
Questions people ask
What are the main topics an SEO content plan should cover?
Whatever set of distinct questions your reader has to get answered before they can buy, and nothing else. There is no universal list, because the topics are a property of the audience rather than of SEO. The practical test is whether each planned page answers a question no other page answers. If two pages answer the same question, you have one page and a duplicate.
How many pages should a topic map contain?
As many as the topic honestly supports, which is usually fewer than a model will offer. A count decided in advance produces padding, and padded pages are the ones that end up thin, unlinked and competing with the page you actually meant to rank. Plan the pages you can name a distinct question for, then stop.
What is the difference between a pillar page and a supporting page?
A pillar answers the broad question and links down to the pages that answer the narrow ones. A supporting page answers one narrow question thoroughly and links back up. The relationship is the point: a set of pages with no links between them is a folder of articles, not a topical map, and nothing about it signals that the site covers a subject.
How is this different from keyword clustering?
Clustering starts with a keyword export and groups what already exists. Topic mapping starts with one subject and works out what should exist, including pages that no keyword tool will suggest because nobody has written them yet. Most teams need both, in that order: map the topic, then cluster an export against the map to see what you missed.
Can ChatGPT build a content plan on its own?
It can structure one and it cannot tell you what is worth building. A language model has no access to search volume, no view of your sales conversations and no idea which pages already earn you money, so it will happily plan a page for a question nobody asks. Give it the topic, the reader and your URL list, and it does the part it is good at, which is separating questions that belong on one page from questions that do not.
Unsubscribe in one click. We never pass your address on.