All briefingsMetadata

How to check whether a WordPress canonical tag points to the wrong URL

A canonical tag is a direct instruction: index this other URL instead of the one you're looking at. Correct for real duplicates, and quietly self-defeating everywhere else. Here's how to check one page and how conflicts spread across a site.

5 min read

A canonical tag tells Google which URL should be treated as the authoritative version when the same or similar content is reachable at more than one address. Google generally respects it, which is exactly why a wrong one is dangerous — it's not a suggestion Google occasionally ignores, it's an instruction it usually follows.

Most canonical problems aren't intentional. They're a side effect of a migration, a theme change, or a plugin setting nobody revisited after it did its job once.

What a wrong canonical actually does

When Page A's canonical points to Page B, Google consolidates ranking signals toward B and generally won't show A in results, even if A is the version you actually want visible. If B doesn't exist, has been redirected elsewhere, or is a weaker page, you've effectively asked Google to stop ranking your good page in favor of a broken or worse one.

This is correct behavior for genuine duplicates — a printer-friendly version, a tracking-parameter variant, a paginated comment page. It's actively harmful anywhere else.

The three patterns that show up most often

A stale canonical survives a URL change. The post's slug changed, or the site moved to a new domain, but the canonical tag still points at the old address — sometimes one that now 404s.

A cross-domain canonical survives a staging-to-production launch. A canonical set to point at a staging or preview host during development never gets updated, and production content quietly tells Google to rank the staging copy instead.

A plugin or theme default applies a canonical pattern nobody chose deliberately — some SEO plugins offer a bulk canonical rule for a post type or taxonomy that made sense for one section and gets silently inherited somewhere it shouldn't.

Checking one URL

View source and look for <link rel="canonical">. Compare the href value against the page's own address, accounting for protocol (http vs https) and trailing slashes, which can look like a mismatch and not actually be one.

A canonical that matches the page's own URL is self-referencing and almost always correct — it's the deliberate default most SEO plugins set automatically. The ones worth investigating point somewhere else entirely.

Finding conflicts across a whole site

A migration or plugin change rarely affects one URL. It tends to touch every post in a category, a whole custom post type, or every page published before a specific date — which means a single stale canonical you find by hand is usually a symptom of a pattern, not an isolated mistake.

The free Content Signal WordPress plugin flags every published page whose canonical points somewhere other than itself, locally and in bounded background batches, so a pattern shows up as a cluster of findings instead of one report you happened to notice.

  • Cross-domain canonicals get priority — they're the most likely to be pointing at a dead or wrong host entirely.
  • Group findings by the date they were likely introduced; a cluster around one migration date confirms the root cause.
  • Fix the source (the migration script, the plugin default) alongside the individual pages, or the pattern reappears on the next import.

Frequently asked questions

Does every page need an explicit canonical tag?

Not strictly — Google can infer a self-canonical when none is present. Most SEO plugins set one automatically for exactly this reason, and it's a cheap, low-risk default rather than a requirement.

Will Google always obey a canonical tag?

Usually, but not unconditionally — it's treated as a strong signal, not an absolute directive. Google can choose a different canonical if other signals (like the actual backlink pattern) strongly disagree, but that's the exception, not something to rely on as a safety net.

Can a canonical pointing at a 404 hurt more than a missing canonical?

Yes. A missing canonical defaults to self-referencing behavior. A canonical pointing at a dead URL can suppress the working page without a working alternative for Google to consolidate toward — closer to accidentally deindexing the page.

Check whether a single URL has this problem right now, free, at the page checker. To catch it across every published post and page, install the free plugin.

Run the audit on your own site.

The free WordPress plugin runs the content checks locally, with no account and no external request. Connect Search Console later if you want traffic evidence attached.

Get the free plugin