Google Index Checker

Free, no signup. Diagnose one public URL, or reconcile a sitemap and GSC export. For Google’s actual index decision, use URL Inspection.

Built by Patrick Stox

Checks run from our server; we fetch the URL you enter and don't keep the results. Anonymous run-level outcome counters may be used for aggregate research; URLs, domains, IPs, and identifiers are never included, and no statistic is released below 100 runs.

Feedback
Report a bug

Found something broken in Google Index Checker? Let us know what happened — this goes straight to a private triage queue, not a public list.

What will be sent 
 No tool inputs, uploads, pasted source, complete results, query parameters, or URL fragments are attached automatically. You can edit or remove the selected passage above. Browser and anti-abuse metadata is processed for spam prevention. 
  
 
  
 
 
  
 
 
  
 
Sample report
Illustrative example — fixed observable response
No public indexing blocker observed
  • Final response: HTTP 200.
  • Robots directives: no noindex observed.
  • Canonical: self-referencing https://example.com/guide.
  • Google index status: not evaluated — verify in URL Inspection.
 
 
How to use it
  1. Enter the exact public URL and choose Check signals.
  2. Review status, redirects, robots directives, and canonical hints observed in the response.
  3. Treat a clean amber result as “no public blocker observed,” not “indexed.”
  4. Open URL Inspection in the verified Search Console property for Google’s actual state.
 
 
     
     
   
What the results mean
Red blockers are directly observed technical barriers such as noindex or a failed final response. Redirect and canonical evidence describes the current URL path and declared preference. Amber means the public response does not answer Google-only questions about discovery, crawl scheduling, duplicate selection, quality, or index state.
How it works
A bounded server request follows the URL, returns response headers and HTML, and deterministic checks extract the final status, redirect path, meta and HTTP robots directives, and canonical hints. The Search Console link is a handoff; the tool has no property access and fabricates no index verdict.
Features
  • Live status and redirect evidence.
  • HTML and HTTP noindex checks.
  • Declared canonical hints and conflict context.
  • Direct URL Inspection handoff for the verified answer.
Limitations
It cannot see Google's index, last crawl, selected canonical, coverage reason, rendered JavaScript, or property data. Public fetches may also differ from Googlebot. It never labels a page indexed, discovered-not-crawled, crawled-not-indexed, or a quality issue.
 
Frequently asked questions
Can this tell me whether Google indexed a page?
No. Only Search Console URL Inspection for a verified property can report Google’s actual index stateStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed., crawl statusCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor., and selected canonicalHow search engines pick one canonical URL among duplicates and consolidate signals onto it..
Why is a clean result amber?
A clean HTTP response and noindexNoindex is a directive that tells search engines to keep a page out of their index, so it won't appear in search results. It works only on pages a crawler can actually fetch — a page blocked in robots.txt can never be noindexed./canonical signals only show that no blocker was observed. They do not reveal crawl scheduling, duplicate clustering, quality, or discovered-not-crawled states.
Does a noindex tag remove a page immediately?
No. A crawler must revisit the page and process the directive. This tool can observe the current directive but cannot see when Google last crawled it or when the index will update.
Can robots.txt prove that a page is not indexed?
No. Blocking crawling does not guarantee that a URL is absent from the index, and this page-level check focuses on the fetched response. Use Search Console and a robots tester for those separate questions.
What does a canonical hint mean for indexing?
A canonical names a preferred duplicate URL, but search engines can choose another version. This tool reports the declared signal and conflicts; Search Console is needed for Google’s selected canonical.
 
Reconcile sitemap, crawl, and GSC evidence
 
Free, no signup. Put sitemap membership, current fetch/status/canonical evidence, and a Google Search Console Page Indexing export in one transparent URL table. This reconciles supplied evidence; it does not call URL Inspection or claim Google’s live index state.
 
 
Local limits: 5 MB per sitemap or GSC input, 50,000 sitemap URLs, 50,000 GSC data rows, and 50,000 unique URLs in the combined reconciliation.
 
  Checks run from our server; we fetch the URL you enter and don't keep the results. Sitemap and GSC files are parsed locally. If crawl is enabled, at most 100 public URLs are fetched through the protected page-fetch endpoint; results remain in this tab. Anonymous run-level outcome counters may be used for aggregate research; URLs, domains, IPs, and identifiers are never included, and no statistic is released below 100 runs. 
 
 
Sample report Static evidence example
https://example.com/a
Sitemap: Yes · Current crawl: indexable · GSC: indexed
Action: Evidence aligns; monitor.
https://example.com/b
Sitemap: Yes · Current crawl: noindex · GSC: indexed
Action: Review the new blocking directive and whether the export is stale.
This demonstrates reconciliation logic; it is not a live Google index report.
 
 
 
How to use it
  1. Paste sitemap URLs/XML and upload a GSC Page Indexing CSV; either source can be used alone.
  2. Keep the fallback at Unknown unless the export’s scope justifies another classification.
  3. Leave current fetch enabled for a bounded sample, or disable it for local-only reconciliation.
  4. Filter the resulting evidence by next action and verify high-impact URLs with URL Inspection separately.
 
  
What the results mean
  • Sitemap — membership in the supplied inventory.
  • Current crawl — raw status, redirects, canonical, and blocking directives from the optional fetch.
  • GSC export — the parsed state in the uploaded file or chosen fallback.
  • Evidence / next action — deterministic explanation of agreement, conflict, or missing evidence.
 
How it works
Local parsers normalize one child sitemap and GSC CSV rows into URL evidence. The optional protected queue fetches up to 100 URLs with pacing and bounded retries, extracts final status, canonical, meta robots, and X-Robots-Tag, then the reconciliation engine joins all sources by normalized URL.
 
Features
  • Up to 50,000 local sitemap and GSC rows.
  • Local parsing with explicit fallback semantics.
  • Optional 100-URL current-evidence crawl.
  • One table combining inventory, crawl, and historical GSC evidence.
 
Limitations
GSC exports can be delayed and scoped, while current fetch evidence can change after export. Only raw HTML is fetched, only the first 100 combined URLs are crawled, and only 1,000 rows are rendered. The tool does not call URL Inspection, prove indexing, crawl sitemap indexes, render JavaScript, or diagnose every reason a URL is excluded.
 
Frequently asked questions
Does the reconciler check Google’s live index?
No. It reads the GSC export you upload and does not call URL Inspection. The result is a reconciliation of supplied and current fetch evidence.
What happens when a GSC export has no status column?
You choose a fallback state. Unknown is recommended because a URL’s presence in a CSV does not by itself prove indexed or not indexed.
How many URLs can it fetch?
Local inputs can contain up to 50,000 unique URLs, but the optional current crawl is bounded to the first 100 combined sitemap/GSC URLs.
What does not evaluated mean in the crawl column?
A current fetch could not be completed, including after bounded rate-limit retries. It is not converted into a blocker or a pass.
Can it parse a sitemap index?
No. Paste URLs or one child URL sitemap. Sitemap-index files are deliberately rejected by this interface.
 
Useful handoffs
Inspect one URL’s observable blockers · Run a broader site audit · Reconcile a migration inventory
 
   
Next stepXML Sitemap Generator — publish a sitemap that only lists URLs you want indexed.

Explore more
ToolCanonicalization CheckerToolXML Sitemap ValidatorToolRaw vs. Rendered HTML CheckerArticleSaaS SEO AuditArticleURL Inspection ToolArticleJoomla SEO
 
 
 
Feature requests for Google Index Checker
 

Upvote what you want most. New ideas can be submitted from the floating Feedback menu;
      requests appear here once approved, and the most-wanted rise to the top.

   
Loading…
  
  ➕ Request a feature   
New requests are reviewed before they appear here.
 
     
  
  
 
 
 
 
   
       
 
Common issues & how to fix them
 
 
 
 
 
Google Index Checker · one finding
 
Noindex directive blocks indexing
 
Recommended action: Remove the noindex directive from pages that should be indexed, then rerun the check.
 
Fix principle: Remove every unintended noindex from its confirmed owner; absence of noindex is sufficient, while an explicit index directive cannot override another noindex because restrictive directives combine.
 
 
 
 Implementation for your setup 
 
Confirm first: The final HTML or HTTP response contains a noindex directive, including one added only by client-side script during rendering. The page is intended to be an indexable canonical URL. A robots meta tag or X-Robots-Tag intended to keep the page indexable is neutralized by a conflicting directive elsewhere, because directives combine using the most restrictive rule. Robots.txt disallows the URL itself, or disallows a resource the page depends on to render, so the crawler cannot reach or fully evaluate the intended indexable page.
 
Do not apply when: Exclusion is intentional for the page type, environment, or workflow state. The directive appears only on a noncanonical or otherwise ineligible URL. Robots.txt does not disallow the URL or the resources it needs to render, and the effective combination of every directive already resolves to the intended indexable state.
 
Likely control points: cms-app · server · edge-cdn
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: The application, server, or edge owner that emits the directive, or the robots.txt file at the site root
 
