Open Graph Tags and Social Preview Caching: Why the Old Card Won't Go Away
You fix the title on a page, change its preview image, share the link on LinkedIn, and the old version shows up anyway. Or the link shows no image at all, even though you can see the tag in the page source. Almost every broken social preview comes down to one of three things: a missing or malformed tag, an image the platform can't fetch, or a stale cached copy. This guide covers how Open Graph tags work, how each platform reads them, and how to force a refresh when the cache is the problem.
What happens when you paste a link
When you paste a URL into Facebook, LinkedIn, X, Slack, WhatsApp or Discord, the platform's server fetches that URL with its own crawler. Facebook's identifies itself as facebookexternalhit, X uses Twitterbot, LinkedIn uses LinkedInBot. The crawler reads the HTML, looks for specific meta tags in the head, downloads the image those tags point to, and builds the card. Then it stores the result so it doesn't have to repeat the work next time someone shares the same link.
Two details in that process cause most failures. First, these crawlers generally read the HTML your server sends and don't run your JavaScript. If your tags are added client-side by a single-page app, the crawler often never sees them. Second, the result is cached, so fixing your tags doesn't fix existing previews until the platform fetches the page again.
The tags that matter
Open Graph was published by Facebook in 2010 and is now read by almost every platform. The protocol lists four required properties, plus a few optional ones that are worth adding anyway:
<meta property="og:title" content="PPF vs FD: Which Earns More After Tax?" />
<meta property="og:type" content="article" />
<meta property="og:url" content="https://example.com/guides/ppf-vs-fd" />
<meta property="og:image" content="https://example.com/og/ppf-vs-fd.png" />
<meta property="og:description" content="Side-by-side 15-year comparison with tax." />
<meta property="og:site_name" content="Example" />
<meta name="twitter:card" content="summary_large_image" />og:titleis the headline on the card. It doesn't have to match the page's HTML title tag. Platforms cut long titles at different points, so put the words that matter first.og:imagemust be an absolute URL, starting withhttps://. A relative path like/og.pngis one of the most common reasons previews show no image.og:urlis the canonical address for the page. Platforms may use it to group shares of different URL variants into one card and one cache entry.og:typeis usuallywebsitefor a home page andarticlefor posts and guides.twitter:cardtells X which layout to use.summary_large_imagegives a wide image;summarygives a small square thumbnail. If X can't find twitter-specific title, description or image tags, it falls back to the og ones, so you rarely need to duplicate them.
Note the attribute names. Open Graph tags use property=, while X's tags use name=. Most parsers are forgiving, but sticking to the documented form avoids surprises.
Getting the image right
The size most platforms recommend is 1200 × 630 pixels. That's an aspect ratio of about 1.91:1. The trouble is that each platform crops and scales differently. Here's what happens to a 1200 × 630 image in a few common layouts:
| Display | Shape | What's cut from 1200 × 630 |
|---|---|---|
| Wide card at 1.91:1 | 1200 × 630 | Nothing |
| Wide card at 2:1 | 1200 × 600 | 15 px from top and bottom |
| Square thumbnail | 630 × 630 | 285 px from each side |
The square case is the important one. If your image has a headline running edge to edge, a square crop removes almost half of it. Keep text and logos in the middle 630 × 630 area and the image survives every layout.
File size matters too. At 1200 × 630 there are 756,000 pixels. A JPEG at about 1 bit per pixel comes out near 95 KB, which every platform fetches happily. A PNG of a photo-style background at the same size can easily pass 1 MB, and some apps, particularly messaging apps on slow connections, are less reliable with heavy images. Use JPEG or WebP for photographic images and PNG only for flat graphics.
Why the old preview won't go away
Every platform caches what it fetched. How long varies and isn't always documented. The cache is usually keyed by URL, and the image may be cached separately, keyed by the image's own URL. That leads to a few distinct problems:
- You changed the title, but the old one shows. The page itself is cached. You need the platform to fetch it again.
- You replaced the image file but kept the same filename. The platform may re-read your tags, see the same image URL, and reuse its cached copy of the old image. Change the filename or add a version, like
og.png?v=2. - It worked on one platform but not another. Each one has its own crawler and cache. Fixing Facebook's doesn't touch LinkedIn's.
Forcing a refresh, platform by platform
- For Facebook (and usually WhatsApp and Messenger with it), open Meta's Sharing Debugger, paste the URL, and click "Scrape Again". The debugger also lists warnings, such as a missing og:image or one that's too small.
- For LinkedIn, paste the URL into LinkedIn's Post Inspector. Inspecting the URL triggers a fresh fetch.
- X no longer has a public validator that shows a preview. Composing a new post with the link, or adding a harmless query string, usually gets a fresh fetch. Previews already posted won't change.
- Slack, Discord, Telegram and most other apps don't offer a manual refresh. A new query string on the shared URL creates a new cache entry.
The query-string trick has a catch
Sharing example.com/page?v=2 makes a new cache entry, but if your og:url tag still points to example.com/page, some platforms will resolve back to the canonical URL and its old cache. Refresh the canonical URL through the debugger where one exists, and use query strings only as a fallback.
A debugging order that works
- Run the page through the Open Graph Previewer. It fetches the live HTML from our server and lists og:title, og:description, og:image, og:type and the twitter tags it found. If a tag is missing here, it's missing for the platforms too.
- Open the og:image URL directly in a private browser window. If it redirects to a login page, returns an error, or loads very slowly, crawlers will have the same trouble.
- Check robots.txt. A
Disallowthat blocksfacebookexternalhit,TwitterbotorLinkedInBot, or a blanket block on unknown bots, stops previews entirely. The Robots.txt Validator will test a URL against a specific user agent. - Check the image dimensions and file size, and keep important content in the centre square.
- Only after all that, use each platform's debugger to clear its cache.
Framework notes
In Next.js, the metadata export or generateMetadata renders these tags into the server HTML, so crawlers see them without running JavaScript. Set metadataBase in your root layout so relative image paths are turned into absolute URLs automatically. In a client-only React or Vue app, you'll need prerendering or server-side rendering for the pages you want to share; otherwise crawlers usually get an empty head.
Limitations of the previewer
- It shows what your page says now, not what a platform has cached. If the previewer looks right and Facebook still shows the old card, the problem is Facebook's cache.
- The card designs are approximations. The tool draws X, Facebook and LinkedIn style cards. The real apps change their layouts, fonts and cropping without notice.
- Some pages can't be fetched. Pages behind a login, a bot challenge or a firewall that blocks unknown crawlers will fail. The fetch also times out after 10 seconds.
- Our crawler isn't their crawler. The previewer identifies itself with its own user agent. A server that treats Facebook's or X's crawler differently, for example by serving them a different page, can produce results the previewer can't reproduce.
Check your tags before you share
Preview how a URL will look on X, Facebook and LinkedIn, and see exactly which Open Graph and Twitter tags were found.