The canonical tag that quietly deletes your site from Google

Our own site had this problem. Every page on esspryllc.com carried a sitemap, an og:url and structured data that all named www.esspry.com as the real address. That domain does not resolve. It has no DNS record at all.

So for as long as that was live, the site was politely telling every search engine that its content lived somewhere unreachable. It is difficult to think of a more effective way to disappear.

We did not notice because nothing looks broken. The site loads. The pages render. Analytics, if you have any, shows the same near-zero numbers it showed last month. There is no error to see.

What a canonical tag actually does

A canonical tag is a line in the head of a page that says: of all the addresses that can reach this content, this one is the real one.

It exists because the same page is usually reachable several ways. With and without www. With and without a trailing slash. With tracking parameters stuck on the end. Over http and over https. To a search engine those are four or more different addresses showing identical content, and it has to decide which one to index and which to treat as a duplicate.

The canonical tag makes that decision for it. Left to guess, the engine picks one itself, and it may not pick the one you built links to.

The failure mode nobody checks for

A missing canonical is a mild problem. A canonical pointing at the wrong domain is a severe one, and it is far more common than it sounds, because of how sites get built.

Somebody starts a project with a placeholder domain. Or the site is copied from an older build. Or a template ships with the agency's own domain in the config. The value gets set once, in one place, and then the site is deployed under a different name and nobody rereads a tag that no human ever sees.

From there it propagates. Whatever generates your sitemap reads the same config. So does the og:url. So does the JSON-LD. One wrong value, quietly repeated in four places that all matter.

How to check, in about thirty seconds

Open your homepage, view source, and search for `rel="canonical"`. Read the domain in the href.

Then open your robots.txt and read the Sitemap line. Then open the sitemap itself and read the first `<loc>`.

All three should name the domain you are actually on. If any of them names something else, you have found something worth fixing today rather than this quarter.

If reading source is not your idea of a good time, the free site check on this site does the same three reads and tells you what it found.

What it costs while it is broken

This is the part worth being precise about, because the damage is not evenly distributed.

Google generally treats the canonical as a strong hint rather than an instruction. Faced with a canonical pointing at a domain that returns nothing, it will often fall back to indexing the address it actually crawled. So the site is not necessarily wiped from the index. That is the good news, and it is why sites can carry this fault for a long time without anyone noticing a cliff.

The bad news is everything downstream. Ranking signals that should consolidate onto one address get split. The sitemap, which is your most direct statement of what exists, points at nothing crawlable, so the discovery path you built is doing no work. Any social share pulls an og:url on the wrong host. And you have handed the engine a reason to distrust the rest of your markup.

The fix is one line. The interesting question is how long it was wrong before anyone looked.

Fixing it so it cannot come back

Do not fix the canonical tag. Fix the thing the canonical tag reads from.

Put the site's origin in exactly one place in your codebase, and have the canonical, the sitemap, robots.txt, the og:url and every structured data identifier read from that one value. Then a domain change is a one line change, and the four things that must agree cannot drift apart, because they are no longer four separate decisions.

That is how this site is built now, which is a slightly embarrassing thing to write given how it started. It is also the first thing we check on SEO work we take on, because nothing else moves until the technical layer agrees with itself.