Why Google is indexing the wrong domain for your site

On a client site in August 2026, we traced it to a single file whose job was to answer one question: what is this site’s address? It answered by reading the deployment environment, which is the hosting platform telling the app what URL it’s currently running on.

In production, that resolved to the platform’s own URL rather than the custom domain. And because every part of the app asked that one file, every part of the app got the same wrong answer.

The structured data one is the quiet damage. Search results recover. Answer engines resolving your business entity to a hosting URL is a longer road back, because that association gets reused every time something asks about you.

The custom domain had been connected about ten days earlier. So it ran wrong for ten days, on a site that looked completely fine the entire time.

Because it works, right up until it doesn’t. Deriving the address from the environment means preview builds get correct links to themselves, nobody has to remember to update a constant, and the hosting platform’s own documentation often nudges you toward it.

It fails at exactly one moment: production, on the real domain, which is the only moment that counts for search. And it fails silently, because a page that declares the wrong canonical renders identically to one that declares the right one.

Pin the production host as a constant. Preview builds then declare production as canonical instead of competing with it, which is what you wanted anyway.

We hit a subtler one on our own site while building this library, on 2026-08-10.

Nothing was derived from the environment here. The problem was that the address was written down in more than one place, and one of them disagreed. Our case study pages declared the non-www version of the domain, while the robots file, the sitemap and every other page declared the www version.

Same category of failure. Different symptom. In the first case the site had one source of truth and it was wrong. In the second it had several, and they’d drifted. Both end with your pages pointing at a host you didn’t intend, and neither shows up as anything visibly broken.

All five, on your live domain, not a preview link.

1. 01Open your homepage, right-click, View Page Source, and search the text for “canonical”. The URL you find should be exactly the domain you want ranking.
2. 02Do the same on a deeper page, a service page or a blog post. This is where mismatches hide, because deeper pages often get built later by someone else.
3. 03Visit yoursite.com/robots.txt and yoursite.com/sitemap.xml and read the URLs in them. Same domain, every time.
4. 04Check www against non-www. Pick one as the real one, and make sure every canonical, the robots file and the sitemap all agree with that choice.
5. 05Search a distinctive exact phrase from your homepage in quotes, and look at which URL comes back.

Character for character. https://site.com and https://www.site.com are two different sites as far as a search engine is concerned, and so are /page and /page/.

Write the production domain down once, as a fixed value, and have everything read from it. In the client case that was a single line, and it corrected all six surfaces at once because they all asked the same file.

Keep an override available for the day the domain genuinely changes, so nobody has to hunt through the code to rebrand. And on each page, point the canonical at that page’s own address, which also protects you from tracking parameters being treated as separate pages.

Then do the part everyone skips. Go fix the README and the code comments. On that client site, both documented deriving-from-the-deployment as intentional behavior. Leave that in place and the next person restores the bug on purpose, believing they’re following the convention.

Last, verify on the live domain rather than in your editor. Load the real page, view source, and read the value back. We check six things: canonical, og:url, og:image, structured data, robots and sitemap.

It won’t un-index the wrong URL overnight. Search engines re-crawl on their own schedule, and it can take days to weeks for the right domain to take over. Submitting the page for indexing helps. Patience is still required.

A canonical tag is also a strong hint, not a command. If your site is reachable at several addresses, back the hint up with real redirects so there’s only one place to land. Your apex should redirect to your www, or the reverse, and it should be a permanent redirect.

And if you’re on a hosted website builder, this particular bug mostly isn’t yours to have, because the platform owns those tags. Worth doing step one anyway. It takes thirty seconds and occasionally surprises people.