Steps
  1. Follow redirects, identify the exact owner of each unintended robots/googlebot meta or X-Robots-Tag noindex, and remove it only at that owner.
  2. Return the intended canonical page with a crawlable 200 response, align its canonical, and purge the caches that can retain the directive.
  3. If a robots meta tag or X-Robots-Tag is present but rendered ineffective by a conflicting directive elsewhere, remove the actual unwanted restrictive directive rather than adding a permissive one to compete with it — the most restrictive rule always wins. Google also honors a robots meta tag placed outside <head>, so an out-of-head placement is a specification and cross-crawler risk to correct, not by itself proof Google is ignoring the directive.
  4. If robots.txt disallows the URL itself, or disallows a resource (such as CSS or JS) the page needs to render its content, correct only the specific Disallow rule at the robots.txt file that owns it — keep the rule as narrow as its original intent, and remember Disallow blocks crawling, not indexing: a disallowed URL can still be indexed if discovered elsewhere.
  5. Keep the URL crawlable so Google can observe the removal.
  
Verify on this platform
 
  • After redirects and cache purge, inspect every robots and googlebot meta tag plus every X-Robots-Tag value on the final response.
  • Fetch and parse robots.txt for every group that applies to the relevant user-agent — Google consolidates every group matching the same user-agent token into one effective ruleset, though not every crawler does — and confirm the URL and its critical rendering resources are not disallowed.
  • Use Search Console URL Inspection’s live test on the production URL, then request indexing when appropriate.
 
Rollback
  1. Restore the prior directive or robots.txt rule if the page or a resource it needs was exposed or blocked unintentionally, then correct the underlying publication rule before trying again.
 
Caveats
  • Do not add index as a counter-directive: the most restrictive directive applies, so another noindex still wins.
  • The live test checks current accessibility; it does not guarantee selection, canonical choice, or indexing.
  • Google’s own parser combines every robots.txt group matching the same user-agent token into one effective ruleset, but many other crawlers and Robots Exclusion Protocol implementations honor only the first matching group — treat a directive split across groups as a real interoperability risk even when Google itself is unaffected.
  • If the page combines a canonical to a different URL with a noindex directive, remove the noindex only if this URL itself should be indexable; if the canonical target is the one meant to be indexed, keep the noindex here and verify the canonical target separately rather than treating its indexability as confirmed by removing this noindex.
 
Official sources
 
 
WordPress
 
Status: supported · Location: Global Settings → Reading/blog_public, or the scoped plugin/theme callback that owns wp_robots
 
Steps
  1. If WordPress core globally owns the directive, confirm the scope and change Settings → Reading so blog_public permits search-engine visibility.
  2. For a scoped page-type or URL rule, identify and change the plugin or theme callback filtering wp_robots or invoking the core noindex behavior; do not invent a plugin UI.
  3. Purge page, object, host, and edge caches that can retain the old output.
  
Verify on this platform
 
  • While logged out, follow redirects and inspect all robots/googlebot meta plus X-Robots-Tag values on the final public response.
 
Rollback
  1. Restore the previous visibility or plugin setting if unintended pages become indexable.
 
Caveats
  • Do not use the global Reading setting to solve a scoped plugin or theme rule.
  • WordPress exposes the wp_robots API, but a third-party owner’s exact UI is not verified here.
  • Robots.txt is a separate control point from this meta/header directive — correct a Disallow rule using the generic-http-html guidance above regardless of which CMS serves the site.
 
Official sources
 
 
Cloudflare Workers / Rules
 
Status: supported · Location: Confirmed Response Header Transform Rule or Worker emitter
 
Steps
  1. Use Cloudflare Trace and configuration review to confirm which Transform Rule or Worker adds the final X-Robots-Tag and account for response-header rule ordering.
  2. Narrow or remove only that confirmed edge emitter; in a Worker, clone the response before modifying its headers.
  3. Purge the affected cache entries and leave any valid origin-owned robots header intact.
  
Verify on this platform
 
  • Compare origin and final Cloudflare responses after redirects, then confirm every final robots header and meta directive is free of unintended noindex.
 
Rollback
  1. Restore the prior edge rule if the scope change exposes excluded routes, then replace it with a narrower condition.
 
Caveats
  • Never blanket-delete a valid origin X-Robots-Tag when Cloudflare is not the confirmed emitter.
  • Later response-header rules can override earlier changes, so verify the final rule order and response.
  • Robots.txt is a separate control point from this response-header directive — correct a Disallow rule using the generic-http-html guidance above.
 
Official sources
 
 
Next.js / Vercel
 
Status: supported · Location: App Router metadata/generateMetadata, Pages Router next/head, or next.config headers()
 
Steps
  1. In the App Router, remove the unintended noindex from static metadata.robots or generateMetadata at the route that owns it.
  2. In the Pages Router, correct the owning next/head robots meta; for an X-Robots-Tag, correct the scoped next.config headers() rule.
  3. Deploy to the intended production environment and purge or bypass relevant caches before verification.
  
Verify on this platform
 
  • Inspect all final robots/googlebot meta and X-Robots-Tag values after redirects on the current production deployment.
 
Rollback
  1. Revert the route metadata, Head output, or headers() rule if the deployment exposes a route that should remain excluded.
 
Caveats
  • Vercel intentionally serves X-Robots-Tag: noindex for Preview Deployments and outdated Production Deployments; preserve that protection.
  • Do not diagnose an intentional preview response as a production metadata defect.
  • Robots.txt (a static file or a route handler such as app/robots.ts) is a separate control point from this metadata/header directive — correct a Disallow rule using the generic-http-html guidance above.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor-owned publication, visibility, or response-header control
 
Steps
  1. Ask the vendor to identify the exact global or scoped control that emits noindex and remove it only for the confirmed public canonical URL.
  
Verify on this platform
 
  • Follow redirects and inspect all robots/googlebot meta and X-Robots-Tag values on the final public response, then use the Search Console live test.
 
Rollback
  1. Restore the vendor visibility control if an unintended page becomes public while the owning rule is corrected.
 
Caveats
  • Do not add index to compete with a noindex emitted elsewhere.
  • Keep the URL crawlable long enough for search engines to observe the removal.
  • Ask the vendor to confirm whether it also owns robots.txt for the domain — a Disallow rule there is a separate control point from a meta/header directive.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Follow redirects and confirm a crawlable 200 final response with no noindex in any robots/googlebot meta or X-Robots-Tag value.
  2. Confirm the canonical points to the intended URL and relevant caches no longer serve the directive.
  3. Fetch and parse robots.txt for the applicable user-agent group(s) and confirm the URL and its critical rendering resources are not disallowed.
  4. Rerun SEO Site Audit Crawler, On-Page SEO Checker, Google Index Checker, Render Gap, or Robots.txt Tester (whichever surfaced the finding), and use Search Console URL Inspection’s live test for Google’s current view.
 
Escalate when
 
Escalate when page ownership or publication intent is unclear, noindex or a robots.txt Disallow rule is applied by multiple layers, or removing it would expose private, duplicate, or staging content.
 
 
 
 
 
 
 
Google Index Checker · one finding
 
Robots.txt blocks crawling
 
Recommended action: Allow Googlebot to crawl this path in robots.txt, publish the file, then rerun the check.
 
Fix principle: Remove every unintended noindex from its confirmed owner; absence of noindex is sufficient, while an explicit index directive cannot override another noindex because restrictive directives combine.
 
 
 
 Implementation for your setup 
 
Confirm first: The final HTML or HTTP response contains a noindex directive, including one added only by client-side script during rendering. The page is intended to be an indexable canonical URL. A robots meta tag or X-Robots-Tag intended to keep the page indexable is neutralized by a conflicting directive elsewhere, because directives combine using the most restrictive rule. Robots.txt disallows the URL itself, or disallows a resource the page depends on to render, so the crawler cannot reach or fully evaluate the intended indexable page.
 
Do not apply when: Exclusion is intentional for the page type, environment, or workflow state. The directive appears only on a noncanonical or otherwise ineligible URL. Robots.txt does not disallow the URL or the resources it needs to render, and the effective combination of every directive already resolves to the intended indexable state.
 
Likely control points: cms-app · server · edge-cdn
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: The application, server, or edge owner that emits the directive, or the robots.txt file at the site root
 
Steps
  1. Follow redirects, identify the exact owner of each unintended robots/googlebot meta or X-Robots-Tag noindex, and remove it only at that owner.
  2. Return the intended canonical page with a crawlable 200 response, align its canonical, and purge the caches that can retain the directive.
  3. If a robots meta tag or X-Robots-Tag is present but rendered ineffective by a conflicting directive elsewhere, remove the actual unwanted restrictive directive rather than adding a permissive one to compete with it — the most restrictive rule always wins. Google also honors a robots meta tag placed outside <head>, so an out-of-head placement is a specification and cross-crawler risk to correct, not by itself proof Google is ignoring the directive.
  4. If robots.txt disallows the URL itself, or disallows a resource (such as CSS or JS) the page needs to render its content, correct only the specific Disallow rule at the robots.txt file that owns it — keep the rule as narrow as its original intent, and remember Disallow blocks crawling, not indexing: a disallowed URL can still be indexed if discovered elsewhere.
  5. Keep the URL crawlable so Google can observe the removal.
  
