You update a page, share the link on WhatsApp or Facebook, and the old title and image show up anyway - sometimes an image from a post you deleted months ago. Nothing's actually broken on your server. The problem lives on the social platform's side, in a cache you don't control, and fixing it takes a different approach than clearing your own cache.
Why this isn't a hosting or WordPress bug
When you paste a link into Facebook, WhatsApp, LinkedIn, or Slack, that platform's crawler fetches your page once, reads the Open Graph tags in your <head>, and stores the result. Every future share of that same URL pulls from their cached copy, not your live page. Some platforms hold that cache for weeks. WhatsApp is notorious for holding it almost indefinitely on mobile, because the preview is often cached per-device as well as per-server.
So three different problems get lumped together under "wrong preview image," and each needs its own fix:
- The tags are fine, but the platform's cached copy is stale.
- The tags are missing, broken, or point to an image the crawler can't reach.
- The tags exist but conflict - two plugins or a theme are each writing their own
og:title, and the crawler picks the wrong one.
Symptom: you changed the image or title, but shares still show the old one
Cause: the platform's crawler cache, not anything on your site. This is almost always the answer when the page looks correct in your browser and in "view source," but wrong when shared.
Fix: force each platform to re-scrape the URL using its own debugging tool. You have to do this per platform - clearing one doesn't clear the others.
| Platform | Tool | What it does |
|---|---|---|
| Facebook / Instagram / Messenger | Sharing Debugger (developers.facebook.com/tools/debug) | Paste the URL, click "Scrape Again" - this refetches and re-caches immediately. |
| Post Inspector (linkedin.com/post-inspector) | Paste the URL and it forces a fresh fetch before you post. | |
| Twitter / X | No public tool anymore | Add a harmless query string (see below) to force a fresh fetch. |
| No debugger at all | Uses Facebook's crawler under the hood - clearing the Facebook cache usually fixes WhatsApp previews too, eventually. | |
| Slack | No public tool | Unfurls re-check periodically; a query-string trick forces it sooner. |
For platforms with no debugger, the reliable workaround is to share a slightly different URL, like yoursite.com/page/?ref=1. To the crawler this is a brand-new URL with no cache, so it fetches fresh tags. It's a workaround, not a real fix, but it gets an urgent share looking right in the next five minutes instead of the next five days.
Symptom: no image shows at all, or a random unrelated one
Cause: usually one of these, in rough order of likelihood:
- No
og:imagetag is being output at all - check with "View Page Source" (not just DevTools, which shows the rendered DOM after JS runs and can mislead you). - The image URL in the tag is a relative path (
/wp-content/uploads/photo.jpg) instead of a full absolute URL. Crawlers need the fullhttps://address. - The image is smaller than roughly 200x200px, or its aspect ratio is too extreme - most platforms silently reject images below their minimum and fall back to nothing, or grab the next image on the page.
- Hotlink protection or a firewall rule (ModSecurity, Cloudflare) is blocking the crawler's user-agent from fetching the image directly.
Fix:
- Right-click the page, choose "View Page Source," and search for
og:image. Confirm it's a full URL starting withhttps://. - Open that exact image URL in an incognito window - if it doesn't load or downloads instead of displaying, that's your problem, not the meta tag.
- Aim for at least 1200x630px for the image - that's the size Facebook and LinkedIn actually use, and anything smaller gets upscaled or dropped.
- If you have hotlink protection enabled in cPanel, add an exception for empty referrers and for known crawler ranges, or temporarily disable it to confirm that's the cause before rewriting rules.
On WordPress, an SEO plugin (Yoast, RankMath, All in One SEO) normally generates these tags automatically from your featured image. If the tag is missing entirely, check that the plugin's social/Open Graph module is actually turned on - some plugins ship it disabled by default.
Symptom: right image, but the wrong title or description
Cause: more than one thing on the page is writing Open Graph tags - an SEO plugin, a separate "social share" plugin, and sometimes the theme itself. Crawlers use whichever tag appears first in the <head>, which is often not the one you meant to control.
Fix: view source and search for every instance of og:title. If you see it twice, you have a conflict:
<meta property="og:title" content="Old title from theme" />
<meta property="og:title" content="Correct title from Yoast" />Deactivate the redundant plugin, or check its settings for an option like "disable Open Graph output" if you need to keep it active for other features. Only one plugin should ever own social meta tags on a given site.
Prevention checklist
| Practice | Why it helps |
|---|---|
| Use one SEO plugin only, and let it own Open Graph output | Avoids duplicate/conflicting tags silently picking the wrong one |
| Set a site-wide default social image in your SEO plugin | Pages without a featured image still get a real preview instead of nothing |
| Keep social images at 1200x630px minimum | Matches what Facebook/LinkedIn actually expect - avoids silent rejection |
| Re-scrape with the Facebook Debugger right after any major content update | Their cache won't refresh on its own for days or weeks |
| Test with a real share, not just DevTools | DevTools shows post-JavaScript DOM, which can hide what crawlers actually see |
If images look right everywhere except one specific plugin's preview (say, a WhatsApp Business catalog or a Slack unfurl), that's almost always that platform's own longer cache window - give it a day before assuming your fix didn't work.
Quick way to check your tags right now
From the command line, you can pull just the meta tags without opening a browser:
curl -s https://yoursite.com/your-page/ | grep -i 'og:'That shows exactly what a crawler sees on first fetch - handy for confirming a fix before you burn a "Scrape Again" click on the Facebook Debugger.