
Indexation
Part of SEO during website changes
Checking indexability after deployment
Check released URLs, crawl access, noindex rules and canonical signals, then compare live and indexed Search Console views.
After deployment, check the released version of each priority page — not just the CMS setting or staging preview. Confirm its final URL serves the intended content, permits Google to fetch it, and sends indexing and canonical signals consistent with the release plan. Passing these checks does not guarantee indexing.
Choose a release-specific sample
Use the approved URL plan. Choose important service or category pages, a guide and examples from each changed template. Add pages that had staging restrictions, custom headers, a domain change or unusual redirect rules. Include URLs intentionally excluded from indexing, so a deliberate exclusion is not mistaken for a fault.
For each sampled URL, record its expected final address and whether it should be eligible for indexing. Keep that expectation beside the observed result. The Page indexing report can reveal patterns; URL Inspection is the appropriate Search Console tool for an individual address.
Indexing status indicators to monitor
- Pages with deliberate noindex
- Expected exclusion – not a fault
- Redirects from staging URLs
- Must resolve to final public URL
- Canonical mismatch risk
- Site preference ≠ Google’s choice
Inspect what the public site delivers
- Follow the requested address.Record its redirects and final URL. Request the route directly; a Search Console live test does not replace a redirect check.
- Check the final response and content.Confirm that the public page loads its main answer and important qualifications. A successful status alone does not establish that the intended answer arrived.
- Check crawl access.Read the applicable
robots.txtrules and any access restriction for the final URL. - Check indexing instructions.Inspect the delivered robots meta tag and
X-Robots-Tagresponse header fornoindex. A shared template or server rule can affect many pages. - Check URL signals.Compare the canonical annotation, internal links and sitemap entry with the intended final address. Google can choose a different canonical, so a matching annotation records the site’s preference, not Google’s decision.
A robots.txt block can stop Google from reading a noindex instruction on the page. Decide which behaviour is intended before changing either control.
Compare live and indexed views
For a Search Console property you control, inspect a priority URL and run the live test after release. It can help identify current access and indexing-instruction problems. The indexed view reflects Google's earlier processing; compare its last crawl date with the deployment date. A clean live test does not check every indexing condition or predict Google's canonical selection.
Use the Page indexing report to look for wider patterns as Google processes the new site. A redirect or deliberate duplicate may be absent from the index for the right reason. Investigate unexpected exclusions on pages marked important in the release plan rather than trying to make every URL indexable.
Live test vs indexed view in Search Console
- Live test
- Shows current state: crawl access, noindex directives, and rendering
- Indexed view
- Reflects Google’s past processing; check last crawl date vs deployment date
Record the fix and recheck
For each exception, save the exact URL, intended state, observed response or directive, owner and proposed correction. After a fix, repeat the public-page checks and, where useful, the live test. Later, compare Google's updated indexed view. The public check shows what the site now serves; the indexed view shows what Google has processed so far.