Verify on this platform
 
  • After redirects and cache purge, inspect every robots and googlebot meta tag plus every X-Robots-Tag value on the final response.
  • Fetch and parse robots.txt for every group that applies to the relevant user-agent — Google consolidates every group matching the same user-agent token into one effective ruleset, though not every crawler does — and confirm the URL and its critical rendering resources are not disallowed.
  • Use Search Console URL Inspection’s live test on the production URL, then request indexing when appropriate.
 
Rollback
  1. Restore the prior directive or robots.txt rule if the page or a resource it needs was exposed or blocked unintentionally, then correct the underlying publication rule before trying again.
 
Caveats
  • Do not add index as a counter-directive: the most restrictive directive applies, so another noindex still wins.
  • The live test checks current accessibility; it does not guarantee selection, canonical choice, or indexing.
  • Google’s own parser combines every robots.txt group matching the same user-agent token into one effective ruleset, but many other crawlers and Robots Exclusion Protocol implementations honor only the first matching group — treat a directive split across groups as a real interoperability risk even when Google itself is unaffected.
  • If the page combines a canonical to a different URL with a noindex directive, remove the noindex only if this URL itself should be indexable; if the canonical target is the one meant to be indexed, keep the noindex here and verify the canonical target separately rather than treating its indexability as confirmed by removing this noindex.
 
Official sources
 
 
WordPress
 
Status: supported · Location: Global Settings → Reading/blog_public, or the scoped plugin/theme callback that owns wp_robots
 
Steps
  1. If WordPress core globally owns the directive, confirm the scope and change Settings → Reading so blog_public permits search-engine visibility.
  2. For a scoped page-type or URL rule, identify and change the plugin or theme callback filtering wp_robots or invoking the core noindex behavior; do not invent a plugin UI.
  3. Purge page, object, host, and edge caches that can retain the old output.
  
Verify on this platform
 
  • While logged out, follow redirects and inspect all robots/googlebot meta plus X-Robots-Tag values on the final public response.
 
Rollback
  1. Restore the previous visibility or plugin setting if unintended pages become indexable.
 
Caveats
  • Do not use the global Reading setting to solve a scoped plugin or theme rule.
  • WordPress exposes the wp_robots API, but a third-party owner’s exact UI is not verified here.
  • Robots.txt is a separate control point from this meta/header directive — correct a Disallow rule using the generic-http-html guidance above regardless of which CMS serves the site.
 
Official sources
 
 
Cloudflare Workers / Rules
 
Status: supported · Location: Confirmed Response Header Transform Rule or Worker emitter
 
Steps
  1. Use Cloudflare Trace and configuration review to confirm which Transform Rule or Worker adds the final X-Robots-Tag and account for response-header rule ordering.
  2. Narrow or remove only that confirmed edge emitter; in a Worker, clone the response before modifying its headers.
  3. Purge the affected cache entries and leave any valid origin-owned robots header intact.
  
Verify on this platform
 
  • Compare origin and final Cloudflare responses after redirects, then confirm every final robots header and meta directive is free of unintended noindex.
 
Rollback
  1. Restore the prior edge rule if the scope change exposes excluded routes, then replace it with a narrower condition.
 
Caveats
  • Never blanket-delete a valid origin X-Robots-Tag when Cloudflare is not the confirmed emitter.
  • Later response-header rules can override earlier changes, so verify the final rule order and response.
  • Robots.txt is a separate control point from this response-header directive — correct a Disallow rule using the generic-http-html guidance above.
 
Official sources
 
 
Next.js / Vercel
 
Status: supported · Location: App Router metadata/generateMetadata, Pages Router next/head, or next.config headers()
 
Steps
  1. In the App Router, remove the unintended noindex from static metadata.robots or generateMetadata at the route that owns it.
  2. In the Pages Router, correct the owning next/head robots meta; for an X-Robots-Tag, correct the scoped next.config headers() rule.
  3. Deploy to the intended production environment and purge or bypass relevant caches before verification.
  
Verify on this platform
 
  • Inspect all final robots/googlebot meta and X-Robots-Tag values after redirects on the current production deployment.
 
Rollback
  1. Revert the route metadata, Head output, or headers() rule if the deployment exposes a route that should remain excluded.
 
Caveats
  • Vercel intentionally serves X-Robots-Tag: noindex for Preview Deployments and outdated Production Deployments; preserve that protection.
  • Do not diagnose an intentional preview response as a production metadata defect.
  • Robots.txt (a static file or a route handler such as app/robots.ts) is a separate control point from this metadata/header directive — correct a Disallow rule using the generic-http-html guidance above.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor-owned publication, visibility, or response-header control
 
Steps
  1. Ask the vendor to identify the exact global or scoped control that emits noindex and remove it only for the confirmed public canonical URL.
  
Verify on this platform
 
  • Follow redirects and inspect all robots/googlebot meta and X-Robots-Tag values on the final public response, then use the Search Console live test.
 
Rollback
  1. Restore the vendor visibility control if an unintended page becomes public while the owning rule is corrected.
 
Caveats
  • Do not add index to compete with a noindex emitted elsewhere.
  • Keep the URL crawlable long enough for search engines to observe the removal.
  • Ask the vendor to confirm whether it also owns robots.txt for the domain — a Disallow rule there is a separate control point from a meta/header directive.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Follow redirects and confirm a crawlable 200 final response with no noindex in any robots/googlebot meta or X-Robots-Tag value.
  2. Confirm the canonical points to the intended URL and relevant caches no longer serve the directive.
  3. Fetch and parse robots.txt for the applicable user-agent group(s) and confirm the URL and its critical rendering resources are not disallowed.
  4. Rerun SEO Site Audit Crawler, On-Page SEO Checker, Google Index Checker, Render Gap, or Robots.txt Tester (whichever surfaced the finding), and use Search Console URL Inspection’s live test for Google’s current view.
 
Escalate when
 
Escalate when page ownership or publication intent is unclear, noindex or a robots.txt Disallow rule is applied by multiple layers, or removing it would expose private, duplicate, or staging content.
 
 
 
 
 
 
 
Google Index Checker · one finding
 
Canonical points to another URL
 
Recommended action: Point the canonical at the intended preferred URL, or confirm that consolidation is deliberate.
 
Fix principle: Align every canonical signal for a page — the HTML <link rel=canonical>, an HTTP Link header, the post-render DOM, and each page's self-reference inside an hreflang cluster — on one confirmed intended URL; a conflict anywhere in that chain is resolved at its owning layer, never papered over by adding another canonical downstream.
 
 
 
 Implementation for your setup 
 
Confirm first: The page emits zero, more than one, or mutually disagreeing canonical signals across its HTML head, HTTP response header, or post-render DOM. A present canonical signal is relative, points to a URL that does not return a live 200 response, sits outside <head> where crawlers may not honor it, or only appears after client-side JavaScript runs.
 
Do not apply when: Exactly one absolute canonical URL is declared consistently across the HTML head, any HTTP header, and the rendered DOM, and that target itself returns 200. The apparent second reference is a distinct, valid annotation — an hreflang alternate, a pagination rel=next/prev, or another non-canonical link — not a competing canonical claim for the same page.
 
Likely control points: cms-app · server · edge-cdn
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: Origin template, application server, or the layer that emits the HTTP Link header
 
Steps
  1. Enumerate every canonical signal for the URL — the HTML <link rel="canonical">, any HTTP Link: rel="canonical" response header, and the post-render DOM — and identify which layer emits each one.
  2. Choose exactly one intended absolute canonical URL per page and make every signal reproduce it verbatim; never declare a relative canonical, and never let a sitemap entry, redirect target, or hreflang alternate imply a different URL than the declared canonical.
  3. Correct or remove the emitting layer for any conflicting or duplicate signal at its source. Do not add a second, "corrective" canonical on top of an existing one.
  4. Confirm the canonical target itself returns a live 200 response on the protocol and host the site actually serves, not a redirect or error.
  
Verify on this platform
 
  • Fetch the raw response and inspect <head> for exactly one absolute canonical link, then check response headers for at most one agreeing Link: rel="canonical".
  • Confirm the canonical target itself returns 200 without redirecting, then use Search Console URL Inspection to compare the user-declared canonical against the Google-selected canonical.
 
Rollback
  1. Restore the previous canonical annotation or header if the correction points crawlers away from a URL that needs to stay indexed, then re-diagnose the true conflicting layer before trying again.
 
Caveats
  • A declared canonical is a hint, not a directive: Google may select a different URL as canonical for various reasons even when every signal you control agrees.
  • Don't specify different canonical URLs for the same page using different mechanisms (for example, one URL in a sitemap and a different one via rel=canonical) — the conflict itself is the defect, not the presence of any one mechanism.
  • If the page belongs to an hreflang cluster, each localized URL must canonicalize to itself (or its own best-language substitute), not to the primary-language version.
 
Official sources
 
 
WordPress
 
Status: supported · Location: Theme output via the wp_head hook, or the single plugin/theme layer that has taken over the canonical tag
 
Steps
  1. Confirm WordPress core's native rel_canonical() output — hooked on wp_head — is the only source of the canonical tag, or that exactly one SEO plugin or theme has deliberately taken over that responsibility. Never leave two layers emitting a tag for the same page.
  2. If a plugin, theme, or manual template edit adds a second <link rel="canonical"> or a conflicting header, correct or remove it at that specific owning layer; do not add a third tag to compensate.
  3. Confirm the intended canonical target is the live, indexable URL the site actually wants, not a query-parameter, paginated, or otherwise non-canonical variant.
  
