A Facebook link preview can keep showing an old image even after you update your website. The usual causes are stale cached data, incorrect Open Graph tags, or an image URL that Facebook’s crawler cannot retrieve. This guide walks through checking the page’s metadata, testing the image, and asking Facebook to scrape the URL again. Meta’s interface can change; the button names below reflect the commonly used Sharing Debugger workflow and have not been live-verified here.
Key Takeaways
- Facebook uses Open Graph metadata—especially
og:image,og:title, andog:description—to build a link preview. - Check the HTML delivered for the exact URL you shared, not only what appears after your site’s JavaScript runs.
- Make sure the image URL is public, loads successfully, and serves an image in a broadly compatible format such as JPEG or PNG.
- Use Meta’s Sharing Debugger to request a fresh scrape. It can reveal some fetch and metadata problems, but it cannot repair your site, image server, or access rules.
1. Check the Open Graph metadata Facebook receives
The page’s <head> should contain one clear set of Open Graph tags. For example:
<head>
<meta property="og:title" content="A useful page title">
<meta property="og:description" content="A concise description of the page.">
<meta property="og:image" content="https://example.com/images/article-share.jpg">
<meta property="og:url" content="https://example.com/article">
</head>
Use an absolute HTTPS URL for og:image. Check that og:url identifies the intended page and that your page’s canonical URL does not point to a different article or variant. Conflicting or duplicated tags can make it difficult to diagnose which value a crawler uses.
Check the HTML returned by the server for the exact URL you shared. For a quick inspection from a terminal, replace the example URL with your page’s URL:
curl -sL 'https://example.com/article' | grep -iE 'og:(title|description|image|url)'
This simple command is a diagnostic aid, not a full HTML parser. If it shows no tags, inspect the page’s source or use your browser’s “View Source” option. Some sites add metadata with JavaScript; do not assume Facebook’s crawler will see metadata that appears only after client-side rendering. Make sure the relevant tags are present in the HTML your server returns.
If the tags are missing or wrong, update the page template or content-management settings, publish the changes, and verify the returned HTML again before requesting another scrape.
2. Verify the image URL itself
Copy the exact URL from og:image and open it directly in a private browser window. It should load the intended image without requiring a login, session cookie, or special access. Also check whether a CDN, firewall, hotlink rule, or bot-protection service blocks automated requests.
You can inspect the response from a terminal:
curl -L -sS -o /dev/null \
-w 'HTTP %{http_code} | %{content_type}\n' \
'https://example.com/images/article-share.jpg'
A successful response should end at the image and report an appropriate image content type, such as image/jpeg or image/png. A redirect to a login page, an error page, or an HTML document is not a usable image response even if the URL looks plausible. Check the final destination as well as the URL’s spelling.
For broad compatibility, JPEG and PNG are safe choices. Avoid assuming that SVG, WebP, or animated formats will work consistently across crawlers and preview paths. A landscape image around 1200 × 630 pixels is a common sharing format, not a guarantee that Facebook will display every pixel without cropping.
3. Request a fresh scrape with Meta’s Sharing Debugger
Open Meta’s Sharing Debugger and enter the exact URL people shared. Review the returned preview and any warnings. If the page has changed, use the debugger’s option to scrape it again—commonly labeled Scrape Again—then inspect the preview it reports.
Use the same URL that is being shared, including meaningful query parameters where relevant. A URL with a trailing slash, a different hostname, or tracking parameters may be treated as a different address or may lead to different page metadata. If your site redirects one version to another, check the final page and its canonical URL too.
After a successful fresh scrape, create a new test post or refresh your sharing workflow. Existing posts may continue to show their already-rendered preview; scraping again does not necessarily rewrite previews that were previously published.
The debugger can help you see what Meta fetched and what metadata it found. It cannot change your site’s tags, make a private image public, bypass a firewall, repair a broken redirect, or guarantee that every Facebook surface immediately displays the same preview.
4. Diagnose based on what the debugger shows
| What you see | What to check |
|---|---|
| The old image is still reported | Confirm you scraped the exact shared URL, then check that the updated og:image is present in the returned HTML. Request another scrape after the page update is live. |
| No image or an image-fetch warning | Open the image URL directly, check its response and content type, and investigate redirects, authentication, CDN rules, and bot protection. |
| The wrong page title or description | Check for missing or duplicate tags, a stale page template, and canonical or redirect behavior that points to another page. |
| The debugger shows the right preview but a post does not | Test a new share and check whether the post is using a different URL variant. Do not assume an existing post will update just because a new scrape succeeded. |
If your site uses a cache or CDN, purge the relevant page or image cache after publishing a correction. Then fetch the URL again and confirm the response has changed before asking Meta to scrape it. Repeatedly requesting a scrape while the server is still returning old HTML or an old image will not fix the underlying issue.
Common Mistakes
- Checking only the visual page. The page can look correct while its server-returned Open Graph tags still point to the old image.
- Using a relative image path. Use a complete URL such as
https://example.com/images/share.pngforog:image. - Testing a different URL from the one shared. Check the actual hostname, path, trailing slash, and relevant query string.
- Assuming the debugger repairs errors. It can report what it fetched; website or hosting changes are still your responsibility.
- Expecting an old post to change. Test a new share after the page has been updated and scraped.
- Ignoring redirects or access controls. An image that loads for you may still fail for an automated crawler if it depends on cookies or is blocked by your infrastructure.
Best Practices
- Keep one authoritative set of Open Graph tags in the server-rendered page head.
- Use a stable, absolute HTTPS image URL and verify it returns an actual image without authentication.
- After changing metadata, check the delivered HTML and image response before requesting a fresh scrape.
- Keep the shared URL,
og:url, and canonical URL aligned when they are intended to represent the same page. - Treat the debugger as a diagnostic tool, not as a substitute for checking your website’s response, cache, and access rules.
Conclusion
When a Facebook link preview is not updating, verify the metadata and image Facebook can fetch before requesting a fresh scrape in Meta’s Sharing Debugger. If the debugger still reports the old information, fix the page response or image access first; scraping cannot correct a problem that remains on your site.
References
- Meta Sharing Debugger — Meta’s tool for inspecting and requesting a fresh scrape of a shared URL. Its interface and labels may change.