Link Preview Shows the Wrong Image
You share a link and the preview displays an image you didn't intend — a random photo from the page, a logo, an outdated banner, or an image from a completely different page. The root cause is almost always a tagging issue, a cache issue, or both.
Common Causes
1. Multiple og:image tags in the HTML — Most platforms use the first og:image tag they encounter. If your CMS, theme, or an SEO plugin injects its own og:image before yours, that one wins.
2. Cached old image — The platform scraped your page before you updated the OG image and is still serving the old version. Facebook caches for up to 30 days, LinkedIn for about 7 days.
3. Missing og:image entirely — When no og:image tag is present, platforms fall back to scanning the page for the largest image. This is unpredictable — they might pick a sidebar ad, a profile photo, or a decorative graphic.
4. CDN serving a stale version — Your origin server has the new image, but the CDN edge node is still serving the old file. The platform crawler hits the CDN, gets the outdated image.
5. og:image URL points to the wrong file — A typo in the filename, a copy-paste error from another page, or a template variable that didn't resolve correctly.
6. Plugin or theme conflict generating duplicate OG tags — Common in WordPress: Yoast SEO, Rank Math, your theme, and a social sharing plugin all output their own set of OG tags. The result is 2-4 competing og:image declarations.
How to Fix
Step 1: Identify what the crawler sees. Open your page in a browser and view the raw source (View Page Source, not DevTools). Search for og:image. Count how many times it appears. If there's more than one, that's your problem.
<!-- This is what you want: one og:image tag -->
<meta property="og:image" content="https://example.com/images/correct-image.jpg" />Step 2: Remove duplicate OG tags. If you find multiple og:image tags:
WordPress: Check which plugins output OG tags. Go to each plugin's settings and disable OG tag output for all except one. Common offenders: Yoast SEO, Rank Math, All in One SEO, Jetpack, social sharing plugins, and some themes.
Custom CMS / static site: Search your templates for og:image. Check layout files, header partials, and any included snippets.
Server-side injection: Some hosting providers or CDNs inject meta tags. Check if your host adds anything to the <head>.
Step 3: Verify the correct image URL. Copy the og:image URL and open it directly in your browser. Confirm it loads the image you expect, it doesn't redirect, it uses HTTPS, and the file isn't outdated (check the visual content, not just the URL).
Step 4: Purge the CDN cache. If your image is served through a CDN (Cloudflare, AWS CloudFront, Fastly, etc.), purge the specific image URL from the CDN cache. Alternatively, deploy the new image with a new filename (e.g., preview-v2.jpg) and update the og:image tag to match. Verify the CDN is serving the new file by fetching the image URL with curl -I and checking the response headers.
Step 5: Clear the platform cache.
Facebook: Go to the Sharing Debugger, enter your page URL, and click "Scrape Again" — click it twice if the first scrape still shows the old image. Verify the "og:image" field shows the correct image.
LinkedIn: Go to the Post Inspector, enter your page URL, and click "Inspect" — this forces a re-scrape.
Twitter/X: Post the URL in a draft tweet (don't publish) — the card preview will trigger a re-crawl. Wait 1-2 minutes, then check the preview again. Twitter/X caches for about 7 days.
WhatsApp: There's no official debugger. Append a query parameter to the URL (e.g., ?v=2) to force WhatsApp to treat it as a new URL. On iOS, delete the conversation containing the old link, then re-share. On Android, clear WhatsApp's app cache in system settings.
Step 6: Verify the fix. After clearing caches, share the link again on each platform. Confirm the correct image appears. If it doesn't, go back to Step 1 and check the source again — the platform debugger output tells you exactly which tags it found.
Platform-Specific Notes
Facebook uses the first og:image tag in the HTML. If a plugin outputs a tag before your intended one, Facebook picks the plugin's image. The Sharing Debugger shows you exactly which image it found and its position in the HTML.
LinkedIn is particularly strict about redirects. If the image URL redirects (even HTTPS to HTTPS), LinkedIn may fail to load it and fall back to scanning the page. Use a direct, non-redirecting URL.
Twitter/X checks for twitter:image first, then falls back to og:image. If you have a twitter:image pointing to the wrong file while og:image is correct, Twitter/X will show the wrong one.
WhatsApp caches aggressively on-device. Even after fixing the server-side issue, recipients may see the old image until their local cache clears.
Prevention Checklist
Follow these steps to avoid wrong-image issues in the future:
Only one og:image tag per page — audit your HTML source. Disable OG tag output in all plugins except one. Use a unique, descriptive filename for each page's OG image (not preview.jpg for every page). Set up a deploy step that purges CDN cache for changed images. After every OG image change, run the page through Facebook Sharing Debugger and LinkedIn Post Inspector. Include og:image:width and og:image:height to avoid asynchronous processing issues. Monitor with an automated OG tag checker if you manage many pages.
FAQ
Already-shared posts on Facebook do not update retroactively. The cached preview is locked to that specific share. Only new shares of the same URL will show the updated image. There is no way to update the image on an existing post without deleting and re-sharing it.
Another plugin, theme, or server-side process is injecting a competing og:image tag. View the raw page source and search for all instances of og:image. The first one in the HTML is the one platforms will use.
Yes. Use og:image for Facebook, LinkedIn, and WhatsApp. Use twitter:image for Twitter/X. Each platform respects its own tag first and falls back to og:image if its specific tag isn't found.