Duplicate without user-selected canonical means Google found more than one URL with the same or nearly the same content, looked for a canonical tag telling it which URL is the original, found none, and chose one itself. The page in the report is the one Google did not choose. It is excluded from the index, and the URL Google picked instead is shown in URL Inspection under Google-selected canonical. Sometimes Google chooses well. On vibe coded sites it often chooses the homepage, because the homepage is the only URL the site ever declared. This article covers where the duplicates come from, how to prove which version of the bug you have, how to date when it started, the fix in order, and the recrawl step that most people skip and then wonder why nothing changed.
What a canonical tag is for
A canonical tag is one line in the head of a page that names the address Google should treat as the original.
<link rel="canonical" href="https://yourdomain.com/services" />Every page should carry one, pointing at its own absolute URL, in the exact spelling you use everywhere else. When the same content is reachable at two addresses, the tag tells Google which one to index and which one to fold into it. When the tag is missing, Google folds them anyway and picks the survivor by its own rules: the shorter URL, the one with more links, the one it crawled first, or the one on https. You do not get a vote, and the report is Google telling you it voted for you.
The two versions AI builders ship
A builder that emits one HTML file for every route puts one canonical tag in that file, usually pointing at the homepage. Every sub-page then carries a written instruction that it is a copy of the homepage. That case shows up in Search Console as the sibling status, Duplicate, Google chose different canonical than user, because you did select one, just the wrong one. The status in this article, without user-selected canonical, is what you get when the builder emitted no canonical at all, and Google found the same content at two addresses.
The two addresses are almost always one of these pairs.
- The page with and without a trailing slash. Both load, both return 200, neither declares which is real.
- The page on www and on the bare domain. Same content, two hostnames, no redirect between them.
- The page on your lovable.app or similar preview subdomain and on your real domain. The preview host was never turned off after you connected the domain.
- The page on http and on https, when the redirect was never set up at the host.
- The page at its real path and at any made-up path, because the server returns 200 with the same content for every URL it does not recognise. This one is the killer, because it means every URL that has ever been linked with a typo is a duplicate of the homepage, and the supply is infinite.
- The page with and without tracking parameters, such as a utm_source added by a newsletter tool, when nothing tells Google the parameters do not change the page.
Prove it in five minutes
- Open the page in Google Search Console's URL Inspection and read the two canonical lines. User-declared canonical shows what your HTML said. Google-selected canonical shows what Google decided. If the first is empty, you have this status. If the first is the homepage, you have the sibling status. Either way, the second line tells you where your page went.
- View Page Source on the page and search for rel=canonical. Read the href as text. Do not trust the browser inspector for this; it resolves the URL and can add a trailing slash or a hostname that is not in the file.
- Load your domain followed by a random path that does not exist and check the status code. If you get a 200 and the homepage, every unknown URL is a duplicate.
- Compare the URL in your sitemap with the URL in the canonical and with the URL in your navigation links. Trailing slash, www, and http versus https must match character for character across all three.
- Load the page on www and on the bare domain, and on http. Two of the three should redirect with a 301 to the third. If all three load, the hostname is not settled.
curl -s -o /dev/null -w "%{http_code}\n" https://yourdomain.com/no-such-page
curl -sI http://yourdomain.com/services | grep -i "^location"
curl -sI https://www.yourdomain.com/services | grep -i "^location"
curl -s https://yourdomain.com/services | grep -i "rel=\"canonical\""The first line must print 404. The second and third should print a Location header pointing at your one true hostname. The fourth should print one canonical tag whose href is the page you fetched.
How to date when it started
On a site that has been live for a while, it helps to know whether the duplicates predate you, because that decides how much of the index Google has already consolidated. The Wayback Machine keeps the original file if you ask for it correctly. Add id_ after the timestamp in an archive URL and the archive returns the unrewritten HTML instead of its own rewritten copy, so the canonical href you read is the one that was live on that date.
https://web.archive.org/web/20260301000000id_/https://yourdomain.com/servicesRead the canonical in a capture from before your last rebuild and one from after. The byte size of the capture tells the same story: a raw JavaScript shell is a few kilobytes, a rendered page is 25 to 110 kilobytes. On a five-page Lovable site I audited, every capture of every sub-page carried the homepage canonical from the day it launched, which is why Search Console showed one indexed page and why the owner's months of content work had been filed as copies.
The fix, in order
- One canonical per page, pointing at that page's own absolute URL, with the exact hostname and slash convention you use everywhere else. On a server-rendered Lovable project this is one line in each route's head() block. On the old build it needs the upgrade first, because one shared HTML file cannot carry a different tag per route.
- Return a real 404 status for unknown paths. On a Cloudflare Worker or a similar edge host that is a few lines in the catch-all route; on a static host it is a config file entry.
- Redirect www to bare or bare to www with a 301, and http to https with a 301. One hostname, one scheme. Most hosts have a toggle for this; check it actually fires with the curl lines above.
- Turn off the preview hostname or make it redirect to the real domain. A lovable.app copy that still serves 200 is a full duplicate of your site.
- Rewrite the sitemap so every URL matches the canonical string exactly and carries a lastmod date. Remove any old sitemap submissions that point at the preview host.
- Request indexing on each affected page in URL Inspection, most important first. Check Google-selected canonical again in two weeks; it should now match the page.
Not sure what Google chose for your pages?
Send me your URL. I will pull the user-declared and Google-selected canonicals for every page in your sitemap and send you the table, with the fix for each mismatch.
The page with redirect variant
Some people see this status alongside Page with redirect for the same URLs, or find that the Google-selected canonical is a URL that now redirects. That happens when you fixed the hostname after Google had already picked the wrong one. Google chose the www version as canonical, you then redirected www to bare, and now the canonical points at a redirect. It resolves on its own once Google recrawls both versions, and you speed it up by requesting indexing on the bare URL and making sure the sitemap lists only the bare URL. Do not add a canonical pointing at the redirecting version to make the report go quiet; that reintroduces the loop.
What happens after
This status is not a ranking problem. It is a door that was closed. Once each page carries its own canonical and Google has recrawled it, the page enters the index and impressions for its queries begin, usually the day it enters. If your report shows Discovered, currently not indexed on the same pages afterwards, that is normal; it means the door is open and the page is in the queue. If it shows Crawled, currently not indexed, Google has now read the real page and wants more from it, which is a content job. And if you want to avoid the whole thing on the next build, the canonical rule belongs in your first prompt, which is what the Vibe Code SEO service starts with.
Questions people also ask
Is Duplicate without user-selected canonical bad for SEO?
It means a page is out of the index, so yes for that page. It is not a penalty and it does not affect the pages Google did choose. Fix the tags and the excluded pages come back.
How do I fix Duplicate without user-selected canonical in Search Console?
Add a self-pointing absolute canonical to every page, settle on one hostname and one slash convention with 301 redirects, return 404 for unknown paths, align the sitemap, then request indexing on each affected URL. The report clears over the following weeks as Google recrawls.
Should the canonical point to the homepage?
Only on the homepage. A canonical on any other page that points at the homepage tells Google that page is a copy of the homepage, and Google will drop it. That is the most damaging single tag a builder can emit, and older Lovable builds emitted it on every route.
Does Google always respect the canonical tag?
It treats it as a strong hint, not a command. If the two pages are clearly different, Google may ignore a canonical that tries to merge them. If the tag points at the page itself and the page is unique, Google follows it.
What is the difference between this and Duplicate, Google chose different canonical than user?
Without user-selected means your page had no canonical. Chose different means it had one and Google overruled it, most often because the tag pointed at the homepage or at a URL that redirects. The fix is the same; the second one tells you the tag is present and wrong.
