On-Page SEO Checker

Free, no signup. A concise five-item on-page memo first, with the full raw-HTML detector output available in Advanced.

Built by Patrick Stox

General preserves the base report. A named profile adds its required-signal checks; unavailable schema guidance and pack weights stay visibly not evaluated.

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 On Page Seo 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 — deterministic raw-HTML findings, not a live site claim
For a 200 page with no title, one H1, a self-canonical, a missing meta description, and an image without alt text, the report would summarize:
Top 5 prioritized findings
2 errors · 1 warning · supporting passes and not-evaluated checks
Page title · No title element was found.
Meta description · No meta description was found.
Image alt text · One image needs review.
Primary heading · One H1 was observed.
Rendered-only checks · Not evaluated in raw-HTML mode.
 
 
 
How to use it
  1. Enter a public, crawlable page URL and choose Run report.
  2. Start on Simple: top 5 for the highest-priority memo.
  3. Open Advanced: all checks to see every supported detector, including passes and not-evaluated states.
  4. Verify important fixes in the rendered page and Search Console where appropriate.
 
 
 
     
     
     
 
What the results mean
  • Errors (red) are clear implementation defects or strong blockers supported by the response.
  • Warnings (orange) are likely issues that need context before changing the page.
  • Needs review (yellow) marks evidence that cannot support a pass or error verdict yet.
  • Information (blue) records useful evidence without calling it a defect.
  • Pass means that specific observable rule passed, not that the whole page is optimized.
  • Not evaluated means no verdict was possible and never counts as a pass.
 
How it works
The server retrieves the public response because browser cross-origin rules prevent direct inspection. The page context normalizes the final URL, status, headers, and raw HTML, then a deterministic detector registry runs supported technical and on-page checks. The Simple memo prioritizes the same results; it does not use a separate opaque score.
 
Features
  • Five-item prioritized memo plus complete detector output.
  • Checks across metadata, headings, canonicals, directives, links, images, and supported markup.
  • Hreflang cluster validation follows up to 500 declared URLs with at most six concurrent fetches.
  • Evidence-based pass, warning, error, information, and not-evaluated states.
  • Escaped output and no fabricated verdicts when evidence is unavailable.
 
Limitations
This checker does not render JavaScript, run Lighthouse, measure Core Web Vitals, assess accessibility, score writing quality, inspect backlinks, or predict rankings. Hreflang detail shown on the page and in coverage samples is bounded even when validation reaches the 500-URL ceiling. A fetch can also differ from Googlebot because it originates from this site's server infrastructure. Confirm rendered and index-level behavior with purpose-built tools.
 
Frequently asked questions
What does an on-page SEO checker analyze?
This checker analyzes signals available in the server-returned HTML and response metadata, including titles, descriptions, headings, canonicals, robots directives, links, images, and supported structured-data patterns.
Is a passing report a guarantee that the page will rank?
No. The report identifies observable implementation issues. Rankings also depend on relevance, content quality, competition, authority, internal linkingAn 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., and signals this raw-HTML tool cannot measure.
Why does the report say not evaluated?
Not evaluated means the checker lacks the evidence or rendering capabilityTurning HTML, CSS, and JavaScript into the final visual page and DOM. needed for a responsible verdict. It is different from a pass and keeps unavailable checks from inflating the result.
Does the checker render JavaScript?
No. It analyzes the raw HTML response. Use a rendered-page tool when a JavaScript application changes metadata, headings, content, or links after load.
Which findings should I fix first?
Start with errors that can prevent crawlingCrawling 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., indexingStoring 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., or a useful search result, then address warnings that affect page meaning. The Simple tab prioritizes five findings using the same detector results shown in Advanced.
 
 
Next stepContent Gap Analyzer — look up the exact spec and expected values.

Explore more
ToolHeading Structure CheckerToolLink AnalyzerToolImage SEO CheckerArticleAlt TextArticleThe HTML lang AttributeArticleRanking in Google Images
 
 
 
Feature requests for On Page Seo 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
 
 
 
 
 
On-Page SEO Checker · one finding
 
Noindex directive is present
 
Recommended action: Remove noindex from pages meant to be indexed, or keep it only when exclusion is intentional.
 
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.
 
 
 
 
 
 
 
On-Page SEO Checker · one finding
 
Robots directive is outside the HTML head
 
Recommended action: Move the intended robots meta directive into the document head and remove ineffective body declarations.
 
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.
 
 
 
 
 
 
 
On-Page SEO Checker · one finding
 
Robots directive combination is ineffective
 
Recommended action: Add the prerequisite robots directive or remove the ineffective token, then verify the effective Googlebot policy.
 
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.
 
 
 
 
 
 
 
On-Page SEO Checker · one finding
 
Noindex and canonical are combined
 
Recommended action: Confirm whether exclusion or consolidation is intended, then remove the signal that conflicts with that outcome.
 
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.
 
 
 
 
 
 
 
On-Page SEO Checker · one finding
 
Robots.txt prevents Googlebot from seeing noindex
 
Recommended action: Allow Googlebot to crawl the page while noindex removal is required, then verify that the directive can be processed.
 
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.
 
 
 
 
 
 
 
On-Page SEO Checker · one finding
 
Canonical is missing
 
Recommended action: Add one absolute rel=canonical URL for the preferred indexable version.
 
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.
 
 
 
 
 
 
 
On-Page SEO Checker · one finding
 
Canonical element is outside the HTML head
 
Recommended action: Move the intended canonical link into the document head and remove body-level canonical declarations.
 
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.
 
 
 
 
  
 
 
     
  •  Warnings Primary H1 is missing Fix: Add one descriptive H1 that clearly states the page’s primary topic. 
  •  Warnings Heading hierarchy skips levels Fix: Restructure headings into a sequential hierarchy that reflects section nesting. 
  •  Information Low visible text volume Fix: Review whether the observed text is complete for the page’s purpose. Add useful information only when something material is missing; do not pad the word count. 
  •  Warnings Title is near-duplicate of another signal Fix: Differentiate the title from competing page signals so it uniquely identifies this page’s intent. 
  •  Warnings Images lack alt attributes Fix: Add concise alt text to meaningful images and empty alt attributes to decorative images. 
  •  Errors Title element is missing Fix: Add one non-empty, page-specific title element in the initial HTML. 
  •  Warnings Meta description is missing Fix: Add a concise page-specific meta description in the initial HTML. 
  •  Information Structured data is absent Fix: Add supported structured data only when it accurately describes visible page content. 
  •  Errors Title elements contain conflicting values Fix: Keep one non-empty title element in the document head and remove every competing title value. 
    •