WordPress canonical URL wrong? Follow the other clues
You open URL Inspection for an important WordPress service page and find Google has selected a different canonical from the one the page declares. It is an unsettling little message, especially when that page is meant to bring in enquiries.
Before changing the canonical field in Yoast, Rank Math or another SEO plugin, inspect the rest of the route. Google may be seeing an old migrated URL, a redirect, a sitemap entry and a set of internal links all pointing in a different direction. The tag may be correct. The website may simply be arguing with it.
For a Dubai, Liverpool or UK service business, this can mean the page being improved by marketing is not the URL Google treats as the main version. Reporting, link equity and organic visibility can end up attached to an older address while everyone keeps polishing the newer one. Bit of a waste of a Tuesday.
First, separate a bad canonical tag from a conflicted site
A canonical tag is a request for search engines to treat one URL as the representative version of substantially similar pages. It is not a switch that forces Google to rank that URL. Google considers several signals when consolidating duplicates, including redirects, rel=canonical annotations, sitemap inclusion and internal linking. Its canonicalisation guidance also makes clear that Google can choose a different representative URL where those signals conflict.
A WordPress canonical URL is wrong when the page declares a URL that is genuinely not the version the business wants indexed, such as an outdated domain, incorrect protocol, a filtered route or a page copied from a template. It is a different problem when the declared tag is sensible but redirects, internal links, the XML sitemap or duplicate content keep promoting another version.
Canonicalisation is a site-wide consistency problem before it is a plugin setting. Changing one field can be the right repair, but only after you know which version should survive and why Google might reasonably be unconvinced.
The canonical signal checklist
Use one important URL at a time. Do not start bulk-editing canonicals across the site because Search Console has shown one unexpected result.
| Signal to compare | What should normally happen | What a conflict can mean |
|---|---|---|
| Page URL | The preferred public address loads as expected. | Trailing slash, HTTP, www, category or parameter variants remain available. |
| Declared canonical | The page source names the preferred representative URL. | An SEO setting, template rule or migration remnant points elsewhere. |
| Redirect behaviour | Old duplicates use a relevant permanent redirect to the preferred URL. | A redirect sends users and crawlers back to an older route. |
| XML sitemap | Only preferred, indexable URLs appear. | The sitemap still publishes a retired or duplicate address. |
| Internal links | Navigation, service cards and contextual links use the preferred URL. | Menus, footer links or old page-builder modules favour the wrong route. |
| Google-selected canonical | Usually aligns once the other signals agree. | Google sees stronger evidence for another similar URL. |
Decide whether there is a real duplicate
Start by putting the declared canonical and Google-selected canonical side by side. Then load both URLs in a private browser window and check their final destination. You are looking for a meaningful difference, not merely a small formatting variation.
Sometimes the older URL redirects cleanly, the old page is gone and the matter is simply waiting for recrawl. More often, both versions still return a 200 status code and contain near-identical content. This happens after WordPress migrations, service-page restructures and page-builder duplication. A page may have moved from /services/web-design/ to /website-design/, while the old route has been left live because somebody did not want to break an old link.
That is not automatically disastrous, but it needs an intentional decision. Keep one version, redirect or canonicalise the other appropriately, then make the remaining signals agree.
Follow the old URL through the WordPress setup
A fairly common scenario: a WordPress service page declares itself canonical at the new URL. Yet the main navigation still links to the old migrated page, the footer has a hard-coded old link, and the XML sitemap lists both. Google has decent grounds to treat the old page as the representative version.
Check places people often miss:
- Header and footer menu items edited separately from page content.
- Reusable Elementor, Divi or block patterns carrying an old URL.
- Service cards in templates or custom fields.
- Breadcrumb settings in an SEO plugin.
- Cached XML sitemaps still being served by a cache layer or CDN.
- Old internal links in blog posts, PDFs and campaign landing pages.
The boring operational bit is that a sitemap can look updated in WordPress while a cached version is still being served at its public URL. If that is the suspicious part of the trail, use this guide to troubleshoot a WordPress sitemap that is not updating before deciding Google has ignored your changes.
Choose the correction route
When the canonical tag itself is wrong
Correct the page-level or template-level canonical setting, then confirm the preferred URL is indexable, returns the expected status code and is the URL used in internal links and the sitemap. Watch for a global SEO template rule affecting a whole post type. Fixing one page while twenty others inherit the same problem is not much of a repair.
When the site signals disagree
Choose the preferred URL based on the business route you actually want to maintain. Update navigation and contextual links, remove retired duplicates from the sitemap, and add relevant permanent redirects where an old URL has genuinely been replaced. Do not redirect unrelated pages to a convenient service page just to tidy a report. That confuses visitors as well as crawlers.
When the pages are different enough to deserve separate indexing
Do not force them into a canonical relationship merely because their titles are similar. A Dubai website design page and a Liverpool website design page may be distinct if each has materially useful local content, evidence and a clear reason to exist. Thin location clones are another matter.
Validate the repair in the right order
- Confirm the preferred URL loads, is indexable and declares the intended canonical.
- Test old and variant URLs for their final redirect destination.
- Check the public sitemap, not only the sitemap preview inside WordPress.
- Search the site for internal links to the retired URL, including templates and menus.
- Use URL Inspection again after deployment and allow time for recrawling and reprocessing.
If the page remains crawled but excluded after the canonical signals have been made consistent, the issue may be wider than duplicate selection. Our guide to WordPress pages crawled but currently not indexed covers the next diagnostic branch without pretending one setting guarantees inclusion.
Where the signals still disagree after this review, it is worth treating it as a broader technical clarity issue rather than another plugin tweak. An AI readiness audit for website structure and machine readability can help review the technical and content signals together, particularly on service sites with years of migrations, page copies and accumulated workarounds.
Questions about WordPress canonical URLs
Why is Google ignoring my canonical tag?
Google may select another canonical when redirects, internal links, sitemap entries or page content give stronger evidence for a different representative URL. It may also decide that the pages are not close enough duplicates for your canonical preference to make sense. Check the full group of related URLs before altering the tag.
Which canonical signals should agree on a WordPress site?
The preferred URL should normally match the declared canonical, internal links, XML sitemap entry and final redirect destination for retired duplicates. It should also be indexable and return a successful page response. These do not make a guarantee, but consistent signals give Google a much clearer instruction.
Should every old WordPress page redirect?
No. Redirect an old page when it has a clear replacement that serves the same intent. If there is no relevant replacement, a redirect may mislead visitors. Review whether the page should remain available, return an appropriate status, or be removed from navigation and the sitemap instead.
Inspect the URL as Google sees it before changing the canonical field in an SEO plugin. A short review of the competing URLs is usually cheaper than months of optimising the wrong page.