Indexability Checklist

Use this for: URLs being considered in the audit.

List the important URLs from your website editor and label each one: preferred public page, duplicate of another page, intentionally excluded public page, private page or removed page. Choose the preferred destination for duplicate content. Include meaningful template variations instead of assuming one product represents every product.

Use those decisions when judging later checks. A thank-you page carrying intentional noindex can be correct, while the same directive on your main service page is a defect. Private content needs access control; a search directive does not protect it.

1. List the relevant published URLs and page-type variations.
2. Choose each URL’s intended state and any preferred duplicate destination.
3. Resolve unclear cases with the content or site owner before changing signals.

Use this for: Preferred public URLs expected to appear in search.

Open the preferred public address in Chrome with Developer Tools → Network recording, reload and select the main document. Read the status and final URL. A normal live HTML page should deliver its content with 200; if the starting address redirects, inspect the destination as a separate URL.

Restore an accidentally missing public page or correct the preferred address. A removed page returning 404 or 410 can be intentional. Do not turn every missing address into a homepage redirect to reduce a report count.

1. Request the exact intended URL with Network recording enabled.
2. Read the main response and any changed destination.
3. Fix an unintended error or update references to the actual preferred page.

Use this for: Wanted pages with empty/error output or a Soft 404 report.

Read the loaded body of a wanted page and compare it with its purpose. An empty template, unavailable-data message or not-found screen may return 200 even though there is no useful page to index. In Search Console, inspect a reported Soft 404 example to see whether that situation applies.

Restore the missing content or correct the route when the page should exist. If it is genuinely gone and has no relevant replacement, return an appropriate not-found response. An out-of-stock product with useful lasting information is not automatically an error page.

1. Read the returned main content of the flagged or suspect URL.
2. Decide whether the promised page exists, is temporarily unavailable or is genuinely removed.
3. Restore the useful page or correct its missing-page response, then inspect again.

Use this for: Public HTML pages, especially JavaScript or mobile-specific templates.

Inspect the wanted URL with a live test and open View tested page when available. Find the actual service details, product information or article answer in the rendered HTML and compare the screenshot with the expected page. Check the smartphone rendering used for the test.

If essential text appears only after a click, consent choice or failed data request, have the developer make the public content available during normal rendering. Keep meaningful primary content on mobile. No fixed word count proves that a page is indexable or useful.

1. Run the live test and inspect the rendered HTML and screenshot.
2. Compare the main answer and important mobile content with the published page’s intended purpose.
3. Fix missing or interaction-dependent primary content and repeat the comparison.

Use this for: Public HTML pages intended for search indexing.

Use View page source and search for robots, googlebot, noindex and none. Inspect the rendered head too when JavaScript changes metadata. For a wanted public page, remove unintended noindex at its source: the page’s search visibility setting, an SEO plugin or the shared template.

Keep deliberate exclusions. An extra index tag does not cancel an applicable noindex rule, and an explicit index tag is not needed on an otherwise eligible page. If initial HTML says noindex, do not rely on JavaScript to remove it later.

1. Read relevant robots tags in source and rendered HTML.
2. Compare any restriction with the URL’s intended state.
3. Remove the accidental restriction in the generating setting and verify the output.

Use this for: Preferred public HTML pages and supported public file URLs.

In Chrome’s Network panel, reload the URL, select its document request and read Response Headers for X-Robots-Tag. Include public PDFs or other supported files if you want them discoverable in search. Their HTTP instructions can differ from the HTML page that links to them.

Ask the developer or hosting owner to remove an unintended noindex header at the route, server or CDN configuration. Check every applicable header; a permissive HTML tag does not neutralize a restrictive response header.

1. Open the exact HTML or file URL with Network recording.
2. Read every applicable X-Robots-Tag response header.
3. Correct unintended restrictions and request the published URL again.

Use this for: Public URLs intentionally excluded with noindex.

For a public URL intentionally kept out of search with noindex, check whether robots.txt or another fetch barrier prevents the crawler from reading that instruction. A robots block alone can leave the URL appearing in results without its content.

When the content is safe to be public, allow the necessary fetch so the noindex can be read. If the material is private, keep authentication or other proper access control and ask the owner to handle any search exposure separately. Never expose private content just to make a directive test pass.

1. Find the intended noindex page and verify its published directive.
2. Check whether its applicable crawl rule or access barrier hides the response.
3. For public content only, correct the conflicting crawl block and test the readable instruction.

Use this for: Pages declaring canonical preferences or belonging to a duplicate set.

