Indexing and technical SEO guide
Diagnose Canonical Selection in WordPress and Search Console
Compare the canonical your page declares with the one Google selected, work out which of three canonical statuses applies, and change signals only when the choice is wrong.
On this page
Put two URLs side by side: the canonical your page declares and the one Google selected, both shown in the URL Inspection tool. If they match, or if Google picked an equivalent URL you are happy with, there is nothing to fix. If Google picked a URL you do not want, find out why the signals disagree (a staging domain, an http and https mix, parameter copies, near-identical pages) and make redirects, canonical tags, internal links, and the sitemap all point at the same address.
Google’s canonicalization overview, checked September 27, 2026, says “indicating a canonical preference is a hint, not a rule.” A saved canonical setting is a request. What Google does with it is an observation you record, not a result you can force.
The three canonical statuses
The Page Indexing report uses three reasons for canonical selection. The descriptions are from Google’s Page Indexing report help, checked September 27, 2026.
| Reason | What Google says | What it usually calls for |
|---|---|---|
| Alternate page with proper canonical tag | “This page correctly points to the canonical page, which is indexed, so there is nothing you need to do.” | Nothing. It is working as intended. |
| Duplicate without user-selected canonical | “This page is a duplicate of another page, although it doesn’t indicate a preferred canonical page. Google has chosen the other page as the canonical for this page, and so will not serve this page in Search.” | Check which URL Google picked. Declare a canonical only if you disagree. |
| Duplicate, Google chose different canonical than user | “This page is marked as canonical for a set of pages, but Google thinks another URL makes a better canonical.” | Inspect both URLs and find the conflicting signal. |
Many WordPress URLs can land in the first two rows on purpose, such as parameter copies of a page. Old addresses that redirect are reported separately, as “Page with redirect.” The rows are a problem only when the URL Google indexed is not the one you want visitors to land on.
Read the declared and selected canonicals
Inspect the URL in Search Console and note User-declared canonical and Google-selected canonical. Google’s URL Inspection help, checked September 27, 2026, describes the second as the URL Google chose. Then inspect the URL Google selected, too, so you can compare both pages.
Next, read what your page actually sends, as a logged-out visitor:
curl -s https://example.com/some-page/ | grep -io '<link[^>]*rel="canonical"[^>]*>'
curl -sI https://example.com/some-page/ | grep -i "^link:"Google’s guidance on specifying a canonical, checked September 27, 2026, accepts a rel="canonical" link element in the HTML head and a Link HTTP header, and asks for absolute URLs rather than relative ones. Look for three things: exactly one canonical, an absolute https:// URL on your live domain, and a target that returns 200 without a redirect. If you find two canonical tags from different sources, fix that first by turning off the second source, so the page makes one declaration before you judge Google’s choice.
If you use WP Visibility, it prints a self-referencing canonical on indexable pages by default, uses the Canonical URL field in the editor’s Indexing panel when you fill it in (“Leave empty to use this post’s own URL”), and prints no canonical on pages it marks noindex, internal search results, or the 404 page. Its wp visibility post-audit <id> command warns when a post’s canonical points to another host, a quick way to catch a staging address left in the field; see Run the Site Audit. A saved field is not proof of output, so confirm with the commands above.
WordPress causes of an unexpected selection
Google’s canonicalization troubleshooting page, checked September 27, 2026, lists causes including a CMS or plugin making incorrect use of canonicalization techniques, server misconfiguration, missing hreflang on localized pages, syndicated content, and hacked sites inserting cross-domain canonicals. On WordPress, these are the patterns to check first:
| Pattern | What you see | Where to look |
|---|---|---|
| Staging domain leakage | Canonicals, links, or images point to staging.garden.example after launch |
Database URLs left from the migration; search and replace them |
| Protocol or host mix | Google selects http:// or the www variant |
Settings > General, WordPress Address (URL) and Site Address (URL), plus the host’s HTTPS and www redirects |
| Parameter copies | Google selects a URL with ?utm_source= or a sort parameter |
Internal links or ads that carry parameters; canonical on the clean URL |
| Near-identical pages | Two posts or a page and a post with the same text | An editorial merge, then a redirect |
| Attachment pages | An image’s attachment page competes with its post | The wp_attachment_pages_enabled option from WordPress 6.4 (checked September 27, 2026), which has no settings screen, or your SEO plugin |
| Paginated or archive copies | Page 2 of an archive, or a category showing full posts, is selected over the post | Show excerpts in archives; link to the post itself |
WordPress’s redirect_canonical() reference, checked September 27, 2026, describes how core already redirects some variants, such as ?p=123 to the pretty permalink and the www or non-www host to the home URL’s form, using a 301. When core does that, a crawled variant is reported as “Page with redirect,” not as a duplicate. When a duplicate is reported instead, something served the variant with a 200 when Google crawled it.
As an illustration, the fictional garden.example launches from a staging copy. The theme’s hardcoded canonical still reads https://staging.garden.example/pruning-guide/. URL Inspection on the live page shows the staging address as the user-declared canonical and the live address as Google’s choice. The fix is to remove the stale canonical so both agree, not to rewrite the live page’s content. This scenario is invented to show the reasoning, and Google’s choice in a real case is something you observe, not something the example predicts.
Decide whether to change anything
Change signals only when the selected URL is one you do not want. If Google picked https://example.com/pruning-guide/ over https://example.com/pruning-guide/?ref=newsletter, that is the outcome you wanted, even if you never declared it.
When the choice is wrong, align the signals. Google’s canonical guidance ranks redirects and rel="canonical" as strong signals and sitemap inclusion as a weak one:
- Redirect true duplicates you do not need to the preferred URL with a 301. Redirect a Changed URL covers WP Visibility’s rules.
- Declare one absolute canonical on each remaining variant, pointing at the preferred URL.
- Link internally to the preferred URL. Google’s guidance says to “link to the canonical URL rather than a duplicate URL.”
- List only preferred URLs in the XML sitemap.
- Differentiate pages that should both be indexed, so they are not near copies.
Google’s guidance also says not to use robots.txt for canonicalization, and recommends against using noindex to steer canonical selection within a site.
Verify the emitted page, then recheck
- Purge page and CDN caches, then repeat the
curlcommands on the preferred URL and each variant. - Confirm redirects land on the preferred URL in one hop. Redirect chains and loops covers tracing them.
- Run Test live URL on the preferred URL and read User-declared canonical.
- Request indexing for the preferred URL once.
Google’s troubleshooting page says that even after content issues are fixed, Google “might hold pages in a duplicate cluster for up to two weeks.” Record the date of your change and look again after that. For deciding whether a duplicate page should be merged or removed in the first place, see 404, 410, or redirect.