TrafficTriage

What Is a Canonical URL and Why the Wrong One Tanks Rankings

By Ugur Saritepe · July 9, 2026

A canonical URL is the one version of a page you tell search engines to index when several URLs show the same content. You declare it with a <link rel="canonical"> tag. Point that tag at the wrong URL and you formally ask Google to drop the page it just crawled. One command shows what yours says.

The 30-second self-diagnosis

Fetch any inner page (not the homepage) and read its canonical tag. curl matters here: it shows the raw HTML a crawler gets, before any JavaScript runs.

curl -s https://yourdomain.com/pricing | grep -oi '<link[^>]*rel="canonical"[^>]*>'

What comes back sorts you into one of four cases:

What a canonical URL actually is

The same content almost always answers on several URLs without you doing anything wrong: http and https, www and the bare domain, ?utm_source= tracking variants, trailing slash and not. To search engines each of those is a separate URL, and together they are duplicate content: one page, many addresses. Google resolves this by picking exactly one URL per group as the canonical; only that URL gets indexed and ranked, and the rest fold into it.

The canonical tag is your vote in that pick. It is one line in the page's <head>:

<link rel="canonical" href="https://yourdomain.com/pricing" />

Two mechanical rules from Google's canonicalization documentation (as of July 2026): the tag only counts inside <head>, and the URL should be absolute, not a relative path. The same documentation ranks the signals Google reads: a redirect and a rel=canonicaltag are each “a strong signal,” while a sitemap listing is a weak one. Note the word signal: the tag is a strong hint, not a command, and Google can override it. That matters later.

Why the wrong canonical tanks your rankings

The canonical tag is a consolidation signal: it moves a page's indexing and ranking credit to whatever URL it names. That is exactly why a wrong one is so damaging. A broken image hurts one page; a broken canonical redirects the credit for a page somewhere else, silently, on every crawl.

How wrong canonicals happen

1. The canonical is hardcoded in a shared template

The classic cause of “canonical points to homepage.” The tag lives in a layout or theme file that every page renders, with the site's root URL pasted into href. Every page then ships the identical tag. Nobody notices, because the tag is invisible in the browser.

30-second check: run the diagnosis curl on two different inner pages. Good: each names itself. Bad: both return the identical homepage href.

Fix:build the canonical from the current page's path, not a constant. In Next.js App Router, set metadataBase once in the root layout, then give each route a relative canonical:

export const metadata = { alternates: { canonical: "/pricing" } };

2. Your SPA sets the canonical with JavaScript

Single-page apps often manage head tags client-side (react-helmet, a useEffect, a router hook). The browser shows the right canonical, but the raw HTML the server sends carries whatever the shared shell had: often the homepage canonical, on every route. Google can eventually render JavaScript, but other crawlers mostly don't, and even Google reads the raw HTML first.

30-second check: compare the diagnosis curlagainst the same page in your browser's devtools. Good: both show the same self-referencing tag. Bad: the browser looks right but curlshows the shell's tag or nothing; crawlers see the curl version. If your page content is also missing from the raw HTML, you have a bigger problem than canonicals; that case is cause 4 in our Vercel indexing triage.

Fix:put the canonical in the server-rendered or prerendered HTML, one per route. If you can't server-render yet, prerendering just the head per route already fixes what crawlers see.

3. The wrong host is baked into your site config

Most frameworks build canonical URLs from a single site-URL constant (an env var, metadataBase, a theme setting). Set it once to https://www.yourdomain.com and later serve the site on the bare domain (or leave a staging address in it), and every canonical on the site now names the wrong host. The apex-vs-www mismatch is the version of this we see most, in both directions.

30-second check: find where your site actually lands after redirects, then compare hosts with your canonical:

curl -sIL -o /dev/null -w "%{url_effective}" https://yourdomain.com

Good: the host printed here matches the host in your canonical tag. Bad: they differ, or the canonical names a domain that no longer serves anything.

Fix: update the one constant your canonicals are built from to the final, post-redirect URL, redeploy, and re-run the diagnosis curl. While you're there, make sure the losing variant 301-redirects to the winner, so the redirect and the tag say the same thing.

4. Some pages have no canonical at all

Usually a template split: the marketing pages share a layout that emits the tag, the blog or docs use another that doesn't. This is the mildest failure. Nothing breaks today; you've just handed the choice back to Google page by page.

