rdyrct
Dashboard
← All articles

How to Fix WhatsApp Link Previews for Branded Short URLs

Getting WhatsApp to show a correct preview for a shortened or branded link comes down to four things: static Open Graph tags placed early in the <head>, HTTPS on both the page and the image with no redirects in the way, a cache-busting query parameter when a preview goes stale, and a redirect chain that doesn’t strip your OG data along the way.

Here’s the fast version before the technical detail:

  • Confirm og:title, og:description, og:image, and og:url exist in the raw HTML, not injected by JavaScript.
  • Serve the page and the image over HTTPS with direct 200 responses, no redirect hops.
  • If WhatsApp shows an old preview, add a version parameter like ?v=2 or change the short path entirely.
  • With Rdyrct, make sure your redirect lands on a page with the correct OG tags intact, and let Rdyrct’s analytics track clicks and devices without ever storing IP addresses.

Key Takeaways

WhatsApp link previews depend on static, early-placed Open Graph tags served over HTTPS with no redirect interference, and stale previews require a cache-busting URL change rather than a cache-clearing tool that doesn’t exist.

Point Details
Static tags only og:title, og:description, og:image, and og:url must exist in raw HTML, never injected by JavaScript.
HTTPS with no redirects Both the page and the image need direct 200 responses over HTTPS.
Cache-busting fixes stale previews Add a versioned query parameter or change the short path since no global cache tool exists.
Client-side fetch means IP exposure WhatsApp mobile fetches previews from the sender’s device, exposing IP data to the landing server.
Rdyrct preserves OG through redirects Rdyrct keeps canonical og:url and query parameters intact while tracking clicks without storing IP addresses.

Table of Contents

Run this before any link goes into a campaign, a newsletter, or a client message. It takes about five minutes and catches the vast majority of preview failures.

  1. Page loads over HTTPS, with a valid certificate.
  2. og:title, og:description, og:image, and og:url all exist in the static HTML source.
  3. Those four tags sit early in <head>, before large stylesheets or scripts.
  4. og:image is an absolute URL (not /images/preview.jpg), returns a 200 status, and isn’t behind a redirect.
  5. The image is a JPEG or PNG, sized appropriately, and under WhatsApp’s practical file size limits.
  6. Nothing in the OG block depends on JavaScript rendering.
  7. The link has been tested fresh on iOS, Android, and WhatsApp Web separately.
  8. If the link runs through a shortener, the final redirect target carries the correct og:url, not a placeholder.

Pro Tip: Keep a saved test checklist in your campaign brief template. The five minutes you spend on QA now saves the “why doesn’t my link show a picture” scramble an hour before a launch.

WhatsApp’s mobile apps fetch the destination URL directly from the sender’s phone to build the preview, not from a centralized Meta server. That’s a meaningfully different model than what most marketers assume, and it explains a lot of the weird inconsistency you’ve probably run into.

  • On iOS and Android, the preview request originates on-device, the moment you paste a link into the composer.
  • WhatsApp Web appears to lean more on server-side crawling through Meta’s own infrastructure, which is why a link can render differently there than it does on your phone.
  • Each platform caches what it fetches independently. A stale preview on your Android phone won’t magically refresh just because someone else on iOS sees the new one.

There’s a privacy angle here that’s easy to miss. Because the fetch happens client-side on mobile, the sender’s IP address can be visible to your landing server during that fetch, a trade-off inherent to how WhatsApp generates previews without breaking end-to-end encryption. WhatsApp also has no public tool for clearing cached previews, unlike Facebook’s Sharing Debugger. If a preview is wrong, your only real lever is changing the URL itself.

WhatsApp’s parser is unforgiving in a specific way: it reads static HTML, it reads it early, and it doesn’t wait around for scripts to finish running.

The minimum viable tag set is og:title, og:description, og:image, and og:url, and all four need to appear as plain, server-rendered HTML. If your site builds meta tags with client-side JavaScript, WhatsApp’s crawler often won’t see them at all, because it isn’t executing your JS the way a browser does.

Placement matters almost as much as presence. Put those four tags high in <head>, ahead of large inline stylesheets or script blocks. WhatsApp’s parser reads only the first chunk of a page’s HTML, so burying your OG tags under a mountain of CSS can push them outside its reading window.

Requirement Specification
Page protocol HTTPS, direct 200 response, no redirect chain
Image protocol Absolute HTTPS URL, direct 200 response
Image format JPEG or PNG
Image dimensions 1,200 by 630 pixels or larger recommended
Image file size Kept reasonably small for quality and performance
Tag rendering Static HTML only, no JavaScript-injected tags
Tag placement Early in <head>, before heavy CSS or scripts

A few things trip up developers repeatedly. If your og:image URL redirects to a CDN path instead of resolving directly, WhatsApp’s fetcher can fail to render an image at all. The same goes for the page URL itself: a redirect chain that bounces through two or three hops before landing on the final page increases the odds that WhatsApp gives up or grabs the wrong metadata. And because WhatsApp truncates titles and descriptions aggressively, front-load your most important words in the first several characters of each tag.

How Do You Fix a WhatsApp Preview That Won’t Update?

