Link Preview Image Not Showing? How to Fix Open Graph for WhatsApp, Facebook and LinkedIn

Short answer
Why is my link preview image not showing?
A link preview is the card that apps like WhatsApp, Facebook and LinkedIn build from a page's Open Graph tags (og:title, og:description, og:image). When you see a link preview image not showing, the usual causes are a missing og:image, a relative URL, a blocked image, a blocked crawler or a stale platform cache.
We are Talha Aslan and team, and we fix this problem on client sites often. The fastest path is a strict order. First, confirm the tags exist. Next, test the image URL. Then check crawler access. Finally, clear the caches.
Open Graph is a set of meta tags that tells social platforms how to display a page. The protocol itself lives at ogp.me. Put simply, the platform sends a bot to your page, reads those tags and draws the card from them.
What do the different symptoms tell you?
In practice, each symptom points to a different layer. For example, no card at all usually means an access problem. A title with no image points to the image itself. An old image almost always means a cache.
| Symptom | Likely cause | First check |
|---|---|---|
| No preview card at all | The bot can't reach the page, or the page is too slow | Firewall, robots.txt, response time |
| Title shows, image doesn't | Missing og:image, relative URL or unreachable file | Open the image URL on its own in a browser |
| Wrong image (logo, icon) appears | No og:image, so the platform picks one from the page | Add an explicit og:image tag |
| Old image or old title | Platform cache | Rescrape in Sharing Debugger, use a new image URL |
| Image appears as a small square | Image is narrower than recommended | Fix size and ratio using official docs |
| Works on Facebook, fails on LinkedIn | LinkedIn's bot is blocked or a tag is missing | LinkedIn Post Inspector |
Use this table as a triage map. Therefore, run the first check in each row before you move on. In practice, the first two checks solve most cases.
Which Open Graph tags do you actually need?
The protocol lists four basic properties: og:title, og:type, og:image and og:url. Meta's guide for webmasters lists og:url, og:title, og:description and og:image as its basic set. It also recommends og:type and og:locale.
- og:title: the headline on the card. It can be shorter than your page title.
- og:description: one or two sentences under the title.
- og:image: the card image, written as a full URL.
- og:url: the canonical, permanent address of the page.
- og:type: the content type, usually website or article.
- og:image:alt: a description of what the image shows. The protocol says pages with og:image should include it.
Also, all of these tags sit in the head of the page. In addition, every page should carry its own values. One sitewide og:image works, but then every share looks the same.
Why must og:image be an absolute URL?
A sharing bot doesn't resolve paths the way a browser does. Instead, it takes the tag value literally. So the image address should include the protocol and the domain. A relative path may leave the bot with nothing to fetch.
Every example in the protocol docs uses a full address that starts with https. Example scenario: your theme outputs /uploads/cover.jpg. The correct form is https://example.com/uploads/cover.jpg.
Also, a correct address is useless if the file won't open. Open the image URL in a private browser window, logged out. A file behind a login, inside a protected folder or returning a 404 will not appear. LinkedIn's sharing help page also warns that images in protected directories can fail.
When should you get professional help?
Sometimes the tags look right, the image opens and you cleared every cache. Still, the card stays blank. At that point the cause usually sits in the server, the security layer or the theme templates. Changing settings by guesswork then tends to create new problems.
In those cases we look at three things together: what the bot actually received, how the theme writes the head, and which security rules fire. If you want a site where share cards work from day one, our custom website design work builds Open Graph into every page template.
That said, a clean card alone won't bring traffic. However, it does shape whether people tap the link. For the wider picture, read our guide on driving website traffic from social media.
What image size and ratio should you use?
Take sizes from the platforms, not from guesswork. LinkedIn's help page gives a minimum of 1200 x 627 pixels, a 1.91:1 ratio and a 5 MB limit. It also notes that images under 401 pixels wide show as a thumbnail. Meta's sharing best practices suggest at least 1080 pixels wide for high resolution screens.
An undersized file is a frequent reason for a link preview image not showing at full width. Read together, these docs give a practical target. Use a landscape image, close to 1.91:1, around 1200 pixels wide. Meta lists JPEG, GIF and PNG as supported types, so one of those three is the safe choice.
If the file is too heavy, shrink it with our image resizer. For general site image sizes, see our hero and banner size guide. Here we focus only on the share card.
Note: platforms update these numbers from time to time. Always confirm the current values on the official page.
What do og:image:width and og:image:height change?
According to Meta's best practices, these two tags let the crawler render the image right away on the first share. Without them, the crawler has to download and process the image first. As a result, the very first share can appear without an image.
In other words, if you publish a page, drop it into a WhatsApp group and see no image, this may be why. A second share that does show the image supports this theory.
- Find the real pixel width and height of the image.
- Put those numbers in og:image:width and og:image:height.
- Optionally, set og:image:type, for example image/jpeg.
- Run the page through Sharing Debugger once to warm the cache.
Instead of typing tags by hand, draft them with our meta tag generator and move them into your theme.
Does WhatsApp need its own tag?
No. WhatsApp doesn't need a separate tag. In our experience, WhatsApp builds its card from the same Open Graph tags. So once og:title, og:description and og:image are right, WhatsApp usually follows.
However, WhatsApp has no public test tool like Sharing Debugger. Therefore, we validate the tags in Meta's Sharing Debugger first. Then we paste the link into a fresh WhatsApp chat to see the result.
Also, WhatsApp builds the preview on the sender's device. So the same link can look different on two phones for a while. If one phone shows an old card, add a query parameter to the link and test it as a new address. That trick helps with diagnosis.
Click to chat links are a separate topic. For those, use our WhatsApp link generator.
Is a firewall behind your link preview image not showing?
Often, yes, and teams often miss it. Meta's web crawlers page names the sharing bot facebookexternalhit. It advises you to allow list either its user agent strings or its IP addresses, and it calls IP addresses the more secure option.
A link preview image not showing after a security change is a classic sign. Bot protection, country blocks, rate limits and human verification screens can treat this bot as hostile traffic. Consequently, the card never forms, or forms only halfway.
- Search your hosting firewall logs for blocks on facebookexternalhit or LinkedIn's bot.
- Check whether your CDN or bot protection service has an exception for social crawlers.
- If you block countries, account for the regions crawlers come from.
- Turn off any maintenance mode or password protected preview that stayed on.
Example scenario: after a wave of attacks, a site switches to strict bot protection. Visitors load it fine. From the next day, though, every shared link shows up bare. Linking the two events can take days, yet the security log shows it in minutes.
These settings live on the hosting side, so make the change together with your host.
Can robots.txt affect your share card?
It can. Meta's documentation explains that you can set a separate user agent block per crawler in robots.txt. It also says crawlers may cache robots.txt for up to 24 hours. So a change may take that long to apply.
Example scenario: a developer added a rule that blocked all bots during staging, and nobody removed it at launch. Often the first sign isn't lost search traffic. Instead, it's shared links that suddenly have no image.
The same page notes that the sharing bot may skip robots.txt for security or integrity checks. Even so, blocking the folder that holds your images is enough to break the card. Review your rules with our robots.txt generator.
Do page speed and server settings break previews?
They can. Meta's crawler page says that if the bot can't reach content within a few seconds, Facebook may not display it. It also asks you to place Open Graph properties within the first 1 MB of the page. In addition, your server should support gzip and deflate encoding.
So keep the tags high in the head. Large inline scripts or style blocks at the top can push the tags past that limit.
HTTPS matters just as much. An expired or broken certificate can stop the bot from fetching the page or the image. Check yours with our SSL checker. Likewise, if the image URL passes through several redirects, shorten the chain with help from our redirect checker.
Why does the old image keep showing?
Because platforms cache the page and the image. Meta's docs say images are cached by URL. They won't update unless the URL changes. So swapping the file contents and uploading it under the same name rarely works.
Meanwhile, the best practices page mentions a standard 24 hour cycle. For faster updates, it recommends a rescrape in Sharing Debugger.
- Upload the new image under a different file name.
- Point og:image to the new address.
- Clear your caching plugin and any CDN cache.
- Rescrape the page in Sharing Debugger.
- Inspect the URL again in LinkedIn Post Inspector.
- Paste the link into a new WhatsApp chat and check.
Order matters here. If you rescrape before clearing your own cache, the bot simply reads the old tags again.
How do you use Sharing Debugger?
Sharing Debugger is Meta's official tool for seeing your page the way its crawler does. Meta's webmaster guide says it shows the scraped tags, errors and warnings. It also triggers a fresh scrape.
- Open Sharing Debugger and paste the full page URL.
- Review the response code and the tags the bot found.
- Look for warnings about missing tags or an unreachable image.
- After fixing tags, use the option to scrape again.
- Confirm that the preview shows the right image and title.
The data on what the bot saw is the key part. For instance, your browser may show the page fine while the bot gets a login screen, a cookie wall or an error page. Then the problem is access, not tags.
What about LinkedIn and X?
LinkedIn reads Open Graph tags too. Its help page says the title, image, description and url tags must exist. It also says that if an image meets the rules and still fails, your site may be blocking LinkedIn from fetching it.
LinkedIn Post Inspector shows how a URL will look on LinkedIn. After you fix tags, inspect the URL there again. This helps refresh an old card.
X uses its own card tags for its card layouts. So if you want a large image card on X, you may need to add the tag that sets the card type. Check the current tag names and image rules in X's developer docs, because they change.
In short, one solid Open Graph setup covers WhatsApp, Facebook and LinkedIn at once. X needs a small extra step.
Where do you manage tags in WordPress or a theme?
On most sites, an SEO plugin or the theme writes the Open Graph tags. The usual trouble is two sources at once. For example, the theme writes one og:image, the plugin writes another, and the platform takes the first.
- View the page source and search for og:image. If there are several, find where each comes from.
- Set a default share image in your plugin's social settings.
- Pick a specific share image for each important page and post.
- After a theme update, check that the tags are still there.
Posts without a featured image fall back to the default image. Without a default, the platform grabs something random, and a cropped logo can end up on the card. For similar issues in Google results, see our post on a wrong image thumbnail in search. The logic there differs.
Can a cookie banner or popup block the bot?
Yes. Some sites show a full screen consent wall, an age gate or a language picker on the first visit. If that screen redirects to its own URL, the bot reads it instead of your page. As a result, the card shows the consent screen title instead of your content.
The fix is to show consent as an overlay on top of the page. Keep the underlying HTML unchanged. That way your Open Graph tags stay the same for every visitor and every bot. You can still meet your privacy and consent duties this way. This article isn't legal advice, so ask your counsel about the consent text itself.
Specifically, Sharing Debugger makes this obvious. If the title the bot saw belongs to the consent screen, you found the cause.
How should multilingual sites set og:url and og:locale?
Each language version should point og:url to its own address. The protocol treats og:url as the permanent ID of the object. So if your Spanish page lists the English URL, the platform may treat both as one object and show the wrong language.
og:locale states the language and region of the content. Meta lists it among recommended extra tags. Use values such as en_US or de_DE.
- Set og:url to the page's own address in each language.
- Write og:title and og:description in that language, not in raw machine translation.
- If the image contains text, make a version per language.
- Make sure language redirects don't send the bot to another version.
Search engine language tags are a separate subject. For those, see our hreflang generator.
Do UTM parameters change the card?
Usually they don't change the content of the card. However, they can affect caching. Platforms often treat a URL with a query string as a new address. So tagged and untagged versions of a page may show different cards for a while.
Example scenario: you changed the image before a campaign but only rescraped the tagged URL. On WhatsApp, the tagged link shows the new card and the plain link shows the old one. Then someone on the team shares the plain link, and everyone calls the issue random.
To avoid this, keep the clean canonical address in og:url and rescrape both versions before launch. Our UTM builder keeps campaign links consistent, so tracking and cards stay in sync.
How should you design the share image?
Even with perfect tags, a weak image won't earn attention. In a chat, the card is small. Consequently, detailed photos and small text disappear. A simple background, one clear focal point and few words work better.
- Keep the main message in the center, since edges may be cropped in some views.
- Then keep the logo small and in a corner.
- If you use text, pick a bold, large font.
- Leave enough contrast between text and background.
- Make a separate image for each key page.
Test contrast with our color contrast checker. Also keep the file size reasonable, because heavy files make it harder for the bot to fetch the image in time.
How should you write the card title and description?
In practice, text drives taps as much as the image. You don't have to copy your SEO title into og:title. A short, clear title written for sharing usually works better. For example, a product name plus one benefit is enough.
For og:description, one or two sentences will do. Platforms cut long text, so put the key point in the first sentence. Also, a correct site name on the card builds trust. For the Google side of that topic, see our post on a wrong site name in search results.
Are there mobile problems beyond the preview?
Most WhatsApp shares happen on phones, and the link opens in a mobile browser. Even with a perfect card, a page that breaks on iPhone sends visitors straight back. That is a separate problem, and we cover it in our post on a website that looks broken on iPhone Safari.
Similarly, page builders may limit your control over Open Graph. We discuss whether such platforms are enough in our article on Google Sites for a business website.
Also note that the small image in Google search results and the favicon come from different signals than Open Graph. So a new og:image won't change your Google thumbnail. For favicon issues, see our favicon fix guide.
What is the full checklist for a link preview image not showing?
Run this list before each new page goes live. That way you catch the problem before launch, not at the moment of sharing.
- og:title, og:description, og:image and og:url sit in the head of the page.
- og:image uses a full https URL.
- The image URL opens in a logged out browser.
- The image is landscape, near 1.91:1 and above the minimum in the official docs.
- og:image:width, og:image:height and og:image:alt are present.
- Only one source writes og:image.
- Your firewall and CDN allow social crawlers.
- robots.txt doesn't block the image folder.
- The SSL certificate is valid and the redirect chain is short.
- Sharing Debugger and Post Inspector return clean results.
Keep the list in a shared team document. Then whoever publishes ticks each item, and the technical owner only looks at what failed. Next time you face a link preview image not showing, you will know exactly where to start.
How long should you wait after changing the image?
We can't give an exact time, since it depends on platform caches and on the steps you take. Meta mentions a standard 24 hour cycle without a manual rescrape. Still, if the image URL didn't change, even that may not be enough.
So don't wait passively. Instead, use a new file name, update the tag, clear your site cache and rescrape. With those four steps, you usually see the change the same day.
On the other hand, cards in messages you already sent often stay as they were. New sends will show the updated card.
What order should you follow in the end?
To sum up, check tags, then the image URL, then access, then size, then cache. This order resolves most cases we see in the first half hour. Every site differs, though, and we can't promise a result.
When the cause sits in the theme or server setup, the lasting fix happens at template level. If you want share cards, speed and mobile behavior planned together, our professional web design process starts with a review of your current site.



