A link preview showing the wrong image or title can make a carefully prepared post look outdated or misleading. The cause is usually in the page’s Open Graph metadata, the image’s accessibility, or cached preview data—not the text you typed into the social post.
This guide shows how to inspect the metadata a crawler can fetch, check the preview image, and request a fresh scrape. Meta’s debugging interface and crawler behavior can change; Meta’s live documentation could not be retrieved while preparing this guide, so exact interface labels and crawler details are intentionally not assumed.
Key Takeaways
- Open Graph tags such as
og:title,og:description, andog:imageprovide the main information used to build many social link previews. - Check the HTML returned for the shared URL, not just what appears after JavaScript runs in your browser.
- The image URL must be publicly fetchable by the platform’s crawler and return a usable image response.
- Correcting a page does not necessarily refresh an already cached preview. Retest the URL with Meta’s Sharing Debugger after publishing changes.
1. Check the Metadata on the Shared URL
Open Graph metadata is placed in the document’s <head>. A basic example looks like this:
<head>
<title>Spring Garden Planning Guide</title>
<meta property="og:title" content="Plan Your Spring Garden">
<meta property="og:description" content="A practical guide to choosing plants and preparing your garden for spring.">
<meta property="og:image" content="https://example.com/images/spring-garden.jpg">
<meta property="og:url" content="https://example.com/guides/spring-garden">
</head>
The Open Graph fields describe the page: og:title is the preview title, og:description is its summary, and og:image identifies an image to use. og:url identifies the page’s canonical URL. A platform may apply its own presentation rules, so tags are guidance to the crawler rather than a guarantee of an identical preview everywhere.
First, check the exact URL you intend to share. A homepage, a URL with tracking parameters, and a URL after redirects can return different metadata. Also check that the page’s HTML source contains the tags; metadata added only after client-side JavaScript executes may not be available to every crawler.
For a quick command-line check, replace the example URL with your page:
curl -sS -L "https://example.com/guides/spring-garden" | grep -iE 'og:title|og:description|og:image|og:url'
This is a quick text search, not a full HTML parser. If it returns nothing, inspect the page source in your browser or use an HTML-aware tool. If the browser displays the correct title but the returned HTML does not contain the expected tags, configure the site to emit metadata in the initial server response or prerendered HTML.
2. Find Conflicting or Missing Tags
Compare the returned metadata with the page you intend to share:
- Wrong title: Check
og:titleand remove duplicate or outdated Open Graph tags. Also check whether your CMS, SEO plugin, or page template is generating another value. - Wrong description: Inspect
og:description. The platform may shorten or format text differently, but a missing or stale tag should be fixed at the source. - Wrong image: Confirm that
og:imagepoints to the intended image, not a site logo, thumbnail, or previous campaign asset. - Missing preview details: Add the relevant Open Graph tags to the page’s HTML head and check that the page is returning the expected document rather than a login page, error page, or redirect destination.
Keep one clear, current value for each property. When a page contains conflicting metadata, crawlers and platforms may not select the value you expect. If your site uses a template or plugin, fix the source that generates the tags so the correction survives future edits.
3. Check Whether the Image Is Fetchable
An image that loads for you may still fail for a crawler. Common causes include a private or signed-in-only URL, a blocked request, a broken path, or a server response that is not actually an image.
Check that the og:image URL:
- Is an absolute URL, including the
https://scheme and hostname. - Opens without a login, cookie, or special browser session.
- Returns the intended image rather than an error page or an unexpected redirect.
- Has not been blocked by access rules on your site, CDN, or image host.
- Uses an image format and dimensions supported by the social platform’s current requirements.
You can request the image directly from a terminal. This downloads the response to a temporary file so you can check that the URL resolves and inspect what was returned:
curl -sS -L "https://example.com/images/spring-garden.jpg" -o /tmp/preview-image
file /tmp/preview-image
A successful download alone does not confirm that every platform can fetch or display the image. Check the response and access rules on your server or CDN, and review the platform’s current image guidance for format and size requirements. Avoid relying on a rigid image-dimension rule from an old tutorial; requirements and preview layouts can change.
4. Retest After Changing the Page
Social platforms may retain preview data from an earlier crawl. That means the browser can show corrected page metadata while a shared-link preview still shows the previous title or image.
Use this sequence:
- Publish the corrected page and image.
- Open the page source or run the metadata check again to confirm the new values are live.
- Open Meta’s Sharing Debugger and submit the exact URL you plan to share.
- Use the debugger’s available option to request a fresh scrape, if shown.
- Review the resulting preview and any fetch or parsing warnings.
- If the preview remains wrong, recheck the exact URL, redirects, image response, and any duplicate metadata before requesting another scrape.
A refresh in a debugging tool may update the data used for later previews, but it does not necessarily change a preview already embedded in an existing social post. If an old post still shows stale information, check the platform’s current behavior for existing posts and consider sharing the corrected URL again where appropriate.
Reproducible Debugging Checklist
Work through these checks in order and record what the debugger reports:
| Check | What to verify |
|---|---|
| Shared URL | You submitted the exact URL, including relevant path and parameters. |
| Redirects | The URL ends at the intended page, not a different page or error response. |
| HTML metadata | The returned page source contains current og:title, og:description, and og:image values. |
| Duplicate tags | Your CMS, template, or plugins are not emitting competing values. |
| Image access | The image URL is public, resolves successfully, and returns the intended image. |
| Cache refresh | You requested a fresh scrape after the page and image changes were published. |
| Final result | The debugger’s latest preview reflects the intended content; retest after any further edits. |
For a repeatable record, note the shared URL, the og:image URL, the time you published changes, and the debugger’s result after refreshing. This makes it easier to distinguish a page-side issue from stale preview data.
Common Mistakes
- Changing the visible page but not its metadata. The headline on the page and
og:titlecan be different values. - Checking only the browser’s rendered view. A browser may run scripts and use your session; a crawler may receive different HTML or lack access.
- Using a relative image path. Use a complete, publicly accessible image URL in
og:image. - Assuming an image that loads for you loads for everyone. Login requirements, CDN rules, or blocked requests can prevent crawler access.
- Expecting a fix to appear immediately. Preview data can be cached; request a fresh scrape after confirming the live page is correct.
- Treating one debugger result as proof that every platform is fixed. Other platforms may crawl separately and apply their own rules.
Best Practices
- Generate Open Graph metadata from the same page data used for the title and description, and avoid duplicate tags from overlapping plugins.
- Use a stable, publicly accessible image URL and replace or version the image when you need to avoid serving a stale asset from a cache.
- Test important landing pages after publishing, especially when changing a page template, SEO plugin, CDN, or image-hosting setup.
- Keep a copy of the current metadata and image URL for campaign pages so you can verify changes quickly.
- Treat the Sharing Debugger as a troubleshooting aid, not a substitute for checking the page’s actual HTML and image response.
Conclusion
To fix a link preview showing the wrong image or title, inspect the Open Graph tags on the exact shared URL, confirm the image is accessible, and then request a fresh scrape in Meta’s Sharing Debugger. Checking each step in that order helps isolate missing metadata, image-fetch problems, and stale preview data.
References
Meta’s live documentation could not be retrieved for this draft. For current instructions and interface labels, consult Meta’s Sharing Debugger and official sharing documentation directly.
