INDEXING & CRAWLING · FIELD GUIDE

Canonical and noindex: different signals, different checks

By SEO Orbiter · Updated

A canonical identifies your preferred version of similar content. A noindex directive asks search engines to exclude a page. Decide whether the URL should be indexed at all before changing either, and compare today’s response with Google’s last known indexed version.

Write down the intended indexed URL

For each affected page, state whether it is a public acquisition page, a duplicate or a private/action page. A filtered duplicate may correctly canonicalize elsewhere; a sign-in page may correctly be noindex. A monitoring alert is a request to check intent, not permission to remove every directive.

Worked example

Illustrative case: /products/blue is the public product. /products/blue?campaign=email should consolidate to it. A private order-confirmation URL is not another canonical product variant; it should remain excluded and protected where appropriate.

Inspect the response and the target

Record HTTP status, redirect chain, the canonical link, robots meta and X-Robots-Tag. Inspect the canonical destination too: it should represent the intended content and be reachable. Multiple conflicting canonicals or a destination returning an error are concrete implementation issues.

  • Check both HTTP headers and HTML directives.
  • Follow redirects to their final URL.
  • Compare the declared target with internal links and the sitemap.

Compare what Google actually reported

Use URL Inspection to examine the selected canonical and last crawl. A declared canonical is a preference, not a guarantee that Google selected it. The Inspection API returns information about the indexed version; it is not the interface’s live test. An old result can predate your fix.

Fix the conflicting signal at its source

Trace an accidental noindex to the template, response header, environment flag or plugin that emits it. Check sibling pages using the same path. For canonical mistakes, correct the shared URL generator instead of overriding isolated pages. Keep staging and private areas excluded.

Worked example

If a staging flag was copied to production, verify the flag and the generated response after deployment. Do not declare recovery just because the configuration file changed: the public HTTP response is the acceptance check.

Verify a fresh response, then follow indexing

Save the corrected URL and check time. Confirm that crawl access permits Google to see the change. If necessary, use Search Console to request reprocessing of a small number of important URLs. Continue to distinguish a successful live fix from Google’s later crawl, canonical choice and traffic outcome.

Browse all diagnosis guides

Primary references

These references describe Google’s reporting and crawling behavior. The worked examples above are illustrative, not customer results.