Guide

og:url vs canonical URL mismatches

Q: What is the difference between og:url and the canonical link?

og:url tells social crawlers the preferred Open Graph object URL for the share. link rel=canonical tells search engines the preferred HTML document URL. They should resolve to the same stable permalink so Facebook, X, LinkedIn, Slack, Discord, WhatsApp, and iMessage treat one page as one card.

Q: What are the most common og:url vs canonical mismatches?

Trailing slash vs no slash, http vs https, www vs apex, tracking or session query strings on one tag but not the other, and pointing og:url at a homepage or alternate language while canonical names the article. Any of these can split cache keys or attach the wrong preview.

Q: How do scrapers pick the page identity?

Most social crawlers prefer og:url when present, otherwise the final fetched URL after redirects. Search engines lean on rel=canonical. When the two disagree, you can get a correct Google result and a wrong or stale social card — or two caches for what users think is one page.

Q: How do I fix and verify og:url and canonical?

Set both to the same absolute https permalink you want people to share. Drop tracking params from both. Match trailing slash and host (www or apex) to your redirects. Then paste the URL into CardScope and confirm og:url matches the canonical you intended before you rescrape platform caches.

og:url and <link rel="canonical"> both name “the” URL for a page — but for different audiences. Social scrapers lean on og:url; search engines lean on the canonical. When they disagree (trailing slash, http/https, www, query strings, or the wrong page entirely), Facebook, X, LinkedIn, Slack, Discord, WhatsApp, and iMessage can cache the wrong identity, show a stale card, or attach a preview to a URL nobody shares. Keep them on the same absolute https:// permalink.

CardScope fetches the URL from the edge and rebuilds diagnostic shells from the tags it finds. It is not a pixel-perfect Facebook, X, or Discord UI. Use CardScope to confirm live og:url matches the canonical you intended; use each platform’s debugger or a fresh share when you need to refresh a cache.

Why they must agree

og:url — preferred Open Graph object URL. Many crawlers use it as the cache key / identity for the share, not only the URL the user pasted.
rel="canonical" — preferred HTML document for search and duplicate consolidation.
Same string, same redirects — if one says https://example.com/post and the other https://www.example.com/post/, you effectively have two identities. Scrapers and Google can pick differently.
Share what you canonicalize — the URL in the address bar after redirects should match both tags.

Common mismatches

Mismatch	Example	Why it hurts
Trailing slash	`.../post` vs `.../post/`	Two cache keys; some CDNs treat them as different objects
Scheme	`http://` vs `https://`	Mixed content / redirect loops; scrapers may keep the insecure identity
Host	`www.` vs apex	Cards and search split across hosts even if both redirect
Query strings	`?utm_source=…` on one tag only	Tracking params create unique “pages”; previews attach to the wrong variant
Wrong page	`og:url` = homepage, canonical = article	Share shows the wrong title/image or steals the site’s home card
Locale / AMP twin	Article vs `/amp/` or `/en/` twin	Unless intentional, pick one permalink and point both tags there

After you align the tags, live HTML can be correct while a client still shows an old card. Use the clear Open Graph cache workflow: fix → verify → rescrape where a tool exists. Pair identity fixes with a solid absolute image — see absolute vs relative OG image URL — and sane title/description lengths in the OG title & description guide.

How scrapers pick identity

Social / chat crawlers — typically prefer og:url when present; otherwise the final URL after redirects. That value often keys the cache.
Search engines — prefer rel="canonical" (and redirects / sitemaps). A correct Google result does not guarantee a correct Slack or Facebook card.
Disagreement — you can rank for URL A while Meta caches URL B. Align both before you rescrape.

A minimal set

If you only set identity tags once for every network, set these to the same absolute permalink:

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

Prefer https://, drop tracking query strings from both, and match your permanent redirect target (trailing slash and www policy included). Same foundation as the Facebook, LinkedIn vs X, Slack vs Discord, WhatsApp / Telegram, and iMessage guides — one permalink, then client-specific tools where they exist.

Checklist before you ship

Pick one absolute https:// permalink — the URL you want people to paste and bookmark.
Set og:url and rel="canonical" to that exact string (same host, path, trailing-slash policy).
Strip tracking / session query params from both tags; keep them out of the share URL when you can.
Confirm redirects — http→https and www↔apex should land on the same URL both tags name.
Do not point og:url at a different page (home, category, AMP twin) unless that is intentional.
Verify with CardScope, then rescrape platform caches if an old identity is stuck.

FAQ

What is the difference between `og:url` and the canonical link?

og:url tells social crawlers the preferred Open Graph object URL for the share. <link rel="canonical"> tells search engines the preferred HTML document URL. They should resolve to the same stable permalink so Facebook, X, LinkedIn, Slack, Discord, WhatsApp, and iMessage treat one page as one card.

What are the most common `og:url` vs canonical mismatches?

Trailing slash vs no slash, http vs https, www vs apex, tracking or session query strings on one tag but not the other, and pointing og:url at a homepage or alternate language while canonical names the article. Any of these can split cache keys or attach the wrong preview.

How do scrapers pick the page identity?

Most social crawlers prefer og:url when present, otherwise the final fetched URL after redirects. Search engines lean on rel="canonical". When the two disagree, you can get a correct Google result and a wrong or stale social card — or two caches for what users think is one page.

How do I fix and verify `og:url` and canonical?

Set both to the same absolute https permalink you want people to share. Drop tracking params from both. Match trailing slash and host (www or apex) to your redirects. Then paste the URL into CardScope and confirm og:url matches the canonical you intended before you rescrape — see clear Open Graph cache.

Is CardScope free?

Three free checks per day per IP, no account. Pro is $19 once for unlimited checks. We parse HTML in memory and discard it — rate limits store a hash of your IP for 48 hours, not the page.

Check a URL on CardScope

Paste the permalink. You get reconstructed shells for the clients CardScope supports, the tag table, and a fix checklist — so you know live og:url matches your canonical before you fight a platform cache. Three free checks per day per IP, no account. Pro is $19 once if you want unlimited checks. We parse HTML in memory and discard it — rate limits store a hash of your IP for 48 hours, not the page.

Try a URL