Verify on this platform
 
  • While logged out, view the public HTML source once and confirm a single <link rel="canonical"> matching the intended URL, then confirm no HTTP Link header contradicts it.
 
Rollback
  1. Restore the previous theme or plugin canonical configuration if removing a tag causes an unintended page to lose its canonical reference, then correct the true conflicting layer before trying again.
 
Caveats
  • Do not invent a specific SEO plugin's settings path: WordPress core exposes wp_get_canonical_url() and rel_canonical() on wp_head, but which plugin or theme, if any, has overridden that output is not verified here.
  • A page builder or headless WordPress frontend is owner-managed; use that system's own verified workflow instead of assuming core theme output controls the response.
 
Official sources
 
 
Next.js / Vercel
 
Status: supported · Location: metadata.alternates.canonical / generateMetadata in the App Router, or next/head output in the Pages Router
 
Steps
  1. Set metadata.alternates.canonical (or the equivalent value returned from generateMetadata) to one absolute intended URL per App Router route; in the Pages Router, emit exactly one canonical <link> via next/head.
  2. Set metadataBase once at the root layout so relative canonical values resolve against the correct production host, instead of leaving canonical relative or inconsistent between preview and production domains.
  3. Do not also emit a second canonical tag from a component, a custom document, or an edge Proxy/Middleware response header once the metadata API owns the output.
  4. If the route belongs to an hreflang cluster, pair alternates.canonical with alternates.languages so each localized route canonicalizes to itself.
  
Verify on this platform
 
  • Fetch the deployed production route without executing JavaScript, confirm exactly one <link rel="canonical"> with the intended absolute URL, then rerun Canonicalization Checker or Render Gap on the same URL.
 
Rollback
  1. Revert the metadata export or route segment if the deployment changes the canonical for a route that needs to keep its prior target, then correct the actual conflicting layer before redeploying.
 
Caveats
  • metadataBase only fills in relative values; an already-absolute canonical value is used as-is and ignores metadataBase.
  • Confirm the production deployment domain matches the intended canonical host — a Preview Deployment URL is never the intended canonical target.
 
Official sources
 
 
Shopify
 
Status: supported · Location: Online Store theme.liquid head output via the canonical_url Liquid object
 
Steps
  1. Duplicate the active theme and confirm theme.liquid emits exactly one <link rel="canonical" href="{{ canonical_url }}" /> in the head; Shopify's canonical_url object already resolves to the platform's intended canonical for standard product, collection, and content pages.
  2. If a second canonical tag is present — added by an app embed, a theme customization, or a duplicated snippet — remove it at that specific source rather than editing canonical_url itself.
  3. Preview representative product, collection, and content routes before publishing the corrected duplicate theme.
  
Verify on this platform
 
  • Inspect the published storefront response without browser execution and confirm a single canonical tag reflecting canonical_url on each route type.
 
Rollback
  1. Republish the previous theme if the corrected theme regresses canonical output or storefront functionality.
 
Caveats
  • These steps apply only to Shopify Online Store Liquid/JSON themes using the canonical_url object.
  • An app-owned storefront, a Hydrogen implementation, or an app that injects its own canonical tag is owner-managed; verify that system's own workflow rather than assuming theme.liquid is the only emitter.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor-owned page builder, headless frontend, or hosted platform template
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor to confirm which single layer emits the canonical tag and header for the URL, then compare the user-declared and Google-selected canonical in Search Console URL Inspection.
  
Caveats
  • Escalate when the vendor cannot identify or expose the layer that emits a conflicting or duplicate canonical signal.
  • Do not accept a claim that the canonical is correct without one production-URL response showing a single agreeing signal.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Fetch the raw response and confirm exactly one canonical signal (the HTML tag and, if present, the HTTP header) names the same absolute, live URL.
  2. Confirm the canonical target itself returns 200 without redirecting.
  3. Compare the user-declared canonical against Google's selected canonical in Search Console URL Inspection.
  4. Rerun the finding's originating tool (Canonicalization Checker, On-Page SEO Checker, SEO Site Audit Crawler, Render Gap, Google Index Checker, or HTTP Header Checker) on the same production URL.
 
Escalate when
 
Escalate when ownership of the emitting layer is unclear, more than one system claims to own the canonical output, or Google's selected canonical keeps diverging from the declared canonical after every signal you control has been made consistent.
 
 
 
 
 
 
 
Google Index Checker · one finding
 
URL redirects before evaluation
 
Recommended action: Update the source to use the live final URL directly, then rerun the check.
 
Fix principle: Trace every hop from the original URL to its terminus, diagnose which layer emits each hop (CMS canonicalization, application code, web-server config, edge/CDN rule, or vendor platform) and which specific failure shape is present — a loop, a dead end, an HTTPS-to-HTTP downgrade, an unexpected cross-domain change, a meta refresh standing in for a server redirect, or a chain exceeding the trace limit — then collapse the chain to a single server-side redirect straight to a confirmed live 200 destination at the layer that actually owns it. Never add a compensating redirect on top of a broken one.
 
 
 
 Implementation for your setup 
 
Confirm first: Tracing the URL through its actual HTTP responses shows more than one hop, a revisited URL (a loop), or a final hop that is not a live 2xx response. A hop changes protocol from HTTPS to HTTP, changes host/domain unexpectedly, or is implemented as an HTML meta refresh or JavaScript redirect instead of a server-side response.
 
Do not apply when: The URL resolves in a single hop directly to a live 200 response, with no protocol downgrade, no unexpected host change, and no loop. The extra hop is a single, intentional, same-domain, HTTPS-preserving server-side redirect with a live 200 terminus — a minor inefficiency, not a broken chain.
 
Likely control points: cms-app · server · edge-cdn · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: The observed HTTP response chain, traced hop by hop from the original URL
 
Steps
  1. Trace every hop from the original URL to its terminus, recording the status code, the Location header (or the meta refresh delay/target), and the scheme and host at each step.
  2. Classify the failure by shape before changing anything: a loop (a URL reappears in the trace), a dead end (the final hop is not a live 2xx response), a scheme downgrade (a hop changes https to http), a cross-domain change (a hop changes host unexpectedly), a meta refresh element standing in for a server response, or a chain that exceeds the checking tool's or server's hop-trace limit.
  3. Identify the exact owning layer for the hop that needs to change — CMS canonicalization, application code, web-server config, edge/CDN rule, or vendor platform — before editing anything; the same symptom can originate at different layers on different sites.
  4. Replace every intermediate hop with a single server-side 301 (or 308 only where the method and body must be preserved) directly from the original URL to the confirmed live 200 destination.
  5. Convert a meta refresh or JavaScript redirect to a real server-side redirect: Google treats an instant meta refresh as a permanent redirect and a delayed one as temporary, but recommends server-side redirects over meta refresh or JavaScript redirects whenever they are possible.
  
Verify on this platform
 
  • Re-trace the URL end to end and confirm exactly one hop lands on a live 200 response, with no loop, no downgrade, and no unexpected host change.
  • Confirm required query parameters are preserved in the Location value, and re-test representative internal links, canonical tags, and sitemap entries that pointed at the old intermediate URL.
 
Rollback
  1. Restore the previous redirect rule or response at the corrected layer if the collapsed redirect sends users or crawlers to the wrong destination or breaks a dependent flow.
 
Caveats
  • A redirect loop can span multiple servers or layers, each of which only sees part of the picture; fix the confirmed owning layer, not just the layer where the loop was first observed.
  • Keep the fix to the exact hop that is wrong — do not collapse an intentional, correctly-scoped single hop (for example a legitimate HTTP→HTTPS or trailing-slash redirect) into the change.
 
Official sources
 
 
Apache
 
Status: supported · Location: .htaccess or virtual host configuration (mod_alias Redirect/RedirectMatch, or mod_rewrite)
 
Steps
  1. Locate every Redirect, RedirectMatch, or RewriteRule directive that touches the URL's path, across every applicable config file and .htaccess in the path hierarchy.
  2. Replace the chain with a single `Redirect permanent` (or `RedirectMatch permanent` for a pattern-based path) issuing one 301 straight to the confirmed live final URL, and remove the superseded intermediate directive(s) entirely.
  3. For an HTTPS downgrade or a cross-domain hop, correct the target scheme/host in that same directive rather than adding another redirect after it.
  
Verify on this platform
 
  • Reload the corrected configuration, then re-fetch the URL and confirm a single 301 response with the corrected Location header lands directly on a live 200.
 
Rollback
  1. Restore the previous Redirect/RedirectMatch/RewriteRule directive(s) if the corrected chain misroutes traffic.
 
Caveats
  • Redirect directives take precedence over Alias and ScriptAlias directives regardless of the order they appear in the file, and can silently shadow a rule you expect to run first; when several Redirect/RedirectMatch directives apply to the same sub-path, the most specific path must be listed first.
 
Official sources
 
 
Nginx
 
Status: supported · Location: server/location blocks (return or rewrite directives)
 
