og:url gives your page a fixed identity. It names the canonical URL that platforms use as the page's permanent ID, and it is one of only four properties the Open Graph protocol marks as required. We wanted to know how well the web actually sets it, so we fetched 45 well-known URLs, parsed the raw server HTML, and compared every og:url against the URL that served that page. The failure rate is the surprise. Twenty-nine of the 40 readable pages declared one, and every one of those 29 was absolute and matched the host that served it. What went wrong, when it went wrong, was absence rather than malformed values: 11 pages shipped no og:url at all, and five of those publish a canonical link they could have copied.
So the useful question is not "how do I format og:url". It is "when does a missing or stale one cost me something". That depends on what each platform does with it, which is narrower than the folklore suggests.
og:url Is an Identity, Not a Redirect
The spec line is blunt: the canonical URL of your object that will be used as its permanent ID in the graph. Meta's own webmaster guide adds the operational half — it should be the undecorated URL, with no session variables, user-identifying parameters, or counters, because likes and shares aggregate at that URL. It names the one case that trips people up in practice: if you run a mobile domain, point its og:url at the desktop version so engagement lands in a single bucket.
What og:url does not do is move a visitor. It is metadata, not a redirect. Paste a link into a chat app and the client still fetches the URL you pasted; a mismatched og:url does not teleport the crawler somewhere else. What it changes is which object your page is filed under. Two URLs that serve identical content but declare different og:url values are two IDs to the graph, and their engagement splits. That is the entire cost model. If you never share two variants of the same page, an odd og:url mostly goes unnoticed.
Real talk: the forums are full of "add og:url and your preview comes back" advice. In our sample every page that had a working preview also had a correct og:url, and plenty of broken-preview cases come from client-side rendering, WAF blocks, or an oversized og:image. og:url is a tidy-up tag, not a repair tool. Fixing it will not resurrect a card whose image is a 404.
What 40 Live Pages Actually Ship
Method: plain GET with a desktop Safari user agent, nothing executed, meta and link tags parsed from the server HTML, then normalized comparison between og:url, the final URL after redirects, and every rel=canonical. Forty pages answered; five returned 403 to the fetcher and were dropped — nytimes.com, medium.com, reddit.com, stackoverflow.com, theatlantic.com.
| Check | Result | What it means |
|---|---|---|
| Pages with og:url | 29 of 40 (72%) | The minority case is the interesting one |
| og:url is absolute | 29 of 29 | Nobody shipped a relative value here |
| og:url is https | 29 of 29 | Zero insecure values, unlike in og:image samples |
| Byte-identical to the URL that served it | 26 of 29 | Three differ only by a trailing slash |
| Matches rel=canonical where both exist | 25 of 25 | 23 of those were byte-identical |
| Points at a different host | 0 of 29 | Cross-domain drift was not a theme |
| Ships a canonical but no og:url | 5 pages | Half the gap is a one-line fix |
| Ships og:site_name | 21 of 40 | Worse coverage than og:description managed |
Read that table again, because the shape of it is the whole story. The values people agonize over — absolute, https, matching the canonical — were clean in every single case where the tag existed. The problem is coverage. Eleven pages left a required property out, and that is a bigger practical failure rate than anything we measured in the og:title, og:type, or og:description families.
The eleven holdouts are not obscure: nextjs.org/docs, overreacted.io, joshwcomeau.com, tailwindcss.com, linear.app, news.ycombinator.com, wikipedia.org, anthropic.com, spotify.com, booking.com and theguardian.com/international. Five of them publish a proper rel=canonical and simply never mirror it into og:url. That pattern is worth naming: documentation sites, app marketing pages and developer blogs in our sample tend to emit Open Graph on article routes only, so the marketing root never gets a full tag set. Your homepage is usually the URL you paste into the most chats.
Three Failure Modes, Ranked by What They Cost
1. The tag is absent. Eleven of 40 pages, five of them with a canonical sitting right there. Nothing breaks visibly; you just have no declared identity, and every platform falls back to the URL it was handed. If you are also running multiple domains or a staging host, that fallback is exactly the ambiguity og:url exists to prevent.
2. The domain moved and the tag followed — or did not. Three pages in the sample were served from a host different from the one we requested: notion.so now answers as notion.com, railway.app as railway.com, and spotify.com redirects to open.spotify.com. Notion and Railway updated both og:url and canonical to the new domain, which is the correct end state. Spotify ships no og:url at all, while its canonical already points at open.spotify.com — a tidy migration that forgot one line. If you rebrand, grep for the old host in your metadata layer separately from your redirect rules; a redirect handles traffic, and only the tags handle identity.
3. Trailing slash drift. railway.app, resend.com and digitalocean.com all declare an og:url that differs from the served URL by exactly one slash. No parser we know of punishes this, and our normalization treated all three as matches. It matters for a different reason: if you build a health check that asserts og:url === canonical === current URL as strings, you will get false alarms on pages that are perfectly fine. Normalize before you compare, or you will spend an afternoon chasing slashes.
One footnote from the same run that belongs here: of the 40 pages, three declared twitter:url, and Notion's value was literally a single slash. A relative value like that gets into production the moment a template variable resolves empty. If your og:url is templated, assert that it starts with https:// before the page ships — the whole 29-for-29 absolute record in this sample came from pages that build the tag from a real base URL.
og:site_name Is the Actual Neglected Tag
Nineteen of the 40 pages shipped no og:site_name. That is 47 percent missing on a property that platform previews use to label which site a link came from, and it is the same story Apple tells publishers in its own Messages technote: keep the site name out of og:title, put it in og:site_name instead.
The sample shows how half-followed that advice is. Of the 20 pages carrying both tags, 19 repeat the brand inside og:title — "Figma: The collaborative canvas for design, code, and AI", "Railway | The all-in-one intelligent cloud provider", "TechCrunch | Startup and Technology News". So the pages that remembered og:site_name are mostly the pages that also violate the rule it exists to serve. Where the tag does appear it stays short, from NPR at three characters to Smashing Magazine at seventeen; no length problem to solve, just coverage.
Fix both lines at once and the preview reads correctly in either direction: a clean, specific og:title, and the brand carried by og:site_name for the platforms that render it as a separate label.
og:url Checklist
- Ship the tag at all. Eleven of 40 live pages did not, and five of them already had a canonical to copy. Homepages, docs indexes and marketing roots are the usual gaps.
- Make it absolute, and keep it https. Zero relative and zero http:// values appeared in 29 pages, so the bar is low and the fix is trivial.
- Make it identical to the canonical. Twenty-five of 25 pages that had both agreed on the same URL after normalization. Two sources of truth for one page is how drift starts.
- Strip the decorations. Meta's guide asks for the undecorated URL: no session IDs, no tracking parameters, no counters. Engagement aggregates at whatever that string is.
- Point mobile and alternate hosts at one version. Pick the desktop URL and send the other host's tag there, so shares do not split across two IDs.
- Re-check the tag after a rebrand. Notion and Railway carried their new domain into og:url; Spotify's canonical moved and its og:url stayed missing. Redirect rules do not update metadata.
- Pair it with og:site_name. Nineteen of 40 pages had none, and 19 of the 20 pages that did still duplicated the brand in og:title. Two lines, one clean preview.
One Line
og:url is the least-broken Open Graph tag on the live web — 29 of 29 well-formed where it exists — and still missing from 11 of the 40 pages we fetched, five of which had a canonical ready to copy. The formatting advice you will find everywhere is not your problem. Coverage is, and og:site_name is the tag getting skipped twice as often as the one you came here for.
Paste a URL into the free OG checker to see the og:url, canonical and site name a scraper reads from your server HTML, then generate the card itself at ogimgen.com. Related reading: the full Open Graph meta tag list covers every property and which ones are required, og:description and og:title walk the same measured treatment for their tags, and og:type explains the fourth required property.