SEO

Index coverage report diagnosis

Use when the page indexing report is full of excluded reasons and you need to know which ones matter.

index-coverage-report-diagnosis.md

Download .md

You are diagnosing a Search Console page indexing report. You are not running a full technical audit.

Report rows (status, reason, URL count, trend, example URLs): {{COVERAGE_ROWS}}
Submitted against indexed counts per sitemap: {{SITEMAP_COUNTS}}
Which URL patterns belong to which template, and which we want indexed: {{TEMPLATE_MAP}}
Site changes in the last 90 days: {{RECENT_CHANGES}}

Output four numbered sections.

1. Table: Reason | Count | Trend | Templates affected, read from {{TEMPLATE_MAP}} | Intended or unintended | Likely cause | Fix | Urgency (Now / This quarter / Leave).
2. "Intended exclusions" - the reasons that are working as designed, so nobody spends a sprint on them.
3. Submitted against indexed: for each sitemap in {{SITEMAP_COUNTS}}, the size of the gap and the single reason from {{COVERAGE_ROWS}} that most likely accounts for it.
4. "Ordered checks" - for the top three unintended reasons, the exact URL level check to run and what each result would mean.

Constraints:
- Do not treat every excluded reason as a fault. Discovered or crawled and not indexed on a filtered or paginated pattern is often intended; say which case this is.
- Do not blame anything in {{RECENT_CHANGES}} unless the trend lines up with its date. Say "timing does not match" where it does not.
- Where a reason has no example URLs, name the export you need instead of guessing.

Fill in before running

Replace each placeholder with your own detail. The more specific you are, the less the model invents.

{{COVERAGE_ROWS}}
{{SITEMAP_COUNTS}}
{{TEMPLATE_MAP}}
{{RECENT_CHANGES}}

Getting a better result

Split sitemaps by template first, or section three tells you nothing you can act on.
Read the trend, not the count - a stable 40,000 excluded is a design decision, a rising 4,000 is a bug.
Check a handful of example URLs by hand before accepting any cause, since the reason labels are coarse.

Questions about this prompt

When is this better than a full technical audit?

When the specific thing in front of you is a page indexing report full of excluded reasons and you cannot tell which are faults. An audit starts from the site; this starts from the report and sorts intended exclusions from real problems. If indexation is fine and rankings are not, audit instead.

What do I need to supply?

Report rows with counts, trend direction and example URLs, submitted against indexed figures per sitemap, and a map of which URL patterns belong to which template and which you actually want indexed. Without that template map nothing can separate a deliberate exclusion from a bug. Add site changes from the last ninety days.

Which section do I act on?

Four come back: a reason by reason table with urgency, the intended exclusions, the submitted against indexed gap per sitemap, and ordered checks for the top three unintended reasons. Read intended exclusions first. It is the section that stops a sprint being spent on filtered URLs that were never meant to be indexed.

What is the mistake that costs me here?

Acting on counts instead of trends. A stable forty thousand excluded is usually a design decision; a rising four thousand is a bug, and the big number is the one that gets escalated. Then open a handful of example URLs by hand before accepting any cause, because the reason labels are coarse.