Topical Coverage Checklist for a Single Page
Audit one page against the entities and questions its topic actually requires.
Checks a specific draft or live page against the entities, subtopics and questions a complete treatment of its topic needs, marking each as covered, thin or missing and returning the exact sections to add before publishing.
Ready-to-use prompt
The prompt
Copy it as-is, then swap the bracketed placeholders for your own details before running it.
Role: You are an SEO editor auditing one page for topical completeness.
Context:
- Page content or draft: {{page_content}}
- Target keyword and intent: {{keyword_and_intent}}
- Audience: {{audience}}
Task:
1. List the entities, subtopics and questions a complete page on this topic must address, and mark each as core or supporting.
2. Audit the supplied page against that list: covered, thin, or missing.
3. For every thin or missing core item, write the section brief — heading, what it must say, what evidence it needs.
4. Flag anything present in the page that is off-topic for the stated intent and should be cut.
5. Give a coverage percentage across core items only, and state how you calculated it.
Rules:
- Judge only the supplied text. Do not assume unstated content.
- Supporting items are optional; never pad a page to cover all of them.
- Recommend cuts as readily as additions.
Output: the requirement list, the audit table, section briefs for gaps, and the cut list.
- Define each core requirement as one independently auditable reader need.
- Cite a supplied passage for every covered or thin judgment.
- Count only covered core items in the percentage; show numerator and denominator.
- Label unavailable evidence as needed, never as verified.
Estimated results
Editor's note
Why this prompt matters
Thin pages are rarely short — they are usually long and incomplete, covering the easy parts of a topic in detail and skipping the parts that need actual expertise. This prompt builds the requirement list first, audits the page against it, and then writes briefs only for the core gaps, while also naming the sections that should be cut for drifting off intent.
Anatomy
Prompt engineering breakdown
Role
Context
Goal
Constraints
Output format
What you'll get
Expected output
Scenario and supplied draft
A generic small-business site is changing one existing page URL. The target intent is procedural: change the address without breaking access or leaving conflicting signals. The audience can edit a CMS but does not manage servers.
The supplied draft says: “Record the current URL and its replacement before editing. Update navigation and in-page links to the replacement. Set up a redirect so visitors reach the new address. Check the canonical settings.” It also contains a lengthy section about choosing a domain name. No other migration instructions appear.
Requirements and audit
These requirements apply to a single URL change, not a domain migration. Supporting material is optional.
| Requirement | Priority | Status | Evidence or gap | |---|---|---|---| | Record old and replacement URLs | Core | Covered | Explicit instruction to record both | | Redirect the old URL permanently | Core | Thin | Redirect mentioned; permanence and destination checks absent | | Update internal links | Core | Covered | Navigation and in-page links explicitly included | | Check the replacement page’s canonical URL | Core | Thin | Settings mentioned without the expected value | | Update sitemap references | Core | Missing | No sitemap instruction | | Validate the change before sign-off | Core | Missing | No acceptance checks | | Monitor for problems after launch | Core | Missing | No follow-up checks | | Explain server-specific redirect syntax | Supporting | Missing | Unnecessary unless this CMS requires manual configuration |
Section briefs for core gaps
Set a permanent redirect. Explain how to route the old address directly to its replacement using a permanent redirect. Avoid inventing CMS menu labels. Evidence needed: platform documentation and a response-header check showing the redirect destination and status.
Confirm the canonical address. State that the replacement should identify its intended canonical URL, rather than retaining the old address. Evidence needed: the rendered canonical tag.
Refresh the sitemap. Check whether the CMS updates it automatically; replace stale references if necessary. Evidence needed: the current sitemap entry.
Test before sign-off. Check that the old URL redirects directly, the replacement loads successfully, and updated links resolve correctly. Evidence needed: recorded URL and response checks.
Monitor after launch. Review requests or reports for failures involving the old URL, and inspect the replacement’s indexing status when data becomes available. Evidence needed: actual logs or search-console observations, not predicted outcomes.
Cuts and coverage
Cut the domain-selection section: it answers a different decision.
Core coverage is 28.6%: 2 covered ÷ 7 core requirements × 100. Thin items receive no credit. This measures completeness against this checklist, not ranking potential.
Under the hood
Why this prompt works
Separating core from supporting items is what prevents the usual outcome, where an AI coverage audit turns a focused page into an encyclopedia. Building the requirement list before looking at the page also stops the model from grading generously against what it just read, and requiring the calculation behind the percentage makes the score checkable.
Model fit
Best AI models for this prompt
Claude
Most willing to mark sections thin and to recommend cuts.
ChatGPT
Best at writing the section briefs for identified gaps.
Gemini
Strong entity lists when the topic is technical or product-specific.
When to use
- Before assigning a draft’s first substantive edit.
- During a live-page refresh when readers repeatedly ask unanswered procedural questions.
- When calibrating depth across writers handling comparable page briefs.
- Before publication, to verify that requested sections actually resolved the original gaps.
When not to use
- For competitor comparisons; use SERP gap analysis with current results.
- For keyword discovery; use semantic keyword expansion.
- For whole-site topical authority planning or deciding which pages to create.
- For diagnosing ranking changes without search-performance data.
- For validating legal, medical or technical accuracy; use authoritative sources and qualified reviewers.
Get more from it
Pro tips
- 1
Run before the first edit round; supply the complete draft, including tables, FAQs and captions.
- 2
Use the cut list alongside additions. Remove domain-level advice from a single-URL procedure unless it changes a required step.
- 3
Leave supporting items out until core gaps close; ask what reader task makes any proposed addition necessary.
- 4
Re-run after edits with the original requirement list so a changed denominator cannot disguise unresolved gaps.
- 5
Specify the audience’s tools and permissions to prevent unusable implementation briefs.
- 6
Require quoted evidence for covered items; a heading alone does not demonstrate coverage.
- 7
On the second pass, distinguish added explanation from supplied evidence. An unsupported assertion does not close an evidence gap.
Don't ship this
Common mistakes
✗ Covering every supporting item.
Fix — Restrict the rewrite to core gaps and re-measure.
✗ Treating the coverage percentage as a target.
Fix — It is a diagnostic; a focused 80% page beats a padded 100% one.
✗ Ignoring the cut list.
Fix — Remove off-intent sections in the same edit round as the additions.
People also ask
Frequently asked questions
Q.How is this different from semantic keyword expansion?
Expansion grows a keyword list around a topic. This audits one specific page against what its topic requires and briefs the missing sections.
Q.Should I aim for 100% coverage?
No. Close core gaps only. Padding a page with supporting subtopics usually weakens its match to the query.
Q.Does it work on drafts?
Yes, and that is the best time to run it — before the first edit round rather than after publishing.