Canonical Tag Validator

When pasted HTML beats a live fetch

The canonical tag validator checks markup you paste, entirely in your browser. There is no network request, which makes it the right tool in situations a URL-based checker cannot reach:

• Before deployment. Test a template or staging page that is behind a login or not yet public.
• After JavaScript runs. Copy the rendered head from browser DevTools and paste it here to validate the canonical your framework actually leaves in the DOM, something a server-side fetch never sees.
• Comparing two states. Validate View Source and the rendered DOM separately. If the canonical differs between them, script is rewriting it, which Google's JavaScript guidance advises against.

Adding the page's URL is optional, but the self-referencing check depends on it. Without a URL, the validator can only judge the tag's form.

What each check is testing

The relative-URL result is deliberately a warning, not an error. RFC 6596 allows relative references and Google says they are supported, but Google recommends absolute URLs because a relative one resolves against whatever host is crawled, including a staging server. A value such as example.com/page with no scheme is a trap: it resolves as a relative path on the current site.

A mismatch with the page URL means the page nominates a different URL. That is intended on duplicates and parameter variants. Reading it correctly depends on knowing which kind of page you pasted.

Where the head actually ends

A validator decides "in the head" structurally, by where the tag sits in the markup. Google is stricter. Its valid page metadata documentation says that when it meets an invalid element in the head, such as an iframe or img, it assumes the head has ended and reads no further. Only title, meta, link, script, style, base, noscript and template elements belong there.

So a canonical can pass the location check here and still be missed by Google if a tracking pixel or embedded widget sits above it. Scan the elements that precede the canonical in the pasted head. The simplest defense is to place the canonical near the top, before any third-party snippets.

Common failures and where they usually come from

Most validator failures trace back to a few sources, and knowing the source shortens the fix.

• Two canonicals. Typically a theme and an SEO plugin both printing one, two SEO plugins active at once, or a canonical hardcoded in a template that a plugin also outputs. If the values match, removing one is housekeeping; if they differ, Google may disregard both and fall back on its own selection. Disable the extra source rather than editing its output.
• A canonical in the body. Usually a widget, page builder block or injected script writing markup after the head has closed. The fix belongs in whatever produced it.
• Noindex beside a canonical to another page. Often a plugin rule applied to paginated or filtered pages, or a noindex added to "fix" duplicates that already had canonicals. Keep the canonical to consolidate, or keep the noindex to exclude; drop the other.
• A mismatch with the page URL. Frequently a canonical built from a hardcoded base URL left over from before an HTTPS or domain move, or a trailing-slash convention that differs from the one the server answers.
• An empty href. A template variable that resolved to nothing, often on page types the template was not written for.

Rules this validator does not test

• Extra attributes on the canonical. Google does not use canonical annotations that carry hreflang, lang, media or type. Language alternates belong in separate rel="alternate" links.
• URL fragments. Google generally does not support a #fragment as a canonical.
• The wrong element. The canonical keyword belongs on <link>; on an <a> element it is invalid.
• HTTP headers. A Link header canonical, or an X-Robots-Tag: noindex, is not part of the HTML, so pasted markup cannot reveal either. The canonical tag checker reads both.
• The target's status. Whether the canonical URL returns 200, redirects or returns an error requires a fetch.

What a clean result establishes

A clean result means the pasted markup declares one well-formed canonical in a sensible place. It does not mean the canonical names the right page; RFC 6596 expects the target to duplicate the page or contain it, which is a judgment about content. It also says nothing about what Google selected. After deployment, confirm the live response with the canonical tag checker, and compare the user-declared and Google-selected canonicals in Search Console's URL Inspection. Google's duplicate URL documentation is the reference for the rules above.

Frequently asked questions