Social Media Link Preview Shows the Wrong Image: A Debugging Checklist

A social media link preview can show an old image, the wrong image, or no image at all—even when the page looks correct in a browser. The cause is often the metadata a crawler reads, an image it cannot fetch, or a preview cached before the page was updated. Use this checklist to narrow down the problem and know what Meta’s inspection tool can—and cannot—tell you.

Key Takeaways

• Check the page’s Open Graph tags in its delivered HTML, especially og:image, og:title, and og:url.
• Make sure the image URL is publicly fetchable and leads to the intended image, including after redirects.
• Ask the relevant platform to fetch the page again; changing metadata does not necessarily refresh a cached preview immediately.
• An inspector can show what its crawler retrieved, but cannot guarantee what every user or placement will display.
• Platform image specifications can change. Confirm current requirements in the platform’s own documentation rather than relying on a universal size rule.

1. Check the Open Graph metadata the page serves

Open Graph metadata gives social platforms information to use when building a link preview. The most relevant properties are:

• og:image: the image URL to use.
• og:title: the preview title.
• og:url: the URL the page identifies as its canonical object.

A basic set of tags in the document’s <head> might look like this:

<meta property="og:title" content="A useful page title">
<meta property="og:url" content="https://example.com/article">
<meta property="og:image" content="https://example.com/images/article-share.jpg">

View the page source or inspect the HTML returned by the server. Confirm that the tags exist, contain the intended values, and are not duplicated with conflicting values. A browser’s rendered page can differ from the initial HTML: if the tags are added only by client-side JavaScript, a crawler that reads the server response may not see them.

Check og:url too. If it points to a different URL, a platform may associate the preview with that URL’s metadata or cached object. Make sure the intended canonical URL and the URL being shared are consistent with your site’s setup.

2. Verify the image URL from outside your browser

Copy the exact og:image value and open it in a private window, or check it from a machine that is not logged in to your site. The image should be available without a session, cookie, or special referrer, and the response should deliver an image rather than an HTML error page.

Check the following:

• The URL is absolute. Prefer a complete URL such as https://example.com/images/share.jpg, not a relative path.
• The response reaches the intended file. Follow redirects and confirm the final destination is the right image, not a default image, login screen, or expired signed URL.
• The file is accessible to crawlers. Look for access controls, hotlink protection, firewall rules, rate limits, or bot challenges that may treat a platform crawler differently from your browser.
• The file is a supported image. Check the response’s content type and ensure the URL does not return an HTML document with an image filename.
• The image meets current platform requirements. Dimensions, file size, and supported formats are platform-dependent and may change. Check the current documentation for the platform where the preview is wrong; do not assume one image specification works everywhere.

If the image is behind authentication, blocked by a robots or firewall rule, or served only to some visitors, the crawler may fail even though it works for you. A URL inspection tool can help you inspect a URL’s components, but it cannot establish that a social platform can fetch the image or replace server-side access checks.

3. Inspect the page with Meta’s tool

For a Facebook or other Meta-related preview, use Meta’s page-sharing inspection tool, commonly referred to as the Sharing Debugger or Graph Inspector. Enter the exact page URL that you intend to share and inspect the data Meta reports. If you have changed the page, use the tool’s available re-scrape or refresh action to request a new fetch.

Compare the reported title, URL, and image with the tags in the page source. If the inspector reports an old image, check whether the page still serves an old og:image, whether the image URL redirects, or whether the crawler has a cached result. If it reports the correct image but a post still looks different, the post may be using an older preview or a different URL than the one you inspected.

The tool is useful evidence about what Meta’s crawler retrieved for that inspection. It does not confirm that every platform uses the same tags, that every placement will render identically, or that every viewer sees the same result. It also cannot make a blocked image publicly accessible or guarantee that a cache refresh takes effect everywhere immediately. For a non-Meta platform, use that platform’s own current inspection or troubleshooting guidance.

4. Rule out redirects and URL variations

Test the exact link copied into the post—not just the page’s final address in your browser. The shared URL might pass through a redirect, use tracking parameters, or differ by trailing slash, protocol, hostname, or path. Those variations can affect what a crawler fetches or which cached preview it uses.

Follow each redirect and note the final URL. Then compare the shared URL, the final destination, and og:url. Check that redirects do not send crawlers to a different page or require a browser session. If you use query parameters for campaign tracking, test both the tracked link and the clean canonical URL rather than assuming they share the same preview cache.

5. Refresh the right cache and retest

Once the metadata and image are correct, request a fresh fetch with the platform’s inspection tool where available. Then test the exact URL again. If the preview remains wrong, work through the page URL, its metadata, the image URL and its redirects, and the platform’s reported fetch results one at a time.

Allow for caching: a successful re-scrape is not a promise that every existing post, app surface, or viewer will update at once. If you need to publish immediately, use a new, deliberately versioned image URL only when you can manage that asset safely; changing URLs may help distinguish a new resource from a cached one, but does not guarantee a platform will refresh the page preview.

Common Mistakes

• Checking only the visual page. The image visible in the article body does not determine the preview; inspect the actual og:image value.
• Assuming browser access proves crawler access. Your browser may have cookies or permissions the platform crawler does not.
• Updating the page but not re-fetching it. Cached metadata can outlive the change on your server.
• Testing a different URL. A redirect, tracking parameter, or alternate hostname can lead to a different fetch or cached object.
• Treating one inspector as universal. Meta’s result describes its own fetch, not every social network’s behavior.
• Relying on an old image-size rule. Verify current image requirements with the platform that is displaying the problem.

Best Practices

Keep one clear set of Open Graph tags in the server-delivered page HTML. Use a stable, absolute image URL that is publicly accessible and returns the intended image. After changing a preview, inspect the exact URL being shared and request a fresh fetch through the relevant platform’s tool. Record the URL tested and what the inspector reported; this makes it easier to distinguish a metadata problem from an image-delivery or caching problem.

Conclusion

When a social media link preview shows the wrong image, verify the metadata, test the exact image URL and its redirects, and inspect the exact shared page URL with the relevant platform. Treat the inspection result as a useful snapshot—not a guarantee of identical behavior everywhere—and check current platform documentation for requirements that may change.

References

• The Open Graph protocol — definitions and examples for Open Graph properties including og:title, og:url, and og:image.

Platform-specific image limits and preview behavior change over time. Confirm current Meta requirements in Meta’s official documentation and inspection tool; current limits could not be independently verified for this article.