URL Canonicalization: How to Test and Fix It

What is URL canonicalization?

Most sites can be opened at more than one address without anyone planning it. The same article might load at http://example.com/post, at https://www.example.com/post/ and at a version with tracking parameters on the end. Canonicalization in SEO is the job of picking the single representative address that should be indexed and shown in search results, then making every signal on your site agree with that pick.

Three terms get mixed up, so keep them apart. The canonical URL is the address you chose. The canonical tag is one way of declaring it. Canonicalization is the whole job, which also includes redirects and consistent internal links. A passing tag check does not finish the job.

The canonical link relation is defined in RFC 6596, published in April 2012, and it can be sent as an HTML link element or as an HTTP Link header, a mechanism described in RFC 8288 on web linking. Search engines, including Googlebot, treat it as a strong hint, not a command. In computing, the word also describes converting a URL into its canonical form, which RFC 3986 on URI syntax covers under URI normalization. This page covers only the SEO meaning. If you need tag syntax and attributes, the canonical tag guide goes deeper than we do here.

Why URL canonicalization matters for SEO

Every address a crawler can reach is a candidate for indexing. When links, shares and bookmarks point at the http version, the www version or the slash version, the link equity your page earns gets divided between several URLs instead of landing on the one you want to rank. Crawlers also burn crawl budget fetching copies, and sometimes the version that shows up in results is the one you never meant to publish, such as an http page or the wrong host.

Duplicate content in this sense is rarely malicious. It is a side effect of how servers and CMS platforms work. Analytics and Search Console can also list one page under several URLs, which hides the real numbers. In the Page indexing report of Google Search Console you may have met the labels this produces: Duplicate without user-selected canonical, Duplicate, Google chose different canonical than user, and the harmless Alternate page with proper canonical tag.

Google Search Central frames this as a choice of representative URL, and duplicate URL versions rarely lead to a penalty. The real cost is diluted signals and an address chosen by the search engine instead of by you.

Common URL variants that need canonicalizing

A typical site produces more duplicate URLs than its owner realizes. The table maps each variant to an example and the fix that suits it.

Variants that no visitor should ever see, which means protocol, host, slash, case and index files, get a 301 redirect. Variants that must stay reachable, such as sorting, filtering by URL parameters and a print view, keep working and carry a canonical tag that points at the main version. A fragment such as #pricing is not a separate URL for crawling purposes, so it needs no canonical at all.

MDN treats the www question as subjective: pick one, stay consistent and send the other host to it with a 301, as the MDN www and non-www guide explains. For the protocol row, our SSL and HTTPS test guide covers certificates and the secure connection. Slashes, case and parameters as URL design belong in the SEO friendly URL guide.

How SEO Site Checker tests URL canonicalization

When you run the report, it opens your address in headless Chromium, follows any redirects, waits for the load event and reads the rendered HTML of the final page.

The exact rule: the report counts every link element in the document whose rel value contains the lowercase word canonical. One element passes, two or more give a warning, and none fails. The href is never compared with anything.

The Meta Canonical row in the same report uses identical detection, so those two rows always show the same result.

What the check reads

A matching tag is counted wherever it sits: in the head, in the body or inside a noscript element. A tag that a script adds while the page loads is seen too. Our report accepts that, though Google recommends putting the canonical in the HTML source and not changing it with JavaScript.

What pass, warning and fail mean

• Pass: exactly one canonical link was found. The row shows a green badge with the href value, with the message This webpage has valid canonical link.
• Warning: two or more canonical links were found, even when they are identical. The row shows the same text as a missing tag, with no href badge and the red How to Fix button.
• Fail: no canonical link was found. The row shows the message This webpage has not canonical link and the How to Fix button.

What the check does not look at

The row is named URL Canonicalization, but the test is narrower than the name, so a pass proves only that a tag exists. It counts a tag in the body, although Google only accepts the link element inside the head, and a green row does not show that the redirects from the fix steps are in place.

• Not tested: redirects for http, https, www, non-www or trailing slash versions of the address.
• Not tested: the value of the href, so an empty, relative, http or other domain address still passes.
• Not tested: a canonical sent only in an HTTP Link header, or written as a meta tag with the name canonical, because neither is a link element in the HTML.

