Google can pick a stranger's domain as your canonical, and Search Console won't show you the traffic

Google's John Mueller has answered a site owner who found an unrelated betting domain sitting where their own pages used to be, and the explanation that came out of the thread deserves a careful read from anyone running a software marketing site on a JavaScript front end. Nothing suggests the site was penalised. Google seems to have briefly lost the ability to tell its pages apart from strangers' pages, because for a while they were all serving the same broken screen.

Roger Montti wrote the case up for Search Engine Journal on September 18, working from a Reddit thread. The site publishes pages about companies and their suppliers, and its owner reported watching pages fall out of the index while Google treated a casino page as the canonical version of them. There was, they said, "absolutely no similarity in content" between the two.

A second account in the thread supplied a mechanism. Their own site had intermittently served a stock client-side failure message during outages, and the third-party canonical turned out to be indexed under that same generic error text. Their reading: Googlebot had fetched the broken shell rather than the page, then filed every URL wearing that shell as one duplicate group. It unwound by itself after a few weeks. Mueller called that a possible explanation and pointed them at the URL Inspection tool.

Google already documents this failure

Montti is not convinced the Reddit case is really about cross-domain canonicals, and his reasoning is sound: that tag has to live on your own site to pass anything anywhere, so either the site was compromised or two unrelated events were being read as cause and effect. Hold that scepticism about this particular site. The mechanism underneath it is not speculative, because Google publishes it. In the common-issues list on Google's canonicalization troubleshooting page, alongside server misconfiguration, sits the line that "two unrelated web servers may return identical soft 404 pages that Google fails to identify as error pages".

That sentence is the entire bug. Canonical clustering groups pages that look substantially the same, then elects one of them. You did not write your error string, and neither did the stranger you are now grouped with. Google's JavaScript documentation notes that every URL returning a 200 gets queued for rendering, so a client-side error delivered under a success status arrives looking like an ordinary page with unusually thin content.

Software marketing sites are exposed for dull reasons. They are disproportionately client-rendered single-page apps, built by product engineers using the same few frameworks as every other software company. Shared stack, shared defaults, shared error copy.

The dashboard goes quiet, not red

The worst part is a detail in the same Google page that has nothing to do with rankings. If the canonical Google picks sits on a property you do not control, Google says "you won't be able to see any of the traffic for your duplicate page". Your reporting does not show an error. It shows less.

Two companies that share nothing become the same document the moment both are serving the failure text their framework shipped with.

The recovery timing is documented as well. Google warns that pages can sit in a duplicate cluster for as long as two weeks after the underlying content problem is fixed, and suggests requesting re-indexing for your most important URLs once it is.

Run those two facts together. A deploy that broke your marketing pages for half an hour on a Friday evening can buy you a fortnight of degraded indexing, and the instrument you would normally check first has been made blind to it. By the time organic numbers look wrong enough to investigate, the incident behind them is several sprints back and nobody kept the logs.

What to do differently

Almost none of the remedies belong to marketing, which is precisely why they do not get done. Mueller's advice was to catch the problem before the site goes live, running automated tests ahead of each push and adding a test whenever something breaks; failing that, monitoring that fetches critical pages hourly and fixes issues "before they become stable problems for search engines". Google's JavaScript guidance is more specific: error states in a client-rendered app should add a robots noindex tag via JavaScript, so a soft 404 never presents itself as indexable.

• Inspect a few money pages in Search Console and confirm the Google-selected canonical is on your own domain.
• Ask engineering whether your error and fallback states carry a noindex tag, and whether they return a 200.
• Get your top landing pages into whatever uptime monitoring the product already pays for, checked on content and not just status code.
• Keep a dated log of front-end incidents, so an organic dip six weeks out has something to be matched against.

The awkward conversation is the third one. At most software companies the marketing site sits outside the product's on-call rotation, so a broken page there wakes nobody. Ask to change that on uptime grounds and it reads like a vanity request. Frame it as an indexing liability with a two-week tail and a reporting gap, and it becomes a risk the people who own the deploy pipeline can be asked to close. Supplying that framing is the marketer's job here, because engineering has no reason to know the canonical rules and Search Console is not on their screen.