How to Decide Which Cluster Pages to Publish First

You have a spreadsheet with forty planned pages on it. You can write four this month. Deciding which content to publish first has quietly become the hardest part of your job, and it usually gets settled in a meeting by whoever argues best.

That's a rough way to run a content program. So let's replace it with something you can defend.

This guide gives you a content prioritization framework for pages you have already planned. You'll score each one on three things: demand, AI citation opportunity, and whether the page can actually be connected to the rest of your cluster. Then you'll sort, apply a few gates, and pick a first release group you can explain page by page.

It won't tell you when to publish across the weeks ahead. That's a calendar question. This is the order question.

Step 1: Freeze the backlog you are actually scoring

Before you can prioritize cluster pages, you need one list that stops moving.

Pull every already-planned page into a single sheet. Give each one a stable ID. Record the proposed title, the primary query or buyer prompt, the cluster it belongs to, the funnel stage, the audience, and its current status. Mark whether it is meant to be a pillar or a spoke.

Then do the boring part. Remove the duplicates. Two rows chasing the same intent are not two pages, they're one page and an argument.

Done means: every candidate has one row, one job, and one named cluster, and you can tell the pillars from the spokes at a glance.

Where people go wrong: they score titles instead of page jobs. A title sounds good or it doesn't. A job is testable. People also mix updates in with new pages, let two rows target the same intent, and keep adding fresh ideas while they're supposed to be choosing. Resist that last one especially. Ideation is a different day.

A keyword variant is not automatically a separate page. Write that on a sticky note if you need to.

If you want a real picture of what you already cover before you score anything, DeepSmith's Content Map crawls your site and your competitors' sites onto one shared taxonomy, classifying every page by granular topic and by funnel stage across Awareness, Consideration, and Decision. Sitemaps get rechecked every 24 hours, so the view stays current. Use it to clean the backlog and see whether a proposed page fills a genuine coverage gap. It won't decide the page's purpose for you. That part is still yours.

Step 2: Give every page one intent and one job

Now go row by row and answer one question in a single sentence: what is the searcher trying to accomplish, and what should this page help them do?

Say it in plain language. Learning a concept. Solving a problem. Comparing options. Evaluating a product. Completing a task. No jargon needed.

Then search the primary query and a couple of close variants. Look at what's actually there. Note the format that keeps showing up: guide, list, comparison, product page, template, video. That format is evidence about what people want when they ask this.

Done means: a reader could tell you why the page exists, which stage it supports, and why it isn't a copy of something else in the sheet. Your proposed format matches the dominant intent, unless you have a written reason for going a different way.

Where people go wrong: they pick a big-volume phrase whose results don't match the page they wanted to write, then write the page anyway. They also split one intent across three thin pages, or bolt a demo CTA onto a page whose whole job is teaching.

Treat what you see in the results as a snapshot, not a law. Results change. A differentiated angle is fine if it genuinely serves the reader better.

Step 3: Score demand as a comparison, not a promise

Here's where most sheets go sideways, so take this one slowly.

Record the best demand signal you can get for each page's primary query and close variants. If you're using Google Keyword Planner, remember what its average monthly searches number actually is: an average for a keyword and its close variants, based on the month. Write down the country, language, network, and date range you used, and keep those settings identical across every candidate. Different settings make different rows uncomparable, and you won't notice until the ranking looks strange.

Add two judgement fields next to the number:

1. Demand quality. Does this query represent the reader and the problem your business actually serves?
2. Click need. Would a searcher need a source page, or is the answer fully satisfied inside the search result or an AI answer?

Done means: every page has a comparable demand value or a clearly labelled estimate, plus the settings and the date you checked. Your sheet never treats volume as expected traffic.

Where people go wrong: they compare numbers pulled from different countries or date windows, count close variants as separate demand, and grab the biggest number without checking intent. Volume and business relevance are not the same field.

Search volume is directional. It doesn't tell you how many clicks you'll get, whether the query converts, how hard the current results are to beat, or whether an AI answer resolves the question before anyone clicks. A low-volume query with perfect fit is not automatically a low priority, and some of the best high priority content topics come out of that column.

Score it 0 to 5:

Use the score comparatively, inside this backlog only. These bands are your decision rules. They are not industry benchmarks, so don't quote them as such.

Step 4: Score the AI citation opportunity from real prompts

This is the half of prioritization that most sheets are missing entirely, and it's the half that has changed most.

