When WordPress shows the wrong canonical URL, it’s almost always one of three things: a plugin or theme filter overriding the default, an SEO plugin’s manual override field left pointing at the wrong page, or two systems (an HTML tag and your sitemap, say) disagreeing about which URL is real. Check the rendered page source for the actual
<link rel="canonical">tag, find which of the three is responsible, and fix that one source instead of guessing at settings.
Why it happens: WordPress builds a canonical, but anything can override it
WordPress core doesn’t leave canonical URLs to chance. Every published post gets one automatically: the wp_get_canonical_url() function builds it from get_permalink(), adds pagination handling for paginated posts and comments, and outputs the result in the page head. That’s the default, and on a plain WordPress install with no SEO plugin, it’s usually correct.
The breakage comes from the next step. That output passes through the get_canonical_url filter hook before it’s printed, which means any theme or plugin can intercept it and substitute a different URL. An SEO plugin doing this on purpose (to point a duplicate page at its main source) is normal and useful. A caching plugin, an old theme function, or a leftover custom filter doing it by accident is how you end up with a canonical tag that quietly points somewhere wrong for months before anyone notices.
Underneath that mechanism, the actual duplicate-content triggers are predictable: URL variations (HTTP vs. HTTPS, www vs. non-www, a trailing slash or not, tracking parameters like ?ref= or ?sort=), category and tag archives that repeat post content across multiple URLs, pagination chains like /page/2/, and syndicated copies of your content living on other domains. None of these are exotic. They’re what most WordPress sites accumulate by default, and a canonical tag is the tool that tells Google which one is the real page.
Step-by-step fix
Start by confirming what’s actually being output, not what a setting says it should be. Load the live page in a browser, view source, and search for rel="canonical". Whatever URL is in that tag right now is the one Google is reading, regardless of what any plugin dashboard claims.
If that URL is wrong, work through these in order:
1. Check for a manual override. In Rank Math, open the post, go to the Advanced tab (enable Advanced Mode from Rank Math SEO → Dashboard if that tab isn’t visible), and look at the Canonical URL field. If it’s populated with something other than the page’s own URL, that’s your answer: someone (or an earlier version of your workflow) set an override on purpose or by mistake.
Every SEO plugin exposes some version of this field. If you’re not on Rank Math, the same field exists under a similar name in Yoast’s Advanced tab or your plugin’s equivalent settings panel.
2. Check for a theme or plugin filter. If the override field is empty but the rendered tag still shows the wrong URL, something is hooking get_canonical_url directly. Search your theme’s functions.php and any custom-code plugins for that filter name. This is the case that manual settings can’t fix, because the setting was never wrong; code downstream of it is rewriting the output.
3. Check whether two systems disagree. A canonical tag pointing one way while your XML sitemap lists a different URL for the same content sends Google a mixed signal. Sitemap inclusion is a real canonicalization signal, just a weaker one than the HTML tag or a redirect, and having them contradict each other is one of the most common ways sites break their own canonicalization without anyone touching the canonical field directly.
4. Set the correct value and re-save. Once you’ve found the actual source, either clear the override field so the post reverts to its own permalink, or set it explicitly to the correct destination URL if this page is intentionally a duplicate of another. Save, and don’t stop here.
How to verify it worked
Re-check the live rendered source, not the editor preview. Load the published URL directly and search for rel="canonical" again; confirm the tag now shows the URL you intended, and that there’s exactly one canonical tag on the page. A page with two conflicting canonical tags (one from a plugin, one hardcoded in a theme template) is a real failure mode, and it only shows up by reading the actual output.
This is the same verification discipline this site applies to every published page: after any programmatic change to SEO fields via the WordPress REST API, re-fetch the live page and confirm the change actually rendered, rather than trusting that a successful API response means the front end matches. A 200 response from a settings update tells you the database was written; it doesn’t tell you what a crawler sees.
Beyond the tag itself, confirm the canonical URL is absolute (not a relative path) and sits inside the page’s <head>. Both are easy to break with a hand-edited template and both make Google discard the signal rather than raise an error you’d notice.
What to do when the standard fix fails
If you’ve cleared the override, confirmed no filter is rewriting the output, and the tag still looks wrong, the problem is usually that the canonical tag isn’t the only signal in play, and something else is winning. Google explicitly ranks these signals by strength: redirects, especially 301s, are the strongest; a rel="canonical" tag is a strong signal but not absolute; sitemap inclusion is weaker still. If a 301 redirect somewhere in your stack points to a different URL than your canonical tag names, the redirect generally wins the argument, and no amount of editing the canonical field will override it.
Also rule out the more common mistakes that look like canonical bugs but aren’t: using noindex on a page when the actual intent was to canonicalize it to another page (these do different things), or relying on a robots.txt block or a URL-removal request to handle what a canonical tag should be doing. None of those substitute for a correct rel="canonical" tag, and Google’s own guidance calls out all three as common errors.
If none of that resolves it, treat it as a technical SEO audit item rather than a one-off fix: canonical URLs are one line item in a broader routine, alongside things like structured data that make similar “here’s the real, authoritative version of this page” statements to Google from a different angle. Working through canonical checks as part of a standing WordPress SEO checklist, rather than only when Search Console flags something, catches drift before it compounds across dozens of posts.
Frequently asked questions
Does WordPress set a canonical URL automatically if I do nothing?
Yes. WordPress core generates one for every published post based on its permalink, with no plugin required. Unpublished content doesn’t get one; wp_get_canonical_url() returns false until the post is live.
Is a wrong canonical tag the same problem as a noindex tag?
No, and mixing them up is one of the most common canonicalization mistakes. A canonical tag tells Google which URL to treat as authoritative among duplicates; noindex tells Google not to show a page in results at all. Using one where you meant the other produces confusing results either way.
Can a sitemap fix a canonical problem on its own?
Not reliably. Sitemap inclusion is a real signal, but it’s a weaker one than a redirect or an on-page canonical tag, and if your sitemap disagrees with your canonical tag, the tag and any redirects generally take priority in how Google resolves the conflict.
Why does my canonical URL keep reverting after I fix it?
This usually means a theme function or plugin is hooking the get_canonical_url filter and rewriting the output every time the page loads, rather than the setting itself being wrong. Editing the field again won’t hold if the code downstream keeps overriding it; that code has to be found and changed instead.
Leave a Reply