Run the free report

How to check your canonical URL

Five quick checks show what a page declares and whether your redirects behave. Only the first two show what our report reads.

1. View the source. Press Ctrl+U and search for canonical. You should find one link tag in the head, with the absolute https address you want indexed.
2. Search the rendered DOM. In Chrome DevTools, open the Elements panel and search for rel="canonical". This is the page after scripts have run, as our report reads it.
3. Use the terminal. Fetch the page with curl and filter for the tag, then request only the headers to see whether a Link header carries a canonical.
4. Test the redirects. Request the http, www and https www versions of your homepage with curl -sI. Every version except the preferred one should answer 301 with a Location header that reaches the preferred address in one hop. The preferred address itself should answer 200.
5. Ask Google. The URL Inspection tool in Search Console shows the user-declared canonical and the Google-selected canonical. When the two differ, Google chose another address.

curl -sL https://example.com/page/ | grep -i canonical
curl -sI https://example.com/page/ | grep -i link
curl -sI http://example.com/
curl -sI http://www.example.com/
curl -sI https://www.example.com/

On the first two lines, look for one canonical tag and any Link header. On the last three, look for a 301 status and a Location line that names your final address directly, because a Location that points at yet another redirect is a redirect chain to shorten. These examples assume the bare domain is preferred. If you chose www, the https www request should answer 200 instead.

How to fix URL canonicalization step by step

Decide first, redirect second, declare third, and only then clean up the supporting signals.

1. Decide once. Choose https, then your preferred domain (www or the bare one), then trailing slash or none, and lowercase paths.
2. Redirect. Send every other version to the final address in a single 301 or 308 permanent redirect hop (308 is defined in RFC 9110).
3. Add one canonical tag. Use an absolute, self referencing link in the head that matches the redirect target exactly.
4. Make signals agree. Align internal links, sitemap URLs, hreflang, og:url and structured data.
5. Retest. Run the curl commands from the previous section, then run the report again.

Pick one preferred version

Write the decision down first. Protocol: https, always. Host: www or the apex domain, whichever suits your branding and hosting. Slash: whatever your CMS already produces. Case: lowercase.

Redirect every other version with a 301

Apache HTTP Server, in .htaccess or the virtual host: this mod_rewrite block handles the http to https redirect and the www to non-www redirect in one hop. The R=301 flag is deliberate, because the plain R flag defaults to a 302 temporary redirect. Apache's documentation prefers a plain Redirect from mod_alias inside a virtual host where possible, and the Apache canonical hostnames recipe shows the options. Behind a proxy or CDN that terminates TLS, the HTTPS variable can read off permanently, so test for a loop first.

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L]

Nginx, in your server config: the first block catches port 80 for both hosts, and the second catches the https www host.

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name www.example.com;
    # add your ssl_certificate and ssl_certificate_key lines here
    return 301 https://example.com$request_uri;
}

This code covers protocol and host only. Your CMS normally handles a trailing slash mismatch (WordPress redirects to its own slash style by itself). Apache can lowercase paths with a RewriteMap using the tolower function, but only in server or virtual host config, not .htaccess, so most owners fix case in the CMS. Redirect an index.html duplicate to the folder address from the same place.

Add one self referencing canonical tag

Place a single link element in the head of each indexable page. Its href must match the redirect target character for character, including scheme, host and slash, so the tag and the redirect never disagree.

<link rel="canonical" href="https://example.com/services/">

Parameter and print variants stay reachable, so they carry a tag too. On a sorted listing such as /shoes/?sort=price, the head names the clean main listing:

<link rel="canonical" href="https://example.com/shoes/">

Make every other signal agree

• Internal links. Link only to the preferred version, so no click goes through a redirect.
• XML sitemap. List the preferred URLs and nothing else.
• Hreflang and og:url. Use the same scheme, host and slash as the canonical tag in both.
• Structured data. Make any url or mainEntityOfPage values match the preferred address.

Then retest and rerun the report. Once https is stable, you can add HSTS so browsers skip the http hop, which our HSTS guide explains.

