Indexability Audit Checklist: What to Check

1. Define the Eligible Set

• Write the site, host, protocol, paths and crawl date.
• List templates intended for search and templates intentionally excluded.
• Record destructive, private, authenticated and staging areas that must not be crawled.
• Name the owner and reviewer for each publishing policy.
• Keep sitemap-only and imported URLs separate from confirmed internal discovery.

2. Confirm Transport Before Page Checks

• Capture requested URL, every redirect hop, final URL, status and MIME type.
• Retry uncertain HEAD failures with GET.
• Separate 2xx HTML from redirects, 4xx, 5xx, timeouts and non-HTML files.
• Stop title, heading, canonical and content checks when no valid document arrived.
• Retain the source page that introduced each failed target.

3. Review Crawl and Index Controls

Check	Pass Condition	Stop or Escalate When
robots.txt	Relevant crawler can fetch wanted pages	Rule blocks the page or required evidence
Meta robots	Visible directive matches publishing policy	Source and rendered values conflict
X-Robots-Tag	Header matches the page policy	CDN or file response adds unexpected noindex
Authentication	Anonymous access matches the intended audience	Session changes the page or status
Availability	Stable successful HTML response	Repeated failure or incomplete capture

4. Check Canonical and Discovery Signals

• Resolve the declared canonical against the final document URL.
• Fetch the target and confirm it is successful and indexable.
• Find chains, loops, multiple canonicals and unrelated targets.
• Compare internal links, sitemap entries and hreflang with the preferred URL.
• Confirm mobile and rendered navigation still exposes important destinations.

5. Check the Rendered Page

• Save source HTML and rendered DOM as separate evidence.
• Record the readiness rule, render wait and failed network requests.
• Confirm title, main heading, body, canonical, robots directives and important links.
• Test one normal page, one important page and one known exception per template.
• Do not call a visible screen proof that every crawler received the same content.

6. Add Search Console Evidence Carefully

• Use the correct verified property.
• Record inspection time, indexed version and live-test time separately.
• Keep discovery, crawl, canonical and indexing labels in their original context.
• Use complete date windows for performance comparisons.
• Treat missing rows as unavailable, not zero impressions.

An Illustrative Sign-Off

Asha’s 3,800 rows become 2,900 eligible pages, 500 approved exclusions, 250 redirects and 150 unavailable observations. Of the eligible pages, 2,760 pass the technical checks, 100 share a canonical-template defect and 40 return unstable server responses. Her sign-off does not say “96.7% indexed.” It says exactly which technical conditions were measured and which provider observations still need time.

7. Prepare the Handoff

Field	Required Value
Scope	Exact URLs or template and exclusions
Evidence	Captured value, layer, source and timestamp
Decision	Pass, needs review, excluded or unavailable
Action	Smallest reviewed change
Ownership	Implementer and reviewer
Safety	Behavior that must remain correct
Verification	Comparable fresh check and timing

Frequently Asked Questions

What should an indexability checklist include?

It should cover intended publishing state, response, crawl access, index directives, canonical signals, discovery, rendering, observed search state and post-change verification.

Where should I start an indexability check?

Start with the exact URL and intended outcome. Confirm the final response before checking tags or Search Console labels.

Should I check every page manually?

Review representative templates and exceptions manually, then use measured rules across the full eligible set. Important or unusual pages deserve individual review.

What should happen when evidence is missing?

Mark the check unavailable, record what is missing and run the next collection step. Do not convert missing evidence into a pass, failure or zero.

Does a green checklist mean the page will be indexed?

No. It means the measured technical eligibility checks passed. Search engines still choose what to crawl, retain and rank.

How often should indexability be reviewed?

Review after migrations, template changes, robots or canonical releases, and when Search Console patterns change. Recurring checks should use comparable scope.

How do I hand the checklist to developers?

Include exact URLs, evidence, affected template, expected state, owner, reviewer, safety checks and a fresh verification method.

Sources, Statistics and Measurement Notes

• Robots Meta Tag, Data-Noindex and X-Robots-Tag Specifications — Google Search Central. Defines page-level and HTTP-header indexing controls; it does not guarantee whether a permitted page will be indexed. Accessed 30 September 2026.
• URL Inspection Tool — Google Search Console Help. Explains live tests and indexed-version observations for verified properties. Accessed 30 September 2026.
• Canonicalization — Google Search Central. Explains canonical signals and why a declared canonical remains a signal rather than a command. Accessed 30 September 2026.
• XML Sitemaps — Google Search Central. States that sitemap submission is a hint and does not guarantee crawling or indexing. Accessed 30 September 2026.
• Ubersuggest keyword overview: indexing issues — Ubersuggest. India, English, checked 30 September 2026: “indexing issues” returned 40 monthly searches and SEO difficulty 18. “How to check if a page is indexed” returned 20 and difficulty 6. These are dated editorial inputs, not traffic forecasts. Accessed 30 September 2026.

Use the Checklist With a Live Crawl

Open the affected LLMIC records instead of relying on the summary count. Preserve unavailable states, assign reviewed work and repeat the same checks after release. Completing this checklist cannot guarantee indexing, rankings or traffic.

Before selecting a bulk action, inspect an important page, a normal page and a known exception. Keep facts, interpretations and recommendations in separate fields. Save the original scope and exclusions with the task so a later reviewer can reproduce the denominator. If a required response, header or rendered document is unavailable, collect it again instead of guessing. This discipline takes longer than clicking “fix all,” but it prevents a weak observation from becoming a site-wide change and gives the execution team a precise result to verify.