Check your share cards before you post
Last updated:
A share card is the small preview — a title, a description and an image — that a social network or chat app builds when someone pastes a link to your page. For most of the people who ever encounter that page, the card is the only version of it they will see: they meet it mid-scroll, judge it in about a second, and decide whether the page behind it deserves a tap. The uncomfortable part is that card failures are silent. Your page can look perfect in your own browser while its card shows no image, a headline from last month, or a description cut off mid-word, because the card is not built from what you see on screen — it is built from a handful of meta tags in the page head, fetched once by a scraper you never watch. So before you publish anything you intend to share, run the draft URL through the Open Graph Checker and look at your page the way your readers will: as four small cards.
The link is the ad
When a link is pasted into a social feed or a chat thread, no human visits your page first. The platform sends out a scraper — a small, impatient crawler — which fetches the page once and builds the card from the meta tags it finds in the head. Nobody in that chain sees your layout, your typography, your carefully tuned hero section or the screenshot you placed above the fold. They see exactly three fields and a picture: og:title, og:description and og:image. If those three are wrong, missing or stale, then as far as your audience is concerned your page is wrong, missing or stale — the beautiful page behind the card never gets the chance to correct the impression.
The card is also stubborn. Platforms cache the scrape, usually against the exact URL, so the first version a scraper builds is often the version that gets shared onward for weeks or months, long after you have edited the page. That is why a share card deserves the same respect as ad creative: for a post whose whole purpose is to be shared, the link is the ad, and the meta tags are the copy. Writing them as an afterthought — or letting a site generator fill them in from whatever text happens to sit nearby — means running a campaign whose creative nobody reviewed.
What each platform actually reads
Start with the baseline. Facebook and LinkedIn read Open Graph: og:title, og:description, og:image, og:url and og:type, as defined by the Open Graph protocol. If those five are present and sane, the two largest professional sharing surfaces are covered. X reads its own Twitter Card tags first — twitter:card, twitter:title, twitter:description, twitter:image — and falls back to the Open Graph equivalents when the Twitter tags are absent. Slack reads Open Graph first, with Twitter Card tags as its fallback. In other words the platforms agree on the ingredients and disagree, mildly, about which shelf they reach for first.
Everywhere, the last resort is the same: the plain <title> element and the meta description, pressed into service when neither Open Graph nor Twitter tags exist. That fallback matters for how you read any checker, including ours. When a tool shows you a card title, the honest question is where the value came from — a dedicated tag you wrote on purpose, or a fallback rescued from a title element that was written for a search-results page and a character budget your card does not share. A checker that quietly substitutes fallbacks and presents them as tags is lying to you by omission, which is why the Open Graph Checker labels every fallback as a fallback instead of pretending the tag exists.
The failures that make cards look broken
The classic is the relative og:image. The tag says content="/images/share.png" — a path, not a URL — and it works in your browser, because the browser knows which site it is on. A scraper will not resolve it: it wants a complete, absolute URL beginning with https://, and when it does not get one it simply builds a card with no image, which readers scroll past without ever knowing what they missed. Close behind it is the image that exists but does not fit: far smaller than the 1200×630 pixels the platforms recommend, or in a ratio that gets center-cropped into nonsense. Treat 1200×630 as what it is — widely published platform guidance, not a standard anyone ratified — but guidance ignored is still a card with the headline cut out of the picture.
The rest are quieter. A missing twitter:card tag means X falls back to a small summary card — a thumbnail beside the text — even when you supplied a large, beautiful image and expected the full-width summary_large_image treatment. Empty tag values are worse than missing tags: an og:title with content="" does not trigger the fallback, it overrides it with nothing. And a wrong og:url — pointing at the staging domain, the homepage, or last week’s article, as copied templates so often do — tells every platform that the canonical page is somewhere else, splitting shares, counts and cache entries away from the page you actually published.
Why the old card keeps showing after you fix the tags
You fixed the tags, you redeployed, you pasted the link again — and the old title is still there, smiling at you. Nothing is broken. Each platform caches the card it built against your URL, and that cache does not watch your site for changes; from the platform’s point of view, it already knows what your page looks like, and re-fetching every URL on every share would be an enormous amount of crawling for very little benefit. The stale card is not evidence that your fix failed. It is evidence that the cache has not been told to look again — and until it is, every colleague and reader who shares the link re-serves the old scrape.
So tell it. Each major platform offers a way to force a fresh scrape of a single URL: the Facebook Sharing Debugger and the LinkedIn Post Inspector both re-fetch the page and show you the card they rebuilt — X historically offered a card validator for the same job. Run your URL through the relevant one after any tag fix and confirm the new card before announcing the post. Where no re-scrape tool exists, changing the URL changes the cache key: appending a query string such as ?v=2 makes the platform treat the link as one it has never seen, which is a perfectly respectable trick for a one-off share. And keep a little patience in reserve — caches can take a while to let go even after a re-scrape, so check, wait, and check once more before you start editing tags that were already correct.
A two-minute pre-publish routine
Make it a routine, not an investigation. One: paste the draft URL into the Open Graph Checker — the staging or preview URL is fine, as long as it is the page the scrapers will fetch. Two: confirm all four cards — Facebook, X, LinkedIn and Slack — show the title, description and image you intended, and note anything labelled as a fallback, because a fallback you chose is fine and a fallback you stumbled into is a tag waiting to be written. Three: confirm the image URL is absolute and the image itself is at least 1200×630. Four: confirm twitter:card is summary_large_image wherever you want the large format on X, and that og:url names the canonical page you are about to publish.
Five: publish — then paste the link somewhere once yourself, to force the first scrape while you are still watching, and look at the card that comes back. If it is stale or wrong, re-scrape with the platform’s own tool rather than editing in a panic. Two minutes, five steps, and the version of your page that most people will ever see is a version you have actually approved. For the wider pre-publish sweep — TLS, security headers, redirects, the rest of the routine checks a page deserves before it goes out — run the Website Health Check alongside it; the cards are the front door, but they are not the whole house.