ScreenshotNeo

BlogHow-to

Why Is My Website Link Preview Missing in WhatsApp Business?

A missing WhatsApp Business link preview usually comes down to page metadata, crawler access, or stale preview data. Here’s how to check each one.

By the ScreenshotNeo team4 October 20267 min read

If a website link appears in WhatsApp Business as a plain URL, or its card has no image or outdated details, check four things: the page’s Open Graph tags, whether the page and image are publicly reachable, whether those tags are in the original HTML response, and whether WhatsApp may be showing a cached preview. Fix the source first, then share the link again. There is no dependable cache-expiry interval or guaranteed refresh method established by the sources available for this guide.

This guide is about previews of links to your website, not linking a WhatsApp Business account to Facebook or Instagram. WhatsApp-specific troubleshooting details below come from secondary technical guides; the Open Graph fields and their purpose are defined by the Open Graph protocol.

1. Confirm the exact page URL

Start with the URL you actually sent. Check that it points to the intended page, loads without a logged-in browser session, and responds successfully to an external request. If the URL redirects, inspect the final page too: the tags should describe the page visitors and crawlers reach, and og:url should identify the intended canonical URL.

curl -L -sS -D /tmp/page-headers.txt "https://example.com/page" -o /tmp/page.html
cat /tmp/page-headers.txt

Replace https://example.com/page with the exact link you shared. This command follows redirects, saves response headers and stores the returned HTML. A successful response in your browser alone is not conclusive: login state, browser cookies, or network access can make the page available to you but unavailable to an external crawler.

2. Check the Open Graph metadata in the HTML response

Open the saved HTML and inspect its <head>. Open Graph defines og:title, og:type, og:image, and og:url as required properties for a page represented as an object. og:description is optional and generally recommended. The protocol also supports image properties such as a secure URL, MIME type, dimensions, and alt text.

<head>
  <meta property="og:title" content="Product documentation">
  <meta property="og:type" content="website">
  <meta property="og:url" content="https://example.com/docs">
  <meta property="og:image" content="https://example.com/images/docs-preview.jpg">
  <meta property="og:description" content="Guides and reference for using the product.">
</head>

Use a page-specific title, description, canonical URL, and image. Check that the values are not empty, malformed, or left over from a different page. The image URL should be an absolute, publicly reachable URL. The Open Graph protocol supports optional image metadata including og:image:secure_url, og:image:type, og:image:width, og:image:height, and og:image:alt.

To quickly search the saved response for these properties:

rg -i 'og:(title|type|url|image|description)' /tmp/page.html

If you do not have rg, search the file in an editor or use:

grep -iE 'og:(title|type|url|image|description)' /tmp/page.html

3. Make sure metadata is present before JavaScript runs

Some sites add social metadata only after client-side JavaScript executes. A browser may show a complete page because its scripts run, while a crawler reading the initial response HTML does not see those tags. Inspect the HTML saved by curl, not just the browser’s Elements panel. If the tags are missing from that response, render them on the server or include them in the HTML delivered for that page.

After changing the implementation, fetch the page again and confirm the response itself contains the expected tags. The title, URL, and image should match the exact page shared.

4. Verify the preview image is accessible

A blocked or unavailable og:image can result in a text-only card or missing thumbnail. Copy the image URL from the metadata and request it without relying on your browser session:

curl -L -sS -D /tmp/image-headers.txt "https://example.com/images/docs-preview.jpg" -o /tmp/preview-image
cat /tmp/image-headers.txt
file /tmp/preview-image

Check that the response succeeds and returns the intended image, rather than an error page, login screen, or redirect to an inaccessible resource. If the image is behind authentication, blocked by an access rule, or unavailable to an external crawler, publish it at a publicly retrievable URL and update og:image.

Do not assume a particular image dimension is a universal WhatsApp requirement: the reviewed sources do not establish a WhatsApp-specific size threshold. Use a valid image URL and the optional image metadata supported by Open Graph where it helps describe the asset.

