How to Fix a Social Media Link Preview Showing the Wrong Image

A social media link preview showing the wrong image is usually caused by outdated Open Graph metadata, a crawler that cannot fetch the intended image, or a preview cached by the platform. This troubleshooting guide shows how to check your page, use Meta’s sharing debugger, and decide what to fix next. Platform interfaces and image specifications can change; the size guidance below is a practical starting point, not a guarantee of current requirements for every network.

Key Takeaways

• Check the page’s og:image, og:title, and og:description tags in the HTML that a crawler can access—not just what appears in your browser.
• Make sure the image URL is an absolute URL that loads publicly and returns the intended image.
• Use Meta’s sharing debugger to inspect what Meta can read and, where available, request another scrape. A new scrape does not guarantee that every platform will refresh its preview immediately.
• Use a clear, sufficiently large image. A 1200 × 630-pixel image is a common practical starting point, but check the destination platform’s current guidance before publishing.

1. Confirm Which Image the Page Declares

Open the affected page’s HTML source or inspect its rendered document and find the Open Graph tags in the <head>. A basic example looks like this:

<head>
  <title>Spring collection</title>
  <meta property="og:title" content="Explore the spring collection">
  <meta property="og:description" content="See the latest products and colors.">
  <meta property="og:image" content="https://example.com/images/spring-share.jpg">
  <meta property="og:image:alt" content="A selection of products from the spring collection">
  <meta property="og:url" content="https://example.com/spring">
</head>

Open Graph metadata gives platforms information to use when constructing a link preview. og:title supplies a title, og:description supplies a description, and og:image identifies an image. The Open Graph Protocol also defines properties such as og:url and og:image:alt.

Check that the tags belong to the page you intend to share, and that each property appears only once with the intended value. If your site uses a CMS or a social-sharing plugin, check its page-level settings as well as the theme or template: one source may override another.

If the page is JavaScript-rendered, compare the HTML delivered to a crawler with the version you see after the page loads in a browser. A crawler may not see metadata added later by client-side JavaScript. Server-rendered or statically generated metadata is generally easier for link-preview crawlers to read.

2. Inspect the Page with Meta’s Sharing Debugger

Meta’s relevant public tool is commonly called the Sharing Debugger. It is sometimes referred to informally as a graph or link inspector. Enter the page URL in Meta’s Sharing Debugger to see the information Meta can retrieve and identify issues such as missing or unreadable Open Graph properties.

A practical check:

1. Enter the exact URL you plan to share, including any relevant path or query string.
2. Review the reported title, description, image, and fetch or scrape diagnostics.
3. If the tool offers an option to scrape the URL again, use it after fixing the page and then inspect the result.
4. Open the reported image URL directly in a private browser window. Confirm it returns the intended image without requiring a login, cookies, or a special browser session.
5. Recheck the page after publishing the fix. A debugger’s result describes what that tool fetched; it does not guarantee an immediate refresh everywhere the URL has been shared.

Labels and controls in Meta’s interface may change. If the page cannot be fetched, investigate the diagnostic message, redirects, and server logs rather than repeatedly requesting a scrape without fixing the underlying problem.

3. Check the Image URL and File

The value of og:image should point to the image you want displayed. Prefer a complete HTTPS URL, such as https://example.com/images/share.jpg, rather than a relative path like /images/share.jpg.

Check these common failure points:

• Wrong image path: The URL points to an old, default, or unrelated image.
• Access restrictions: The image requires authentication, a cookie, or an approved browser session.
• Blocked crawler requests: A firewall, bot filter, CDN rule, or robots.txt policy may prevent a platform’s crawler from retrieving the page or image.
• Unexpected response: The URL redirects to another asset, returns an error, or serves a different file than expected.
• Image changed at the same URL: A browser or platform may still have a cached copy of the previous file.

For a quick check, open the image URL directly and confirm the visible image is correct. If you can use a terminal, inspect the response headers too:

curl -I 'https://example.com/images/share.jpg'

Look for a successful response and an image content type. A successful check from your computer does not prove that Meta or another platform can fetch the asset; networks, bot rules, and geographic access can differ.

4. Choose a Preview Image That Works at Small Sizes

A preview may be cropped or displayed at different sizes depending on the platform and placement. Choose an image with the main subject near the center, avoid putting essential text close to the edges, and check how it looks when reduced to a small card.

A 1200 × 630-pixel image, with an aspect ratio close to 1.91:1, is a useful general-purpose starting point for a wide preview. It is not a universal platform requirement. Confirm the current image dimensions, file-size limits, and display guidance for each network where the link will appear; those details can change and may vary by placement.

Write meaningful alternative text for people using assistive technology. Add suitable alt text to images in the page content, and, where supported by your Open Graph implementation, provide og:image:alt for the share image. Alternative text describes the image; it does not repair an incorrect og:image URL or force a platform to display a particular crop.

5. Understand Caching Before Changing the Page Again

Preview data may be cached by social platforms. Updating the page’s metadata does not necessarily change a preview that the platform already fetched, and platforms do not all refresh on the same schedule or offer the same refresh controls.

After correcting the metadata:

1. Confirm the published page returns the new tags.
2. Confirm the image itself is available at the declared URL.
3. Use the destination platform’s official inspection or refresh tool if one is available. For Meta, that is the Sharing Debugger described above.
4. Allow time for the platform to update, then test the exact URL again.

Avoid changing the shared URL with random query parameters as a supposed universal cache fix. Platforms may treat a different URL as a different resource, but this can split engagement or create duplicate links; it does not correct broken metadata or guarantee a new preview.

Common Mistakes

• Changing only the visible page: The headline or hero image in the page body may differ from the Open Graph values used for a preview.
• Testing a different URL: http versus https, www versus non-www, redirects, and query strings can lead to different fetch results. Inspect the exact link being shared.
• Assuming a successful browser load means crawler access works: A page may load for you while bot protection, authentication, or server rules block a platform.
• Expecting a debugger to update every network: Meta’s tool reports Meta’s fetch; it cannot guarantee what another service has cached.
• Treating one image dimension as mandatory everywhere: Requirements and display behavior vary. Check the current guidance for the target platform.
• Using alternative text as a preview fix: Alt text helps communicate image content; the og:image value still needs to identify the correct, accessible image.

Best Practices

• Set page-specific Open Graph title, description, and image values in your CMS or site template.
• Use an absolute, stable image URL and check that it returns the intended file without authentication.
• Keep important visual content away from image edges and preview the crop at small sizes.
• Test the exact canonical URL you publish, including its redirects.
• After a change, inspect the page and image again before requesting a platform refresh.
• Treat each platform’s debugger and image guidance as platform-specific, and recheck official guidance when requirements matter.

Conclusion

Start by checking the Open Graph tags and the image URL that the crawler can actually access. Then use Meta’s Sharing Debugger to review Meta’s fetch and request another scrape if the option is available. If the metadata and image are correct, caching may explain why an older preview remains visible; a refresh request can help, but it is not a guarantee of an immediate update across platforms.

References

• The Open Graph protocol — protocol overview and definitions of Open Graph properties.
• Meta Sharing Debugger — Meta’s tool for inspecting how a URL is fetched for sharing.

Platform-specific image requirements and debugger interfaces can change. They were not independently checked against current platform guidance for this article, so verify the latest official specifications for the networks where you publish.