Google's John Mueller says a JavaScript error page can get your site treated as a duplicate of an unrelated site

Search Engine Journal's Roger Montti reported on Thursday that Google's John Mueller has responded to a Reddit post claiming a business site was being de-indexed and replaced in Google's index by an unrelated casino URL. The site owner said their pages cover companies and suppliers, and that Google was showing a betting page as the canonical for their content, though the two sites had nothing in common.

Where the casino URL actually came from

A cross-domain canonical is a meta tag one site adds to point at another site's URL. Google treats it as a strong hint but is free to ignore it. For signals to move from site A to site B, site A has to carry the tag pointing at site B. If neither site added the tag, the reported de-indexing has another cause.

Another Reddit user, No_Wrap_9584, described the same problem and worked out what was happening. When they searched Google for the third-party URL, it was indexed with the title "Application error: a client-side exception has occurred (see the browser console for more information)." That is a generic JavaScript error message, and their own site had occasionally served the same message during short outages when the app failed to load. Their theory: Googlebot crawled the error page rather than the real content, then treated every URL serving that shell as a duplicate. From that group, Google picked one as the canonical, which is why an unrelated site can appear in place of yours.

What Mueller said to do about it

Mueller agreed the theory could be right. He recommended using the URL Inspection tool in Search Console to check how Google is rendering the page.

He then wrote that the outcome is the same in all three cases the owner might worry about: whether Google picks your page as canonical and indexes the error message, whether Google treats it as a soft 404, or whether Google picks the other page as canonical. In every case your page fails to show for normal content.

Mueller said the fix is to catch the error before Googlebot ever sees it. He described his own habit on smaller sites: run a large set of automated checks on the built site before pushing it live, and whenever something goes wrong, have the coding agent add a new test for that case. He also recommended external monitoring on the most important pages, fetching them on a schedule and alerting when the content is wrong, so the problem is caught early.

What to do on a client-rendered site

A React or other client-rendered site fails in a way most server frameworks do not: when the bundle throws during hydration, or when a chunk fails to download, the page can render as a small error string instead of real content. The HTML the crawler receives can look near-identical across many unrelated sites using the same framework, which is what makes them clusterable.

Two steps for a team shipping a client-rendered site. Serve a real 5xx status from the server when the app cannot render, so the crawler treats the response as an error rather than as thin duplicate content. And check what Googlebot actually receives at the moment of a deploy: URL Inspection in Search Console shows the rendered HTML, and any 200 response that is really an error page is a warning sign to investigate before it spreads across the index.

Source

Google Responds To Cross-Domain Canonical De-Indexing Report by Roger Montti at Search Engine Journal.