5. Check access rules and crawler blocking

Review firewall rules, access controls, and robots policies if the page or image works for you but not for an unauthenticated external request. A secondary WhatsApp troubleshooting guide identifies crawler access and client-side-only metadata as possible failure causes. The available sources do not establish a current official WhatsApp preview specification, so treat these as practical checks rather than guarantees about a specific crawler implementation.

  • Confirm the shared page loads without a session or special browser cookies.
  • Confirm the image URL can be fetched publicly.
  • Review firewall, bot protection, and robots rules for restrictions affecting crawlers.
  • Ensure the Open Graph tags appear in the original HTML response.

6. Retest after correcting the page

Once the page and image are accessible and the metadata is present in the response, share the link in a fresh chat. Preview data may be stale after a metadata change. If the old card persists, try a changed page URL or a versioned image URL as a diagnostic workaround—for example, changing an image path or its version query parameter after publishing the updated asset. This can help test whether the old preview is being reused, but it is not a guaranteed cache-clearing method. No dependable cache duration or official refresh interval is established here.

Common problems and fixes

Symptom Likely cause What to check or change
Only the URL appears Missing or unusable Open Graph tags, or the page cannot be fetched. Check the exact response HTML for og:title, og:type, og:image, and og:url; fetch the page without a logged-in session.
Text appears, but the thumbnail is missing The image URL may be inaccessible, blocked, or incorrect. Request the exact og:image URL publicly and confirm it returns the intended image.
The preview shows old details The preview may be using cached data. Confirm the current response is correct, then test with a fresh chat and, if useful, a changed page URL or versioned image URL. There is no guaranteed refresh interval.
Tags appear in the browser but not in fetched HTML The site may add metadata only after client-side JavaScript runs. Include the tags in the HTML response, then fetch the response again to verify.
The image works for staff but not externally Authentication, access rules, or crawler blocking may prevent retrieval. Make the asset publicly retrievable and review access, firewall, and robots restrictions.
The wrong page details appear The shared URL, redirect destination, or canonical metadata may point to another page. Check the redirect chain and make the page’s og:url and other fields describe the intended URL.

Performance, reliability, and cost

For this issue, begin with the smallest checks: fetch the page HTML, inspect its head, then fetch the image. That isolates metadata errors from image-access errors without relying on a preview card to reveal what the site served. If you change metadata or assets, verify the new response before retesting in WhatsApp. The sources do not provide a cache lifetime, image-size threshold, or guaranteed refresh procedure, so avoid planning around any such number.

Or skip the browser setup

If you need a visual capture of the page while debugging, ScreenshotNeo is a website screenshot API and MCP server. A screenshot can help you inspect what a page renders; use the HTML checks above to verify Open Graph metadata itself. ScreenshotNeo accepts and removes cookie consent banners, newsletter popups, and chat widgets before capture, and each step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing; responses report the page verdict and billing status. Its MCP server lets AI agents use take_screenshot, get_page_info, and capture_pdf.

One GET request returns an image or PDF. See the ScreenshotNeo API documentation for options.

cURL

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://example.com/page -o shot.webp

Python

import requests

r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://example.com/page"}, timeout=90)
open("shot.webp", "wb").write(r.content)

Node.js

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://example.com/page' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

ScreenshotNeo includes 1,000 screenshots per month free with no card; paid plans start at $5 for 3,000. Every feature is on every plan. Sign up for free and get 1,000 screenshots a month with no card.

FAQ

Does Open Graph metadata only help WhatsApp?

No. Open Graph is a protocol for representing web pages as rich objects in social graphs, so its page fields are useful when checking other social sharing previews too.

Is a Facebook sharing debugger a guaranteed WhatsApp refresh tool?

The reviewed sources do not establish that. Use the actual HTML and image checks, then test the corrected link in a fresh chat.

How long does WhatsApp keep a preview cached?

The sources reviewed for this guide do not establish a dependable cache duration.