Link Preview Not Showing? How to Find the Real Cause in Two Minutes

You paste your own link into a WhatsApp chat, or a Slack channel, or a post on X, and the card comes back empty. No image, no title, just a bare URL sitting there like it forgot to get dressed. Or maybe there is an image, but it is the wrong one, the one you swapped out of that blog post two years ago.

A link preview, the small card with an image, headline and site name that a shared page turns into, is supposed to just work. When it does not, you start searching, and almost every guide you find is written for a different app than the one giving you trouble.

Here is what those guides tend to skip: a link preview not working almost never has more than three possible causes, and you can usually tell which one you have in under two minutes, before you touch a single line of code. This guide walks through that check first, then the fix for whichever bucket you land in.

Run This Two-Minute Self-Test First

Diagnosing a broken link preview is a lot like figuring out why a car will not start. A mechanic does not swap parts at random, they test the battery first, because that check takes ten seconds and rules the most common cause in or out. A link preview has the same kind of shortcut, and it takes about two minutes.

A link preview stops showing for one of three reasons: the crawler (the automated program a platform sends to read your page) cannot reach it, the page is missing the tags that tell platforms what to show, or the platform is displaying a cached, saved copy from before you fixed anything. Work through the steps below in order, and stop as soon as one of them points you somewhere.

1. View your page's source code and search for og:title and og:image. Right-click the page, choose "View Page Source," then press Ctrl+F (or Cmd+F on a Mac) and search for og:. If you see lines like <meta property="og:image" content="..."> with real values filled in, your tags exist, and you can move to step 2. If the search comes up empty, or the content is blank, skip ahead to the "tags are missing or wrong" section below. Do not confuse this with your page's plain <title> tag: some platforms fall back to it, but a rich link preview specifically needs the Open Graph tags.
2. Paste the same URL into the checker at socialpreview.tools. This runs a fresh crawl of your page right now, the way a platform's bot would, and shows you which tags exist, what image it downloaded, and any errors. If the checker reports an error, that error names which bucket you are in. If it comes back clean but the app you are pasting into still shows something wrong or outdated, go to step 3.
3. Compare what the checker just found to what the platform is currently showing you. If they match (the checker also shows no image, or the same wrong title), the problem is real and current: an access issue or a tags issue, covered in the next two sections. If they do not match (the checker shows a fresh preview, but WhatsApp or X still shows the old one), the platform simply has not re-checked your page. That is a cache problem, and the fix looks nothing like the first two.

Branch 1: the crawler can't reach your page

If the checker's error mentions an unreachable image, a failed fetch, or a very slow response, the problem sits between the platform's crawler and your server, before your page's actual content even gets read. A crawler, sometimes called a bot, is an automated program a platform sends out to read a page. It announces itself with a name, called a user agent, the way you might wear a name tag at a conference.

Facebook, Instagram and WhatsApp share crawler infrastructure and use the user agent facebookexternalhit; Slack uses Slackbot; X uses Twitterbot. If your server or a security tool is blocking unrecognized visitors, there is a good chance it is blocking these too.

1. Open your site's robots.txt file (found at yoursite.com/robots.txt) and look for a directive, an instruction in that file, saying Disallow: / under a wildcard user agent (User-agent: *), or a specific block naming facebookexternalhit, Slackbot, or Twitterbot. If none of these appear, robots.txt is not your problem. If one does, remove the blocking line and save the file. Meta's own crawler documentation states that its crawler generally respects robots.txt rules, so a blanket block there can quietly kill previews across Facebook, Instagram and WhatsApp at once, since they share infrastructure. Meta also notes that its cached copy of your robots.txt can take up to 24 hours to refresh after you fix it.
2. Check whether a firewall or bot-management tool (Cloudflare, a security plugin, a web application firewall) is set to block unrecognized visitors. Look in its settings for a bot-protection or "challenge unknown visitors" rule. If it blocks anything not on an allowlist, add the platform crawlers by name, or loosen the rule for the page you are trying to share. A crawler that receives a security challenge page instead of your content cannot read your tags, and the preview fails with no error message visible to you.

One more thing worth ruling out: response speed. Practitioners commonly report that Meta's crawler gives up on a page that takes longer than around five seconds to respond, though Meta has not published an exact figure, so treat that number as a widely repeated estimate rather than an official limit. If your page is slow because of heavy plugins or an overloaded server, the fix is performance work, not a markup change.

The same goes for an og:image URL that sits behind a login, a redirect chain, or a CORS restriction: the crawler needs direct, public access to the exact image file, not a page that eventually gets there. If your image keeps redirecting, a redirect checker like httpcheck.tools will show you the full chain that URL is actually taking.

Branch 2: the tags are missing or wrong

If step 1 of the self-test came back empty, or the checker flagged something like a missing title or missing image tag, the problem lives in your page's markup, not out on the network. That is good news, in a way. Markup is something you can fix yourself, on your own page, without waiting on anyone else.

The Open Graph protocol, the shared standard platforms read to build a preview card, lists four properties as required on any page: og:title, og:type, og:image, and og:url. Miss one and you are not just risking a plain-looking card, you are technically outside the specification. In practice, the most common gaps look like this:

