Social Preview: Catching Bad-Looking Shares Before They Happen
Learn how to preview exactly how your link will appear on Facebook, LinkedIn, Twitter, Discord and Slack, and how to fix the most common preview problems.
What you will learn in this guide
- How social previews are generated
- Why your preview looks different on each platform
- How to test before publishing
- How to force a cache refresh on Facebook and LinkedIn
- Common preview problems and one-line fixes
1 How previews are generated
When you paste a URL into Facebook, LinkedIn, Twitter, Discord or Slack, each platform fetches your page once, reads the meta tags, and stores a cached preview. Every share after that reuses the cached version until the platform decides to refetch — and none of the platforms publish how long that is, so treat any specific figure you see quoted as folklore rather than fact.
2 Test before publishing
- 1Run the Social Preview toolOpen content-tools.html#social-preview and paste your URL. See exact previews for Facebook, LinkedIn, Twitter, Discord, Slack and iMessage.
- 2Check each platform separatelyEach platform uses slightly different aspect ratios and text lengths. A preview that looks fine on Facebook may be cropped weird on Twitter.
- 3Use platform-specific debuggersFacebook Sharing Debugger, LinkedIn Post Inspector, Twitter Card Validator. Each forces a fresh fetch of your URL and shows what their platform sees.
- 4Clear cache after fixingIf you find a problem, fix it, then re-run each debugger to clear the cache before promoting the URL.
3 Common preview problems
| Problem | Likely cause | Fix |
|---|---|---|
| Tiny logo instead of image | Missing og:image | Add og:image with absolute URL |
| Wrong title | og:title missing; using page | Add explicit og:title |
| Image cropped weirdly | Aspect ratio not 1.91:1 (1200x630) | Resize to 1200x630 |
| Old image still shows after edit | Platform cache (30 days) | Use platform debugger to refresh |
| Image not loading | Relative URL or blocked by referrer policy | Use absolute URL; allow social bot user agents |
4 Force a cache refresh
- 1FacebookOpen developers.facebook.com/tools/debug. Paste URL. Click "Scrape Again". Updated immediately on Facebook.
- 2LinkedInOpen linkedin.com/post-inspector. Paste URL. The fetch refreshes LinkedIn's cache.
- 3TwitterTwitter's validator was deprecated; current workaround is post a tweet with a query parameter (e.g., ?v=2) which forces a fresh fetch.
- 4Discord/SlackThese respect OG tags but cache aggressively. Adding a query parameter usually forces a re-fetch.
5 The cache is the whole problem
Almost every "my OG tags do not work" report is a cache problem, not a tag problem. The tags were fixed. The platform simply is not looking at them.
These platforms fetch your page once, when a link is first shared, and then keep what they found. They do not come back to check. So the moment somebody shares your URL, whatever your page said at that instant becomes the preview everybody else sees — and editing the markup afterwards changes nothing, because the platform has stopped reading your page.
How long does that last? Nobody outside those companies knows. None of them publishes a cache duration, and the specific figures that circulate online are community guesses that change without announcement. The practical consequence is identical whatever the true number is: assume the cache is long, assume you cannot wait it out, and force a refresh.
6 What OG tags do not do
It is worth saying directly, because a great deal of advice implies otherwise: Open Graph tags do not help your Google rankings.
Google does not use og:title or og:description as ranking signals. A page with immaculate OG markup will rank exactly where the same page without it would have ranked. These tags exist to control how your link appears on platforms that are not search engines, and that is the whole of their function.
That is not an argument against them. It is an argument for using them for the right reason. A link shared into a Slack channel or a LinkedIn feed with a clear image and a description written for a human is a link people click. A link showing a cropped logo and the first sentence of your cookie banner is a link people scroll past. The benefit is in the click-through on shares — genuine, measurable, and not a ranking benefit.
The related overclaim to avoid: og:description is not a place for keywords. Nothing reads it except the platform rendering the preview, and the person who sees that preview is deciding whether to click. Write it for them.
7 The image is doing all the work
In a feed or a chat window the image occupies most of the preview's visual footprint, which means it is doing nearly all of the persuading. If you get one tag right, get og:image right.
- 1Absolute URL, over HTTPSA relative path is the single most common cause of a preview with no image at all. The platform is fetching from the outside; it cannot resolve /images/hero.png against a context it does not have.
- 2Check your server is not blocking the fetcherBot-mitigation and hotlink-protection rules routinely refuse unfamiliar user-agents, including the platform crawlers. The debugger will say it could not fetch the image; your access log will confirm why.
- 3Keep content away from the edgesPlatforms crop to different ratios. Text near the left or right edge loses its first or last words somewhere — and you will not see it happen, because it happens on somebody else's phone.
- 4Make any text largePreviews are often rendered far smaller than the source image. Text sized for a desktop screenshot is unreadable by the time it reaches a feed.
- 5Give important pages their own imageA single company logo used site-wide produces a preview that is technically valid and says nothing about the page. If a page is worth sharing, it is worth an image that shows what it is about.
8 Where to spend the effort, and the test that ends the argument
You do not need bespoke tags on every page, and a generic site-wide rollout is a poor use of an afternoon. The pages that actually get shared are a small and predictable set: the homepage, the pricing or main product pages, and the handful of articles people link to.
Do those properly — a real image, a title that reads well out of context, a description written for somebody scrolling a feed. Then set a sensible fallback for everything else so that nothing ever produces a genuinely broken preview.
And set og:url to the canonical URL, which is the detail nobody thinks about. Platforms use it to decide whether two shares refer to the same link, so it is what consolidates share counts. If it reflects whatever tracking-parameter-laden variant the sharer happened to copy, every variant is counted as a different link.
Then run the only test that answers the question: share the link into a private channel or a draft post, and look at what appears. Everything a validator tells you is about your markup. Only the preview tells you about the result — and it is your last chance to catch a bad one before it is cached and shared by everybody.
9 Frequently asked questions
Because the platform cached it. Facebook, LinkedIn, Slack and the rest fetch your page once, when a link is first shared, and then keep what they found — they do not come back to check. Editing your tags afterwards changes nothing about a preview that has already been stored, because the platform is no longer looking at your page. Run the URL through the platform's own debugger to force a re-fetch. This single step accounts for the large majority of 'my OG tags do not work' reports.
Nobody outside those companies knows, and none of them publishes it. The specific durations you will see quoted around the web are community folklore, not documented behaviour, and they change without announcement. The practical consequence is the same whatever the true number is: assume the cache is long, assume you cannot wait it out, and force a refresh with the debugger rather than hoping.
No. Google does not use og:title or og:description as ranking signals, and adding them will not move a page in the results. What they control is how your link appears when somebody shares it — on Facebook, LinkedIn, Slack, Discord, WhatsApp and most messaging apps. That matters commercially because a share with a broken preview gets fewer clicks than a share with a good one. The benefit is real; it is a sharing benefit rather than a ranking one, and it is worth being clear which is which.
The most common cause by far is a relative URL in og:image. The platform is fetching your page from the outside; it cannot resolve /images/hero.png against a context it does not have. Use an absolute URL over HTTPS. The second most common cause is your own server blocking the platform's fetcher — a bot-mitigation rule or a hotlink-protection rule that refuses unfamiliar user-agents. The debugger will usually tell you it could not fetch the image, and your access log will confirm it.
1200 by 630 pixels is the safe default: it matches the roughly 1.91:1 ratio the major platforms expect and degrades gracefully elsewhere. Keep important content away from the edges, because different platforms crop differently and your headline will lose its first or last words on somebody's phone. And make any text in the image large — previews are frequently displayed at a fraction of the source dimensions, so text sized for a desktop screenshot is illegible by the time anybody sees it.
Not strictly. X falls back to Open Graph when the twitter:* equivalents are absent, so correct OG tags will produce a reasonable preview there with no extra work. The reason to add them is control: twitter:card lets you choose between a small thumbnail and a large image card, and the large card is substantially more visible in a feed. If you add them, add all of them — declaring a large image card without supplying twitter:image produces a worse result than saying nothing at all.
Share the link into a private Slack channel or a draft post, and look at what appears. That is the only test that shows you what your visitors will actually see. Everything a validator tells you is about your markup; only the preview tells you about the result — and the gap between the two is where cropped headlines, stock-photo logos and missing images all live. It costs a minute, and it is the last chance to catch a bad preview before it gets cached and shared by everybody.