Steps
  1. Find every `return 3xx` or `rewrite ... permanent`/`redirect` directive that touches the path, including one in a different server block for an old host or scheme.
  2. Replace them with a single `return 301 <final-url>;` (or 308 only where method/body must be preserved) in the location that receives the original request, and delete the superseded intermediate directive(s).
  3. When consolidating rewrite rules inside a location block, use the `break` flag rather than `last` — nginx caps internal rewrite/rewrite-loop processing at 10 iterations and returns a 500 once that limit is exceeded, which is a distinct cause of a chain-shaped failure from a client-visible HTTP loop.
  
Verify on this platform
 
  • Run `nginx -t` to validate the configuration, reload, then re-fetch the URL and confirm a single 301/308 response lands directly on the live destination.
 
Rollback
  1. Restore the previous return/rewrite directive(s) if the consolidated redirect misroutes traffic.
 
Caveats
  • nginx enforces its own internal rewrite-cycle limit (10 iterations, then a 500) separately from any client-facing redirect loop a browser or crawler reports; confirm which one is actually occurring before changing rules.
 
Official sources
 
 
Cloudflare Workers / Rules
 
Status: supported · Location: Bulk Redirects or Redirect Rules in the Cloudflare dashboard, or a Worker
 
Steps
  1. Confirm whether the hop is actually emitted by an edge redirect rule at all: Cloudflare Bulk Redirects and Redirect Rules run in the request-processing pipeline after WAF evaluation, so a rule can appear not to fire when a WAF action intercepts the request first.
  2. Consolidate every edge-owned hop for the URL into a single Bulk Redirect (or Redirect Rule) issuing one status code straight to the confirmed live destination, and remove the superseded rule(s) rather than layering a new one on top.
  3. If a Worker also emits a redirect for the same path, resolve the collision there — decide which layer owns the redirect and remove it from the other, rather than running both.
  
Verify on this platform
 
  • Purge the affected cache path, then re-fetch the URL through Cloudflare and confirm one edge-issued redirect lands directly on the live destination, unaffected by a WAF action.
 
Rollback
  1. Restore the previous edge rule (or disable the new one) if the consolidated redirect misroutes traffic or interacts badly with a WAF rule.
 
Caveats
  • Bulk Redirects are static and cannot use regex or string replacement; a pattern-based collapse needs a Redirect Rule or a Worker instead.
  • A WAF rule that blocks or challenges a request can prevent the edge redirect from ever running; that looks like a missing hop, not a rule conflict, until the WAF layer is checked.
 
Official sources
 
 
WordPress
 
Status: supported · Location: WordPress core's own canonical-redirect layer (redirect_canonical()) plus whichever layer implements the explicit redirect
 
Steps
  1. Determine whether one hop in the chain is WordPress core's own automatic canonicalization (`redirect_canonical()`, which normalizes trailing slashes, the www prefix, and stray query parameters such as `?p=` or `?page_id=`) rather than a manually configured redirect.
  2. If the automatic canonical hop is unwanted for a confirmed, intentional exception, remove it only for that case using the `redirect_canonical` filter — do not disable core canonicalization site-wide.
  3. WordPress core has no admin UI for managing arbitrary URL-to-URL redirects. Implement or correct the actual explicit redirect at the layer that owns it — the web-server configuration (see the generic-http-html, Apache, or Nginx guidance in this recipe) or a redirect-management plugin the site owner has already vetted. Do not invent a plugin's UI or assume one exists.
  
Verify on this platform
 
  • While logged out, re-trace the URL and confirm it reaches a live 200 response in one hop, and that WordPress core's canonical redirect no longer stacks with a separate redirect layer.
 
Rollback
  1. Remove the `redirect_canonical` filter override, or restore the previous server-config or plugin-level redirect rule, if the change misroutes traffic.
 
Caveats
  • Custom code that calls `wp_redirect()` with a user-supplied destination is vulnerable to open redirects; use `wp_safe_redirect()` instead for any redirect target that is not a trusted, hardcoded URL.
  • A page builder or headless WordPress frontend owns its own redirect behavior; treat it as platform-managed rather than assuming core template control applies.
 
Official sources
 
 
Shopify
 
Status: supported · Location: Shopify admin: Content → Menus → URL redirects
 
Steps
  1. Confirm the source path is actually broken (returns a 404) — Shopify's URL redirect feature only redirects from broken URLs, and rejects redirects from reserved paths (`/apps`, `/cart`, `/orders`, `/services`, `/shop`) and from fixed paths such as `/products`, `/collections`, and `/collections/all`.
  2. Point the redirect entry directly at the final live destination rather than at another URL that is itself a redirect entry, and delete the superseded intermediate entry so the store issues exactly one hop.
  3. If the destination page's visibility is later restored, Shopify automatically deletes the associated redirect entry; recheck for a reappeared broken URL after any content-visibility change that seems to have "un-fixed" a redirect.
  
Verify on this platform
 
  • Re-fetch the original broken URL and confirm it now redirects in a single hop to a live 200 destination.
 
Rollback
  1. Restore the previous redirect entry (or recreate it pointing at its prior destination) if the new destination misroutes traffic.
 
Caveats
  • Stores are limited to 100,000 URL redirects (20,000,000 on Shopify Plus); a large migration needs bulk CSV management rather than one-by-one entries.
  • An app-owned storefront or Hydrogen implementation is owner-managed and needs its own verified redirect workflow.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor-owned redirect, routing, or CDN configuration
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor to trace every hop for the URL and confirm the final destination is a live 200 response with no loop, downgrade, cross-domain change, or meta refresh substituting for a proper server-side redirect.
  
Caveats
  • Escalate when the vendor cannot expose or correct the exact rule emitting a hop.
  • Do not accept a claim that the URL "eventually works" as equivalent to a single verified hop landing on a live 200 response.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Trace the full redirect chain end to end and confirm exactly one hop lands on a live 200 response.
  2. Confirm the redirect is a real server-side response (301/308 for a permanent move), not a meta refresh or JavaScript redirect standing in for one.
  3. Re-inspect the corrected URL with Search Console's URL Inspection live test after deployment.
  4. Rerun Redirect Checker (and Redirect Chain Mapper, where the finding came from it) against the corrected URL.
 
Escalate when
 
Escalate when the loop or chain spans multiple systems or owners, the intended final destination is not itself confirmed live, the fix would change authentication or session behavior, or a vendor platform cannot expose or correct the layer emitting the hop.
 
 
 
 
 
 
 
Google Index Checker · one finding
 
URL is not a live 2xx response
 
Recommended action: Restore a live 2xx response at the evaluated URL, then rerun the check.
 
Fix principle: Trace every hop from the original URL to its terminus, diagnose which layer emits each hop (CMS canonicalization, application code, web-server config, edge/CDN rule, or vendor platform) and which specific failure shape is present — a loop, a dead end, an HTTPS-to-HTTP downgrade, an unexpected cross-domain change, a meta refresh standing in for a server redirect, or a chain exceeding the trace limit — then collapse the chain to a single server-side redirect straight to a confirmed live 200 destination at the layer that actually owns it. Never add a compensating redirect on top of a broken one.
 
 
 
 Implementation for your setup 
 
Confirm first: Tracing the URL through its actual HTTP responses shows more than one hop, a revisited URL (a loop), or a final hop that is not a live 2xx response. A hop changes protocol from HTTPS to HTTP, changes host/domain unexpectedly, or is implemented as an HTML meta refresh or JavaScript redirect instead of a server-side response.
 
Do not apply when: The URL resolves in a single hop directly to a live 200 response, with no protocol downgrade, no unexpected host change, and no loop. The extra hop is a single, intentional, same-domain, HTTPS-preserving server-side redirect with a live 200 terminus — a minor inefficiency, not a broken chain.
 
Likely control points: cms-app · server · edge-cdn · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: The observed HTTP response chain, traced hop by hop from the original URL
 
Steps
  1. Trace every hop from the original URL to its terminus, recording the status code, the Location header (or the meta refresh delay/target), and the scheme and host at each step.
  2. Classify the failure by shape before changing anything: a loop (a URL reappears in the trace), a dead end (the final hop is not a live 2xx response), a scheme downgrade (a hop changes https to http), a cross-domain change (a hop changes host unexpectedly), a meta refresh element standing in for a server response, or a chain that exceeds the checking tool's or server's hop-trace limit.
  3. Identify the exact owning layer for the hop that needs to change — CMS canonicalization, application code, web-server config, edge/CDN rule, or vendor platform — before editing anything; the same symptom can originate at different layers on different sites.
  4. Replace every intermediate hop with a single server-side 301 (or 308 only where the method and body must be preserved) directly from the original URL to the confirmed live 200 destination.
  5. Convert a meta refresh or JavaScript redirect to a real server-side redirect: Google treats an instant meta refresh as a permanent redirect and a delayed one as temporary, but recommends server-side redirects over meta refresh or JavaScript redirects whenever they are possible.
  
Verify on this platform
 
  • Re-trace the URL end to end and confirm exactly one hop lands on a live 200 response, with no loop, no downgrade, and no unexpected host change.
  • Confirm required query parameters are preserved in the Location value, and re-test representative internal links, canonical tags, and sitemap entries that pointed at the old intermediate URL.
 
Rollback
  1. Restore the previous redirect rule or response at the corrected layer if the collapsed redirect sends users or crawlers to the wrong destination or breaks a dependent flow.
 
