ProMapRanker
Free tools · More SEO Tools

Canonical Tag Checker

Free Canonical Tag Checker - instant, no signup.

What is a canonical check?

A canonical check verifies that the canonical tag on a web page is set up correctly, so search engines index the version of the URL you actually want ranked. Running one means pasting a page's HTML into a parser that pulls out every <link rel="canonical"> tag, then testing that tag against a short list of rules: is there exactly one, is it an absolute URL, does it use https, and does it point back to the page it lives on or somewhere else entirely. If any of those checks fail, the canonical signal you are sending to Google is weaker than it should be, and that can quietly cost you rankings for months before anyone notices.

Most site owners assume their canonical tags are fine because a developer or a CMS plugin set them up once, years ago. A canonical url checker exists precisely because that assumption breaks more often than people expect, especially after a redesign, a CMS migration, or a plugin update that silently changed how canonical tags are generated. Instead of guessing, you can check canonical tag output directly from the rendered HTML and see exactly what a crawler would see.

How to run a canonical check

  1. Open the page you want to audit in your browser, right click anywhere on the page, and choose "View Page Source" (or press Ctrl+U). If the canonical tag is injected by JavaScript rather than baked into the server response, use "Inspect" instead so you capture the rendered DOM the way a crawler would eventually see it, not just the raw HTML the server sent before scripts ran.
  2. Select and copy everything inside the <head> section, or just copy the single <link rel="canonical" ...> line if you can find it quickly with your browser's find-in-page search (Ctrl+F on the source view usually gets you there in seconds).
  3. Paste the copied markup into the HTML box in the tool above. You do not need to clean it up first, strip comments, or isolate the head tag, the parser is forgiving and will find the canonical tag wherever it sits in the pasted text, even inside a full page dump.
  4. Type the page's actual, current URL into the "Current page URL" field, exactly as it appears in the address bar, including https and any subdomain. This is what the tool compares the extracted canonical against to determine whether the tag is self-referencing.
  5. Click "Run Canonical Check" and read the report. Each line is labeled pass, warn, or error so you can scan it in a few seconds without having to interpret raw markup yourself.
  6. Fix anything flagged in your CMS, page builder, or template code, then paste the updated HTML back in to confirm it now comes back clean before you move on to the next page in your audit list.

Why a bad canonical tag hurts your SEO

Canonical tags exist to solve a specific problem: the same content is often reachable through more than one URL. Tracking parameters, session IDs, capitalization differences, trailing slashes, and printer-friendly versions can all produce separate URLs that show the same content. Without a correct canonical, search engines have to guess which version matters, and Google does not always guess in your favor. A missing or broken canonical tag leaves that decision entirely up to the algorithm, which means duplicate content confusion is possible even when nothing on the page itself is technically wrong.

The practical damage shows up in a few predictable ways. Crawl budget gets wasted re-crawling near-identical URLs instead of your newest content. Link equity that should consolidate onto one URL gets split across several, weakening all of them. In the worst cases, a canonical tag that mistakenly points to the wrong page, a competitor's page, a staging URL, or a page that has since been removed, can cause your real page to drop out of the index entirely, an accidental deindexing that is painful to diagnose because nothing else about the page looks broken. Running a check canonical tag routine after any template or migration change is the cheapest insurance against this class of problem.

This is also why shipping more than one canonical tag on a page is treated as a hard error rather than a minor style issue. When a page ships with two or more canonical tags, often because a CMS plugin and a manually added tag both fire, most search engines will either use only the first one they encounter in the HTML or disregard all of them as an unreliable signal. Either outcome means you lose control over which URL gets indexed, which defeats the entire purpose of adding a canonical tag in the first place.

None of this requires a large site to become a real problem. A single local business site with a handful of service pages can still end up with conflicting canonical tags if the theme, an SEO plugin, and a page builder each try to manage the same tag independently. Small sites feel the damage just as sharply as large ones because they have fewer pages competing for rankings in the first place, so losing indexing on even one important service page is a proportionally bigger hit to visibility than it would be on a site with thousands of URLs to spare.

Understanding what this checker flags

Duplicate canonical tags