Open the published source and locate rel="canonical". If an HTTP Link header declares a canonical, inspect it too. Open the target and compare its content with the page: it should be the intended representative, not an unrelated homepage or an unavailable address.

For an independently useful page, a self-referencing canonical is a clear default. For a genuine duplicate, name the chosen equivalent page. Correct wrong template values and use a complete preferred address; a canonical is a signal, not an instruction that guarantees selection.

1. Read the page’s HTML or HTTP canonical declaration.
2. Open its target and compare the content and intended role.
3. Correct the generating field or template and inspect the published declaration.

Use this for: Duplicate URL sets and pages with multiple canonical signal sources.

For a duplicate set, compare the canonical declared in the source, any HTTP Link header, rendered metadata, sitemap entries and internal links. They should support the same preferred address. JavaScript should not change an existing canonical to a different target.

Update the actual source of a conflicting signal, such as a campaign URL in a category card or a stale sitemap entry. Use canonicalization for duplicate consolidation; do not add noindex merely to force Google to choose a different duplicate.

1. Choose a representative duplicate set and its intended canonical.
2. Compare source/header/rendered declarations with sitemap and internal-link destinations.
3. Correct the inconsistent references and repeat the comparison.

Use this for: URLs with available indexed canonical information.

Inspect the exact URL in Search Console and use the indexed information to read User-declared canonical and Google-selected canonical when available. Open both addresses if they differ and compare their content and signals. The live test cannot predict Google’s canonical choice.

A correctly consolidated duplicate needs no repair just because it is excluded. If a distinct intended page loses to an unrelated or wrong representative, fix misleading canonical signals or substantive content duplication. When the report predates your change, confirm the new output now and wait for a later crawl record.

1. Read canonical fields in the indexed URL Inspection result.
2. Compare any different selected URL with the intended content and signals.
3. Preserve correct consolidation or repair the specific conflicting cause.

Use this for: Sites with Page indexing data.

In Search Console → Indexing → Pages, open a not-indexed reason and inspect representative URLs. Match each address to its intended state. A retired URL, redirect or alternate with the right canonical may be working correctly; an accidental noindex on a wanted service page is different.

Use the matrix below to classify each reviewed case as intended, defect, pending or unknown. Expand the sample when template variations disagree. A completed classification is useful even when a genuine defect remains open.

1. Open a not-indexed reason and inspect concrete example URLs.
2. Compare the stated reason and crawl date with each URL’s intended state.
3. Assign a specific next action only where the state is wrong or unresolved.

Use this for: Wanted URLs reported as discovered or crawled but currently not indexed.

For Discovered, currently not indexed, Google knows the address but has not crawled it. Review its useful discovery paths and any wider access or host problems. For Crawled, currently not indexed, compare the last crawl date with the published version, inspect the received content and check whether another page serves the same purpose.

The crawled label alone does not prove poor quality or identify a particular defect. If the page genuinely duplicates another answer, choose a sensible representative. If useful unique information is missing, improve that information. If no cause is established, keep the result pending instead of inventing one or repeatedly resubmitting the unchanged URL.

1. Identify the exact not-indexed reason and available crawl date.
2. Follow the discovery/access branch or the fetched-content/duplicate branch as appropriate.
3. Apply a supported repair, or keep the case pending when the evidence is inconclusive.

Use this for: Wanted pages with unexplained missing visibility after technical checks.

If a wanted page remains missing despite clean live technical checks, review Search Console’s Removals, Manual actions and Security issues reports. Check the actual affected scope and dates; an old removal request or a reported policy issue is different from a page-level noindex.

Give confirmed findings to the responsible owner and follow the report’s remediation process. Do not cancel an intentional removal or infer a manual action just because traffic fell. A clean set of these reports still does not guarantee indexing.

1. Open the three relevant Search Console reports.
2. Check whether any active finding or request covers the wanted URL.
3. Resolve an unintended restriction with its responsible owner and review the updated status.

Use this for: Published fixes to an indexability defect.

After publication, repeat the failed response, directive, canonical or rendered-content check on the same URL. If the change came from a shared template or header rule, test a second affected page and a deliberately excluded control. Only then consider Request indexing for a small set of changed wanted URLs; use an updated sitemap for a larger set.

Keep two outcomes separate: the live defect is repaired, and the later index record reflects the intended state. Repeated requests do not speed up crawling, and a successful request never guarantees inclusion.

1. Repeat the original failed live check after the change is published.
2. Test relevant template and exclusion controls.
3. Request a recrawl when appropriate and check the later indexed record separately.