Alternate Page With Proper Canonical: Fix or Ignore?

You opened the Page Indexing report, saw a pile of URLs under Alternate page with proper canonical tag, and searched for what it means. Every result told you the same thing: it's normal, ignore it.

That advice is right roughly half the time. The other half, the exact same status is sitting on a page you are paying to rank — a service page, a city page, a paid-ads landing page — quietly telling Google to index something else instead. Nobody gets a warning, because to Google this looks like the system working.

This post gives you the two-minute test that separates the two cases, then the four patterns that produce a false 'safe to ignore' on service-business sites.

What does 'Alternate page with proper canonical tag' mean?

It means Google crawled the URL, found a canonical tag pointing at a different URL, agreed with it, and indexed that other URL in its place. Google's Page Indexing report defines the status as: 'This page is marked as an alternate of another page... This page correctly points to the canonical page, which is indexed, so there is nothing you need to do.' See the Page Indexing report documentation.

Read that last clause carefully. Google is telling you the *mechanism* worked. It is not telling you the *outcome* is what you wanted. Google has no idea which of your URLs you built a business around.

The page is not penalised, not broken, and not de-ranked. It simply does not exist as an independent result. Its signals — links, content, relevance — get consolidated into whatever URL the canonical points at.

When is this status genuinely safe to ignore?

It is safe in exactly one condition: the URL the canonical points to is the URL you want ranking, and that URL is indexed. If both are true, this is not an error — it is duplicate consolidation doing its job, and you should close the tab.

The boring, harmless cases you will see on almost every site:

• Parameter and tracking variants — /services/?utm_source=facebook collapsing into /services/
• Paginated or filtered views that point back to the main listing
• Protocol and host variants — http:// or www. versions pointing at your live https:// apex domain
• AMP or mobile alternates pointing at the desktop canonical (this is the case Google's definition was literally written for)
• Print or amp-style duplicates generated by a theme you never touched

None of these cost you anything. All of them will show up in this report forever. That is why the internet's stock answer is 'ignore it' — and why the dangerous cases hide so well inside a list of a few hundred harmless ones.

How do you tell in two minutes whether it is a real problem?

Run one comparison: does the Google-selected canonical equal the URL you want to rank? Paste the affected URL into Search Console's URL Inspection tool, open Page indexing, and read two fields — User-declared canonical (what your site says) and Google-selected canonical (what Google actually indexed).

Google's URL Inspection documentation describes the Google-selected canonical as 'the page that Google selected as the canonical (authoritative) URL when it found similar pages on your site' and warns that 'Google might select the user-declared canonical, but sometimes Google might choose another URL that it considers a better canonical example.' Source: URL Inspection tool.

Three outcomes, three verdicts:

The whole diagnosis is that one comparison. Everything else in the report is noise until you have made it. If you are staring at hundreds of affected URLs, sort by which ones you actually want traffic to — a technical SEO audit should start with your money pages, not with the biggest number in the report.

One caveat from Google's own docs: the inspected value 'can be a few hours out of date.' If you shipped a fix this morning, re-inspect tomorrow before you conclude it failed.

Which four patterns silently canonicalise away a page you need?

Four recurring patterns produce a false 'safe to ignore' on service-business sites, and all four are self-inflicted at the template level.

The unifying failure: someone set a canonical rule at the template level, not the page level. It was correct for the one page they were looking at and wrong for the forty pages that inherited it.

Verdict on the four: the child-service and city-page patterns are the expensive ones. They kill the pages with commercial intent. Host and UTM variants are usually recoverable in an afternoon.

Why did your page builder canonicalise a city page to its template?

Because most page builders and CMS SEO plugins let you set the canonical field once on a template and copy it to every page generated from it. Duplicate the 'Dallas' page to make 'Fort Worth', and you duplicate the hardcoded canonical too — now Fort Worth tells Google 'index Dallas instead.'

It is the single most common way location and service-area pages quietly fail. The pages exist. They look fine. They are in the sitemap. And Search Console files every one of them under a status whose official advice is 'nothing you need to do.'

The fix is mechanical: every page that you want ranking on its own gets a self-referencing canonical — a canonical tag pointing at its own URL. Google's duplicate-URL guidance explicitly recommends including 'a rel=canonical link on the canonical page itself.' See Consolidate duplicate URLs.

Then check that the canonical is actually a full absolute URL on the right host. A relative canonical, or one still pointing at a staging domain, produces the same symptom.

What breaks when UTM-tagged ad landing pages get canonicalised?

Nothing breaks for paid traffic — canonicals do not affect whether your ads run or where they land. What breaks is the landing page's ability to exist in organic search at all, and your ability to trust the Quality Score story you tell yourself about it.

Get the two cases straight:

• A UTM-tagged version of a page you already have (/services/plumbing?utm_source=google) — canonical to the clean URL. Correct. Ignore the report entry.
• A dedicated PPC landing page with different copy and a different offer (/lp/24-7-emergency) — should NOT canonical to /services/plumbing. They are different pages with different conversion jobs. Give it a self-referencing canonical, or noindex it if you truly want it out of organic.

Canonicalising a distinct landing page to a service page tells Google the two are the same document. They are not. You lose the landing page as an organic asset, and you muddy which page Google associates with the keyword you're bidding on.

Noindex and canonical solve different problems. Noindex says 'do not show this page.' Canonical says 'this page is the same as that one.' Reaching for the wrong lever is how a perfectly good landing page vanishes.

How do you fix a wrong Google-selected canonical?

You do not force it. You give Google stronger, consistent signals and wait for a recrawl. Google lists what actually feeds the decision: whether the page is served over HTTP or HTTPS, redirects, presence of the URL in a sitemap, and rel=canonical annotations — and states plainly that 'indicating a canonical preference is a hint, not a rule.' See Google's canonicalization documentation.

In Google's ranking of methods, redirects and rel=canonical are described as strong signals; a sitemap is a weak one. So the order of operations:

• Point every signal at the same URL. Google's guidance is explicit: don't specify different URLs as canonical for the same page using different techniques. Tag, sitemap, internal links, and redirects must agree.
• Set a self-referencing canonical on every page you want indexed independently — absolute URL, correct host, correct trailing-slash form.
• Fix internal links. If your nav links to the non-canonical variant, you are voting against yourself on every page of the site.
• Make the page actually different. If Google overrode your self-canonical, it decided two of your pages are near-duplicates. Thin, templated city pages with the town name swapped are exactly what triggers this — that is a content problem, not a tag problem.
• Redirect the loser if the duplicate serves no purpose. A 301 is the strongest signal available and removes the ambiguity permanently.
• Re-inspect after the next crawl. Expect days to weeks, not hours.

If Google keeps overriding you after the signals are consistent, stop fighting the tag. Two of your pages are competing for the same intent, and the honest fix is to merge them — see keyword cannibalization for how to decide which page survives.

Anyone who promises to 'fix' this in a week is guessing. Recrawl timing is Google's, not yours. What is in your control is making sure that every signal points where you want it, once.

Where should you start if the report shows hundreds of URLs?

Start with the ten to twenty pages you would be angry to lose — your core service pages, your top city pages, your best-converting landing page. Inspect those. If their Google-selected canonical is correct, the rest of the report can wait, likely forever.

The mistake is triaging by volume. A report with 400 affected URLs where all 400 are UTM variants is healthy. A report with 12 affected URLs where 3 are your money pages is an emergency. Volume tells you nothing; which URLs tells you everything. Pull the affected list from the Page Indexing report in Search Console and sort it against your revenue pages, not against the count.

If you'd rather not hand-inspect every template on your site, our technical SEO audit covers canonical mapping across service, location, and landing-page templates — and tells you which of your indexation issues actually cost money. Get my free audit.