Caveats
  • A redirect loop can span multiple servers or layers, each of which only sees part of the picture; fix the confirmed owning layer, not just the layer where the loop was first observed.
  • Keep the fix to the exact hop that is wrong — do not collapse an intentional, correctly-scoped single hop (for example a legitimate HTTP→HTTPS or trailing-slash redirect) into the change.
 
Official sources
 
 
Apache
 
Status: supported · Location: .htaccess or virtual host configuration (mod_alias Redirect/RedirectMatch, or mod_rewrite)
 
Steps
  1. Locate every Redirect, RedirectMatch, or RewriteRule directive that touches the URL's path, across every applicable config file and .htaccess in the path hierarchy.
  2. Replace the chain with a single `Redirect permanent` (or `RedirectMatch permanent` for a pattern-based path) issuing one 301 straight to the confirmed live final URL, and remove the superseded intermediate directive(s) entirely.
  3. For an HTTPS downgrade or a cross-domain hop, correct the target scheme/host in that same directive rather than adding another redirect after it.
  
Verify on this platform
 
  • Reload the corrected configuration, then re-fetch the URL and confirm a single 301 response with the corrected Location header lands directly on a live 200.
 
Rollback
  1. Restore the previous Redirect/RedirectMatch/RewriteRule directive(s) if the corrected chain misroutes traffic.
 
Caveats
  • Redirect directives take precedence over Alias and ScriptAlias directives regardless of the order they appear in the file, and can silently shadow a rule you expect to run first; when several Redirect/RedirectMatch directives apply to the same sub-path, the most specific path must be listed first.
 
Official sources
 
 
Nginx
 
Status: supported · Location: server/location blocks (return or rewrite directives)
 
Steps
  1. Find every `return 3xx` or `rewrite ... permanent`/`redirect` directive that touches the path, including one in a different server block for an old host or scheme.
  2. Replace them with a single `return 301 <final-url>;` (or 308 only where method/body must be preserved) in the location that receives the original request, and delete the superseded intermediate directive(s).
  3. When consolidating rewrite rules inside a location block, use the `break` flag rather than `last` — nginx caps internal rewrite/rewrite-loop processing at 10 iterations and returns a 500 once that limit is exceeded, which is a distinct cause of a chain-shaped failure from a client-visible HTTP loop.
  
Verify on this platform
 
  • Run `nginx -t` to validate the configuration, reload, then re-fetch the URL and confirm a single 301/308 response lands directly on the live destination.
 
Rollback
  1. Restore the previous return/rewrite directive(s) if the consolidated redirect misroutes traffic.
 
Caveats
  • nginx enforces its own internal rewrite-cycle limit (10 iterations, then a 500) separately from any client-facing redirect loop a browser or crawler reports; confirm which one is actually occurring before changing rules.
 
Official sources
 
 
Cloudflare Workers / Rules
 
Status: supported · Location: Bulk Redirects or Redirect Rules in the Cloudflare dashboard, or a Worker
 
Steps
  1. Confirm whether the hop is actually emitted by an edge redirect rule at all: Cloudflare Bulk Redirects and Redirect Rules run in the request-processing pipeline after WAF evaluation, so a rule can appear not to fire when a WAF action intercepts the request first.
  2. Consolidate every edge-owned hop for the URL into a single Bulk Redirect (or Redirect Rule) issuing one status code straight to the confirmed live destination, and remove the superseded rule(s) rather than layering a new one on top.
  3. If a Worker also emits a redirect for the same path, resolve the collision there — decide which layer owns the redirect and remove it from the other, rather than running both.
  
Verify on this platform
 
  • Purge the affected cache path, then re-fetch the URL through Cloudflare and confirm one edge-issued redirect lands directly on the live destination, unaffected by a WAF action.
 
Rollback
  1. Restore the previous edge rule (or disable the new one) if the consolidated redirect misroutes traffic or interacts badly with a WAF rule.
 
Caveats
  • Bulk Redirects are static and cannot use regex or string replacement; a pattern-based collapse needs a Redirect Rule or a Worker instead.
  • A WAF rule that blocks or challenges a request can prevent the edge redirect from ever running; that looks like a missing hop, not a rule conflict, until the WAF layer is checked.
 
Official sources
 
 
WordPress
 
Status: supported · Location: WordPress core's own canonical-redirect layer (redirect_canonical()) plus whichever layer implements the explicit redirect
 
Steps
  1. Determine whether one hop in the chain is WordPress core's own automatic canonicalization (`redirect_canonical()`, which normalizes trailing slashes, the www prefix, and stray query parameters such as `?p=` or `?page_id=`) rather than a manually configured redirect.
  2. If the automatic canonical hop is unwanted for a confirmed, intentional exception, remove it only for that case using the `redirect_canonical` filter — do not disable core canonicalization site-wide.
  3. WordPress core has no admin UI for managing arbitrary URL-to-URL redirects. Implement or correct the actual explicit redirect at the layer that owns it — the web-server configuration (see the generic-http-html, Apache, or Nginx guidance in this recipe) or a redirect-management plugin the site owner has already vetted. Do not invent a plugin's UI or assume one exists.
  
Verify on this platform
 
  • While logged out, re-trace the URL and confirm it reaches a live 200 response in one hop, and that WordPress core's canonical redirect no longer stacks with a separate redirect layer.
 
Rollback
  1. Remove the `redirect_canonical` filter override, or restore the previous server-config or plugin-level redirect rule, if the change misroutes traffic.
 
Caveats
  • Custom code that calls `wp_redirect()` with a user-supplied destination is vulnerable to open redirects; use `wp_safe_redirect()` instead for any redirect target that is not a trusted, hardcoded URL.
  • A page builder or headless WordPress frontend owns its own redirect behavior; treat it as platform-managed rather than assuming core template control applies.
 
Official sources
 
 
Shopify
 
Status: supported · Location: Shopify admin: Content → Menus → URL redirects
 
Steps
  1. Confirm the source path is actually broken (returns a 404) — Shopify's URL redirect feature only redirects from broken URLs, and rejects redirects from reserved paths (`/apps`, `/cart`, `/orders`, `/services`, `/shop`) and from fixed paths such as `/products`, `/collections`, and `/collections/all`.
  2. Point the redirect entry directly at the final live destination rather than at another URL that is itself a redirect entry, and delete the superseded intermediate entry so the store issues exactly one hop.
  3. If the destination page's visibility is later restored, Shopify automatically deletes the associated redirect entry; recheck for a reappeared broken URL after any content-visibility change that seems to have "un-fixed" a redirect.
  
Verify on this platform
 
  • Re-fetch the original broken URL and confirm it now redirects in a single hop to a live 200 destination.
 
Rollback
  1. Restore the previous redirect entry (or recreate it pointing at its prior destination) if the new destination misroutes traffic.
 
Caveats
  • Stores are limited to 100,000 URL redirects (20,000,000 on Shopify Plus); a large migration needs bulk CSV management rather than one-by-one entries.
  • An app-owned storefront or Hydrogen implementation is owner-managed and needs its own verified redirect workflow.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor-owned redirect, routing, or CDN configuration
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor to trace every hop for the URL and confirm the final destination is a live 200 response with no loop, downgrade, cross-domain change, or meta refresh substituting for a proper server-side redirect.
  
Caveats
  • Escalate when the vendor cannot expose or correct the exact rule emitting a hop.
  • Do not accept a claim that the URL "eventually works" as equivalent to a single verified hop landing on a live 200 response.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Trace the full redirect chain end to end and confirm exactly one hop lands on a live 200 response.
  2. Confirm the redirect is a real server-side response (301/308 for a permanent move), not a meta refresh or JavaScript redirect standing in for one.
  3. Re-inspect the corrected URL with Search Console's URL Inspection live test after deployment.
  4. Rerun Redirect Checker (and Redirect Chain Mapper, where the finding came from it) against the corrected URL.
 
Escalate when
 
Escalate when the loop or chain spans multiple systems or owners, the intended final destination is not itself confirmed live, the fix would change authentication or session behavior, or a vendor platform cannot expose or correct the layer emitting the hop.
 
 
 
 
 
 
 
Google Index Checker · one finding
 
Sitemap URL is missing from the index set
 
Recommended action: Verify the URL is canonical, indexable, useful, and internally linked, then inspect its exclusion reason in URL Inspection.
 
Fix principle: Sitemap membership, canonical intent, and observed index membership are three different evidence sets. Decide which URL should be indexed, then correct the set that contradicts that intent instead of assuming either the sitemap or observed index is automatically authoritative.
 
 
 
 Implementation for your setup 
 
Confirm first: A canonical URL intended for search is absent from the sitemap or observed index without an explained crawl, quality, or eligibility reason. A non-canonical, redirected, blocked, noindexed, duplicate, or retired URL remains in the sitemap or observed index set. The declared canonical and the URL selected or represented in supplied index evidence disagree.
 
Do not apply when: The sitemap contains only absolute, canonical, index-intended URLs that return successful responses. Every mismatch has a documented intended state and the contradictory sitemap, canonical, robots/noindex, redirect, or content signal has been corrected at its owner.
 
Likely control points: cms-app · server · content-data · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: Canonical URL policy, sitemap generator, response/indexing directives, and Search Console evidence
 
