The frustrating part isn't that it's broken. It's that you fixed it and it still looks wrong.
You updated the image. You changed the title. You reshared the URL on LinkedIn or Facebook and stared at the same old broken card staring back at you. Nothing.
You did nothing wrong. Well — you might have, initially, but by the time you're staring at that cached preview, the original mistake is probably already corrected. The problem is that the platform doesn't know that yet.
Here's the short answer before the longer one: link preview issues almost always come from one of two things. Either your meta tags for SEO and social are missing or malformed — so there was never anything useful for platforms to read — or the tags are correct now but the platform cached an old (bad) version and won't show the update until you force it.
The fix is different depending on which one you're dealing with.
Step 1: Verify your Open Graph tags actually exist
Before you blame caching, make sure the tags are there. View source on your page (Ctrl+U / Cmd+U) and search for og:. If you see nothing — or if you only see a generic site title from a layout template — the problem is upstream of caching. No amount of cache-busting will fix tags that don't exist.
The four that matter most:
<meta property="og:title" content="Your Page Title">
<meta property="og:description" content="A description for the preview card.">
<meta property="og:image" content="https://yourdomain.com/images/your-image.jpg">
<meta property="og:type" content="website">
Two things catch people out here almost every time.
The og:image must be an absolute URL. Not /images/your-image.jpg. Not ./images/your-image.jpg. The full https://yourdomain.com/images/your-image.jpg.
Crawlers fetching your tags don't have the context of your domain — they're reading raw HTML and need the full address. A relative path will silently fail on every platform.
The image dimensions matter. The baseline that works everywhere is 1200×630 pixels at a 1.91:1 ratio. Too small and some platforms won't render it. Wrong ratio and it gets cropped awkwardly.
The full breakdown — including file size limits and the safe zone nobody warns you about — is in the og:image size guide.
If you're on Next.js, the cleanest way to handle all of this is through the App Router's Metadata API — it generates your tags from a typed object and makes the duplicate-tag problem structurally impossible. Full walkthrough: meta tags in Next.js.
The fastest way to see exactly what every platform is reading right now: paste your URL into the Meta Tag Auditor. It fetches your actual tags, flags missing or broken ones, and renders the real preview card — so you're not guessing based on view-source.
Step 2: Rule out a site or CDN cache serving a stale page
Before you blame the platforms, check that your own server is actually serving the updated page. If you're behind a CDN or have page caching enabled (common with Cloudflare, Vercel, or any WordPress caching plugin), the HTML being served to platform crawlers might still be the old version — with the old tags.
Fetch your URL with curl and check the tags directly:
curl -s https://yourdomain.com/your-page | grep -i 'og:'
If the output shows the old tags, the problem is your cache, not the platform's. Purge your CDN or page cache first, then re-run the diagnostic.
Step 3: Force a refresh with the platform debuggers
This is the one most people skip straight to — which is why they spend 45 minutes hitting "scrape again" on a page that still has broken tags on the origin server. Do steps 1 and 2 first.
Once you've confirmed your tags are correct on the live page, use the platform's official tools to force a re-scrape:
LinkedIn: LinkedIn Post Inspector — paste your URL, hit "Inspect." LinkedIn caches aggressively and won't pick up changes until you explicitly tell it to re-fetch. The Post Inspector forces that fetch.
Facebook / Meta: Facebook Sharing Debugger — paste the URL, click "Debug," then click "Scrape Again." Sometimes you need to hit "Scrape Again" twice before it picks up fresh data. After scraping, scroll down to "Link Preview" to see what it's actually reading.
After forcing the re-scrape, wait. Platforms typically propagate changes within 5–30 minutes, though LinkedIn can sometimes hold onto a cached card longer depending on how widely the original URL was shared. If you've shared the link many times before, it may take a few scrape cycles.
A note on Twitter/X: X reads your Open Graph tags and falls back gracefully — it doesn't have a public debugger like the others, but ogp.me and card validators will show you what it would read. Most X preview issues come down to the twitter:card tag being missing (summary_large_image is what you want for the big preview) or og:image being a relative URL.
Step 4: Check whether the image URL itself is accessible
Platform crawlers are not your browser. They don't have your session cookie. They can't access images behind authentication, and they'll silently fail on images blocked by robots.txt or served from a domain on a restrictive CORS policy.
Test this by opening your og:image URL directly in an incognito window. If it doesn't load without authentication — or if it redirects — that's your problem. The image needs to be publicly accessible, no login required.
Also worth checking: the image path. After a site migration or a media library reorganisation, the og:image tag sometimes still points at a path that no longer exists. The tag is technically present; it's just referencing a 404.
The fix flow, in order
So you've got a link preview not showing (or showing the wrong thing). Here's the order to work through it:
- View source on the live page — confirm the
og:tags are actually in the HTML - Check that
og:imageis an absolutehttps://URL — not relative - Fetch the page with
curl— confirm your server or CDN isn't serving a cached old version - Open the
og:imageURL in incognito — make sure it's publicly accessible and not a 404 - Use the platform debugger — LinkedIn Post Inspector or Facebook Sharing Debugger
- Hit "Scrape Again" — then wait 5–30 minutes before re-testing
- If it still shows the old card — scrape again, confirm origin is serving fresh HTML, give it more time
Step 7 is genuinely annoying for widely-shared URLs. LinkedIn in particular can be stubborn about releasing a cached preview when the URL has significant share history. Keep scraping, give it time, and resist the urge to create a new URL just to force a refresh — that breaks all your existing shares.
A few things that aren't actually the problem
While I'm here:
- Changing the filename of your og:image does not force a cache refresh on most platforms. They cache by URL, so a new filename at a new URL would work — but it's the nuclear option and rarely necessary.
- Adding
?v=2to your page URL won't help. Platforms cache based on the canonical URL, not query strings. - The preview looks wrong in your messaging app (Slack, iMessage, WhatsApp) — these have their own caches and scrapers. WhatsApp, in particular, caches previews aggressively and sometimes holds them for weeks. The fix for those is more time and more patience; there's no equivalent of Facebook Debugger for iMessage.
The underlying problem here is always one of three things: the tags don't exist, the image URL is broken or relative, or the platform cached the old version before you fixed it. Once you know which one you're dealing with, the fix is actually straightforward — it's the diagnosis that trips people up.
Sources (retrieved 2026-06-03):
- Kinsta — "How to Use the LinkedIn Post Inspector" — kinsta.com/blog/linkedin-debugger/
- The Open Graph Protocol — tag definitions and absolute URL requirement — ogp.me
- Facebook Sharing Debugger — developers.facebook.com/tools/debug/
- LinkedIn Post Inspector — linkedin.com/post-inspector/