SEARCH CONSOLE

Use URL Inspection without confusing live and indexed states

A disciplined URL Inspection workflow keeps the processed record, the current live response, and the work you still need to observe separate.

Start for free
  • Practical release checks
  • Clear limits
  • Built for operators

THE SHORT ANSWER

What to know before you change anything.

The indexed result describes what Search Console knows from a processed version of a URL. A live test checks the URL as it can be fetched now. A healthy live test is useful release evidence, but it does not prove that the current version is already indexed or will appear for a query.

  • Store indexed and live timestamps in different fields.
  • Check X-Robots-Tag as well as HTML directives.
  • Record declared and selected canonicals separately.

PRACTICAL WORKFLOW

Use this process in the next release.

Keep every observation dated and every change tied to the earliest demonstrated issue.

  1. 01

    Inspect the indexed record

    Record the status, last crawl, selected canonical, and any reported reason before changing the page.

  2. 02

    Run the live test

    Check the current response after a controlled change. Review headers and rendered output, not only the on-screen summary.

  3. 03

    Name the first mismatch

    State the earliest observed failure—such as access, a directive, canonical conflict, or delivery issue—and keep later questions open.

  4. 04

    Verify a bounded release

    Ship the smallest reversible change, test a representative cohort, and return to the indexed record only after an appropriate observation window.

RELEASE CHECKS

A small checklist before you ship.

These checks make the diagnosis repeatable for another teammate.

  • Store indexed and live timestamps in different fields.
  • Check X-Robots-Tag as well as HTML directives.
  • Record declared and selected canonicals separately.
  • Do not treat a recrawl request as an indexing promise.

COPYABLE TEMPLATE

Capture the evidence in one place.

Copy this into a release ticket or investigation record, then complete it for a representative URL.

URL: [exact address]
Indexed result checked: [timestamp]
Live test checked: [timestamp]
Declared canonical: [value]
Selected canonical: [value]
First discrepancy: [finding]
Release owner: [person or team]
Follow-up date: [date]

WHY THIS MATTERS

Use the report to narrow the next decision.

Start with the question you need to answer. If the page is unexpectedly absent, look for access, directives, canonical signals, and content delivery before asking for another crawl. If you ship a fix, use the live test to prove the fix reached production, then allow time to observe the later indexed record.

KEEP LEARNING

Continue with the related guide.

Build an XML sitemap that supports discovery

An XML sitemap is a structured discovery hint. It works best when it contains the clean canonical URLs you want crawlers to find—not every address your application can generate.

Frequently asked questions

Common questions

Bounded answers for the checks that most often get conflated.

Why do the indexed result and live test disagree?

They represent different points in time. The indexed result is based on a processed version, while the live test checks the current URL.

Should I request indexing after every change?

Use requests selectively after a meaningful, shipped repair. They do not replace a technical diagnosis or guarantee an outcome.

PUT THE WORKFLOW TO USE

Turn technical SEO checks into a repeatable workflow.

Use Spacebrain to organize the work, the evidence, and the next owner around every release.

Start for free