Steps
  1. Create an intended-index set first: the canonical URLs the site actually wants eligible for search.
  2. Compare that set with sitemap membership, live response/canonical/robots evidence, and supplied index evidence; classify each mismatch by the set that is wrong.
  3. Remove redirected, non-canonical, noindexed, blocked, duplicate, or retired URLs from the sitemap and add missing intended canonical URLs only after their live signals agree.
  4. Correct conflicting canonical, robots, noindex, redirect, or duplicate-content signals at their owning template or response layer.
  5. Resubmit the corrected sitemap and inspect representative URLs; do not claim immediate indexing because sitemap submission is a hint, not a guarantee.
  
Verify on this platform
 
  • Validate that every sitemap URL is absolute, successful, canonical, and intended for indexing.
  • Inspect representative mismatch classes and confirm the live URL reports the intended response, canonical, and indexing directives.
  • Re-run the set comparison after Google has had time to recrawl; preserve pending versus evaluated states.
 
Rollback
  1. Restore the prior sitemap generation rule if the change removes legitimate canonical inventory.
  2. Revert only the specific canonical or directive change that contradicted confirmed intent, then re-evaluate the affected URLs.
 
Caveats
  • Index membership is observational and delayed; absence from a supplied export is not proof of a technical defect.
  • Do not put every discovered URL in a sitemap. Sitemaps should express preferred canonical inventory.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor sitemap, canonical, and indexing controls
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor how it chooses sitemap URLs and whether redirected, noindexed, non-canonical, or unpublished URLs can enter the generated file.
  • Independently fetch representative URLs and compare the generated sitemap with the intended canonical set.
  
Caveats
  • Escalate when the vendor cannot exclude incorrect URLs or explain which template owns canonical output.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Define the intended canonical index set before modifying any source.
  2. Require sitemap URLs to be absolute, successful, canonical, and index-intended.
  3. Verify the live response and directives for each mismatch class.
  4. Recompare after recrawl without turning pending or unavailable index evidence into a pass.
 
Escalate when
 
Escalate when canonical intent is disputed, the supplied index evidence is incomplete or stale, or different systems independently generate the sitemap and canonical signals.
 
 
 
 
 
 
 
Google Index Checker · one finding
 
Indexed URL is absent from the sitemap
 
Recommended action: Add the canonical indexable URL to the sitemap or confirm its deliberate exclusion and remove stale variants.
 
Fix principle: Sitemap membership, canonical intent, and observed index membership are three different evidence sets. Decide which URL should be indexed, then correct the set that contradicts that intent instead of assuming either the sitemap or observed index is automatically authoritative.
 
 
 
 Implementation for your setup 
 
Confirm first: A canonical URL intended for search is absent from the sitemap or observed index without an explained crawl, quality, or eligibility reason. A non-canonical, redirected, blocked, noindexed, duplicate, or retired URL remains in the sitemap or observed index set. The declared canonical and the URL selected or represented in supplied index evidence disagree.
 
Do not apply when: The sitemap contains only absolute, canonical, index-intended URLs that return successful responses. Every mismatch has a documented intended state and the contradictory sitemap, canonical, robots/noindex, redirect, or content signal has been corrected at its owner.
 
Likely control points: cms-app · server · content-data · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: Canonical URL policy, sitemap generator, response/indexing directives, and Search Console evidence
 
Steps
  1. Create an intended-index set first: the canonical URLs the site actually wants eligible for search.
  2. Compare that set with sitemap membership, live response/canonical/robots evidence, and supplied index evidence; classify each mismatch by the set that is wrong.
  3. Remove redirected, non-canonical, noindexed, blocked, duplicate, or retired URLs from the sitemap and add missing intended canonical URLs only after their live signals agree.
  4. Correct conflicting canonical, robots, noindex, redirect, or duplicate-content signals at their owning template or response layer.
  5. Resubmit the corrected sitemap and inspect representative URLs; do not claim immediate indexing because sitemap submission is a hint, not a guarantee.
  
Verify on this platform
 
  • Validate that every sitemap URL is absolute, successful, canonical, and intended for indexing.
  • Inspect representative mismatch classes and confirm the live URL reports the intended response, canonical, and indexing directives.
  • Re-run the set comparison after Google has had time to recrawl; preserve pending versus evaluated states.
 
Rollback
  1. Restore the prior sitemap generation rule if the change removes legitimate canonical inventory.
  2. Revert only the specific canonical or directive change that contradicted confirmed intent, then re-evaluate the affected URLs.
 
Caveats
  • Index membership is observational and delayed; absence from a supplied export is not proof of a technical defect.
  • Do not put every discovered URL in a sitemap. Sitemaps should express preferred canonical inventory.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor sitemap, canonical, and indexing controls
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor how it chooses sitemap URLs and whether redirected, noindexed, non-canonical, or unpublished URLs can enter the generated file.
  • Independently fetch representative URLs and compare the generated sitemap with the intended canonical set.
  
Caveats
  • Escalate when the vendor cannot exclude incorrect URLs or explain which template owns canonical output.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Define the intended canonical index set before modifying any source.
  2. Require sitemap URLs to be absolute, successful, canonical, and index-intended.
  3. Verify the live response and directives for each mismatch class.
  4. Recompare after recrawl without turning pending or unavailable index evidence into a pass.
 
Escalate when
 
Escalate when canonical intent is disputed, the supplied index evidence is incomplete or stale, or different systems independently generate the sitemap and canonical signals.
 
 
 
 
 
 
 
Google Index Checker · one finding
 
Indexed URL conflicts with the canonical set
 
Recommended action: Choose the preferred URL and align sitemap membership, canonical tags, redirects, and internal links to it.
 
Fix principle: Sitemap membership, canonical intent, and observed index membership are three different evidence sets. Decide which URL should be indexed, then correct the set that contradicts that intent instead of assuming either the sitemap or observed index is automatically authoritative.
 
 
 
 Implementation for your setup 
 
Confirm first: A canonical URL intended for search is absent from the sitemap or observed index without an explained crawl, quality, or eligibility reason. A non-canonical, redirected, blocked, noindexed, duplicate, or retired URL remains in the sitemap or observed index set. The declared canonical and the URL selected or represented in supplied index evidence disagree.
 
Do not apply when: The sitemap contains only absolute, canonical, index-intended URLs that return successful responses. Every mismatch has a documented intended state and the contradictory sitemap, canonical, robots/noindex, redirect, or content signal has been corrected at its owner.
 
Likely control points: cms-app · server · content-data · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: Canonical URL policy, sitemap generator, response/indexing directives, and Search Console evidence
 
Steps
  1. Create an intended-index set first: the canonical URLs the site actually wants eligible for search.
  2. Compare that set with sitemap membership, live response/canonical/robots evidence, and supplied index evidence; classify each mismatch by the set that is wrong.
  3. Remove redirected, non-canonical, noindexed, blocked, duplicate, or retired URLs from the sitemap and add missing intended canonical URLs only after their live signals agree.
  4. Correct conflicting canonical, robots, noindex, redirect, or duplicate-content signals at their owning template or response layer.
  5. Resubmit the corrected sitemap and inspect representative URLs; do not claim immediate indexing because sitemap submission is a hint, not a guarantee.
  
Verify on this platform
 
  • Validate that every sitemap URL is absolute, successful, canonical, and intended for indexing.
  • Inspect representative mismatch classes and confirm the live URL reports the intended response, canonical, and indexing directives.
  • Re-run the set comparison after Google has had time to recrawl; preserve pending versus evaluated states.
 
Rollback
  1. Restore the prior sitemap generation rule if the change removes legitimate canonical inventory.
  2. Revert only the specific canonical or directive change that contradicted confirmed intent, then re-evaluate the affected URLs.
 
Caveats
  • Index membership is observational and delayed; absence from a supplied export is not proof of a technical defect.
  • Do not put every discovered URL in a sitemap. Sitemaps should express preferred canonical inventory.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor sitemap, canonical, and indexing controls
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor how it chooses sitemap URLs and whether redirected, noindexed, non-canonical, or unpublished URLs can enter the generated file.
  • Independently fetch representative URLs and compare the generated sitemap with the intended canonical set.
  
Caveats
  • Escalate when the vendor cannot exclude incorrect URLs or explain which template owns canonical output.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Define the intended canonical index set before modifying any source.
  2. Require sitemap URLs to be absolute, successful, canonical, and index-intended.
  3. Verify the live response and directives for each mismatch class.
  4. Recompare after recrawl without turning pending or unavailable index evidence into a pass.
 
Escalate when
 
Escalate when canonical intent is disputed, the supplied index evidence is incomplete or stale, or different systems independently generate the sitemap and canonical signals.
 
 
 
 
 
 
 
Google Index Checker · one finding
 
Expected indexed URL is blocked by robots
 
Recommended action: Remove or narrow the robots.txt rule when the expected URL must be crawled and indexed.
 
Fix principle: Sitemap membership, canonical intent, and observed index membership are three different evidence sets. Decide which URL should be indexed, then correct the set that contradicts that intent instead of assuming either the sitemap or observed index is automatically authoritative.
 
 
 
 Implementation for your setup 
 
