Wrong Image When You Share a Link on Facebook or LinkedIn? Fix Open Graph

You share a link to your website on Facebook, LinkedIn, X, WhatsApp or Slack and the preview card is wrong. It shows last year’s picture, your logo squashed into a corner, a random image from the footer, a stock photo from a plugin, or a gray box with no image at all. You changed the image on the page, but the preview refuses to update.

Two separate things cause this, and you usually need to fix both. First, the page has to tell the platforms which image to use, through Open Graph tags in the page’s HTML. Second, every platform keeps a copy of what it found the first time someone shared the link, and keeps showing that copy until you ask it to look again. This guide is for site owners, designers and marketers. It needs no server access.

What is happening

When a link is pasted into a social network or chat app, the platform’s crawler fetches the page and reads tags in the <head>. The format most of them read is the Open Graph protocol, defined at ogp.me. A typical set looks like this:

<meta property="og:title" content="Spring Menu at Example Cafe" />
<meta property="og:description" content="Five new dishes, available from March." />
<meta property="og:type" content="article" />
<meta property="og:url" content="https://example.com/spring-menu/" />
<meta property="og:image" content="https://example.com/wp-content/uploads/spring-share.jpg" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta property="og:image:alt" content="A table of spring dishes" />

The Open Graph protocol lists og:title, og:type, og:image and og:url as the basic properties every page should have. The width, height and alt properties describe the image tag that comes immediately before them.

X reads its own twitter: tags first, such as twitter:card set to summary_large_image, and falls back to the Open Graph tags for anything missing. LinkedIn, Facebook, WhatsApp, Slack, Discord and most chat apps read Open Graph.

If there is no og:image, the platform guesses, usually by grabbing some image from the page. That guess is where the random footer badge or the squashed logo comes from.

What you see	Most likely cause	Go to
The old image, even after you changed it	The platform’s cached copy, or your own page cache serving old HTML	Step 4 and Step 5
A random image from the page, or your logo	No og:image tag, so the platform guessed	Step 2
A different image each time, or the wrong one of two	Duplicate Open Graph tags from two plugins or the theme	Step 2
No image at all, just text	The image is too small, the wrong format, blocked, or the URL is broken	Step 3
A tiny square thumbnail instead of a wide card	The image is below the size the platform needs for a large preview, or X is set to the small summary card	Step 3
Right image on Facebook, wrong on LinkedIn	Each platform has its own cache; you refreshed one but not the other	Step 4

Step 1: See what the platforms see

Start with the official debugging tools. They fetch your page with the platform’s own crawler and show exactly what it read.

• Facebook Sharing Debugger (developers.facebook.com/tools/debug/): you need to be logged in to Facebook. Paste the URL and click Debug. It shows the preview, the time it last scraped the page, every Open Graph property it found, and warnings. The same preview is used for Facebook and, in practice, is the best quick proxy for other Meta apps.
• LinkedIn Post Inspector (linkedin.com/post-inspector/): you need to be logged in to LinkedIn. Paste the URL and click Inspect. It shows the preview LinkedIn will build and the properties it used.
• X: X removed the preview from its old Card Validator. The practical test is to paste the link into a new post and look at the card in the composer without posting it.

Read the warnings in the Facebook debugger carefully. The common ones mean:

Warning	Meaning
Inferred Property: The ‘og:image’ property should be explicitly provided	There is no og:image. Facebook picked an image itself. Add the tag.
Provided og:image URL … could not be processed as an image because it has an invalid content type	The image URL returned something that is not an image, often an HTML error page, a login page or a firewall challenge.
Bad Response Code	Facebook’s crawler got an error status from your page. A firewall, a maintenance plugin or a redirect loop is usually the reason.
The following required properties are missing: fb:app_id	Only matters if you use Facebook’s developer features such as Insights for your domain. For ordinary sharing it can be ignored.

Step 2: Check the tags in your page

Open the page in a private window, right-click, choose View page source, and press Ctrl+F (Cmd+F on a Mac) to search for og:image. Or run this on your computer:

curl -sL https://example.com/your-page/ | grep -iE 'property="og:|name="twitter:'

What the flags do: -s hides progress, -L follows redirects, and grep -iE prints every line containing an Open Graph or Twitter tag, ignoring case. Replace the URL with the page you are sharing. On Windows PowerShell type curl.exe, or use the View page source method. If the tags are minified onto one line, the output will be one long line; search it for og:image.

Good output: exactly one og:image with a full https:// address to the picture you expect, plus a title, description and URL. Bad output:

• No og:image at all. Nothing is generating the tags, or the page has no image set. Install or configure one SEO plugin and set a share image.
• Two or more og:image or og:title tags from different sources. Two tools are both writing Open Graph. Platforms handle duplicates differently, so the result looks random. Usual pairs: an SEO plugin plus Jetpack, an SEO plugin plus a social sharing plugin, or an SEO plugin plus a theme or page builder with its own “social meta” option. Keep one and switch the feature off in the others.
• A relative path such as /wp-content/uploads/image.jpg. Open Graph images must be absolute URLs including https:// and the domain.
• A staging or old domain in the image URL, left over from a migration. Fix the site address and run a search and replace as described in WordPress redirecting to the old domain after migration.
• An http:// image URL on an https site. Some platforms refuse it. See mixed content on an HTTPS site.

Where to set the share image in WordPress

Most SEO plugins, including Yoast SEO, Rank Math, All in One SEO, SEOPress and The SEO Framework, output Open Graph and Twitter tags and give you two levels of control. Exact menu names differ, so look for these two places in yours:

1. A site-wide default image in the plugin’s social or general settings, used when a page has nothing more specific.
2. A per-page social image in the plugin’s panel under the editor, often on a tab named Social or with Facebook and X icons. If this is empty, many plugins fall back to the page’s featured image, then to the site default.

