og:url, canonical, and consolidating shares

og:url tells social platforms which address a page really lives at; rel="canonical" tells search engines the same thing. They’re read by different systems for different purposes, and they should both point at the same clean URL. When they do, shares of variant URLs consolidate against one address instead of scattering.

Neither is glamorous, and disagreement between them causes odd, hard-to-attribute problems.

What each one does

<link rel="canonical" href="https://example.com/page/">
<meta property="og:url" content="https://example.com/page/">

rel="canonical" is a hint to search engines that this page is the preferred version among possible duplicates. It affects which URL gets indexed and which accumulates ranking signals.

og:url is the address platforms treat as the identity of the shared object. Where a platform keeps per-URL counts or comments, og:url is the key those attach to. It’s also often the address the platform links to, meaning a wrong value sends people somewhere unintended.

Same information, two audiences. Set both.

Why fragmentation happens

One page is reachable at many addresses without anyone intending it:

• https://example.com/page/ and https://example.com/page — trailing slash.
• https://www.example.com/page/ — the www variant.
• http:// — if the old scheme still resolves.
• ?utm_source=newsletter and four other tagged variants.
• ?ref=partner, ?fbclid=…, and other parameters added by other systems.
• Uppercase or differently ordered parameters.

Each is a distinct string. Without a declared canonical address, a platform may count each separately, and a page shared a hundred times reads as six pages shared modestly.

Setting og:url to one clean address collapses them.

Rules for the value

Absolute, with scheme and host. A relative path is invalid here.

HTTPS. Never point either tag at an http:// version.

One host. Pick www or bare, and use it everywhere — tags, sitemap, internal links, redirects.

Consistent trailing slash. Match whatever your site actually serves. If /page/ is the real address and /page redirects, use /page/.

No tracking parameters. This is the point of the exercise.

Self-referencing. On an ordinary page, both tags name that page’s own address. They’re only different from the page’s URL in specific cases below.

Unique per page. The most damaging mistake here is a template that hard-codes the homepage address into every page’s og:url, which makes every share of every article look like a share of your homepage. Worth checking on any site you didn’t build.

When they legitimately differ from the current URL

Syndicated content. An article republished on another site sets rel="canonical" to the original. Whether og:url should also point at the original depends on intent: pointing there consolidates engagement on the original, keeping it local means the copy accumulates its own. Choose deliberately — usually the original, since that’s what the canonical is saying too.

Paginated series. Each page in a sequence is its own canonical; don’t canonical page two to page one, because they have different content.

Filtered or sorted views of the same list. Canonical to the unfiltered version, since the alternatives aren’t separately useful.

Print or AMP-style variants. Canonical to the main version.

Outside those, self-referencing is correct.

Failure modes worth checking for

og:url disagreeing with rel=canonical. Two systems told two different things about the same page. Usually a symptom of one being template-generated and the other hand-set.

A canonical pointing at a redirect. The declared canonical URL should return 200, not bounce. A canonical chain is a signal the crawler has to resolve, and sometimes doesn’t resolve the way you meant.

A canonical pointing at a 404. Happens after a URL restructure where the tag wasn’t updated. This is worse than having no tag.

Mixed hosts. Half the site canonicals to www, half to bare. Common on sites migrated between the two.

Tracking parameters in the tag. Means a tagged URL was crawled and the tag was built from the request URL rather than from the page’s known address. Build these values from your site’s route data, not from the incoming request.

Checking

For any page:

curl -s https://example.com/page/ | grep -i 'canonical\|og:url'

Both should appear, once each, with identical values, absolute and HTTPS.

Then confirm that value resolves directly:

curl -sI https://example.com/page/ | head -1

200, not 301.

Two commands, and they catch most of what goes wrong here.

Redirects do the other half

Tags declare the preferred address; redirects make the alternatives lead there. Both are needed.

Standing rules worth having in place once: http → https, one host → the other, and a consistent trailing-slash policy. With those and correct tags, variant URLs both redirect and declare correctly, and shares consolidate whichever route someone took.