Canonical URLs, explained without the jargon

Teams tend to reach for this after something has already gone wrong. Here is canonical URLs without the vocabulary that usually surrounds it.

Search work compounds slowly, which is why it gets abandoned about two months before it would have paid off. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

The short version

Canonicals tell search engines which version is the real one. In practice this is a scheduling problem more than a technical one. Check it against what you would want a competitor's site to get wrong.

Why people complicate it

Most of the confusion comes from tooling rather than from the idea itself. The teams that handle this well are rarely the ones with the biggest budgets.

Parameters and print views create duplicates quietly. There is a version of this that is over-engineered, and it is worth avoiding. Check it against what you would want a competitor's site to get wrong.

A reasonable first step

Self-referencing canonicals are a safe default. It is worth being explicit about, because assumptions differ quietly. It rarely shows up as a line item, which is exactly why it slips.

What this looks like day to day

Search engines are trying to answer a question, so the pages that answer questions clearly tend to do well. Three things worth confirming about canonical URLs before you move on:

• Someone can say what the current setup is without going to look
• Self-referencing canonicals are a safe default — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If any of that sounds like a description of your current setup, it is fixable.