30-second check: run the diagnosis curl on one page from each section of your site (one product page, one blog post, one doc). Bad: any of them returns nothing. Fix:emit a self-referencing canonical from the shared layout logic, computed from each page's own path.

Self-referencing is the default; cross-page is the exception

The safe default for every indexable page is a canonical that names the page itself. Deliberately pointing one URL's canonical at a different URL is correct only when the two really are the same content:

Verify the fix: user-declared vs Google-selected canonical

Because the tag is a hint, the last word belongs to Google, and Search Console shows you both sides of the conversation. Open URL Inspection on a fixed page and compare two fields in the indexing section: User-declared canonical (what your tag says) and Google-selected canonical (what Google decided). Healthy means they match.

If they don't, or pages sit under “Duplicate, Google chose different canonical than user” in the Pages report, Google overrode your tag because other signals disagreed with it: internal links pointing at a different variant, the sitemap listing another URL, a redirect going elsewhere. Realign everything to name one URL per page (tag, sitemap, internal links, redirects), request indexing, and give Google days to a couple of weeks to recrawl. Occasionally Google's pick is simply right; when the URL it chose is the better one, change your tag to agree rather than fighting it.

How TrafficTriage runs this check

Canonicals are check #4 of the eight in our free Triage Report. We fetch your homepage plus up to three sampled inner pages (your key paths and the first URLs from your sitemap) and read each page's rel=canonicalfrom the raw HTML, the same crawler's-eye view as the curl above. Every sampled inner page canonicalizing to the homepage scores Critical. A homepage canonical whose host differs from the host your site actually resolves to scores Monitor; we compare against the post-redirect host, so a site that correctly 301s the bare domain to www and canonicalizes to www passes with no false alarm. Missing canonicals on sampled pages score Monitor.

If this check comes back Critical, fix it before anything on the report that's merely Monitor: a site whose every page claims to be the homepage can only ever rank its homepage.

From experience: 1 site in 7 gets this wrong

Between July 5 and July 9, 2026, we ran this check on 28 sites. Four failed it: two declared a canonical host that didn't match the live one (one said wwwwhile the site resolved to the bare domain, the other the exact reverse), and two were missing canonicals on part of their pages. In all four cases the tag was built from a config value nobody had looked at since launch. A fifth site technically failed too, but for a grimmer reason: it had been hacked, and the pages Google had indexed weren't the owner's at all, so canonicals were the least of its problems.

Notably, none of the 28 had the every-page-to-homepage failure. It is the rarest of the three cases in the wild, and also the only one we score Critical, because it caps a whole site at one indexable page. Our own site passes the check: as of July 2026, traffictriage.com serves a per-page, correct-host canonical on every sampled page. The other seven checks from the same report are explained in Checks Explained, starting with what a soft 404 is.

FAQ

Do I need a canonical tag on every page?

Google picks a canonical for every page whether you declare one or not, so a missing tag isn't fatal. But declaring a self-referencing canonical on every indexable page costs nothing and keeps you in control: without it, a tracking-parameter variant or an old duplicate can win the pick, and you find out only when the wrong URL shows up in search results.

Why did Google choose a different canonical than the one I set?

Because rel=canonical is a strong hint, not a command. When your other signals disagree with the tag (internal links pointing at a different URL, the sitemap listing another variant, a redirect going elsewhere), Google weighs them all and can override you. Search Console reports this as "Duplicate, Google chose different canonical than user." The fix is to make every signal name the same URL.

Should page 2 of a paginated list canonicalize to page 1?

No. Page 2 is not a duplicate of page 1: it lists different items. Canonicalizing the whole series to page 1 tells Google the later pages don't need to exist, so anything only reachable or listed there loses its path into the index. Each paginated page should carry a self-referencing canonical.

Is a canonical tag the same as a 301 redirect?

No. A redirect physically sends every visitor and crawler to the target URL; the old address stops serving content. A canonical tag leaves the page fully reachable and only advises search engines which URL to index. For true duplicates you don't need to keep serving (an old domain, http, a retired URL), the redirect is the stronger and cleaner signal.

Want the canonical check run on your site right now?

Get a free Triage Report: eight checks run from your URL alone, no Search Console access needed, each scored Critical / Monitor / Healthy, ending with the one thing to fix this week. It renders on your screen in about half a minute, with no signup and no email required.

Request your free Triage Report →