Somewhere in Search Console you have found what may be the strangest row this product ever shows a site owner. It sits in the Page indexing report, in a table headed, word for word:
The table’s heading in Search Console
Why pages aren’t indexed
One of the reasons listed in that table — one of the alleged problems — reads:
The reason, as the report names it
Alternate page with proper canonical tag
Click it, and the page that opens presses the charge; this line sits directly under the reason’s name:
The line under the reason’s name, on its detail page
These pages aren’t indexed or served on Google
Now read the reason again, slowly. Proper. In a report that exists to list what is wrong, Google is using the word for done correctly. It looked at your page, judged your canonical tag proper — and filed that verdict under a heading about failure, above a sentence about pages not being served. It is easy to lose a whole evening to that contradiction, hunting for the fix to something Google just said was right. (If it was Google’s email that first named this reason to you, the email itself is a separate story — one page is enough to trigger it.)
The word to believe is proper. The rest of this article shows why — and how to prove it on your own page, so you can close the report and mean it.
Two addresses, one page
“Canonical” is the piece of jargon doing all the work here, so, in plain words: to Google, every
distinct address is potentially a separate page. That matters because ordinary sites produce
spare addresses constantly — with www. and without, with a slash at the end and without, with
the tracking tail a newsletter adds to a link. Same content, several spellings — and Google would
rather not list one page five times.
A canonical is the standard solution: one line in the page’s code, a note visitors never see, saying the real address for this content is over there. You almost certainly never wrote one. Site platforms write it for you, page by page, as routine plumbing.
With that translated, the reason comes apart cleanly:
- “Alternate page” — Google found one of the spare addresses.
- “with proper canonical tag” — the note was there, and it held: it named the real address, and the real address is the one Google has listed.
Put back together, the row says: we found a copy of your page; you had already labelled it as a copy; we did as the label asked. Google’s own help page for the Page indexing report describes this reason with a sentence you will rarely meet in a screen full of warnings:
Google’s help page, describing this reason
This page correctly points to the canonical page, which is indexed, so there is nothing you need to do.
“there is nothing you need to do” — in writing, from Google’s own documentation of the report whose heading sent you here.
One footnote, because a careful reader who opens that link will notice it. The help page’s description names only the made-for-purpose copies — the separate “mobile” versions some platforms once built beside a page. In practice the report files ordinary spare addresses here too; the row on my own site, below, is one of those.
Why a correct page is filed under a problem heading
Because the table answers a narrower question than its heading suggests. “Why pages aren’t indexed” is an inventory: every address Google knows on your site and decided not to list, each with its reason. Most reasons are faults — blocked, broken, missing. But this address is a duplicate of a page that is listed is also, strictly, a reason an address is not in the index. So there it sits: a correct outcome, shelved between genuine errors, wearing the same alarming heading.
Nothing is missing. The content is on Google — under its real address, once, which is the point of the whole arrangement. The same help page says so in as many words:
Google’s help page, on duplicates and alternates
Duplicate or alternate pages shouldn’t be indexed. Having a page marked duplicate or alternate is usually a good thing; it means that we’ve found the canonical page and indexed it.
The report simply has no shelf marked “working as intended”. So this row shares a room with real problems, and inherits their tone.
The one on my own site
My own site has exactly one page filed under this reason, and it teaches the lesson better than any invented example could. The listed address:
https://kovalweb.com/core-web-vitals/#!
The #! tail is a leftover from an old scheme some sites once used to write their
addresses; the web moved on years ago. How Google came to hold this spelling I don’t know — the
report doesn’t say — and it changes nothing about the verdict.
The reason it lands here, and not in some other report, is the note. This address loads — it answers with the page — and the page it answers with carries this line, which you can read on any site by viewing its source:
<link rel="canonical" href="https://kovalweb.com/core-web-vitals/" />
That is the whole mechanism the reason name is describing. A spare spelling arrived, the page it served named its real address, and Google listed that address instead. Alternate page — the spelling. Proper canonical tag — the line above, doing its job.
(A near-twin of this address, without the trailing slash, sits in a different report entirely — it forwards instead of loading, so it counts as a redirect. That half has its own article.)
Mine traces to a slash and an old address scheme. Across sites, these alternates usually come from a short list:
-
Nothing to do
Address spellings —
www.and without,httpandhttps, slash and no slash. Several spellings, one page, one note pointing at the spelling the site settled on. -
Nothing to do
Tracking tails — links in newsletters and ads arrive decorated,
?utm_source=and friends. The decorated address shows the same page, and the note says so. - Nothing to do Made-for-purpose copies — printer-friendly versions, or the separate “mobile” copies some platforms once generated beside the main page (AMP, if you have met the term).
-
Nothing to do
Old address schemes — leftovers like my
#!, from ways addresses used to be written, still remembered long after the site moved on.
None of these needs a person. Which leaves the one version that might.
The version that does deserve a look
“Proper” carries one quiet assumption: that the note points where you meant it to point. Nearly always it does. But this row has a rare second reading, and separating the two is the only real work the report can ask of you.
Open the row and read the listed addresses with one question in hand: is this the address itself — or a spelling of it?
-
Close it
Spare spellings and decorated copies — tails, slashes, print versions,
#!s. The page they duplicate is on Google under its real address. This is the report working correctly, and there is nothing behind it. - Worth a minute A page you actually want found, listed here as somebody’s alternate — your services page, a product, the post you promote. That means Google indexed something else in its place, because a note on that page said to. Either the note is right and you hadn’t realised it (two pages were merged in a redesign, say) — or the note names the wrong page, and Google is obediently listing the wrong thing.
Telling those apart takes one tool and about a minute.
Prove it to yourself
The same help page points at the tool:
Google’s help page
You can find the canonical for any URL by running the URL Inspection tool.
URL Inspection is the search box at the very top of Search Console. Paste an address in, open the Page indexing section of the result, and near the bottom sit the two fields that settle this article:
- User-declared canonical — the address your page’s note asks for.
- Google-selected canonical — the address Google actually chose to list.
For the harmless case, inspect the real address — the one your listed alternate points at. You
are looking for the verdict “URL is on Google”, and “Page is indexed” inside the panel:
the content is listed, nothing is missing. When the address you inspect is the real one,
Google-selected canonical reads Inspected URL — the panel’s way of saying this page is its
own canonical, listed under exactly the address you meant.
For the worrying case, inspect the page you care about — the one that turned up as an alternate — and read User-declared canonical. If it names that page’s own clean address, or a page you would genuinely want standing in for it, the note is right and the row is noise. If it names a page with no business representing this one — an old address, an unrelated page — you have found the rare genuine version of this warning. The fix lives wherever your platform sets canonicals (a page setting, a theme, a plugin); the proof it worked is these same two fields, agreeing on the address you meant.
The correct action is to close the report
Two doors to close before you go. The issue’s page offers a Validate fix button, and it is not for you — it asks Google to re-check a fault, and this row is not one. And the row itself may sit there for a long time after you walk away: the date beside my own listed address says Google last read it in March 2025, over a year before I opened the report. A row staying put is not the same as a problem staying put.
So this article ends the way the evidence does: stop working on this row. Google’s message called your canonical proper. Its help page put “there is nothing you need to do” in writing. And two fields on your own page settle whatever doubt the heading planted. The honest conclusion is that there was never anything to fix — and knowing that is worth more than any fix you could have spent the evening on.
The part worth remembering
"Proper" is Google's word, and it means what it says: the duplicate was labelled, the label was followed, and the real page is on Google under its real address. A heading cannot overturn the sentence beneath it. Closing this report without changing anything is not neglect — here, it is the fix.
Koval SEO Console reads the public pages of your site — the same ones Google sees — and explains what it found in plain words, with the evidence beside each finding — then answers fixed, not fixed, or couldn't confirm when you check again.
Check my site