When a preview shows the wrong image, an old headline, or nothing at all, work through this in order rather than guessing:

  1. Paste the link into a fresh WhatsApp message on two or three different devices, and give it about 10 seconds to render before assuming it’s broken.
  2. Check whether the issue is device-specific. If it looks fine on WhatsApp Web but wrong on your phone, you’re dealing with a caching difference, not a broken tag.
  3. Add a versioned query string, ?v=2 or similar, or switch to a new short path entirely. This forces WhatsApp to treat it as an unseen URL and fetch fresh metadata.
  4. Verify the raw server response for both the page and the image using curl -I. You want a clean 200 status, the right content type, and no redirect headers.
  5. If your CMS or CDN takes time to propagate metadata changes, test against a brand-new URL rather than waiting on the old one to catch up.
  6. Rule out HTTPS certificate issues, robots or user-agent blocking, and JavaScript-only meta rendering, in that order, since these are the three most common silent failures.

Pro Tip: Bookmark a test link with a throwaway query parameter you control, like ?test=whatsappcheck, so you’re never guessing whether a stale result is really stale or just cached in your own head.

How Should You Configure Rdyrct for Reliable WhatsApp Previews?

The redirect itself is the part most people get wrong, not the OG tags. If your Rdyrct short link redirects to a page, but that redirect rewrites or drops query parameters along the way, WhatsApp can end up reading metadata from the wrong version of that page, or a stripped-down one that’s missing your intended og:url.

Set up your redirects so the final landing page carries the correct, canonical og:url, matching the page WhatsApp actually renders after following the link. Preserve any versioning or tracking parameters through the redirect chain rather than letting them get stripped, since that’s what lets you cache-bust a stale preview without also losing the campaign context those parameters carry. A 301 or 302 that rewrites your query string on the way through defeats the purpose of adding one in the first place.

If your og:image is hosted on a CDN, confirm the CDN serves it as a direct 200 response over HTTPS, not through its own internal redirect layer.

On the privacy side, this is where Rdyrct’s approach earns its keep. Rdyrct’s analytics capture referrer and device information to show you where clicks come from and what they’re using, without storing the sender’s IP address anywhere in the system. That distinction is worth documenting for a privacy or compliance team reviewing your stack, especially given that WhatsApp’s own client-side fetching model means the sender’s IP is already exposed to your landing server during preview generation. Your link shortener’s analytics don’t need to compound that exposure.

Pro Tip: Log your server response headers when debugging, using something like Cloudflare Workers, so you can see exactly what WhatsApp’s fetcher receives instead of guessing from the rendered preview alone.

Run this sequence every time you push an OG change or set up a new branded short link, not just when something looks broken:

  1. Deploy the change, then paste the link into WhatsApp’s message composer on both an iOS and an Android device, watching for the preview to render within roughly 10 seconds.
  2. Open the same link on WhatsApp Web and compare what renders there against mobile, since Web’s crawling behavior can differ.
  3. Run curl -I against both the page URL and the image URL, checking for a clean 200 status, the correct content type, and appropriate cache-control headers.
  4. Click through the link yourself and confirm in your Rdyrct dashboard that the click registered with referrer and device data, and that no IP address shows up anywhere in the record.

What Does Rdyrct’s Approach Get Right That Most Advice Misses?

Most guides on this topic treat WhatsApp previews as a pure markup problem: get your OG tags right, and you’re done. That’s incomplete. The redirect layer is where branded links actually break, and almost nobody talks about it, because most link-shortening advice was written before marketers cared about preserving metadata through a redirect chain at all.

The conventional fix, “just add OG tags,” ignores that a redirect can quietly rewrite the exact og:url WhatsApp ends up reading, or drop the query parameter you needed for cache-busting. I’d argue the redirect configuration deserves more attention than the tags themselves, since broken tags are easy to spot and broken redirects are not.

The privacy piece is the part I think gets underweighted the most. Every article on this subject mentions that WhatsApp’s client-side fetch model exposes a sender’s IP to the landing server, then moves on without asking what that means for the tracking layer sitting on top of it. If your link shortener also logs that IP for its own analytics, you’ve stacked a second exposure on top of one WhatsApp already introduced. That’s the gap worth prioritizing first: not just “does my preview look right,” but “does my tracking stack add exposure that didn’t need to exist.”

— Andrea

Get Correct Previews and Private Analytics With Rdyrct

Rdyrct is built for exactly the failure mode this article walks through: a redirect that quietly breaks your Open Graph metadata or strips the query parameter you needed for cache-busting. Rdyrct’s branded redirects preserve the final landing page’s OG tags and let you keep versioned parameters intact through the redirect chain, so a ?v=2 cache-bust survives the trip instead of getting stripped somewhere in the middle.

On the tracking side, Rdyrct’s analytics give you referrer and device breakdowns for every click without ever storing IP addresses, which matters given that WhatsApp’s own preview fetching already exposes some of that data at the client level. You get the campaign visibility without compounding the exposure. If you’re setting up a link for an email send, a podcast show-note, or an offline QR code that also needs to render cleanly in WhatsApp, start building your branded short link at Rdyrct and check the redirect against the checklist above before it goes live.

Sources