Good: a single <link rel="canonical" href="https://example.com/blog/post"> tag appears once in the <head>. Bad: the same page outputs two canonical tags, for example one hardcoded in the theme template and a second one injected by an SEO plugin that did not detect the first. A canonical check will flag this instantly and list every href it found so you can see exactly where the conflict is coming from. This particular failure mode is easy to miss because both tags can look correct individually, the problem only shows up when you count how many there are, which is exactly what an automated check does reliably and a quick visual scan of the source code often does not.

Relative vs absolute URLs

Good: href="https://example.com/services/plumbing" gives crawlers the full, unambiguous destination. Bad: href="/services/plumbing" is a relative path that technically works in most cases but leaves room for misinterpretation on staging environments, subdomains, or when the tag is copied to the wrong context. Google's own documentation recommends absolute URLs for canonical tags specifically to remove that ambiguity, and the recommendation matters more than it might seem, because a relative path that resolves correctly on your production domain can resolve to an entirely different, broken URL if the same template ever gets rendered on a staging subdomain or a development copy of the site that briefly gets indexed by mistake.

Self-referencing canonicals

Good: a page at https://example.com/pricing carries a canonical pointing to that exact same URL, confirming it is the authoritative version of itself. This is the most common and safest pattern, and it is what most pages on a site should have. A self referencing canonical is not required by Google, but it is considered best practice because it removes any ambiguity, especially on pages that could otherwise be reached through multiple paths, such as with or without a trailing slash, with or without a tracking parameter, or through both a www and a non-www host. Bad, or at least worth a second look: the canonical points to a completely different URL, which is only correct if that page is intentionally a duplicate, a print view, or a filtered variant of the main content. If you did not intend that relationship, treat it as a signal that a template default is bleeding into pages it should not touch.

HTTP vs HTTPS mismatches

Good: an https page carries an https canonical, matching protocols throughout. Bad: an https page carries a canonical tag pointing to the old http:// version of the URL, usually left over from a migration that updated the visible page but not the templating logic that generates the canonical tag. This quietly tells search engines your preferred version is the insecure one, which works against the SSL migration you already paid for. It is a surprisingly common leftover because the visible redirect from http to https usually gets tested and confirmed, while the canonical tag value, buried in the head section, rarely gets a second look once the migration is declared finished.

Canonical check workflow: paste HTML, extract canonical tag, run pass and fail checks 1. Paste HTML head section or canonical tag 2. DOMParser extracts every link rel="canonical" 3. Canonical check report generated in your browser PASS One canonical tag found Absolute https URL Self referencing match WARN / ERROR Duplicate canonical tags Relative or http URL Points to a different page

Best practices and common mistakes

Most canonical tag problems are not caused by a single dramatic mistake, they build up gradually from small inconsistencies between a CMS default, a plugin setting, and whatever a developer hardcoded years ago. The list below covers the mistakes that show up most often during audits, roughly in order of how much damage they tend to cause.

  • Never point a canonical tag at a page that is set to noindex. That combination sends contradictory signals, since you are telling search engines both "this is the authoritative version" and "do not index this version," and it often results in neither URL being indexed the way you want.
  • Keep canonical tags consistent with your hreflang setup. If a page is part of an hreflang cluster serving multiple languages or regions, its canonical should normally point to itself, not to another language or region variant, otherwise you risk collapsing distinct localized pages into a single indexed version.
  • Avoid canonical chains, where page A points to page B, and page B points to page C. Search engines may not follow the full chain, so always point directly to the final, real destination rather than letting tags cascade through several intermediate URLs.
  • Recheck the canonical setup after every CMS migration, theme change, or plugin update. These are the most common moments for canonical tags to silently break or duplicate, precisely because nobody is looking at the head section during a visual redesign.
  • Do not use canonical tags to fake a redirect. If a page has permanently moved, use a real 301 redirect instead of a canonical tag pointing elsewhere, since a canonical is a hint about duplicate content, not a mechanism for moving traffic or link equity the way a redirect is.
  • Match canonical protocol and host to the page's actual served version, including www versus non-www and http versus https, so the canonical tag agrees with the URL that actually loads in a visitor's browser.
  • Audit paginated series carefully. Page 2, 3, and beyond of a paginated list should generally carry a canonical pointing to itself rather than all pointing back to page 1, otherwise you risk the later pages never getting crawled or indexed at all.