So the order of precedence is usually: per-page social image, then featured image, then site default. If the wrong image appears, check each of those three in turn for that page.

For WooCommerce products, the product image is usually used. For your home page, check whether the home page is a static page (Settings > Reading) and set the social image on that page, not only in the plugin’s home page settings, since plugins treat a static front page differently.

Step 3: Check the image itself

A correct tag pointing at an unsuitable image still fails. Use these sizes:

Platform	What its documentation asks for
Facebook	At least 1200 x 630 pixels for the best display on high resolution screens; at least 600 x 315 for the large link preview; aspect ratio close to 1.91:1; file no larger than 8 MB.
LinkedIn	At least 1200 x 627 pixels (1.91:1); 5 MB maximum, according to LinkedIn’s help page on making your website shareable, which changes from time to time.
X, large image card	2:1 aspect ratio, minimum 300 x 157, maximum 4096 x 4096; under 5 MB; JPG, PNG, WEBP or GIF (only the first frame of a GIF is used).
X, small summary card	Square (1:1), minimum 144 x 144.

One image of 1200 x 630 pixels, saved as a JPEG or PNG under about 1 MB, works well everywhere. Keep text and faces away from the edges, because some apps crop to a square or a narrower shape. Avoid SVG for share images; the platforms do not display it. Full sizes for every platform, plus favicon sizes, are on the social share and favicon image sizes cheat sheet.

Now check the crawler can actually download it:

curl -sI https://example.com/wp-content/uploads/spring-share.jpg
curl -sI -A "facebookexternalhit/1.1" https://example.com/wp-content/uploads/spring-share.jpg
curl -sI -A "LinkedInBot/1.0" https://example.com/wp-content/uploads/spring-share.jpg

-I fetches only headers and -A sends the crawler’s user agent name, to catch rules that block bots by name. Replace the URL with the exact og:image address from Step 2. Good output for all three: HTTP/2 200, a content-type: image/jpeg (or png, webp) line, and a content-length well under the size limits. Bad output: a 403 (a firewall, hotlink protection or a security plugin blocking crawlers), a 301 to a login page, content-type: text/html (you are getting a page, not an image), or a 404. These checks are only a hint: a real crawler comes from the platform’s own network, which your computer cannot imitate. If the debugger says it cannot fetch the image but these commands work, look at your firewall or Cloudflare security events for blocked requests from facebookexternalhit or LinkedInBot and allow them. 403 Forbidden on WordPress explains how to find the rule.

Also check the page itself returns 200 to those user agents (run the same commands on the page URL). A coming soon page, a cookie wall that replaces the whole page, or a members-only area means the crawler sees a different page from you.

Step 4: Make each platform fetch the page again

Platforms cache what they found. Changing the image on your site does nothing to a preview that was already built.

• Facebook: in the Sharing Debugger, click Scrape Again. Check the “Time Scraped” changes and the preview shows the new image. If it still shows the old image, the platform fetched an old copy of your page from your own cache; go to Step 5, then scrape again.
• LinkedIn: running the URL through Post Inspector makes LinkedIn fetch it fresh. Without it, LinkedIn’s own guidance has said the first crawl is cached for about seven days. Posts that were already published keep their old preview; only new shares pick up the change.
• X: there is no manual refresh. X refetches cards periodically. Adding a harmless query string, for example ?v=2, makes it a new URL and forces a fresh fetch for a post you are about to publish. Do not use that trick for pages where duplicate URLs matter, and make sure your canonical tag points at the clean URL.
• WhatsApp, Slack, Teams and others: they also cache, and offer no public refresh tool. A query string on a new share is the usual workaround.

The first share problem: on a link nobody has shared before, Facebook sometimes shows no image on the very first share, because it downloads the image in the background. Including og:image:width and og:image:height lets it render the card immediately; most SEO plugins add these for you. Running the URL through the Sharing Debugger before you post does the same job.

Step 5: Clear your own caches

If the debugger still sees old tags after Scrape Again, your site is serving it an old copy of the page. Check the page response:

curl -sI https://example.com/your-page/ | grep -iE 'cache|age|x-litespeed|cf-cache-status'

A HIT status or a large age value means a cache served it. Purge the page in your caching plugin, your host’s cache and your CDN, then scrape again. The full map of cache layers is in WordPress changes not showing.

If you replaced the image by uploading a new file with the same file name, the platform, your CDN and the browser can all keep the old picture for a long time. Upload the new image under a new name, set it as the share image, and scrape again. This is the single most reliable fix for “the old image keeps coming back”.

Step 6: Page builders, themes and special pages

• Page builders and themes: some include their own social meta setting. If your SEO plugin handles Open Graph, switch the builder’s or theme’s version off, then recheck for duplicates with Step 2.
• Hero images set as CSS backgrounds are invisible to crawlers that guess an image, because they only look at <img> elements. That is another reason to set og:image explicitly.
• Archive, category and shop pages: SEO plugins usually have separate social settings for taxonomies and archives. Set an image there, or the site default is used.
• Multilingual sites: each language version should output its own og:url and, if useful, an og:locale. Check the plugin is translating the social fields, not only the visible content.

If none of that worked

Gather this before you ask your developer, host or plugin support for help:

• the page URL and the exact og:image URL;
• a screenshot of the Facebook Sharing Debugger result including warnings and the Time Scraped;
• the output of the grep command in Step 2 (shows duplicates) and the three image curl -sI commands in Step 3;
• which plugins, theme and builder could be outputting meta tags, and which one you intend to keep.

If the crawler is being blocked, your host or CDN can tell you which firewall rule matched. If the page looks wrong to visitors as well as to social platforms, go to the site looks broken triage page first.