Why Is My Link Preview Broken? A Triage Guide
A plain-language starting point for a broken link preview if you're not sure yet whether the problem is code, caching, or the image itself — figure out which category you're in first.
August 16, 20267 min read
"Why is my link preview broken" covers a lot of different symptoms, and the fix depends entirely on which one you're actually looking at. No image at all is a different problem than the wrong image. A preview that used to work and now doesn't is a different problem than one that never worked. This guide isn't a deep technical walkthrough of any one of those — it's meant to help you figure out, in the first two minutes, which category you're in, so you can go read the specific fix that actually applies instead of guessing.
First, describe the symptom precisely
"Broken" means different things, and the fix genuinely depends on which of these you're seeing. Take a moment to identify exactly which one matches before doing anything else:
- No preview at all — just a plain blue link with no title, description, or image
- A title and description show up, but no image
- An image shows up, but it's the wrong one — old, generic, or from a different page
- The preview looked right yesterday and looks wrong today, with nothing you're aware of having changed
- The preview looks right on one platform (say, Facebook) but wrong on another (say, X or Slack)
If there's no preview at all
This usually means the page has no usable Open Graph or Twitter Card tags for the platform to read at all — not a missing image specifically, but a missing or malformed tag set entirely. The most common cause, especially on modern JavaScript-heavy sites, is that the meta tags are added to the page after it loads in a browser, by client-side code, rather than being present in the raw HTML a server sends back. Social crawlers generally don't run JavaScript, so anything added that way is invisible to them even though it looks completely normal when you view the page yourself. Check your page's actual HTML response (view source, not the browser's inspector) to see whether the tags are really there before assuming anything else is wrong.
If text shows up but the image doesn't
This narrows things down significantly — your basic tag setup is working, since the title and description are rendering, and the problem is specific to the image. The most frequent causes are an og:image URL that's relative instead of absolute, an image that requires login or is blocked by robots.txt, or an image that's too small, too large, or in an unsupported format for that particular platform. This is a well-defined debugging path with a fairly short list of usual suspects, worth working through directly.
If the wrong image shows up
This is different from no image at all — something is loading, it's just not what you intended. If it's an old version of your intended image, this is very likely a caching problem: the platform scraped your page before you made a change and is still showing what it found then, or the image URL itself is unchanged even though the file behind it was swapped, so something in the chain — the platform, a CDN, a browser — is reusing a cached copy. If it's a generic fallback image entirely unrelated to the page (a site-wide default, a logo, a placeholder), check whether your page-specific og:image tag is actually being read, or whether the platform is falling back to a sitewide default because the specific tag is missing or malformed on that page.
If it used to work and stopped, with no obvious cause
Almost always caching, and almost always tied to a recent deploy or content change you may not immediately connect to the preview. Something changed on the page or in the image, the platform hasn't re-scraped since, and it's showing you a snapshot from before the change. This is the single most common root cause across all the 'broken' variants above, and it's worth ruling in or out early: has anything on this page or its image changed recently, even something that seems unrelated to sharing? If yes, a forced re-scrape on the relevant platform is the first thing to try, not a deep audit of your markup.
If it's fine on one platform but broken on another
This tells you your core Open Graph tags are probably fine, since at least one platform is reading them successfully. The problem is more likely platform-specific: X and other platforms rely on twitter:card and twitter:image tags that are separate from standard Open Graph tags, and a platform that doesn't fully fall back to og:* values will show a broken card even when Facebook renders the same page perfectly. Similarly, LinkedIn applies stricter image requirements than most other platforms, so an image that's technically valid Open Graph markup can still get rejected there specifically. Check what's different about the platform-specific tags and requirements, not the general Open Graph setup that's already proven to work elsewhere.
Why guessing tends to waste more time than a quick check would
It's tempting, when a preview looks broken, to jump straight to the most recent thing you remember changing and assume that's the cause — a redesign, a new CMS plugin, a migration to a new hosting provider. Sometimes that instinct is right. Just as often, the actual cause is something unrelated and easy to overlook: a caching layer that's been quietly serving stale content since before the change you're blaming, or a platform-specific requirement (like LinkedIn's stricter image validation) that was never satisfied in the first place and only becomes visible now because someone finally tried sharing the link there. Spending five minutes correctly identifying which of the symptom categories above you're actually looking at is almost always faster than several rounds of changing things and re-testing based on a guess about the cause, particularly because a wrong guess (assuming it's a code bug when it's really a cache) can lead you to make unnecessary changes that don't actually fix anything and complicate the next round of debugging.
A decision path, condensed
- No preview anywhere: check whether Open Graph tags exist in the raw HTML at all
- Text but no image: check the image URL is absolute, public, and within size/format limits
- Wrong image: check for a stale platform cache or a fixed URL with swapped-out content behind it
- Worked before, broken now with no obvious change: assume caching first, force a re-scrape before digging deeper
- Works on one platform, not another: check platform-specific tags (twitter:card, twitter:image) and platform-specific image requirements
Getting a direct answer instead of guessing
Working through this triage by eye takes time, and it's easy to misdiagnose a caching issue as a markup issue or vice versa if you're only looking at how a link happens to render when you personally paste it somewhere. useopengraph's free scanner fetches a page the way a crawler actually does and reports exactly which tags exist, which are missing, and whether the linked image is reachable — turning "why is my link preview broken" into a specific, named answer in one pass rather than a manual process of elimination. For ongoing peace of mind once something's fixed, the Cache Debugger shows what each major platform currently has cached for a URL, so you can confirm a fix actually took effect everywhere it needs to, not just on the one platform you happened to check.
View the page's raw HTML source directly, not the browser's inspector, which shows the DOM after JavaScript has run. Social crawlers generally don't execute JavaScript, so a tag that only appears after hydration looks completely normal to you but is invisible to the platform.
No — it usually means the opposite, that your core Open Graph tags are fine since Facebook is reading them successfully. X relies on separate twitter:card and twitter:image tags that don't reliably fall back from og:*, so the gap is more likely platform-specific tags than a broken general setup.
Almost always a cached scrape from before your change, not a failed fix. Force a re-scrape where a platform offers one (Facebook's debugger, LinkedIn's inspector) or use a cache-busting query parameter where it doesn't, then re-check before assuming the fix itself didn't work.
A scanner that fetches the page the way a crawler does can report exactly which tags exist and whether the image is reachable in one pass, and a cache debugger can show what each platform currently has stored — together turning the triage above into a direct answer rather than a manual elimination process.
Stop paying per seat
for a usage-shaped problem.
Unlimited teammates, one usage pool. Start free with the scanner — no card required.