You share a blog post to LinkedIn and the card that comes back is your homepage. Not the post. The homepage, with the generic tagline and the hero image your designer picked eighteen months ago. You open the page source expecting to find a missing tag, and everything is there: the right title, the right description, an og:image pointing at the right file.
Every tag was correct except one, and the one that was wrong quietly outranked all the others.
og:url Is an ID, Not a Link
The Open Graph protocol lists four required properties, and og:url is the one people treat as decorative. The spec defines it as "the canonical URL of your object that will be used as its permanent ID in the graph." Read that phrase again, because the important word is ID.
Nothing clicks og:url. It is never displayed. No user encounters it. Its entire job is to answer a question the crawler asks itself after it has finished reading your page: what is this thing I just fetched? The crawler pulls the URL you shared, parses the tags, and then files the result under the value of og:url rather than under the address it actually requested. Every behavior downstream hangs off that filing decision. Which card gets stored, which cache entry gets hit next time, which page the share counts land on.
That is why a page can have flawless metadata and still produce someone else's preview. The tags describe the content correctly. The identity says the content is something else.
Why Every Page on Your Site Might Be Serving the Homepage Card
Meta documents the consolidation rule directly on its canonical URL page: "All links that specify the same canonical URL are treated as the same resource by Facebook's link sharing infrastructure for the purpose of metrics and metadata (link image, title, etc.)."
When you do that on purpose it is genuinely useful. The www and non-www versions of a page, the variant with a tracking string on the end, the AMP copy, the print view: point them all at one og:url and they behave as a single object with one preview and one pooled share count. When it happens by accident, an entire site collapses into one card.
The accident is almost always inheritance. A theme, a plugin, or a framework layout declares og:url once at the site level, every route inherits it because no route bothered to override it, and now a thousand pages all claim to be the homepage. The symptom is distinctive: the preview isn't broken, it's just consistently the wrong page, and it's the same wrong page every time.
We shipped a version of this bug on this site. Prelinq's root layout declared a site-wide Open Graph block, Next.js merges metadata down the route tree, and any route that didn't set its own value inherited the homepage's identity. The same inheritance trap caught our rel=canonical too, which was the more expensive half: twelve blog posts spent weeks telling Google they were duplicates of the homepage. Both fixes were one explicit line per route. Neither bug produced a single error message.
og:url and rel=canonical Are Not the Same Tag
They make the same claim to different audiences. Google reads rel=canonical to decide which URL to index. Social crawlers read og:url to decide which object to file the card under. Setting one does nothing for the other, and site audit tools flag the mismatch as its own class of finding for good reason.
In practice they should almost always carry the same value, and the common failure is an SEO plugin that manages rel=canonical properly while og:url stays hardcoded in a template nobody has opened since launch. If you fix one after reading this, check the other in the same sitting.
Strip the Session IDs and Tracking Parameters
Meta's webmaster documentation is specific about what belongs in the value: "the undecorated URL, without session variables, user identifying parameters, or counters."
Ignore that and the identity stops being stable. If og:url carries whatever UTM string the visitor happened to arrive with, every share mints a fresh object, the cache never warms up, and the share count on the page that actually matters stays near zero while hundreds of near-identical entries each hold two or three. The same mechanism explains why an http-to-https migration can appear to wipe years of engagement overnight. New value, new identity, and the old counts stay attached to the old one.
It Also Defeats the Cache-Busting Trick
The standard workaround for a stale preview is to append something meaningless to the URL and reshare, so the platform sees an address it has never crawled. On a page with no og:url that works fine. On a well-built page it doesn't: the crawler fetches your new address, reads og:url, looks up that value, finds the copy it already has, and serves you the stale card you were trying to escape.
The better the tags, the less reliable the hack. We covered what each platform caches and which purge buttons still exist separately, because the answer varies more than most guides admit.
Where og:url Stops Mattering
All of the above assumes something will come back and read your page again later. On a few surfaces, nothing ever will.
WhatsApp on mobile builds the card on the sending device and attaches it to the message, so the preview travels with the message rather than living in a central store keyed on anything. There is no object to consolidate, no cache to hit, and no correction coming, which is why a bad WhatsApp preview is permanent. og:url still shapes the one fetch that happens at compose time, but the identity mechanics that govern Facebook and LinkedIn simply don't apply. If you are debugging a chat app, this tag is not your problem.
How to Check It Without Guessing
Load two different pages from the same site and compare, because the inheritance bug is invisible if you only ever test one URL. On each one, confirm that og:url:
- Exists at all, and sits inside <head> with the other tags.
- Is absolute and https, not a path like /blog/my-post.
- Points at the page you are on, or deliberately at the canonical variant of it.
- Matches that page's rel=canonical.
- Carries no session ID, UTM string, or counter.
- Differs from the value on the other page you loaded.
That last check is the one that catches the expensive bug. Prelinq's Open Graph checker fetches the page live on every request and holds no cache of its own, so it shows the value a crawler would receive right now rather than one saved earlier. Run it twice, on two URLs, and read the og:url line on both.
Then comes the part no checker helps with. If the page belongs to someone else, an affiliate offer, a client site, a news article, a partner's landing page, you can identify the exact wrong value and have no way whatsoever to change it. That is a different problem wearing the same clothes, and it describes most of the links people actually share.
Prelinq works by moving the identity onto a page you control. Each link you build gets its own slug and its own og:url, declared explicitly rather than inherited, so it arrives at every platform as a distinct object carrying the title, description, and image you chose, and forwards whoever clicks to the original destination. No shared identity with your homepage, no collision with a page you've never seen, and no stale copy filed under a value you can't reach.
Be clear about the limit. Owning og:url doesn't reach into a post that already rendered a card; that copy stays until the platform re-reads on its own, which on LinkedIn can take up to seven days. What it changes is everything after: because the page is yours, you can edit the tags whenever you like, and every new share picks up the new version. Two active links are free, so you can build a card, check what identity it declares, and see it rendered across X, LinkedIn, Discord, and Facebook before it leaves your hands.