Confirm first: A canonical URL intended for search is absent from the sitemap or observed index without an explained crawl, quality, or eligibility reason. A non-canonical, redirected, blocked, noindexed, duplicate, or retired URL remains in the sitemap or observed index set. The declared canonical and the URL selected or represented in supplied index evidence disagree.
 
Do not apply when: The sitemap contains only absolute, canonical, index-intended URLs that return successful responses. Every mismatch has a documented intended state and the contradictory sitemap, canonical, robots/noindex, redirect, or content signal has been corrected at its owner.
 
Likely control points: cms-app · server · content-data · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: Canonical URL policy, sitemap generator, response/indexing directives, and Search Console evidence
 
Steps
  1. Create an intended-index set first: the canonical URLs the site actually wants eligible for search.
  2. Compare that set with sitemap membership, live response/canonical/robots evidence, and supplied index evidence; classify each mismatch by the set that is wrong.
  3. Remove redirected, non-canonical, noindexed, blocked, duplicate, or retired URLs from the sitemap and add missing intended canonical URLs only after their live signals agree.
  4. Correct conflicting canonical, robots, noindex, redirect, or duplicate-content signals at their owning template or response layer.
  5. Resubmit the corrected sitemap and inspect representative URLs; do not claim immediate indexing because sitemap submission is a hint, not a guarantee.
  
Verify on this platform
 
  • Validate that every sitemap URL is absolute, successful, canonical, and intended for indexing.
  • Inspect representative mismatch classes and confirm the live URL reports the intended response, canonical, and indexing directives.
  • Re-run the set comparison after Google has had time to recrawl; preserve pending versus evaluated states.
 
Rollback
  1. Restore the prior sitemap generation rule if the change removes legitimate canonical inventory.
  2. Revert only the specific canonical or directive change that contradicted confirmed intent, then re-evaluate the affected URLs.
 
Caveats
  • Index membership is observational and delayed; absence from a supplied export is not proof of a technical defect.
  • Do not put every discovered URL in a sitemap. Sitemaps should express preferred canonical inventory.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor sitemap, canonical, and indexing controls
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor how it chooses sitemap URLs and whether redirected, noindexed, non-canonical, or unpublished URLs can enter the generated file.
  • Independently fetch representative URLs and compare the generated sitemap with the intended canonical set.
  
Caveats
  • Escalate when the vendor cannot exclude incorrect URLs or explain which template owns canonical output.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Define the intended canonical index set before modifying any source.
  2. Require sitemap URLs to be absolute, successful, canonical, and index-intended.
  3. Verify the live response and directives for each mismatch class.
  4. Recompare after recrawl without turning pending or unavailable index evidence into a pass.
 
Escalate when
 
Escalate when canonical intent is disputed, the supplied index evidence is incomplete or stale, or different systems independently generate the sitemap and canonical signals.
 
 
 
 
 
 
 
Google Index Checker · one finding
 
Expected indexed URL has noindex
 
Recommended action: Remove noindex from the expected URL and confirm both raw and rendered directives permit indexing.
 
Fix principle: Sitemap membership, canonical intent, and observed index membership are three different evidence sets. Decide which URL should be indexed, then correct the set that contradicts that intent instead of assuming either the sitemap or observed index is automatically authoritative.
 
 
 
 Implementation for your setup 
 
Confirm first: A canonical URL intended for search is absent from the sitemap or observed index without an explained crawl, quality, or eligibility reason. A non-canonical, redirected, blocked, noindexed, duplicate, or retired URL remains in the sitemap or observed index set. The declared canonical and the URL selected or represented in supplied index evidence disagree.
 
Do not apply when: The sitemap contains only absolute, canonical, index-intended URLs that return successful responses. Every mismatch has a documented intended state and the contradictory sitemap, canonical, robots/noindex, redirect, or content signal has been corrected at its owner.
 
Likely control points: cms-app · server · content-data · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: Canonical URL policy, sitemap generator, response/indexing directives, and Search Console evidence
 
Steps
  1. Create an intended-index set first: the canonical URLs the site actually wants eligible for search.
  2. Compare that set with sitemap membership, live response/canonical/robots evidence, and supplied index evidence; classify each mismatch by the set that is wrong.
  3. Remove redirected, non-canonical, noindexed, blocked, duplicate, or retired URLs from the sitemap and add missing intended canonical URLs only after their live signals agree.
  4. Correct conflicting canonical, robots, noindex, redirect, or duplicate-content signals at their owning template or response layer.
  5. Resubmit the corrected sitemap and inspect representative URLs; do not claim immediate indexing because sitemap submission is a hint, not a guarantee.
  
Verify on this platform
 
  • Validate that every sitemap URL is absolute, successful, canonical, and intended for indexing.
  • Inspect representative mismatch classes and confirm the live URL reports the intended response, canonical, and indexing directives.
  • Re-run the set comparison after Google has had time to recrawl; preserve pending versus evaluated states.
 
Rollback
  1. Restore the prior sitemap generation rule if the change removes legitimate canonical inventory.
  2. Revert only the specific canonical or directive change that contradicted confirmed intent, then re-evaluate the affected URLs.
 
Caveats
  • Index membership is observational and delayed; absence from a supplied export is not proof of a technical defect.
  • Do not put every discovered URL in a sitemap. Sitemaps should express preferred canonical inventory.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor sitemap, canonical, and indexing controls
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor how it chooses sitemap URLs and whether redirected, noindexed, non-canonical, or unpublished URLs can enter the generated file.
  • Independently fetch representative URLs and compare the generated sitemap with the intended canonical set.
  
Caveats
  • Escalate when the vendor cannot exclude incorrect URLs or explain which template owns canonical output.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Define the intended canonical index set before modifying any source.
  2. Require sitemap URLs to be absolute, successful, canonical, and index-intended.
  3. Verify the live response and directives for each mismatch class.
  4. Recompare after recrawl without turning pending or unavailable index evidence into a pass.
 
Escalate when
 
Escalate when canonical intent is disputed, the supplied index evidence is incomplete or stale, or different systems independently generate the sitemap and canonical signals.
 
 
 
 
 
 
 
Google Index Checker · one finding
 
Multiple URL variants appear in the index set
 
Recommended action: Redirect and canonicalize duplicate variants to one preferred URL and link internally only to that version.
 
Fix principle: Sitemap membership, canonical intent, and observed index membership are three different evidence sets. Decide which URL should be indexed, then correct the set that contradicts that intent instead of assuming either the sitemap or observed index is automatically authoritative.
 
 
 
 Implementation for your setup 
 
Confirm first: A canonical URL intended for search is absent from the sitemap or observed index without an explained crawl, quality, or eligibility reason. A non-canonical, redirected, blocked, noindexed, duplicate, or retired URL remains in the sitemap or observed index set. The declared canonical and the URL selected or represented in supplied index evidence disagree.
 
Do not apply when: The sitemap contains only absolute, canonical, index-intended URLs that return successful responses. Every mismatch has a documented intended state and the contradictory sitemap, canonical, robots/noindex, redirect, or content signal has been corrected at its owner.
 
Likely control points: cms-app · server · content-data · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: Canonical URL policy, sitemap generator, response/indexing directives, and Search Console evidence
 
Steps
  1. Create an intended-index set first: the canonical URLs the site actually wants eligible for search.
  2. Compare that set with sitemap membership, live response/canonical/robots evidence, and supplied index evidence; classify each mismatch by the set that is wrong.
  3. Remove redirected, non-canonical, noindexed, blocked, duplicate, or retired URLs from the sitemap and add missing intended canonical URLs only after their live signals agree.
  4. Correct conflicting canonical, robots, noindex, redirect, or duplicate-content signals at their owning template or response layer.
  5. Resubmit the corrected sitemap and inspect representative URLs; do not claim immediate indexing because sitemap submission is a hint, not a guarantee.
  
Verify on this platform
 
  • Validate that every sitemap URL is absolute, successful, canonical, and intended for indexing.
  • Inspect representative mismatch classes and confirm the live URL reports the intended response, canonical, and indexing directives.
  • Re-run the set comparison after Google has had time to recrawl; preserve pending versus evaluated states.
 
Rollback
  1. Restore the prior sitemap generation rule if the change removes legitimate canonical inventory.
  2. Revert only the specific canonical or directive change that contradicted confirmed intent, then re-evaluate the affected URLs.
 
Caveats
  • Index membership is observational and delayed; absence from a supplied export is not proof of a technical defect.
  • Do not put every discovered URL in a sitemap. Sitemaps should express preferred canonical inventory.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor sitemap, canonical, and indexing controls
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor how it chooses sitemap URLs and whether redirected, noindexed, non-canonical, or unpublished URLs can enter the generated file.
  • Independently fetch representative URLs and compare the generated sitemap with the intended canonical set.
  
Caveats
  • Escalate when the vendor cannot exclude incorrect URLs or explain which template owns canonical output.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Define the intended canonical index set before modifying any source.
  2. Require sitemap URLs to be absolute, successful, canonical, and index-intended.
  3. Verify the live response and directives for each mismatch class.
  4. Recompare after recrawl without turning pending or unavailable index evidence into a pass.
 
Escalate when
 
Escalate when canonical intent is disputed, the supplied index evidence is incomplete or stale, or different systems independently generate the sitemap and canonical signals.