Why Is My Link Preview Showing the Wrong Image? A Debugging Guide

A link preview can show an old image, a logo instead of your featured image, or no image at all—even when the page looks correct in a browser. The cause is often the page’s Open Graph metadata, an image the platform crawler cannot access, or a cached preview. This guide walks through how to check each one and refresh a stale preview.

Key Takeaways

• Social platforms commonly use Open Graph tags such as og:title, og:description, and og:image to build a link preview. Each platform may apply its own rules and fallbacks.
• Check the HTML returned for the exact URL you shared; a browser-rendered page can differ from what a crawler receives.
• Make the image URL absolute, publicly accessible, and suitable for a crawler to fetch without cookies or a login.
• After fixing metadata or the image, use the relevant platform’s preview inspector or cache-refresh tool. Rechecking the page alone does not necessarily refresh a cached preview.
• Platform requirements and tools can change. Confirm current requirements in the platform’s official documentation before relying on specific image limits.

How a platform chooses a preview image

Many platforms read metadata from the page’s <head> section. Open Graph defines properties including og:title, og:description, og:type, og:url, and og:image. A platform may use these values to create a preview, but it can also apply its own rules, use a fallback, or retain a previously fetched result.

For example, a page can include:

<head>
  <meta property="og:title" content="A Guide to Spring Gardening">
  <meta property="og:description" content="Practical tips for planning a productive garden.">
  <meta property="og:type" content="article">
  <meta property="og:url" content="https://www.example.com/guides/spring-gardening">
  <meta property="og:image" content="https://www.example.com/images/spring-gardening-share.jpg">
  <meta property="og:image:alt" content="Seedlings growing in a garden bed">
</head>

Use the URL that represents the canonical page for og:url, and make og:image an absolute URL. Metadata should be present in the HTML the crawler can retrieve; relying on JavaScript to add or change these tags can fail if a crawler does not render the page in the same way as a full browser.

Some platforms also read platform-specific metadata. Those tags can complement Open Graph, but they do not guarantee every platform will display the same image or text. The preview is ultimately controlled by the platform using its own crawler and rules.

A step-by-step debugging workflow

1. Check the exact URL you shared

Copy the full URL from the post, including its protocol, hostname, path, and any query parameters. A platform may treat a URL with tracking parameters, a trailing slash, or a different hostname as a separate page from the one you tested.

Check that the page loads without requiring a login and that it does not redirect to a different page unexpectedly. If it redirects, inspect the final page too: the crawler may extract metadata from the destination rather than the original URL.

2. Inspect the HTML metadata

Open the page’s source HTML—not only the browser’s Elements panel—and search for og:image, og:title, and og:description. The Elements panel shows the current document after scripts run; the original response source helps reveal what a crawler may receive before JavaScript changes the page.

You can also fetch the response from a terminal:

curl -sSL https://www.example.com/guides/spring-gardening | grep -iE 'og:(title|description|image|url)'

Replace the example URL with the exact page you shared. This is a useful check of the HTML returned to a basic HTTP client, but it does not reproduce every platform crawler’s behavior, user agent, network, or cache.

Look for common metadata problems:

• og:image is missing, misspelled, or points to an old image.
• More than one og:image tag is present, and the platform selects a different one than expected.
• A site template or plugin emits a default logo after the page-specific image tag.
• The tag exists only after JavaScript runs.
• The page’s canonical URL or redirect points to a different page with different metadata.
• A content-management system, page cache, or CDN is still serving the previous HTML.

If you find duplicate tags, fix the source that generates them rather than merely adding another tag. Then clear the relevant site or CDN cache and inspect the returned HTML again.

3. Test the image URL itself

Open the og:image URL in a private browser window or fetch it directly. It should return an image without requiring authentication, a session cookie, or a special browser referrer. A successful image load in your logged-in browser is not proof that an unauthenticated crawler can retrieve it.

A quick response-header check is:

curl -sSIL https://www.example.com/images/spring-gardening-share.jpg

