Is Your Preview URL Getting Indexed Instead of Your Real Domain?

You bought a domain, pointed it at your site, and everything looked done. Then you search your business and the result that shows up is an ugly platform subdomain — or a staging link you forgot was public. This is not Google being slow or wrong. It is Google doing exactly what it was told by a site that is, technically, live at more than one address. To fix it you first have to know which of the two situations you are in.

Situation one: a preview or staging URL got indexed

Most AI builders and hosts give every deploy its own URL, and some of those are meant to be private. The good platforms mark them so they stay out of search — Vercel, for example, automatically sets an X-Robots-Tag: noindexheader on preview deployments (and on outdated production ones), so they are not indexed by default (V0-009). Replit’s development URL (*.replit.dev) is only reachable while the editor is running, so it is not a durable public page at all (RPL-013).

The trap is when a safeguard gets removed by accident. On Vercel, if you assign a custom domain to a non-production (preview) branch, Vercel does not set the noindexheader — so that deployment can be indexed (V0-010). A staging site you attached a real domain to is no longer hidden. That is a common way a “private” environment ends up competing with your production site.

Situation two: the default domain never left

The other cause is quieter. When you add a custom domain, the platform’s default address often keeps working too — so the same content is live at two URLs, and Google has to guess which is canonical.

Platforms handle this very differently, and the difference decides how much work the fix is.

Read the last column as a spectrum. Lovable is the more contained case: you designate one primary domain and the others redirect to it (LOV-011), so the duplication is handled by the platform rather than left to you. Replit is the case that needs active handling: the *.replit.app address remains live alongside your custom domain, and there is no documented switch to turn it off (RPL-014), so you have to resolve the duplication with signals rather than by deleting the second URL.

How to fix it, in order

1. Pick one canonical home. Decide that your custom domain — one host, www or bare, over HTTPS — is the real site. Every fix below points at that one URL.
2. Redirect the duplicate where you can. If the platform lets you make other domains redirect to the primary (as Lovable does, LOV-011), do that — a redirect is the strongest, least ambiguous signal.
3. Where you can’t redirect, use canonical tags.On a host where the default domain can’t be disabled (RPL-014), give every page a self-referential <link rel="canonical"> that points at the custom-domain URL, so both copies name the same authoritative address.
4. Never attach a real domain to a preview branch. On Vercel, that is what strips the noindex and turns staging into an indexable competitor (V0-010). Keep custom domains on production only.
5. Confirm what Google actually indexed. Use Google Search Console and a site: search for each address to see which URLs are in the index — then request removal or reindexing so the record matches your intent.

Our free visibility scan reads a public page the way a search engine does and reports what its canonical and indexing signals actually say — with no score and no email gate. To see exactly how your builder handles default domains and rendering, the platform pages break each one down. And when the canonicalization and redirects need to be implemented in the codebase, that is Search Foundation.