Fix Facebook Sharing the Wrong Image with the Debugger

When a WordPress page shows the wrong photo, a stale thumbnail, or no image at all on Facebook, the cause is almost always one of two things: the page's og:image tag is missing, wrong, or unreachable, or Facebook already scraped the URL once and cached the result. The fix is Meta's Facebook Sharing Debugger at developers.facebook.com/tools/debug/ — paste the URL, read what it found, and click "Scrape Again" to force a fresh fetch.

Why Facebook Shows the Wrong or Missing Image

There is no `og:image` tag, or it points to the wrong file

Facebook's crawler reads Open Graph meta tags in the page head — og:title, og:description, and og:image. If og:image is absent, Facebook guesses an image from the page content, which is why an unrelated logo or an ad thumbnail sometimes appears instead of the intended photo. If the tag exists but references a URL that 404s, redirects elsewhere, or was deleted after a media library cleanup, the preview breaks the same way.

Facebook already cached an old scrape

Facebook scrapes a URL the first time it's shared and stores the result — title, description, and image — against that exact URL. Editing the post or fixing the og:image tag afterward does not update what Facebook shows, because it isn't re-reading the page on every share. It serves the cached preview until something forces a re-scrape.

Redirects and HTTP/HTTPS mismatches

If a shared URL redirects (http:// to https://, a trailing slash change, www to non-www, or a permalink structure change), Facebook may cache the preview under a different canonical URL than the one people are actually sharing, or fail to follow a redirect chain that's too long. A canonical tag pointing to a different URL than the one being shared can cause the same confusion.

Lazy-loaded or blocked images

Facebook's crawler does not execute JavaScript, so an image that only loads via a lazy-load script, or one referenced through a data-src attribute instead of src, will not be picked up as og:image unless a plugin explicitly sets the tag to the real, final image URL. If the image sits behind a login wall, an IP allowlist, or a security rule that treats unfamiliar crawlers as bots, Facebook can't fetch it and shows nothing or falls back to a default.

Theme or plugin changes removed the tags

An SEO plugin update, a theme switch, or a caching plugin serving an old cached HTML fragment can result in og:image silently disappearing or reverting to a placeholder from before the current content existed. This is common enough after a site migration that it's worth checking the debugger as a standard step — see how it fits alongside a broader move in migrating a site to new hosting.

Walking Through the Facebook Sharing Debugger

Go to developers.facebook.com/tools/debug/ and log in with a Facebook account that has developer access (Meta requires this even for basic scraping).
Paste the exact URL being shared — including the protocol and any trailing slash — and click "Debug."
Read the Link Preview panel on the right. It shows exactly what Facebook currently has cached: which image, title, and description will render when someone pastes that link into a post.
Check the Warnings and Errors list above it. Common messages flag a missing og:image, an image below the minimum size, too many Open Graph tags of the same type, or an inaccessible image URL. Each warning names the specific property involved, narrowing down where to look in the page source.
Click Scrape Again. This forces Facebook to discard its cached copy and re-fetch the URL right now, pulling in whatever og:image, og:title, and og:description currently exist on the live page.
Re-check the Link Preview panel. If the correct image now appears, the fix is done. If it's still wrong, the live page — not Facebook's cache — is serving the wrong tag, which points back to the SEO plugin configuration or the image URL itself.

The `og:image` Requirements That Actually Matter

Facebook has specific expectations for the image it displays, and violating them causes it to shrink the preview, crop oddly, or skip the image entirely:

Recommended size: 1200×630 pixels (roughly a 1.91:1 ratio). Smaller images still work but render as a small square thumbnail instead of the large preview.
Minimum size: 200×200 pixels. Below this, Facebook may reject the image outright.
Absolute URL: og:image must be a full URL starting with https://, not a relative path like /wp-content/uploads/photo.jpg, which won't resolve for the crawler.
Publicly reachable: the image must load without authentication, without a firewall rule blocking the request, and without depending on cookies or a session. A staging environment or a security plugin restricting access by user agent can cause the crawler request to fail even though the image loads fine in a browser.

How WordPress SEO Plugins Set These Tags

Yoast SEO, Rank Math, and All in One SEO all generate Open Graph tags automatically, usually pulling og:image from the post's featured image unless a "Social Image" field is set manually in that plugin's metabox. Most also support a site-wide fallback image, used when a post has no featured image.

Conflicts show up when more than one source outputs Open Graph tags on the same page — for example, a theme that hardcodes an og:image tag in its header alongside an SEO plugin doing the same thing, or a social sharing plugin adding its own tags. When duplicate og:image tags exist, which one Facebook uses isn't guaranteed. Viewing page source and searching for og:image is the fastest way to spot duplicates before troubleshooting further. Plugin updates are a common way these conflicts get reintroduced, which is one reason WordPress maintenance usually includes a check of front-end output after major updates, not just the admin screens.

Batch Re-Scraping Many URLs

The Sharing Debugger's web UI only handles one URL at a time, which is slow after a bulk theme change, a domain migration, or a site-wide image resize. Facebook's Graph API scrape endpoint can be called directly instead: a POST request to https://graph.facebook.com/?id={url}&scrape=true triggers the same cache-clearing action as clicking "Scrape Again." The API requires an access token — a temporary one is available from any Meta app via the Graph API Explorer — and with a token set, the call can be looped over a list of URLs from the command line:

TOKEN="your-access-token"
for url in $(cat urls.txt); do
  curl -s -X POST "https://graph.facebook.com/?id=${url}&scrape=true&access_token=${TOKEN}"
  sleep 1
done

Still run any page that shows a warning through the debugger UI afterward, since the API response doesn't surface the same readable error list.

How Nova Handles This

Open Graph tags and social previews are a WordPress content and plugin concern, not an infrastructure one, so WordPress support is the right path when an SEO plugin, theme, or caching layer is dropping og:image unexpectedly. Nova's managed updates apply plugin and core updates in a controlled way, and daily GCS backups make it straightforward to roll a site back if a theme or plugin change turns out to have broken the tags in the first place.

FAQ

How long does Facebook cache a link preview?

Facebook doesn't publish a fixed expiration. In practice a cached preview can persist anywhere from about a day to several weeks, which is why editing the page alone doesn't fix an already-shared link — a manual "Scrape Again" is what forces the update.

Why is the image still wrong even after I scrape again?

If the debugger still shows the wrong image after scraping, the live page is serving that image in og:image, not Facebook's cache. Check page source for duplicate or stale tags, confirm a page caching plugin isn't serving an old HTML snapshot, and verify the SEO plugin's social image field for that specific post.

Does this same problem affect LinkedIn and Twitter/X?

Yes, each platform caches independently with its own tool: LinkedIn has its Post Inspector, and X reads similar tags but caches separately. Re-scraping on Facebook does not clear LinkedIn's or X's cache — each needs its own refresh.

Can I stop Facebook from picking a random image when og:image is missing?

Yes — set an explicit og:image tag, either directly, through an SEO plugin's social image field, or via a site-wide fallback image in that plugin's settings, so Facebook always has a defined image instead of guessing from page content.