JavaScript error pages can make Google index another site instead

A site owner reported on Reddit that Google was de-indexing a small but growing number of their company and supplier pages and had chosen a casino betting page on an unrelated domain as the canonical for them. The two sites share no content. Search Engine Journal’s piece covers the thread, including two replies from Google’s John Mueller. His main point is that the cause matters less than catching the error before the site goes live with it.

The likely cause came from another commenter who had seen the same thing. When that commenter searched the third-party canonical URL in Google, it was indexed with the title “Application error: a client-side exception has occurred (see the browser console for more information).” Their own site shows that same generic JavaScript error when the app fails to load during outages. The commenter’s theory is that Googlebot crawled the error screen instead of the real page, and Google then treated every URL showing that identical error text as a duplicate of the others. Their case cleared up on its own after a few weeks.

The theory fits how Google picks canonicals, and it needs no canonical tag at all. Google groups pages with the same content and chooses one URL to represent the group, whatever the pages declare, as covered in Mueller’s list of reasons Google overrides rel=canonical. An error screen is the same text on every site that shows it, so a supplier directory and a casino can land in one duplicate group. The likelier explanation is that the casino page simply won that group, not that someone attacked the site. Search Engine Journal’s piece adds the other side: a genuine cross-domain canonical needs a tag on your own pages pointing to the other domain, so if you find one you did not add, treat it as a hack.

Mueller agreed the error-page explanation could be right and said the exact mechanism does not matter much. His second reply lists three ways Google can handle a page that serves an error message:

• The page stays canonical but is indexed with the error message as its content.
• Google treats the page as a soft 404, which Mueller says is what Google should be doing.
• Another site’s page becomes the canonical.

In every case, per Mueller, the page no longer shows in search for its normal content. The casino URL in Search Console is a symptom. The broken render is the problem, the same way silent soft 404s cost one publisher most of its traffic after a migration.

What to do

1. Run the live test in Search Console’s URL Inspection tool on an affected page, as Mueller suggests, and look at the rendered screenshot and HTML for error text instead of your content.
2. Search Google for the URL that Google selected as canonical. If its indexed title is an error message, the commenter’s explanation probably applies to you too.
3. Check your raw HTML for a rel="canonical" pointing off-site. If one is there and nobody on your team added it, handle it as a security incident.
4. Catch the error before Google does. Mueller runs automated tests before every deploy on his own sites and adds a new test each time something breaks. He also recommends fetching your most critical pages hourly, with your own monitoring or a third-party tool, and checking for problems.

A client-side exception only appears after JavaScript runs, so a plain HTTP fetch of the HTML will likely look fine while users and Googlebot see the error. The check needs a real browser. A minimal version with Playwright:

// check-pages.mjs: run hourly from cron or CI
import { chromium } from 'playwright';

const urls = ['https://example.com/', 'https://example.com/suppliers/'];
const browser = await chromium.launch();
const page = await browser.newPage();
for (const url of urls) {
  await page.goto(url, { waitUntil: 'networkidle' });
  const text = await page.innerText('body');
  if (text.includes('Application error')) {
    console.error(`Error screen on ${url}`);
    process.exitCode = 1;
  }
}
await browser.close();

Outages that come and go are the hard case. The commenter’s site looked clean by the time they investigated, so a live test run today can pass even though Google indexed the error last week. Hourly checks with logged results show when the error screen appeared, which a single live test cannot.