Build a small prompt set around each planned page's job. Include the exact buyer questions the page should answer, plus close natural-language variants. Group them by active research, category education, competitor comparison, and purchase evaluation. A practical starting point is 20 to 50 prompts for the whole exercise. That's an operating recommendation from practitioners, not a required sample size.

For each prompt, record:

• The engine and the date you checked.
• Whether your brand is mentioned.
• Whether your domain or a specific page is cited.
• Which competitors are mentioned or cited.
• Which source types and pages get cited.
• Whether the answer is accurate, and whether the cited source really supports it.
• Whether your planned page would add a missing, clearer, more authoritative, or more current source.

That last line is the whole point. You're not asking "is this topic popular." You're asking "is there a source-shaped hole here that my page would fill."

Done means: every candidate has at least one relevant prompt, and your strongest candidates have enough prompt coverage that you aren't deciding off a single answer.

Where people go wrong: they count brand mentions as citations. Those are different things. A brand can be named late in an answer, described vaguely, and never linked. People also treat one engine as the whole market, and assume a page will get cited because it uses the target keyword. It won't.

Checking this by hand across engines gets old fast. DeepSmith's AI Visibility tracks your prompts and reports mention rate, citation rate, share of voice, sentiment, and visibility trend, with a per-engine breakdown. The Pages view shows which of your pages are actually cited and which prompts drive those citations. Competitor citations show which rival pages win the same prompts. Coverage is tiered: Pro tracks ChatGPT, Grow adds Perplexity, Scale adds Gemini, and Enterprise covers all ten engines, including Claude, Google AI Overviews, Google AI Mode, Grok, Meta AI, Microsoft Copilot, and DeepSeek. Use those views to turn a planned page into a specific, evidenced opportunity. No tool guarantees a citation, and you shouldn't score as if one does.

Demo workspace data, shown to illustrate the view rather than a customer result.

Score it 0 to 5:

This is an editorial judgement supported by observations. It is not a forecast of citation probability, and framing it that way will get you in trouble at the next review.

Step 5: Check your own site before you add another page

Take a breath. You're most of the way through the hard thinking.

For every candidate, find the current owner of that query or intent on your own site. Ask three questions. Should an existing page be updated instead? Would this new page cannibalize one you already have? Which related pages already exist and could link to it? Then check the current results for the depth and format readers expect, and note the strongest competing pages as evidence of the work required.

Label each candidate: new page, update existing page, merge or consolidate, or hold. A new page has to have a distinct intent and a clear reason to exist.

Done means: nothing is labelled "new" by default. Every label has a reason behind it.

Where people go wrong: they publish a new URL because the keyword list said so. They split authority between near-duplicates. They mistake a high-ranking page with a different intent for an opportunity to take it over.

Useful rule: if an existing URL already serves the intent and has some authority behind it, score the update instead of automatically scoring a new spoke. If two planned pages answer the same question, keep the stronger page job and fold the other one's evidence into it. Google is clear that it wants unique, useful, people-first content rather than recycled versions of what already exists, and that guidance applies to your own site too. This step is where most teams find that the honest way to prioritize cluster pages is to cut a few of them.

Step 6: Map pillar and spoke dependencies before you sort

You now have two scores per page. Don't sort yet. Sorting first is the mistake that produces a beautiful ranking full of pages that can't ship.

Draw each cluster as a small dependency map. For every spoke, record its parent pillar, its related spokes, the internal links it should receive, and the links it should provide. Then use this sequence rule to settle pillar or spoke first:

1. If the pillar is missing and the spokes need it for orientation, publish the pillar first or alongside the first spokes.
2. If the pillar already exists and works, publish the strongest spoke first when its demand or citation opportunity is clearly higher.
3. If a spoke supplies the evidence, definition, comparison, or use case the pillar needs to feel complete, ship that spoke first or in the same release group, then update the pillar to link to it.
4. Don't hold a high-opportunity spoke hostage to a perfect pillar rewrite. Ship the minimum useful hub, connect the spoke properly, and improve the hub later.
5. If a page has no sensible parent, no related pages, and nowhere to link, mark the dependency risk instead of pretending it's ready.

Done means: nothing you selected is orphaned. Your first release group has either a useful existing pillar or a deliberately scoped new one, plus the spokes that make the cluster worth visiting. Every planned internal link has a source page and a destination page.

Where people go wrong: they treat "pillar first" as an absolute law. It isn't. They publish a broad pillar with no depth behind it, or isolated spokes that never connect back to a hub. The honest answer to pillar or spoke first is conditional. It depends on what you already cover, how useful that coverage is, and what the opportunity scores say.

