Why Your Link Preview Shows the Wrong Image—and How to Fix It

A link preview can show an old image, a logo, or a picture from the wrong page even when the page looks correct in your browser. The cause is usually either the page’s Open Graph metadata or a social platform’s saved copy of the page. This guide shows how to tell those problems apart and troubleshoot them without assuming that one platform’s preview represents every network.

Key Takeaways

• Check the HTML that a crawler receives, especially og:image, og:title, og:description, and og:url.
• A correct page in your browser does not prove that a crawler can see the same metadata or fetch the image.
• If the metadata or image has changed, ask the affected platform to fetch the URL again; its cached preview may otherwise remain stale.
• Test each platform separately. Meta’s debugging tool, for example, is not a universal preview validator.

First, identify what is wrong

Write down the exact URL you shared and the platform where the preview looks wrong. Then compare the preview with the page’s intended title and image.

There are two common situations:

1. The crawler receives the wrong information. The page has an incorrect og:image, the tag is missing, or the crawler cannot fetch the image.
2. The crawler has old information. The page has been corrected, but the platform is still showing a preview it saved earlier.

These can look identical in a feed. Check the page’s current metadata before treating the problem as a cache issue.

Check the Open Graph tags

Open Graph metadata gives social services information to use when displaying a shared page. For an image preview, start with these tags in the page’s HTML <head>:

<meta property="og:title" content="A clear page title">
<meta property="og:type" content="website">
<meta property="og:url" content="https://example.com/articles/spring-guide">
<meta property="og:image" content="https://example.com/images/spring-guide.jpg">
<meta property="og:description" content="A short description of the guide.">

The most important image field is og:image. Use an absolute HTTPS URL to the intended image. The URL in og:url should identify the page you mean to share; check that it agrees with your canonical URL and does not point to a different article or variant.

Optional image metadata, such as og:image:width, og:image:height, og:image:type, and og:image:alt, can provide additional context. Do not add dimensions or a MIME type unless they accurately describe the image. Platform-specific image rules can change, so check the affected platform’s current documentation rather than assuming one set of dimensions works everywhere.

Inspect the HTML delivered for the exact shared URL. Use your browser’s view-source feature, not only the rendered page or a developer-tools view of the final DOM. Some crawlers may not run the same JavaScript as a browser, so metadata added only after client-side rendering can be missed.

You can also inspect the initial response from a terminal:

curl -sS -L --max-time 20 https://example.com/articles/spring-guide \
  | grep -iE 'og:(title|type|url|image|description)'

Replace the example address with the exact URL you shared. This is a quick check, not a complete simulation of a social crawler: it does not reproduce every platform’s request headers, parsing behavior, or access rules. If the output contains multiple og:image tags, check their order and values; platforms may not handle ambiguous or conflicting metadata identically.

Make sure the image can be fetched

Copy the value of og:image and check the image URL itself. Confirm that it:

• Opens without requiring a login, a cookie, or a session.
• Returns the intended image rather than an error page, redirect to an unrelated asset, or HTML document.
• Uses an image format the target platform supports.
• Is not blocked by access controls or crawler restrictions.
• Has enough resolution and an aspect ratio suitable for the platform’s current requirements.

A browser showing the image is useful, but not conclusive: your browser may have access to a session or follow a path that a crawler cannot. To inspect response headers and redirects, run:

curl -sS -L -I --max-time 20 https://example.com/images/spring-guide.jpg

Check the final response after redirects and confirm it is successful and reports an image content type. Some servers handle HEAD requests differently from normal image requests; if the result is unexpected, try a normal request and inspect its headers instead. Also verify the file itself: the URL can return an image successfully and still point to the wrong image.

If your site uses a content management system, page builder, or SEO plugin, check which component controls the final tags. A theme, plugin, or template may emit a default site-wide image or duplicate tags that override the image you set in the editor.

Tell a metadata issue from a stale cache

Use this sequence to avoid repeatedly changing the page when the platform is simply showing an older scrape:

1. Inspect the exact shared URL. Check its returned HTML and confirm og:image points to the intended asset.
2. Check the image URL independently. Verify that the asset is publicly fetchable and is the correct file.
3. Request a fresh scrape on the affected platform. Use that platform’s official link-preview or sharing-debug tool, if it offers one. Review what it reports and request a re-scrape when available.
4. Wait and check the same URL again. A platform may take time to refresh or display a newly generated preview. Repeatedly changing metadata before confirming what the crawler sees can make diagnosis harder.
5. Test another platform separately. If one network shows the correct image and another does not, the difference may be in their caches, crawler access, or preview rules—not necessarily in your page’s current tags.

For a Meta share, Meta’s Sharing Debugger is the relevant place to inspect and request a refreshed Meta scrape. Its results apply to Meta’s crawler and preview behavior; they do not establish what LinkedIn, X, messaging apps, or other services will display. The label “Meta Graph Inspector” should not be confused with a general-purpose validator for every social network.

If you change the image but keep the same image URL, a platform or intermediary may still serve a cached copy of the old file. Publishing the replacement at a new filename can help distinguish the new asset from the old one, but does not guarantee that every platform will refresh immediately. If you use a query-string version, first confirm your server and image delivery setup handle it correctly.

A practical troubleshooting checklist

When a preview still shows the wrong image, work through these checks in order:

For a site-wide issue, compare a working page and a failing page. If both emit the same default image, look for a shared template or plugin setting. If only one page fails, inspect its individual metadata and asset URL. This comparison often narrows the problem faster than changing several settings at once.

Note on current Meta requirements

Meta’s debugging workflow and platform-specific preview requirements can change. I could not retrieve Meta’s current documentation in this environment, so the Meta-specific advice here is limited to using its Sharing Debugger to inspect and refresh Meta’s scrape; confirm current requirements in Meta’s official documentation before relying on particular image limits or interface steps.

Common Mistakes

• Checking only the rendered page. The crawler may receive different HTML from the page your browser displays.
• Assuming a cache is the cause. If the current HTML still names the wrong image, a re-scrape will likely fetch the same wrong metadata.
• Assuming a successful image URL means the right image. Confirm the returned file visually as well as checking its response.
• Treating one platform’s result as universal. Each service can crawl, cache, and interpret previews differently.
• Changing several things at once. Update one likely cause, then inspect the fetched metadata or preview again so you can tell what fixed the problem.

Best Practices

• Define Open Graph metadata in the page template or publishing system that controls the final HTML, and inspect the output after publishing.
• Use a stable, absolute image URL and keep the page’s og:url consistent with its intended canonical address.
• When replacing an image, verify both the file and the response from its URL; use a new filename when you need to clearly distinguish a replacement asset.
• Keep a short record of the shared URL, platform, metadata observed, and time of the re-scrape. This helps separate a persistent configuration problem from a delayed cache refresh.
• Check the affected platform’s own documentation for its current image and preview rules.

Conclusion

When a link preview shows the wrong image, first inspect the Open Graph metadata and confirm the image URL returns the intended, accessible file. Then refresh and check the preview using the affected platform’s own tools. Treat each network as a separate crawler and cache, not as a guaranteed copy of what another service displays.