Fixing Canonical URLs in WordPress
A canonical tag is a hint about which duplicate is the master copy, not an instruction. Most canonical problems in WordPress are really URL problems that the tag was asked to paper over.
Quick fix: open the page source and search for rel="canonical". Three outcomes matter: there is exactly one and it matches the URL you loaded, which is correct; there is more than one, which means two plugins are both writing it; or it points somewhere unexpected, which is the actual bug. Everything below follows from which of the three you have.
The trap is treating the canonical tag as a fix. It is a hint about which duplicate is authoritative. If the duplicates should not exist, the tag is the wrong tool and a redirect is the right one.
What the tag actually does
A canonical tag consolidates signals from several URLs onto one. It does not remove pages from the index, does not block crawling, and search engines are free to ignore it when the evidence disagrees — for instance when the canonical target redirects elsewhere, or when the two pages plainly show different content.
WordPress emits a self-referencing canonical on singular posts and pages by default. An SEO plugin normally removes that output and produces its own, which is fine. Both producing it at once is not.
Confirm what is being emitted
Check the source, not the plugin settings screen. Settings describe intent; the source describes reality.
- View the rendered HTML for the affected URL and count the canonical tags. Two tags is a conflicting-plugin problem, and search engines typically discard both.
- Check the HTTP headers too. A canonical can be sent as a
Link: <...>; rel="canonical"header, which never appears in the page source and is easy to miss. Checking HTTP response headers shows how to read them. - Compare against the address bar. A canonical of
http://on anhttps://page, orwwwon a non-wwwpage, means the stored site address disagrees with how the site is actually served. - Test logged out. Some plugins output different markup for administrators.
- Follow the canonical target. If it 301s somewhere else, the tag is self-defeating and should be pointed at the final destination.
The mismatches that cause most of it
WordPress generates canonicals from the stored Site Address, so any inconsistency between that value and the URL visitors actually reach shows up in every canonical on the site at once.
| Symptom | Cause | Fix |
|---|---|---|
Canonical uses http on an HTTPS site |
Site Address never updated after the certificate | Correct the stored address, then force HTTPS at the server |
Canonical adds or drops www |
Server serves both hostnames | Pick one, redirect the other permanently |
Canonical points to /home/ from / |
Static front page canonicalising to itself as a page | Ensure the front page canonical is the bare domain |
| Every paginated page points to page 1 | Plugin setting or theme filter | Make each page self-referencing |
| Canonical points at a staging domain | Database copied without a search-and-replace | Run a proper URL replacement across the database |
| Query-string URLs canonicalise to themselves | Tracking parameters treated as distinct pages | Canonicalise to the clean URL |
The staging case is worth singling out. A copied database keeps every absolute URL it contained, so a production site can quietly canonicalise its whole catalogue to a development hostname. If the site was recently moved, check this before anything else — migrating a WordPress site properly covers the replacement step that prevents it.
Canonical, redirect or noindex
These three get used interchangeably and they are not interchangeable.
- Canonical. Both URLs stay reachable and useful to visitors, and you are choosing which one accumulates ranking signals. Product variants and filtered listings fit here.
- 301 redirect. One URL should no longer exist. Stronger, unambiguous, and it fixes the visitor experience as well as the index. Prefer it whenever the duplicate has no reason to be visited.
- Noindex. The page is useful to visitors but has no business in search results — internal search pages, thin tag archives, thank-you pages. Never combine noindex with a canonical pointing elsewhere; the two instructions contradict each other.
WordPress-specific duplicates worth deciding on: attachment pages, which usually deserve a redirect to the parent; author archives on a single-author blog, which usually deserve noindex; and tag archives with two posts in them, which usually deserve deleting. The WordPress SEO checklist covers where each of these lives.
Verify, then leave it alone
After the change, reload the affected URLs logged out and confirm exactly one canonical tag matching the intended address, with no redirect between the tag and its target. Spot-check a post, a page, an archive, page 2 of that archive, and the homepage — those five cover the templates where the rules differ.
Then stop. Canonical tags are a consolidation signal, not a ranking lever, and re-pointing them repeatedly is more likely to slow reindexing than to help. If pages are still missing from search after the tags are correct, the cause is elsewhere: why a WordPress site is not showing in Google covers indexing blocks, and fixing orphaned content covers pages nothing links to.
Frequently asked
- Yes, for singular posts and pages WordPress outputs a self-referencing canonical tag by default. Archives, search results and paginated views are handled less completely, which is one reason SEO plugins replace the core output entirely.
- No. Each paginated view should reference itself, because pointing them all at page 1 tells search engines the later pages are duplicates and the content linked only from them can drop out of the index.
- Only when both versions genuinely need to stay reachable, such as a product listed in two categories. If one version simply should not exist, a 301 redirect is stronger and removes the duplicate rather than annotating it.