Canonicalization Checker

Free, no signup. Check the canonical Google can see, the HTTP Link header, and whether the chosen target is actually a clean, live URL.

Built by Patrick Stox

Checks run from our server; we fetch the URL you enter and don't keep the results. The URL and its canonical target are fetched to build this report. The full URL is not stored; after a successful check, only its domain may be remembered in this browser. 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 Canonical 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. 
  
 
  
 
 
  
 
 
  
 
Example result
Illustrative example — fixed signals, not a live URL claim
Page checked: https://example.com/product?color=blue
Observed canonical signals
html canonical: https://example.com/product
Google override-risk predictor
LOW — Parameterized page canonicals to a clean URL. Fix: This is usually good when parameters do not change content; ensure internal links and sitemap use the clean URL.
This example assumes the canonical target returns a direct 200. If it redirected or failed, the same engine would add a high-risk finding instead of hiding that evidence.
 
 
 
How to use it
  1. Enter the exact URL variant you want to audit, including parameters when they are part of the question.
  2. Choose Audit canonical. The report shows every HTML and HTTP Link-header canonical observed.
  3. Read the override-risk explanations and fixes, then confirm that the target resolves directly to a live page.
  4. Use Search Console URL Inspection to compare the user-declared and Google-selected canonical for a verified property.
 
 
 
     
     
    
 
What the results mean
The report checks the observable signals involved in CanonicalizationHow search engines pick one canonical URL among duplicates and consolidate signals onto it. and estimates when conflicts may lead Google to select another URL.
  • High marks a direct conflict such as disagreeing canonicals, noindex plus canonical, an unreachable target, or a target that redirects.
  • Medium marks a meaningful consistency risk, including cross-domain targets or hreflang that omits the canonical URL.
  • Low means the observed signals are internally consistent or describe a normal parameter cleanup. It is not a promise that Google agrees.
 
How it works
One bounded server request collects the final URL, response headers, and HTML body. A deterministic parser reads canonical and hreflang links from the head plus canonical Link headers, resolves relative URLs, records duplicates and noindex, and then checks each unique canonical target through the status endpoint. The predictor maps those observed signals to explicit risk reasons and fixes.
 
Features
  • HTML and HTTP Link-header canonical discovery.
  • Relative, missing, multiple, and conflicting canonical checks.
  • Noindex, hreflang, cross-host, protocol, and parameter consistency signals.
  • Bounded canonical-target status and redirect verification.
  • Plain-language likelihood labels without claiming Google's selection.
 
Limitations
The checker reads the server response and does not render JavaScript. It cannot compare page content across duplicate URLs, inspect all internal links or sitemap signals, access Search Console, or observe Google's selected canonical. A low-risk result only describes the evidence fetched in this run.
 
Frequently asked questions
Can this tell me Google’s selected canonical?
No. Google’s selected canonical is only observable through Search Console URL InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate "Test live URL" mode fetches the current version. for a verified property. This tool predicts override risk from observable HTTP and HTML signals.
Does it fetch rendered JavaScript canonicals?
No. It reads the server response. A canonical injected only after JavaScript runs is discouraged and should be verified in URL Inspection.
Should every indexable page have a self-referencing canonical?
A self-referencing canonical is generally useful because it makes the preferred URL explicit and helps keep parameters or alternate URL forms from becoming ambiguous. It is still a hint, not a directive.
Can a canonical point to a redirect?
It can, but it creates a conflicting and inefficient signal path. Point the canonical directly to the final live 200 URL and align internal linksAn internal link is a hyperlink from one page on a website to another page on the same website. Internal links help search engines discover your pages and pass ranking signals (PageRank and anchor-text context) between them., redirects, and sitemap entries with it.
Why might Google ignore a canonical tag?
Google may choose another URL when content, redirects, internal links, sitemapsA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing., hreflangHreflang is an annotation (in HTML, HTTP headers, or XML sitemaps) that tells search engines which language and optional region a page targets, and which alternate versions exist. It only works when every page in the cluster references all the others., protocol or host signals disagree, or when the declared target is unavailable. This checker tests several observable conflicts but cannot see Google’s full index-level evidence.
 
Next stepXML Sitemap Generator — publish a clean sitemap that agrees with your canonical targets.

Explore more
ToolGoogle Index CheckerToolSEO Incident SimulatorToolXML Sitemap ValidatorArticleMagento SEOArticleJoomla SEOArticleCanonicalization
 
 
 
Feature requests for Canonical 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
 
 
 
 
 
Canonicalization Checker · one finding
 
Canonical is missing
 
Recommended action: Add one self-referencing absolute canonical URL to the page.
 
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.
 
 
 
 
 
 
 
Canonicalization Checker · one finding
 
Canonical is relative or invalid
 
Recommended action: Replace the relative reference with a valid absolute HTTPS URL.
 
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.
 
 
 
 
 
 
 
Canonicalization Checker · one finding
 
Multiple canonicals conflict
 
Recommended action: Choose the intended value, align the conflicting signals, and rerun the check.
 
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.
 
 
 
 
 
 
 
Canonicalization Checker · one finding
 
Canonical points elsewhere
 
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.
 
 
 
 
 
 
 
Canonicalization Checker · one finding
 
HTML and HTTP canonicals disagree
 
Recommended action: Choose the intended value, align the conflicting signals, and rerun the check.
 
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.
 
 
 
 
 
 
 
Canonicalization Checker · one finding
 
Canonical target is not a live 2xx URL
 
Recommended action: Restore a live 2xx response at the evaluated URL, then rerun the check.
 
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.