The Canonical Error Nothing Warns You About: A Tag Pointing at the Wrong URL

In February 2025 a journalist at WIRED posted a public question to a web development forum. He was looking into the new doge.gov website, and he had noticed that its canonical tags pointed at x.com. He wanted to know why a developer would make that choice.

The thread collected 876 upvotes and 80 replies. The top answer, at 647 upvotes, gave the correct technical explanation: the site was largely a feed of posts syndicated from that platform, and a canonical tag is how you tell a search engine which copy of syndicated content is the original.

Another reply put the effect in plain language, and it is the sentence this whole article hangs on. A canonical pointing at another domain tells search engines that when someone searches for the content on this page, do not show this page. Show that other one instead.

That is the risk in one line. The canonical is the only tag on your site that can give your search visibility to a URL you do not own, with no error, no warning, and nothing broken on the page.

What the tag actually does

A canonical is a single link element in the head of your HTML:

<link rel="canonical" href="https://example.com/blue-widgets" />

It answers one question. If several URLs serve the same or nearly the same content, which one should the search engine treat as the real one? The URL you name gets indexed and gets the ranking signals. The page carrying the tag does not.

This is a hint rather than an instruction. Google can and does overrule it, usually when the two pages are not similar enough for the claim to make sense. But when it is honoured, it is decisive, and honouring it is the normal case.

The tag has no idea whether the URL you gave it is the one you meant. There is no validation step. A canonical pointing at a page that does not exist, at a staging server, or at a competitor is syntactically identical to a correct one. Your HTML validates. Your page loads. Your rankings go somewhere else.

Cross-domain canonicals are a real feature

Pointing a canonical at another domain is supported behaviour, and often the right call.

The standard case is syndication. You publish an article, a partner republishes it, and the partner's copy carries a canonical pointing back to yours. Both copies stay live, readers on the partner site read it there, and the search visibility stays with you. Press release distribution, content partnerships and aggregators all work this way.

The doge.gov case used that same mechanism, aimed in the direction that gives visibility away rather than keeping it. Same tag, same syntax, opposite result. Everything depends on which end of the arrangement you are on.

Five ways it goes wrong by accident

Almost nobody sets a bad canonical on purpose. These are the usual causes.

A hardcoded value in the template. Someone adds a canonical to the shared layout, uses one absolute URL, and every page on the site now declares the homepage as its canonical. Over the following weeks the index shrinks to that single URL. This is the most destructive version, and it is also the easiest one to write.

A staging host left in the tag. The canonical was generated from an environment variable that never got switched, so the live site announces that its pages really live on staging.example.com. The staging site is usually noindexed or password protected, which means the canonical points at something the crawler cannot even reach.

Markup copied along with the content. You lift a template, a component or an article from somewhere else and the canonical comes with it. Your page now points at theirs.

A canonical aimed at a near-duplicate. You have /professional-headshots and /corporate-headshots, they overlap, and at some point one was canonicalised to the other. Later you wonder why the page you optimised is not the page appearing in results. Threads asking why the wrong page ranks turn up on SEO forums constantly, and a canonical pointing sideways is a common cause.

A canonical and a redirect that disagree. The page canonicalises to URL A while the server redirects visitors to URL B. Now you have given the crawler two contradictory answers about the same content, and neither of them is the one you would give if someone asked you directly.

That last one is worth tracing rather than guessing at. Paste the URL into the Redirect Detector and it walks the chain one hop at a time, showing each hop's URL and the HTTP status code the server returned, up to ten hops, and the final destination it lands on. If the address at the end of that chain is not the address in your canonical tag, you have found the disagreement. It will also tell you when a redirect loops back on itself.

Read the raw source, not the rendered DOM

The check that matters takes ten seconds, and there is one trap in it.

View the page source, not the browser inspector. The inspector shows you the DOM after JavaScript has run, which is not necessarily what arrived in the response. Use view-source: in the address bar, or curl -s https://example.com/page | grep canonical from a terminal, and look at what the server actually sent. A canonical injected by client-side JavaScript may or may not be picked up, and a canonical you can see in the inspector but not in the source is a different problem from a canonical with the wrong value in it.

Three things to confirm while you are in there.

There is exactly one. Two canonical tags on a page is a real and common bug, usually caused by a plugin and a theme both adding one. When they conflict, the search engine either picks one or ignores both, and you do not get to choose which.

The URL is absolute and correct, character for character. Protocol, host, trailing slash. http where the site serves https sends the crawler to a URL that redirects, which weakens the whole signal.

It points at itself. This is the default every page should hold to. A page's canonical should be its own URL unless you can name the specific reason it should not be, out loud, in a sentence. Paginated series, filtered variants of a listing, and syndicated copies all have such reasons. A regular article does not.

That last check is the one worth building into your habits, because it is the one that catches the template bug, the staging bug and the copied-markup bug in a single pass. Open three pages from different sections of the site, view the source on each, and read the canonical. If all three name the same URL, you already know what is wrong.

If your tags survive all three checks and Search Console still reports a canonical problem, you are looking at a different failure: Google saw your tag and overruled it, or never saw it at all. That one is covered in duplicate without user-selected canonical.