Social Preview Cache Guide: Facebook, WhatsApp, LinkedIn, X, Slack and Discord
A social preview has two parts: the metadata and image your site serves, and the copy a platform keeps after crawling your page. Fixing the first does not automatically clear the second.
This is the compact platform map for diagnosing an old, missing or cropped product preview.
Platform comparison
| Platform | What you control | Refresh reality |
|---|---|---|
Public HTML, og:image, image URL and page cache |
Facebook supports re-scraping through the Sharing Debugger and its documented scrape endpoint. FastOG can request a Facebook refresh when configured. | |
| The next public HTML and image response | No public preview-refresh API. Cached previews are controlled by WhatsApp and can differ by recipient. | |
| Public HTML and image response | No documented programmatic invalidation endpoint. LinkedIn decides when to crawl again. | |
| X | Public HTML, twitter:image and fallback Open Graph tags |
No documented programmatic invalidation endpoint. X decides when to crawl again. |
| Slack | Public HTML and image response | Slack caches unfurls for shared URLs; the application cannot force every existing message to be rebuilt. |
| Discord | Public HTML and image response | Discord caches embeds for shared URLs; the application cannot rewrite an existing embed everywhere. |
Platform behavior and endpoints change. Treat the table as an operational boundary, not a promise about refresh timing.
Diagnose the origin first
Before blaming a platform, inspect the page a crawler receives:
curl -s https://example.com/product/example | grep -Ei 'og:image|og:title|twitter:image'
Then fetch the image URL from the response:
curl -I "https://cdn.example.com/cover.png"
The page should expose current metadata, the image URL should be public, and the image response should return a supported image content type with 200 OK. If the page cache serves old HTML, no platform can discover the new cover.
Why changing the image URL helps
Social platforms cache the page URL, and they may also cache the image URL. A dynamic cover should therefore use a new image URL when the product data changes. The product permalink remains canonical while the image cache key changes.
Adding ?v=2 to the product permalink can make a test look fresh, but it creates a second address for the same product and can split analytics and sharing history. Version the image URL instead when possible.
Facebook is the exception
Facebook is the only platform in this guide for which FastOG offers an active re-scrape path. When enabled, a product update can queue a request to Meta's scrape endpoint for that product URL. It is queued and best-effort, so a rate limit or temporary Meta error does not prevent the store from serving the correct metadata.
This does not refresh WhatsApp, LinkedIn, X, Slack or Discord. Do not describe a Facebook re-scrape as a universal social-cache purge.
A practical order of operations
- Fetch the live page and confirm the current tags.
- Purge the site's page cache or CDN if the tags are old.
- Confirm the image URL is public and returns an image.
- Change the image URL when the image bytes changed.
- Use Facebook's debugger or configured re-scrape path for Facebook.
- For other platforms, wait for a new crawl or share a URL that has not already been cached. Do not promise an exact delay.
The Free OG Image Tester can fetch a product URL and show the crawler-visible metadata alongside a generated cover. It is useful for separating a store-side problem from a platform-side cache.
FAQ
Can one plugin refresh every social preview?
No. A plugin can control the HTML and image URL served by the site. Each platform controls its own crawler and cache.
Why does the preview look correct on Facebook but old on WhatsApp?
The platforms maintain separate caches. A Facebook re-scrape changes Facebook's copy only; WhatsApp keeps its own recipient-specific preview.
Should I change the product URL after every price update?
Usually no. Keep the canonical product URL stable and change the generated image URL when the cover content changes. Changing the page URL is a blunt cache-busting workaround with SEO and analytics costs.
Does a new image URL guarantee an immediate WhatsApp update?
No. It guarantees that the next fetch of that image URL can receive new bytes. It does not force WhatsApp to fetch the page or replace a preview already stored in a recipient's app.
Related
Try it free — no signup required
Preview and test dynamic OG images in seconds.
Open the Free OG Image Tester