The duplicate of your site you didn't know you published

When you deploy to Netlify, Vercel, or most other hosts, you get a free subdomain immediately: something like bucolic-crostata-0c1d32.netlify.app or your-project.vercel.app.

Later you point your real domain at it. The site goes live at yourbusiness.com and everyone moves on.

The subdomain keeps serving. Byte for byte, the same site, on a second hostname, with no redirect and usually no canonical tag. You now have two copies of your website on the public internet and Google gets to choose which one it indexes.

This is not theoretical

Auditing a portfolio of sites this week, I compared each custom domain against its platform subdomain. Two of them were byte-identical — same content length, same hash, no redirect, no rel=canonical on either side. One was a 244,914-byte application, served twice.

There were also two stale copies: older deploys of the same projects, still live on their own subdomains, still fully indexable, quietly serving a version of the product from months earlier.

None of that was deliberate. It is just what happens by default.

Why it costs you

Google picks a canonical for you. When it finds identical content on two hostnames and no signal about which is authoritative, it chooses. It usually gets it right. "Usually" is doing a lot of work in that sentence, and the failure mode is your machine-generated subdomain ranking instead of your brand.

Any authority splits. Links, engagement signals, and crawl budget divide across two hostnames instead of accumulating on one.

Stale copies are worse than duplicates. A months-old deploy shows old pricing, old inventory, old claims. If someone lands there, they are reading a version of your business that no longer exists.

How to check, in thirty seconds

Compare your domain against the platform subdomain:

curl -s https://yourbusiness.com/ | shasum

curl -s https://your-project.netlify.app/ | shasum

Identical hashes mean identical pages on two hostnames. Then check whether either declares a canonical:

curl -s https://your-project.netlify.app/ | grep -i 'rel="canonical"'

Empty output means nothing is telling Google which one wins.

Also worth checking: whether a robots.txt exists at all. Single-page apps frequently have a catch-all route that returns index.html for every path — including /robots.txt. The file looks present and is actually your homepage wearing a filename.

How to fix it

Best: a 301 from the subdomain to the domain. On Netlify, a _redirects file:

https://your-project.netlify.app/* https://yourbusiness.com/:splat 301!

The ! forces the rule even when a matching file exists. This consolidates everything onto the domain and costs one line.

Acceptable: a self-referencing canonical pointing at the custom domain on every page. It tells Google which version counts without redirecting humans. Weaker than a 301, because a canonical is a hint and a redirect is an instruction.

For abandoned copies: delete or password-protect them. A deploy nobody maintains is not an archive, it is a liability. Password protection returns 401, which drops it from the index while staying reversible. Deleting is definitive.

Never solve this by adding noindex to a site you actually want indexed. It is a surprisingly common mistake made in a hurry, and it removes the wrong copy.

The wider pattern

Every deployment platform hands you extra public hostnames, and each one is a page that can outrank you:

• Platform subdomains — .netlify.app, .vercel.app, *.pages.dev
• Branch and preview deploys — usually noindex by default, but verify rather than assume
• Deploy permalinks — the immutable per-build URLs, which persist indefinitely
• Staging environments on a real subdomain — staging.yourbusiness.com is the classic offender

The rule that covers all of it: every hostname that serves your content should either redirect to the canonical one or refuse to serve strangers. There is no third acceptable state.

Common questions

Doesn't Google figure this out on its own? Usually. But you are choosing to leave the decision to an algorithm when a one-line redirect removes the question entirely.

Will a 301 break my deploy previews? No, if you scope the rule to the production subdomain specifically. Preview URLs live on different hostnames.

What if I want the subdomain reachable for testing? Password-protect it. Reachable to you, invisible to crawlers.

How long until Google drops the duplicate? Days to weeks after it recrawls and sees the redirect. Nothing to do but wait.

We build sites at Riv Lux Media, and we check this on every launch. Esta entrada en español →