Common use cases

Post migration audits are the single most common reason people reach for a canonical url checker. After moving to a new domain, a new CMS, or a new hosting platform, canonical tags are one of the easiest things to get wrong because they are usually generated by a template setting that nobody remembers to update, and the mistake can sit unnoticed for months since the visible page renders perfectly fine either way. A quick canonical check on a handful of representative pages, homepage, a couple of key landing pages, and a couple of deeper interior pages, catches this before it costs weeks of rankings.

E-commerce sites live and die by this issue because of filter and sort URL parameters. A single product category can generate dozens of crawlable URLs through combinations of size, color, price sort, and pagination parameters, each one technically a distinct URL even though the underlying products barely change. Every one of those variants needs a canonical tag pointing back to the clean category URL, otherwise the site's crawl budget gets consumed by near-duplicate parameter combinations instead of new inventory, and thin, filtered pages can end up competing with the main category page for the same rankings.

Publishers who syndicate content to partner sites need the syndicated copies to carry a canonical tag pointing back to the original article, not a self referencing canonical on the syndicated version. Getting this backwards means the syndication partner's copy can outrank the original in search results, which is a frustrating outcome for anyone who invested the time to write the piece in the first place.

Local businesses running location or service pages for multiple cities face a related trap, near-identical page templates for each city can accidentally end up pointing their canonical at the same flagship location page instead of self-referencing, which quietly removes the other city pages from the index even though each one targets a genuinely different search audience.

Agencies running technical audits across client sites use a canonical check as a fast first pass, pulling the head section from a sample of templates (homepage, category page, product page, blog post) to confirm the canonical logic is sound sitewide before digging into deeper crawl data. Because the tool works entirely from pasted HTML, it fits neatly into a manual audit workflow without needing crawler access or API credentials for every client site.

Frequently asked questions

What does a canonical check actually look at?

It parses the HTML you paste in, extracts every link rel="canonical" tag it finds, and evaluates the result against a short set of rules: tag count, whether the URL is absolute, whether it uses https, and whether it matches the current page URL you entered.

Can this tool crawl my site automatically?

No. Browsers block cross-site fetching for security reasons, so the tool works by having you paste the page's HTML directly rather than trying to fetch a URL for you. Copy the head section from view-source and paste it in.

Is a relative canonical URL actually wrong?

Not strictly wrong, most crawlers will resolve it correctly, but it is flagged as a warning because absolute URLs remove any ambiguity, particularly on staging domains, subdomains, or pages accessible through more than one host.

Why did the checker flag my self referencing canonical as a warning?

It only warns when the canonical URL does not match the page URL you typed in. If that mismatch is intentional, for example the page is a duplicate of another URL on purpose, the warning is informational rather than an error.

What is the difference between this and the canonical tag generator?

The generator builds a correctly formatted canonical tag from a URL you provide. This canonical check does the reverse: it audits a tag that already exists on a live page and tells you what, if anything, is wrong with it.

How many canonical tags should a page have?

Exactly one. Duplicate canonical tags are invalid HTML for this purpose and create an unreliable signal, since search engines may use only the first one found or ignore the set entirely.

Canonical tags are one small piece of the technical foundation that local businesses need to get right before rankings improve, and ProMapRanker is built around that bigger picture, tracking local pack positions and site health together in one place. If you want to see where your site currently stands, start free with 150 credits.

Related tools

Canonical Tag Generator, the direct companion to this checker, builds a correctly formatted canonical tag from any URL in a few seconds.

Meta Robots Tag Generator helps you pair the right indexing directives with your canonical setup on pages that need noindex or nofollow.

Hreflang Generator is useful when your canonical and hreflang tags need to stay consistent across language or region variants.

JSON-LD Validator checks another critical piece of your page's head section, structured data, for errors the same way this tool checks canonical tags.

Related tools

Track your real Google Maps rankings

These free tools get you set up - ProMapRanker shows where you actually rank across your whole service area on a geo-grid.

Start free - 150 credits