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. It's the same site, byte for byte, on a second hostname, with no redirect and usually no canonical tag. So 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

I audited a portfolio of sites this week and compared each custom domain against its platform subdomain. Two of them were byte-identical: same content length, same hash, no redirect, and 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 that were still live and fully indexable on their own subdomains, quietly serving a version of the product from months earlier.

None of that was deliberate. It's 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 one is authoritative, it makes the call itself. 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 get spread across two hostnames instead of adding up on one.

Stale copies are worse than duplicates. A months-old deploy still shows the prices, inventory, and claims from back then, so anyone who lands there is 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

If the hashes match, you're serving the same page on two hostnames. Next, check whether either one 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 often have a catch-all route that returns index.html for every path, /robots.txt included, so the file looks present when it's really 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. That one line consolidates everything onto the domain.

Acceptable: a self-referencing canonical pointing at the custom domain on every page. It tells Google which version counts without redirecting humans. Still, it's 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 a liability. Calling it an archive doesn't change that. Password protection returns a 401, which gets the copy dropped from the index, and you can reverse it any time. Deleting is definitive.

Never solve this by adding noindex to a site you actually want indexed. People make that mistake in a hurry more often than you'd expect, 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 check yours anyway
• 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're choosing to leave that decision to an algorithm when a one-line redirect removes the question entirely.

Will a 301 break my deploy previews? Not 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. You can still get in, and crawlers can't.

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 →