Open Graph WhatsApp Previews: How the Crawler Actually Works
Open Graph on WhatsApp behaves differently from every other platform you've already fixed a preview on, and that's the part nobody tells you. Your tags validate fine on Facebook. X shows the card correctly. Then you paste the same link into a WhatsApp chat and get a bare blue link, or a thumbnail that hasn't matched your page in months.
If you've already ruled out the obvious stuff (a missing og:image, a typo in the meta tag) and you're still stuck, the answer usually isn't in your HTML. It's in how WhatsApp's crawler is built, and what it will and won't do with the markup it finds.
I've spent a fair amount of time going through server logs for sites with broken previews, and WhatsApp shows up differently from Facebook, LinkedIn, or Slack every time. Not because it's mysterious. Because it's a Meta product running on Meta's crawling infrastructure, inherited from the 2014 Facebook acquisition of WhatsApp (announced at a headline value near 19 billion dollars, per Meta's own investor relations page), with its own stricter rules layered on top of the standard Open Graph spec.
Most WhatsApp link preview guides you'll find online are lists of numbers with no source attached. This one traces every figure back to Meta's own documentation, and says plainly where that documentation goes quiet.
How WhatsApp Actually Fetches a Link Preview
Open Graph itself is simple: four core properties in your page's head, og:title, og:type, og:image, and og:url, that any platform supporting link previews reads as a baseline. WhatsApp reads them too, but it adds its own requirements on top, and it fetches them through a crawler with its own identity, its own timing, and its own limits.
The two user agents you'll find in your logs
Here's where it gets specific, and where most competing articles just stop. Meta's own WhatsApp Business link-previews documentation gives the literal user agent string the app uses: WhatsApp/2.x.x.x A|I|N. The letter at the end tells you the platform: A for Android, I for iOS, N for WhatsApp Web (their term, not mine, but it's consistent across the doc). A real request looks something like WhatsApp/2.22.20.72 A for an Android device fetching your page.
That's one answer. The other is facebookexternalhit/1.1, which shows up because WhatsApp shares crawling infrastructure with Facebook for certain paths, most notably WhatsApp Web. Both strings travel in the same request field your server already logs for every visitor, the User-Agent header, just carrying a different identity when the requester is a link-preview crawler instead of a person.
So the honest answer to "which user agent fetches WhatsApp previews" has two parts: the app-specific string for mobile fetches, and the shared Meta crawler string for the web client. If you're filtering server logs and only search for "facebookexternalhit," you'll miss every mobile-app preview request entirely.
WhatsApp/2.22.20.72 A
WhatsApp/2.22.19.78 I
WhatsApp/2.2236.3 N
facebookexternalhit/1.1Client-side versus server-side, and why it matters for your logs
The practical difference between those two user agents traces back to where the fetch happens. Mobile app previews are widely reported to be generated on-device, meaning the phone itself requests your page and builds the card before the message sends. WhatsApp Web and the shared-infrastructure path run through Meta's servers instead, the same way facebookexternalhit does for a regular Facebook share. Meta's documentation doesn't spell this out in exactly those terms, so treat it as the best available explanation for the two-user-agent split, not a verbatim quote.
What it does explain, precisely, is what the crawler does once it lands on your page: no JavaScript execution, and a hard 10-second window. If a preview hasn't appeared above the message composer within 10 seconds, according to Meta's own doc, something in your page didn't meet the requirements in time.
That 10-second figure is specific to WhatsApp's own preview render. You'll see a roughly 5-second number floating around for facebookexternalhit generally on other platforms; that's a different, unofficial figure, and conflating the two just muddies both claims.
What "best attempt" actually means
One line in Meta's documentation deserves more attention than it gets: WhatsApp "will make the best attempt to show link previews," but this "should not be relied on. It's not guaranteed to work (and continue to work)." That's Meta, in its own words, telling you this is best-effort behavior, not a service-level guarantee. If your preview works today and breaks next month with zero changes on your end, that's consistent with how WhatsApp describes its own feature, not necessarily a bug on your page.
The WhatsApp-specific rules that trip people up
This is the part almost every competing article gets close to right but never sources. WhatsApp doesn't just read your Open Graph tags. It reads them under conditions the baseline spec never mentions, and every number below comes straight from Meta's own page, not a practitioner estimate.
Your head markup, according to Meta, "must appear within the first 300KB of the HTML." That's not a soft guideline. If your site loads a pile of inline scripts, analytics snippets, or a bloated CSS block before the og:title tag, and the whole thing pushes past 300KB before the crawler reaches your meta tags, WhatsApp may simply never see them. This is one of the more common, least-diagnosed causes of a broken preview on large ecommerce pages and CMS themes with heavy header includes.
Beyond that size cap, three more requirements matter:
- og:title, og:description, and og:url must sit inside the head tag and must not be empty. An empty string technically satisfies "the tag exists" but fails WhatsApp's rendering, which explains why some pages with a present-but-blank og:description still show nothing useful.
- Titles render at a maximum of two lines. Descriptions get one or two lines, and Meta's own guidance is that roughly 80 characters "will suffice." Longer copy gets truncated, sometimes mid-word.
- URLs should be undecorated: no session variables, no user-identifying parameters, no tracking counters tacked onto the query string.
That two-line title and roughly 80-character description limit is worth sitting with, because it means the copy you write for search engines and the copy WhatsApp will actually show are not automatically the same job. For the fuller breakdown of how og:title and og:description differ from your page's actual title tag and meta description, see the Open Graph title and description guide.
The image spec, and the number most guides get wrong
Here's the figure that gets misquoted more than any other in this niche. Search around and you'll find "300KB" repeated as gospel across half a dozen WhatsApp preview guides, none of which link to where the number came from. Meta's own documentation states the image "must be under 600KB in size," must be "300px or more in width," with a maximum aspect ratio of 4:1 width to height, and must be served as an absolute URL rather than a relative path.
600KB is the documented ceiling, not 300KB. The smaller figure that circulates is a more conservative, unofficial convention some practitioners recommend for mobile data efficiency, and it's not wrong to aim for it, but it's not what WhatsApp's own spec requires. Treat 600KB as the hard limit and anything smaller as a courtesy to users on slow connections.
If you want to check your current og:image against that ceiling, along with the width, ratio, and absolute-URL requirements above, run your page through the social preview checker, which pulls the image and grades it against the documented limits directly. If you're building the tags from scratch rather than debugging an existing page, the tag generator writes them correctly the first time, with live previews across platforms as you fill in each field.
Does robots.txt affect what WhatsApp fetches
This is the question I get asked the most, and it's the one place I'll refuse to give a clean yes or no, because Meta hasn't given one either. Their general Web Crawlers documentation says most of Meta's crawlers "should respect" robots.txt, then immediately carves out an exception: "the FacebookExternalHit crawler might bypass robots.txt when performing security or integrity checks." That page never names WhatsApp specifically, and there's no separate Meta document stating, in terms specific to WhatsApp's own crawler, whether it checks robots.txt before fetching a preview.
I've seen this claimed confidently in both directions across practitioner blogs, and neither claim cites anything. Some argue the on-device mobile fetch path doesn't go through a declared server-side crawler at all, so robots.txt may never enter the picture for those requests. Others assume WhatsApp behaves exactly like a standard facebookexternalhit fetch and respects Disallow rules the way Googlebot would.
Given that WhatsApp runs on Meta's shared infrastructure and Meta's other crawlers generally respect robots.txt with a stated security exception, the defensible position is: assume it might check, and stop guessing. Explicitly allow both WhatsApp and facebookexternalhit user agents in your robots.txt rather than leaving the door ambiguous.
User-agent: facebookexternalhit
Allow: /
User-agent: WhatsApp
Allow: /And don't guess at what your live robots.txt is actually returning right now, since a caching layer, a CDN rule, or a recent deploy can change what's actually being served without you noticing.
When it's not your tags, it's the cache
You'll occasionally fix every issue above, confirm the tags are correct with a checker, and still see the old image in WhatsApp. That's usually not a tag problem anymore. WhatsApp caches previews by the exact URL string and, unlike Facebook's Sharing Debugger or LinkedIn's Post Inspector, doesn't offer a public tool to force a re-scrape.
The common workaround is appending a throwaway query parameter (something like ?v=2 or ?refresh=1) so WhatsApp treats the link as new and fetches it fresh. It's a workaround, not a fix, and it doesn't change anything about the underlying page. For the fuller breakdown of caching behavior across platforms, that's worth its own read on the Open Graph tags and cache refresh guide.
It's also worth remembering that a WhatsApp-broken preview and a search-engine-broken snippet are two unrelated problems that happen to share a symptom. Open Graph tags don't influence how Google indexes or ranks your page; that's a separate layer of metadata entirely, closer to what a tool like indexcheck.tools checks for title and description handling in search results. Fixing your og:title won't move your ranking, and fixing your indexing won't fix your WhatsApp card. They just happen to look adjacent because both start with the same meta tags.
Checking what WhatsApp actually sees
Everything above traces back to one page: Meta's own WhatsApp Business link-previews documentation. Not a blog post repeating a number nobody sourced, not an AI summary averaging five uncredited guides together. If you're debugging a preview right now, the fastest path isn't reading more articles about the 300KB head limit or the 600KB image cap; it's seeing whether your actual page, as currently deployed, meets them. Run the URL through the social preview checker for a read on your head size, tag presence, and image spec against those documented numbers.
Frequently Asked Questions
Which user agent fetches WhatsApp previews?
Two, and you need both if you're checking server logs. Meta's WhatsApp documentation gives the app's own format as WhatsApp/2.x.x.x A|I|N, where the trailing letter marks Android, iOS, or WhatsApp Web. Alongside that, facebookexternalhit/1.1 appears for requests that route through Meta's shared crawling infrastructure, which is the path WhatsApp Web commonly uses. If you're grepping logs for one string and expecting to catch every WhatsApp preview request, you'll come up short; search for both.
What og:image size does WhatsApp want?
According to Meta's own WhatsApp Business link-previews documentation, the og:image file must be under 600KB, at least 300px wide, with a maximum aspect ratio of 4:1 (width to height), served over an absolute URL. That 600KB figure is the officially documented ceiling. The 300KB number repeated across other guides is an unofficial, more conservative practitioner convention, useful for cutting mobile data usage, but not the actual documented requirement.
Does robots.txt affect WhatsApp previews?
There's no single official Meta statement that answers this specifically for WhatsApp. Meta's general Web Crawlers documentation says its crawlers should respect robots.txt but notes facebookexternalhit "might bypass" it for security or integrity checks, and it never names WhatsApp by name. The safest practical approach is to explicitly allow the WhatsApp and facebookexternalhit user agents in your robots.txt rather than assume compliance or bypass, and to verify what your live robots.txt currently returns rather than rely on memory of a file you edited months ago.
Why does WhatsApp show only the URL?
WhatsApp falls back to a bare URL when it can't extract usable content from your page within its fetch and 10-second render window. The most common causes are empty og:title, og:description, or og:url tags, head markup that runs past the documented 300KB cutoff before the crawler reaches your meta tags, HTTP instead of HTTPS, or Open Graph tags injected by JavaScript after page load, which a non-JavaScript crawler never executes and therefore never reads.