URL canonicalization on WordPress, Shopify, Wix and Cloudflare

Many site owners cannot edit server files, and on hosted platforms they never need to. What matters is where each platform prints the tag and where its redirect settings live.

WordPress core prints a canonical link on single posts and pages, and Yoast SEO and Rank Math both add a per page canonical field. When the report shows a warning, the usual cause is a theme and a plugin that each print a tag, so switch one off. Also check that the Site Address under Settings, General uses your preferred https URL.

Shopify themes print the tag with the canonical_url Liquid object, normally inside theme.liquid. If the report warns, search theme.liquid and any installed SEO app for a second canonical tag and remove it. Set your primary domain in the admin's domain settings, and domains configured as redirects will send visitors to it. Wix generates a self referencing canonical on every page and lets you change it per page in the page's SEO basics panel; check Wix's help center for the current route.

Cloudflare can handle the redirect side without touching your origin: use a redirect rule or a bulk redirect for www to the apex domain, and turn on Always Use HTTPS for the protocol. If your origin has an HTTPS redirect like the Apache rule above while the SSL mode is Flexible, the browser loops, because Cloudflare reaches your server over plain http. Use Full or Full (strict) with a certificate on the origin. On cPanel hosts, the Redirects screen with the type Permanent (301) covers host and protocol versions without code.

Canonical tag, 301 redirect or sitemap: which signal to use

Several signals can state your preferred address, and they differ in strength and in what the visitor sees.

Google describes redirects and the canonical tag as strong signals and a sitemap entry as a weak one, and its Google duplicate URL guidance lays out all the methods. Our XML sitemap guide explains why entries should list preferred URLs only.

If nobody needs the other address, redirect. If both addresses must stay reachable, use the tag. Files with no head, such as PDFs, cannot hold a tag, so they use the HTTP Link header, sent as a response header that names the preferred address:

Link: <https://example.com/downloads/guide.pdf>; rel="canonical"

On Apache you set it with Header set (mod_headers) and on Nginx with add_header, in the block that serves the file. Google supports it for web search only. Pick the tag or the header for a page, not both, to avoid a mismatch.

Avoid mixed signals. A page that redirects to address A while its tag names address B, or a canonical that points at a redirecting URL, forces the search engine to guess. Noindex plus canonical on one page is a separate conflict, covered below.

URL canonicalization best practices

• Use absolute URLs. Write the scheme and host in every canonical, because a relative URL is easy to resolve wrongly.
• One tag per page. Give each indexable page a self referencing canonical and make sure it is the only one.
• Keep the target live. The canonical address should return 200, be indexable and not redirect anywhere else.
• Clean sitemap and links. List only canonical URLs in the XML sitemap and link internally to the preferred version.
• Match every detail. Scheme, host, slash and case should be identical in the redirect target, the tag, the sitemap and og:url.
• Review after changes. Look at the canonical set again after a migration, a theme change or a new SEO plugin.

For the wider audit, the technical SEO checklist covers the checks that sit beside this one.

URL canonicalization mistakes that break the check

Common causes: two canonical tags on one page, usually one from the theme and one from a plugin, which produces the warning state.

The quieter mistakes do not always change the report, yet they hurt in search. Each has a symptom you can look for.

• A second tag from a plugin. The report shows a warning even though the page looks fine. Search the rendered DOM for rel="canonical" and switch off whatever prints the extra element.
• A tag in the body. Our check counts it, but Google only accepts the canonical link element in the head, so the page can pass here and still be ignored. Move it into the head.
• A target that redirects, returns 404 or is noindex. The tag names an address that cannot be indexed, so the signal is wasted. Canonical plus noindex on one page is the same contradiction, as the noindex tag guide explains.
• Every page canonical to the homepage. This usually comes from a template with a hardcoded address. Inner pages drop out of the index, or Search Console reports Duplicate, Google chose different canonical than user.
• An http canonical on an https page. Search engines keep being pointed at the insecure version after the redirect was added. Update the template or SEO plugin setting to https.

One mistake is specific to our check. Writing rel="Canonical" with a capital letter is valid HTML, but the report will not find it and marks the tag as missing.