You send a launch page, blog post, or client URL in WhatsApp and get a plain text link instead of the visual card you expected. A WhatsApp link preview image missing is more than a cosmetic problem. It makes a polished page look unfinished, reduces confidence at the moment of sharing, and gives people less reason to tap.
The frustrating part is that the page can look perfect in a browser while its share preview fails. WhatsApp does not take a screenshot of your page. It reads metadata in the page source, tries to fetch the referenced image, and may reuse a cached version of what it found before. One broken tag, blocked image request, redirect, or stale cache can turn a branded card into a grey box.
Why a WhatsApp link preview image is missing
WhatsApp primarily relies on Open Graph metadata. The most relevant tag is `og:image`, which tells sharing platforms which image belongs with a URL. It also uses related fields such as `og:title`, `og:description`, and `og:url` to build the preview.
If `og:image` is absent, points to the wrong file, or cannot be fetched by WhatsApp, no image appears. That sounds simple, but the failure can happen at several layers: your CMS may not output the tag, your CDN may deny the crawler, a plugin may create conflicting tags, or WhatsApp may still hold an old result.
This is why changing the featured image in WordPress, Webflow, Ghost, or your custom site does not always fix the preview immediately. You changed the page. WhatsApp may be looking at cached metadata or an image URL that was never publicly available to begin with.
The image URL is not publicly fetchable
Your browser may load an image because you are logged in, on an approved network, or carrying cookies. WhatsApp's crawler has none of that access. The image must be reachable over public HTTPS without a login, firewall challenge, IP restriction, referrer requirement, or expiring signed URL.
Copy the exact URL from your `og:image` tag and open it in a private browser window. It should load directly as an image, not redirect to an HTML page, a media library screen, or an access-denied message.
This catches a common issue on staging sites and protected documentation portals. It also catches CDN settings that block unfamiliar bots. Security settings are valuable, but your social-preview crawler needs a path to the image.
The tag is missing, duplicated, or rendered too late
View your page source, not just the live DOM in browser developer tools. Search for `og:image`. You want one clear, absolute image URL in the initial HTML response.
A frequent CMS problem is duplicate metadata. Your SEO plugin may output one `og:image`, while a theme, social-sharing plugin, ecommerce extension, or custom script outputs another. Platforms do not always choose the same tag you expect. Remove the conflict and keep one authoritative source.
JavaScript-only metadata is another trap. If your site adds Open Graph tags after the page loads, WhatsApp may never see them. Social crawlers generally need metadata present in the server-rendered HTML. For Next.js and other app frameworks, generate the tags during server-side rendering or static generation rather than injecting them in the browser.
The file is technically valid but a poor preview asset
An OG image should be a real image file with a standard content type, usually JPEG or PNG. Use a large landscape format such as 1200 by 630 pixels for reliable cross-platform results. Keep the important text and logo away from the edges, since platforms can crop differently.
File size matters too. A huge source image might work on your site and still be slow or unreliable for a crawler. Compress it aggressively without making text fuzzy. As a practical target, keep social images under 300 KB when possible, especially when you need consistent WhatsApp behavior across mobile networks.
Avoid unusual formats, images served as downloads, and URLs with fragile query parameters. A clean, stable HTTPS image URL is easier for every platform to fetch and cache.
How to fix a WhatsApp link preview image missing
Start with the shared URL itself. Make sure you are testing the exact version people receive: `https` versus `http`, `www` versus non-`www`, trailing slash versus no trailing slash, and campaign parameters if they are included. Different URL variants can create different cache entries and, on poorly configured sites, different metadata.
Then work through this order. It prevents you from redesigning an image when the real problem is an inaccessible URL.
- Confirm that the page source includes `og:image`, `og:title`, `og:description`, and `og:url`.
- Verify that `og:image` uses an absolute HTTPS URL and opens publicly in a private browser session.
- Check that the image returns an image content type, such as `image/jpeg` or `image/png`, rather than HTML or a redirect loop.
- Remove duplicate Open Graph tags created by overlapping plugins, themes, or custom code.
- Use a properly compressed 1200 by 630 image and publish it at a stable URL.
- Check the final destination after redirects. The URL you share should reach the page that contains the intended metadata.
If your site uses Cloudflare, another CDN, or a web application firewall, inspect its bot protection and hotlink rules. The right solution is usually not turning security off. It is allowing legitimate social crawlers to request public page metadata and public OG images without a challenge.
Handle redirects and canonical URLs carefully
A redirect is not automatically a problem. A single permanent redirect from an old URL to its current URL is normal. Trouble starts when redirects chain together, switch between domains, or send a crawler somewhere different from a visitor.
For example, your campaign link may redirect from `http` to `https`, then from a non-`www` domain to `www`, then to a locale path. Each hop adds another point of failure. Keep the chain short and make your `og:url` match the final canonical page URL.
Also look for a mismatch between your canonical tag and Open Graph tags. If one part of your stack says the page is `/pricing` and another says it is `/pricing/`, social platforms may cache results in ways that feel random. Pick one public URL format and use it consistently.
Know when the real issue is caching
You fixed the metadata, but WhatsApp still shows the old image or no image at all. That does not necessarily mean the fix failed. WhatsApp caches link previews, and cache timing is not fully under your control.
A useful test is to share a slightly different URL version, such as the same page with a harmless query parameter. If the new version displays the updated card, your metadata is likely correct and the original URL is holding an old cached result. Do not make query parameters your permanent sharing strategy, though. They can fragment analytics and create multiple preview variants.
Instead, make the correct image and metadata available at stable URLs, then give the cache time to refresh. For a high-stakes launch, validate the card before the campaign begins rather than minutes after the first message goes out.
Build previews that hold up beyond WhatsApp
Fixing one broken WhatsApp card is useful. Maintaining preview images one page at a time is where teams lose hours. A blog with 200 posts, a SaaS site with feature pages, or an agency with multiple client sites cannot depend on someone opening Canva whenever a URL needs to be shared.
The better setup is to treat OG images as publishing infrastructure. Design one on-brand layout, connect it to your existing page data, and let each URL receive its own title, image, author, price, date, or category. Your product announcement gets an announcement card. Your documentation page gets a documentation card. Neither needs a manual export.
That is the operating model behind getwowlink: design once, connect once, and every page gets its own OG image. It can sit alongside SEO tools that already manage titles and descriptions, while giving your team control over the visual layer those tools often leave generic.
There is a trade-off. Dynamic image generation needs dependable source data. If your page titles are inconsistent, featured images are missing, or product fields are incomplete, the generated card will faithfully reveal that inconsistency. Set sensible fallbacks for missing photos and long titles, then test a few edge-case pages before applying a design sitewide.
A quick pre-share check for important URLs
Before sharing a launch, sales page, or client deliverable, check the final public URL in a private browser. Confirm the page source has one `og:image` tag, the image opens without authentication, and the card looks good at small size. Large desktop mockups can hide text that becomes unreadable inside a WhatsApp thread.
Then test a representative set of pages, not just the homepage. Check a post with a long title, a page without a featured image, an old URL that redirects, and a newly published page. Those are the pages most likely to expose gaps in your metadata rules.
A missing preview image is usually fixable in minutes. The larger opportunity is making sure it never becomes a recurring publishing chore. When every shared URL has a clear, branded visual card, WhatsApp stops being the place where your carefully built pages suddenly look unfinished.
