TL;DR
- John Mueller responded to a report of a site being de-indexed and replaced by an unrelated casino domain as its canonical, reported by Search Engine Journal on 18 September 2026.
- The likely cause is not a hijacked canonical but a site serving a generic client-side error shell to Googlebot, which then treats every URL showing that same error as duplicates.
- Mueller said the specific canonical outcome does not matter because every version ends with the page not showing for its normal content; the fix is the underlying error, not the canonical.
- His advice: use Search Console live URL inspection, catch errors before launch with automated tests, and monitor critical pages on a schedule so a broken render is caught early.
- A real cross-domain canonical requires the tag on your own domain, so if it is there and you did not add it, treat it as a hack; if it is not, it is not a canonical de-indexing.
Google's John Mueller responded to a report of a site apparently being de-indexed and replaced in search by an unrelated domain, and the useful takeaway is that this is almost never a hijacked canonical. It is usually a site accidentally serving an error page to Googlebot, which then gets treated as a duplicate of every other site showing the same generic error. Search Engine Journal reported the exchange on 18 September 2026.
The panic in these cases is understandable: a site owner sees their pages vanish and a strange domain, in this instance a casino site, listed as the canonical version of their content. But the mechanism people assume, that someone else canonicalised their site to a casino, is not how canonicals work. The real cause is more mundane and more fixable.
What a cross-domain canonical is
A cross-domain canonical is a meta tag that tells search engines the content on one site is the same as the content on another site. It is the multi-site version of the ordinary canonical tag that handles duplicate URLs within a single site. Google treats both as a strong hint, not an obligation, so it can and does ignore them.
Its legitimate uses have narrowed to almost nothing. It was a way to signal a site migration when a 301 redirect was genuinely impossible, which is rare now, and a way to point at the original version of syndicated content. For syndication, Google's guidance has since changed to recommend a meta noindex on the syndicated copies instead, using a robots meta tag such as noindex for Googlebot-News or for Googlebot generally. Because a canonical is only a hint while a redirect and a noindex are directives Google must obey, there is little reason to use a cross-domain canonical today.
What actually happened in the reported case
The site owner described a growing de-indexing where Google saw a casino betting page as the canonical version of their pages about companies and suppliers, despite no similarity in content. A second site owner who had seen the same thing supplied the likely explanation, and it has nothing to do with a malicious canonical.
Their site had occasionally served a client-side JavaScript error, the generic message "Application error: a client-side exception has occurred", during temporary outages when the application failed to load. When the third-party canonical URL was searched in Google, it showed as indexed with that same error message as its title. The theory is that Googlebot crawled an error or fallback response rather than real content, and then treated multiple unrelated URLs all showing that identical error shell as duplicates of one another. That is what produced the cross-domain canonical selection and the de-indexing, and it resolved itself once the pages served real content again.
What Mueller said to do
Mueller agreed the error-shell explanation was plausible and recommended using Search Console's live URL inspection to see how Google is actually rendering the page. His second point was more blunt and more useful: ultimately, he said, the specific canonical outcome does not matter, because every version of it ends the same way.
| Outcome Mueller described | Result |
|---|---|
| Your page is canonical but indexed with the server error message | Your page does not show in search for its normal content |
| Your page is treated as a soft 404, which Mueller said is what should happen | Your page does not show in search for its normal content |
| The other page is treated as canonical | Your page does not show in search for its normal content |
The point of the table is that chasing which canonical Google picked is a distraction. Whatever the label, the underlying problem is the same, Googlebot saw an error instead of your content, and the fix is the same too.
The real fix is not about canonicals at all
Mueller's recommended solution is to catch the error before the site goes live, not to fight the canonical after the fact. He described running automated tests before pushing a site live, and adding a new test whenever something goes wrong, so that a known failure can never recur silently. For an already-live site, the equivalent is monitoring: fetch your most critical pages on a schedule, hourly or similar, and check for issues, so a broken render is caught and fixed before it becomes a stable problem that search engines pick up.
This reframes the whole issue. The danger is not a canonical attack; it is your own site intermittently serving an error shell to Googlebot, most often on JavaScript-heavy pages that fail to render, during a deploy, or in an outage. If Googlebot only ever sees real content, the duplicate-error-shell problem cannot happen, and the exotic-looking cross-domain canonical symptom never appears.
When it really is a cross-domain canonical, and when it is coincidence
There is a narrow case where a cross-domain canonical genuinely is the cause: for the signal to transfer, your own domain has to contain a cross-domain canonical pointing at the other site. If that tag is on your pages and you did not put it there, that points to a hack, and the response is a security investigation, not an SEO one. If that tag is not on your pages, then whatever you are seeing is not a cross-domain canonical de-indexing, however much it looks like one.
This is where the SEJ report makes a wider point worth keeping. SEOs often tag a coincidence as a cause. A site loses rankings, someone notices multiple pages on a similar topic and blames keyword cannibalisation, or finds some low-quality backlinks and blames those, when the real cause was something unrelated, like an error shell served for a week. Two things happening around the same time are not proof one caused the other. Diagnose from what Google is actually rendering, through the live URL checker and your logs, before reaching for a dramatic explanation.
What this means for Thai marketers
This lands hardest on the kind of sites that are common in Thailand: JavaScript-heavy builds, single-page-application front ends, and sites on shared or lower-cost hosting that occasionally time out. Those are exactly the setups most likely to serve Googlebot a client-side error shell during a deploy or a traffic spike, which is the real trigger behind the scary-looking symptom here.
The practical guidance for a Thai site is unglamorous and reliable. Confirm what Googlebot actually renders using Search Console's URL inspection rather than trusting what you see in a browser, because a page that loads fine for a visitor can still hand Googlebot an error during a failed render. Put basic uptime and render monitoring on your most important pages so an outage that shows an error shell is caught in hours, not discovered weeks later as a de-indexing. And if pages do drop out, check the rendered content first before assuming a canonical, a penalty, or a competitor did it. This is core technical hygiene, and it belongs in a periodic SEO audit alongside the rest of your SEO work rather than as an emergency response after the traffic has gone.
Frequently asked questions
Can another website canonicalise my site to theirs and de-index me?
No. For a cross-domain canonical to transfer signals, the tag has to be on your own domain pointing at the other site. If that tag is on your pages and you did not add it, treat it as a possible hack. If it is not on your pages, what you are seeing is not a cross-domain canonical de-indexing, even if it looks like one.
Why did an unrelated site appear as my canonical?
The likely cause is that your site served a generic client-side error shell to Googlebot during an outage, and Google treated every unrelated URL showing that identical error as duplicates of one another. That produced the odd canonical selection, and it typically resolves once the pages serve real content again.
What did Mueller recommend?
Use Search Console's live URL inspection to see how Google renders the page, and fix the underlying error rather than the canonical. He advised catching errors before launch with automated tests, and monitoring critical pages on a schedule for already-live sites, so a broken render is caught before search engines index it.
Should I still use cross-domain canonicals?
Rarely. A canonical is only a hint, while a 301 redirect and a meta noindex are directives Google must obey. For a migration use a 301, and for syndicated content Google now recommends a meta noindex on the copies rather than a cross-domain canonical.
How do I tell a real cause from a coincidence?
Diagnose from what Google is actually rendering, using the live URL checker and your server logs, before blaming a canonical, cannibalisation, or backlinks. Two things happening at once do not prove one caused the other, and dramatic explanations are often misdiagnoses of a mundane rendering or uptime problem.
The bottom line
A site vanishing and a casino domain appearing as its canonical looks alarming and is almost always benign in origin: Googlebot crawled an error shell and lumped identical errors together. Mueller's advice is to stop chasing the canonical, because every version of the outcome means the same thing, and to fix the cause instead, catch the error before launch with tests, and monitor critical pages so a broken render never becomes a de-indexing. For Thai sites on JavaScript-heavy or lower-cost setups, that monitoring is the whole lesson: make sure Googlebot only ever sees your real content.