One technical note worth keeping straight. Google says it analyses relationships between pages through their links, can use the number of links pointing to a page as one signal of relative importance, and primarily discovers pages through links. That supports deliberate architecture and crawlable internal linking. It does not promise a ranking lift from any particular cluster shape, and it does not mean a URL folder makes something a pillar.

Step 7: Apply the rubric and the hard gates

Now you can sort. This is the content prioritization framework itself, and it is deliberately small. Score every candidate on three dimensions, each from 0 to 5.

The formula is simple:

Priority score = (Demand x 0.40) + (Citation opportunity x 0.40) + (Dependency readiness x 0.20)

You get a number from 0 to 5. Sort descending. Then apply the gates.

A page cannot enter your first publish group if any of these are true:

• Its intent is unclear, or it duplicates another page.
• There's no credible audience problem or prompt behind it.
• It can't be linked into the site without creating an orphan or an unresolved cannibalization.
• It can't be written accurately from the product, subject, or first-hand knowledge you have.
• Its central claim or source requirement can't be verified.

A gate is not a low score. That distinction matters. A low score means the page waits its turn. A gate means the candidate has a defect, and the fix is to repair it before comparing it to ready pages at all.

When two pages tie, use these in order:

1. The page that creates a usable parent-child link for more high-scoring pages.
2. The page with evidence from repeated buyer prompts, not one anecdotal query.
3. The page whose intent and format are clearest from the current results.
4. The page you can make genuinely useful without padding or unsupported claims.
5. The page that resolves a competitor-owned citation or a gap in an important prompt group.

Done means: every non-gated page got the same formula, your sheet still holds the three component scores separately, and you can explain any page in the first batch in one sentence.

The mistake that costs the most: letting a high demand score override a zero on dependency. A page that can't be connected, duplicates a live URL, or has no clear job is not a high priority content topic no matter how big its search number is. High priority content topics earn the label on all three dimensions, not one. Fix the structural problem or take it out of the first batch. Keeping the component scores visible is what makes this catchable, which is exactly why you don't collapse the sheet down to one column.

Step 8: Turn the ranking into a defensible first release group

Almost done. One more pass, and it's the one that turns a sorted list into a decision.

Take the top pages by score, then look at them as a group rather than as rows. A good first release group usually contains:

• The minimum useful pillar or hub, when the cluster doesn't have one.
• The highest-scoring spoke that answers a distinct, high-fit prompt.
• One or two more spokes that make the hub more useful and create strong reciprocal links.
• A mix of page jobs only where the audience and the evidence support it.

Then write two kinds of sentence. For every selected page: "Ship this now because [demand evidence], [citation opportunity], and [dependency state]." For every page you passed over: one line saying why it waits. Those deferral lines save you the entire argument next month.

Done means: the group is small enough to actually execute, structurally connected, and justified page by page. Your next group is already ranked, and you didn't have to guess.

Where people go wrong: they call the whole backlog "priority," which means nothing. They pick only broad high-volume pillars and end up with hubs pointing at empty space. Or they keep a stale ranking after publishing a pillar, changing a URL, discovering an existing page, or watching a competitor become a cited source. Re-score when any of those happen. This is a decision system, not a permanent label.

Keep the evidence attached to the page record too. A rationale that lives only in the meeting turns prioritization back into opinion by Thursday.

When the selected pages move into production, the rationale should travel with them. In DeepSmith's Content Studio, an evidence-backed idea moves from New Ideas to Planned Content to Produced Content with its justification intact, and the Writer turns a planned item into a researched, internally and externally linked, publish-ready article with metadata and a cover image. Deep IQ supplies the company, product, persona, brand voice, visual, and content-type context behind every run, so you review for strategic alignment instead of rebuilding a brief each time. Prioritization decides what gets made. This is the part that gets it made.

What to do next

Open your backlog and do one cluster. Not all of them. One.

Score its pages on demand, citation opportunity, and dependency readiness, run the gates, and write the rationale lines for whatever comes out on top. You'll have a defensible answer to which content to publish first inside an afternoon, and you'll have proven the method on something small before you scale it.

Then put those pages in the queue, keep the evidence with them, and re-score when something real changes.

If you'd rather not assemble the coverage view and the prompt evidence by hand, start a free DeepSmith trial and let Content Map and AI Visibility supply both, then take the winners straight into production. Seven days, real data, no long-term contract.

You're closer than you think. Most teams already have the backlog. They just never had the order. Run the framework once and you'll prioritize cluster pages the same way every quarter after that.