• No Open Graph tags at all. The page only has a regular <title> tag. Some platforms fall back to that and grab the first image they find on the page; others show nothing.
• Tags added by JavaScript after the page loads. If your site is built with a framework that injects meta tags client-side (common on single-page apps), a crawler that does not run JavaScript sees an empty <head>, even though your own browser shows the tags fine. What your browser's inspector shows you is not always what a crawler sees; view-source, not the inspector panel, is closer to the truth here.
• A relative image URL. Something like content="/images/cover.jpg" instead of a full address starting with https://. Some platforms resolve this correctly, others do not, which is a common reason a preview works on one app and not on another.
• A missing or misconfigured twitter:card tag. If you want a large image card on X, you need twitter:card set explicitly to summary_large_image; the summary versus summary_large_image breakdown covers when the smaller card is the better choice. Without a separate twitter:image, X and several other platforms fall back to your og:image value, so you are not always starting from zero, but that fallback does not cover every field.

Writing these tags by hand does not have to be a manual, trial-and-error job. The tag generator at socialpreview.tools builds the full set for you, form fields on one side and a live preview on the other, so you can watch the card update as you type, before any of it goes anywhere near your live page.

Branch 3: it's a stale cache, not a real problem

A cache, in this context, is a saved copy. Platforms do not re-crawl your page every time someone shares it; they crawl once, save what they found, and hand that copy to everyone from then on. It is like a friend who photographed your shop front last year and still shows that photo to everyone who asks. You repainted the door in the meantime, and the photo does not know that.

Fixing your tags does nothing to a preview that has already been cached. You are looking at an old photo, not a broken one. The single trick that works across nearly every platform is adding a harmless query string to the end of your URL, something like ?v=2 or ?ref=refresh.

Because the platform has never crawled that exact URL before, it treats it as new and fetches it fresh. Share the link with that query string attached, instead of the bare URL, and the updated preview should appear.

Some platforms also offer a direct way to force a re-crawl. A WhatsApp link preview is the trickiest case: unlike Facebook or LinkedIn, WhatsApp has no public tool to request a fresh crawl at all. Its preview gets generated by the sender's device the first time a link is pasted, then cached server-side for everyone else. Practitioner reports put that cache at a day to several days (WhatsApp publishes no official documentation on this, so treat it as observed rather than stated policy), which makes the query-string trick the only lever available.

An iMessage link preview behaves differently again: when no usable preview image turns up, it falls back to your site's apple-touch-icon or favicon file. If that file is missing or too small, the fallback fails too. Troubleshooting threads report the same fix again and again: a site's apple-touch-icon address was returning a 404 page, and once the icon file was restored, the preview rendered correctly with nothing else changed.

Platform quirks at a glance

Once you know which of the three buckets you are dealing with, the platform you shared to mostly just affects how you go about the fix. This table is meant as a quick reference, not a replacement for the branches above.

Check it before you publish, not just after

The self-test above works just as well before you hit publish. Run your URL through the checker while you are still editing, catch a missing og:image or a stray relative URL before anyone shares the page, and you skip this whole troubleshooting process. It takes less time than writing the post title.

If your CMS generates these tags automatically, a wrong preview usually means one plugin setting or theme field got overridden, not that the whole system is broken. Either way, the checker and the generator at socialpreview.tools give you the same view a platform's crawler gets, so you are fixing what is actually there instead of guessing.

Frequently Asked Questions

Why is my link preview not showing?

It comes down to one of three things: the platform's crawler could not reach your page (blocked by robots.txt, a firewall, or a slow server), your page is missing the Open Graph tags that build the card (no og:title or og:image, or tags injected by JavaScript that a crawler never sees), or the platform is showing a cached copy from before you made a fix. Run the two-minute self-test above to find out which one applies before you change anything.

How do I get a link preview to update?

Add a harmless query string to the end of your URL, something like ?v=2, and share that version instead of the original. Because the platform has never crawled that exact address before, it fetches your page fresh rather than pulling the saved copy. If a platform offers its own refresh tool, Facebook's Sharing Debugger and its "Scrape Again" button, or LinkedIn's Post Inspector, use that first since it is more reliable than waiting out a cache on its own. For a fuller rundown of each platform's refresh options, the site's Open Graph guide covers the cache-clearing tools in more depth.

Why does the preview work on Slack but not on X?

Slack's link-unfurling system checks for Open Graph and Twitter Card metadata automatically, with no special setup required, and it renders a card generously even from partial data. X's card crawler is stricter: it needs twitter:card declared explicitly, expects specific image dimensions, and will not fill in the gaps the way Slack does. A page that "mostly" has its tags right often clears Slack's bar without any trouble but falls short of X's, which is exactly why the same link can look fine in one app and broken in the other.

Does a link preview need og:image?

Per the official Open Graph specification, yes: og:image is one of four required properties, alongside og:title, og:type, and og:url. In practice, Facebook and Slack will still render a text-only card from your title and description if no image is present. X's large-image card and a rich iMessage link preview both need an actual image, so skipping og:image is against spec everywhere and costly on at least a couple of the platforms your readers use.