Check the final response after redirects, the HTTP status, and the Content-Type. The response should provide the image itself with an appropriate image media type, not an HTML error page, a login form, or a blocked-request message. Also check that redirects do not lead to a private or inaccessible destination.

Common retrieval failures include:

• The image URL returns 403, 404, or another error to unauthenticated requests.
• A firewall, bot-protection service, hotlink rule, or CDN blocks the social crawler.
• The URL is temporary, signed, or expires before the platform fetches it.
• The server returns HTML or an incorrect content type instead of image data.
• The image host has a TLS, DNS, or redirect problem the crawler cannot resolve.
• The image is too large, too small, unusually shaped, or in a format the platform does not accept.

For broad compatibility, publishers often prepare a clear landscape share image around 1200 × 630 pixels. Treat that as a practical starting point, not a universal platform rule: accepted dimensions, file formats, file-size limits, and cropping behavior can vary and change. Keep the important subject away from the edges because previews may crop the image differently on different devices.

4. Refresh the platform’s cached preview

If the page source and image are correct but the preview is still old, the platform may have stored an earlier scrape. Use that platform’s official preview inspector or cache-refresh option to request a new fetch. For Facebook sharing, Meta’s Sharing Debugger is a commonly used place to inspect a URL and request that it be scraped again.

After requesting a refresh, inspect the result shown by the platform’s tool. If it still shows the wrong image, return to the exact metadata and image URL reported there; the tool may reveal a different URL, a fetch error, or metadata that differs from what you expected. Each platform maintains its own cache, so refreshing one platform does not necessarily refresh another.

Allow for a delay where the platform indicates one. Avoid repeatedly changing image URLs as a first response: first confirm which URL the crawler fetched and whether the source or CDN is still returning stale content.

5. Compare the platform result with the page response

Use this sequence to isolate the source of the problem:

1. The page source contains the wrong og:image: fix the template, plugin, or page metadata.
2. The source is correct, but the image request fails: fix public access, redirects, hosting, or image delivery.
3. Both are correct, but the inspector reports old data: request a fresh scrape and check page/CDN caches.
4. The inspector shows the intended image, but a post does not: confirm you shared the same URL and check whether that platform or post format has separate preview behavior.
5. One platform works and another does not: compare their fetch diagnostics and requirements; do not assume they share caches or interpret metadata identically.

Common Mistakes

• Checking only the visual page. The featured image on the page is not necessarily the og:image value.
• Using a relative image path. Prefer a complete https:// image URL so the crawler does not have to infer the host or path.
• Testing while logged in. Authentication can hide a broken public image request.
• Assuming a successful curl proves every crawler can fetch the page. It checks one request path, not a platform’s full crawler behavior or cache.
• Refreshing the website but not the platform preview. Site and social-platform caches are separate.
• Changing metadata without clearing a page cache. The source file may be updated while the live response remains old.
• Assuming image dimensions alone explain the issue. First verify that the image URL is accessible and that the crawler actually selected it.
• Expecting every platform to display an identical card. Platforms can use different metadata, fallbacks, crops, and cache states.

Best Practices

• Put page-specific Open Graph metadata in the server-delivered <head> and avoid duplicate tags.
• Use a stable, absolute image URL that can be fetched publicly without cookies or expiring access tokens.
• Serve the correct image content type and use a clear landscape image with enough resolution for likely crops.
• Check the exact shared URL, response HTML, image response, and platform inspector result before changing multiple things at once.
• After changes, clear relevant site/CDN caches and request a fresh scrape from each platform where the preview is wrong.
• Keep a record of the intended og:image URL for important landing pages so future checks can distinguish a metadata regression from a stale platform cache.

Conclusion

When a link preview shows the wrong image, check the metadata in the page response, confirm the image is reachable by an unauthenticated crawler, and then refresh the affected platform’s cached scrape. Testing those three layers in order usually identifies whether the problem is page configuration, image delivery, or stale preview data.

References

• The Open Graph protocol — reference for core Open Graph properties and their meaning.
• Meta Sharing Debugger — Meta’s URL preview debugging and scrape-refresh tool. Platform interfaces and requirements can change; check current official documentation for platform-specific image constraints.