Why Does My Link Preview Show the Wrong Image? A Debugging Checklist

A link preview can show an old image, an image from another page, or no image at all—even when the page looks correct in a browser. The cause is usually in the metadata the sharing platform reads, the image URL it tries to fetch, or a cached preview. Use this checklist to find where the mismatch starts and what to try next.

Key Takeaways

• Check the page’s Open Graph tags in the HTML returned to crawlers, not just what appears in the browser.
• Make sure og:image points to the intended, publicly fetchable image using an absolute URL.
• Check redirects, access restrictions, and the final page URL before assuming the image itself is at fault.
• Use the relevant platform’s preview or debugger tool to request a fresh scrape when available.
• Platforms cache and interpret previews differently; a change may not appear everywhere immediately.

1. Check the Open Graph metadata

Open Graph metadata tells many sharing platforms what title, description, and image to use. A typical page includes these tags inside the HTML document’s <head>:

<meta property="og:title" content="A useful page title">
<meta property="og:description" content="A short summary of the page.">
<meta property="og:image" content="https://example.com/images/article-cover.jpg">
<meta property="og:url" content="https://example.com/article">

Start by checking that og:image names the image you expect, and that the title and description belong to the same page. An old CMS template, a default site-wide image, or metadata copied from another page can cause an otherwise well-designed page to share the wrong preview.

The og:image value should be an absolute URL, including the scheme and hostname. A relative value such as /images/cover.jpg can be ambiguous to a scraper. Make sure the URL uses the intended public address, such as https://example.com/images/cover.jpg.

Check the HTML a scraper can see

View the page’s source or fetch its HTML and search for og:image, og:title, and og:description. For example, from a terminal:

curl -sSL https://example.com/article | grep -i 'og:image\|og:title\|og:description'

Replace the example URL with your page’s public URL. This command is a quick check, not a complete simulation of a social platform’s crawler. If it shows the wrong tag, fix the page template or CMS settings that produce the HTML.

If the tags look right in your browser’s developer tools but are missing from the fetched HTML, your site may be adding them with JavaScript after the initial page load. Some crawlers may not render the page the same way a browser does. Prefer serving the correct metadata in the initial HTML response, particularly for pages intended to be shared.

2. Confirm the image URL works on its own

Open the exact URL from og:image in a private browser window. Check that it loads without signing in, accepting a cookie prompt, or navigating through a page that blocks automated requests. Also check that the URL returns an image, rather than an error page or an HTML document.

Look for common URL and delivery problems:

• Wrong or outdated URL: The metadata may still reference a previous campaign image or a file that has moved.
• Redirects: The image URL may redirect to a different file, a login page, or an unexpected host. Check the destination, not only the starting URL.
• Access restrictions: Authentication, hotlink protection, firewall rules, or bot challenges may prevent a crawler from retrieving the image.
• Insecure or malformed address: Check for typos, an incorrect hostname, or a URL that does not use the intended scheme.
• Unexpected image response: The server may return an error or the wrong content type even though a browser displays something useful through another route.

If you use a command-line check, inspect the response and redirects rather than treating a successful browser display as proof that every crawler can fetch the file. For example:

curl -sSIL https://example.com/images/article-cover.jpg

This requests response headers and follows redirects. Confirm that the final response is successful and that the destination is the intended image. Server rules and network conditions can vary, so this check does not guarantee that a particular platform can access the file.

3. Check for a stale preview

If the page metadata and image URL are correct, the platform may be showing a previously fetched preview. Social networks commonly cache shared-page information, and changing a tag does not necessarily update an existing preview immediately.

For Meta, try its Sharing Debugger with the exact URL people share. Where the tool offers a scrape or refresh action, use it to ask Meta to fetch the page again, then review the metadata and any reported fetch problems. Meta’s tool and interface can change; I could not verify the current interface or refresh behavior against live Meta documentation while preparing this article, so check the tool’s current instructions rather than relying on a particular button label.

After requesting a new scrape, test the link again. A refresh request is not a guarantee that every already-shared post will change, nor does it refresh other platforms’ caches. If you changed the image file but kept the same image URL, a platform may also retain an older copy. When practical, publish the replacement as a new filename and update og:image to that URL.

4. Check which URL is actually being shared

A page can have several addresses: a URL with tracking parameters, a redirected URL, and a canonical URL. Check the exact link being pasted and where it redirects. Compare it with og:url and the page’s canonical link so you can spot a template or redirect that points to the wrong page.

Also test the final destination after redirects. If a short link, campaign URL, or alternate domain lands on a different page than expected, the destination’s metadata may determine the preview. When investigating, use the exact shared URL in the platform’s debugger rather than checking only a nearby version of the page.

5. Compare platforms separately

A correct preview in one app does not prove every platform will show the same result. Platforms can fetch metadata at different times, cache it separately, and apply their own image selection and display rules. A preview may also be cropped differently in different placements, even when it uses the intended source image.

When the problem appears on only one platform, use that platform’s own preview or debugging tools if available. Compare the fetched URL, reported metadata, and image there. Avoid repeatedly changing correct page tags to solve what may be a platform-specific cache or display difference.

Common Mistakes

• Checking only the visual page: The page can display the right image while its Open Graph tags name another one.
• Using a relative image path: A crawler may not resolve it as intended; use a complete, absolute image URL.
• Refreshing the wrong URL: A debugger check for the canonical address may not diagnose a shared link that redirects elsewhere.
• Assuming a refresh updates every platform: Each service can maintain its own cached preview.
• Ignoring bot access: A successful fetch in your logged-in browser does not establish that an unauthenticated crawler can retrieve the page or image.
• Changing many variables at once: Update one likely cause, then fetch or inspect again so you can tell whether it fixed the issue.

Best Practices

1. Put accurate og:title, og:description, and og:image tags in the initial HTML response.
2. Use an absolute image URL and keep the image publicly retrievable without a login or browser-only interaction.
3. Test the page URL and the image URL independently, including any redirects.
4. After publishing a change, inspect the exact shared URL with the relevant platform’s debugging tool when available.
5. Give platforms time to fetch and update previews; verify each platform separately instead of assuming one refresh clears all caches.

Conclusion

When a link preview shows the wrong image, trace the data in order: inspect the rendered Open Graph tags, test the image URL, confirm the exact destination being shared, and then check the platform’s cached preview. This separates a page configuration problem from a fetch failure or a platform-specific delay.

References

• The Open Graph protocol — metadata properties used to describe a page, including title, description, and image.
• Meta Sharing Debugger — Meta’s tool for inspecting how a URL is read for sharing.