TidyURLs
HomeBlogAbout
Go to Tools
BLOG
The TidyURLsJournal

Practical guides, tutorials, and insights about URLs, SEO, web development, and online marketing. Learn, troubleshoot, and get the most of the web.

Back to the Journal
TidyURLs Journal

Facebook Link Preview Showing Old Image? How to Fix It

Practical insights, clear explanations, and useful ideas for understanding the web.

October 28, 20267 min read5 topics
Facebook Link Preview Showing Old Image? How to Fix It
Explore the details
#Facebook#Open Graph#Link Previews#Social Media#Website Troubleshooting
October 28, 20267 min read

If your Facebook link preview is showing an old image, the cause is usually either outdated Open Graph metadata on the page or a preview Facebook has cached from an earlier scrape. The steps below help you distinguish between those problems, check whether Facebook can reach the page and image, and request a fresh preview.

Key Takeaways

  • Facebook reads Open Graph metadata from the page response, especially og:image and og:url.
  • Check the exact URL you shared, the HTML it returns, and whether the image is publicly accessible before refreshing the preview.
  • Use Meta's Sharing Debugger to inspect the scrape and request another one. A new scrape does not guarantee an immediate update everywhere.
  • Make sure crawlers can reach the page and image without authentication, blocking rules, or broken redirects.

How Facebook chooses a link preview image

A page can supply preview information with Open Graph tags in its HTML <head>. For example:

<meta property="og:title" content="A Guide to Example Product">
<meta property="og:description" content="Learn how the product works and what it can do.">
<meta property="og:image" content="https://example.com/images/product-guide.jpg">
<meta property="og:url" content="https://example.com/product-guide">
<meta property="og:type" content="article">

og:image identifies the image Facebook should consider for the preview. og:url identifies the page's preferred, canonical URL. og:title and og:description supply text for the preview, while og:type describes the page. The tags should be present in the HTML that the crawler receives—not only added later by JavaScript.

The og:image value should be an absolute, publicly reachable HTTPS URL. Image metadata such as og:image:width, og:image:height, and og:image:alt can provide additional information. Use a clear landscape image with sufficient resolution; 1200 × 630 pixels is a common target for link previews, but check Meta's current requirements for any size limits or recommendations.

If the image has changed but the og:image URL has not, Facebook may still use a previously fetched copy. Changing the image filename and updating og:image to that new URL can help distinguish the new asset from the old one, but it does not guarantee an instant update.

Troubleshoot the preview in order

1. Check the exact URL being shared

Copy the URL from the Facebook post and compare it with the page's og:url. Look for differences such as http versus https, www versus a non-www host, trailing slashes, query parameters, or a redirect to another page. Facebook may have preview data associated with a different URL variant than the one you just edited.

Make sure the page's canonical URL and og:url point to the intended public page. If a redirect is expected, check that it ends at that page rather than at an outdated URL or an error page.

2. Inspect the HTML Facebook can receive

Fetch the page response and inspect its final URL and Open Graph tags. For example, from a terminal:

curl -sSL -D /tmp/page-headers.txt -o /tmp/page.html \
  -w 'Final URL: %{url_effective}\nHTTP status: %{http_code}\n' \
  'https://example.com/product-guide'

grep -iE 'og:(title|description|image|url|type)' /tmp/page.html

Replace the example URL with the exact address you are sharing. Confirm that the response succeeds, the final URL is expected, and the returned HTML contains the current og:image and og:url. If the tags are missing or stale in this response, fix the page template, publishing system, or server-side rendering first. Refreshing a preview cannot correct incorrect page HTML.

3. Test whether the image is accessible

Open the exact og:image URL in a private browser window, then check that it returns an image rather than a login page, an HTML error, or a broken redirect. A command-line request can help identify HTTP errors and redirects:

curl -sSL -o /dev/null \
  -w 'Final URL: %{url_effective}\nHTTP status: %{http_code}\nContent type: %{content_type}\n' \
  'https://example.com/images/product-guide.jpg'

A successful response should end at the intended image and have an image content type. Also confirm that the image is the right file, has not been replaced by a stale CDN copy, and is large enough to display clearly. If the image URL redirects, test the final destination too. Avoid relying on an image hosted behind a login, expiring link, or access-control rule.

4. Check crawler access and page delivery

A page may work in your browser but fail for Facebook's crawler. Review the site's robots.txt, firewall, CDN, bot-protection, and hosting rules for blocks or challenges that affect Facebook's scraper. Check access to both the page and the image: allowing the page while blocking the image can still produce an incomplete preview.

Also check whether the server returns different HTML to crawlers, requires cookies, or serves a temporary error during scraping. A command using a browser-like user agent can reveal some differences, but changing the user agent yourself does not prove Facebook's crawler can access the site. Use your server or CDN logs to investigate requests from Facebook's crawler where available.

5. Request a fresh scrape

Open Meta's Sharing Debugger, enter the exact page URL, and inspect the reported scrape and preview. If the tool offers a way to scrape the URL again, use it after confirming that the page and image are correct. Read any warnings or fetch errors it reports, make the relevant fix, and request another scrape.

Then check the preview again using the same URL. If the debugger shows the new image but an existing post or another URL variant still shows the old one, you may be looking at cached data for that specific share or URL. A fresh scrape can refresh the data Meta retrieves, but changes may take time to appear in every context; Meta does not provide a universal guaranteed update time.

What to do when the old image persists

Use the result of each check to narrow down the cause:

  • The HTML contains the old image URL: fix the Open Graph tags or page template, publish the change, and check the response again.
  • The HTML has the new URL, but it leads to the old image: inspect the image path, redirects, and CDN or hosting cache. A new filename can make the updated asset easier to distinguish.
  • The page or image cannot be fetched publicly: remove the relevant access block or challenge, then verify access from outside an authenticated browser session.
  • The debugger reports errors: address the reported fetch or metadata issue before requesting another scrape.
  • The debugger shows the new image, but a particular post does not: check that post's exact URL and remember that refreshing fetched preview data may not rewrite an already published post.

When testing, change one thing at a time and recheck the same URL. That makes it easier to tell whether the fix was a metadata correction, an image-access fix, or a cache refresh.

Common Mistakes

  • Changing the page image but not og:image: the preview follows the metadata, which may still point to the old asset.
  • Checking only the browser-rendered page: the tags may be injected by JavaScript and absent from the HTML Facebook fetches.
  • Refreshing the wrong URL: a redirect, query string, or host variant can mean you are inspecting a different page address.
  • Assuming a browser-visible image is crawler-accessible: cookies, hotlink protection, bot challenges, or firewall rules can prevent a scraper from retrieving it.
  • Using a redirecting or temporary image URL: redirects can fail or lead to a different asset. Prefer a stable, public image URL that returns the intended image.
  • Expecting a refresh to change every existing post immediately: a new scrape does not guarantee that already published posts or every preview context will update at once.
  • Using a tiny or unsuitable image: the file may load but still make for a poor preview. Use a clear image at a suitable resolution and follow Meta's current guidance.

Best Practices

  • Put the Open Graph tags in the server-delivered page HTML and keep them synchronized with the page's current content.
  • Set a deliberate og:image and og:url for each shareable page; do not rely on a fallback image or an accidental URL variant.
  • Use stable HTTPS image URLs that return the correct image without authentication or unnecessary redirects.
  • After publishing a change, verify the actual HTTP response and image URL before requesting a new scrape.
  • Keep a repeatable check for important landing pages: inspect metadata, fetch the image, review crawler access, then use the Sharing Debugger.
  • Treat a successful debugger preview as a diagnostic result, not as a guarantee that every existing share will instantly change.

Conclusion

When a Facebook link preview shows an old image, first confirm what the page actually serves and whether the current image is accessible. Then use Meta's Sharing Debugger to inspect and refresh the scrape for the exact URL. Fixing the source metadata or access problem before requesting another scrape is the most reliable way to diagnose the issue.

References

Meta's live documentation and interface could not be retrieved for this article, so current labels, size limits, and cache timing should be confirmed in Meta's own tool. The debugger is available at Meta Sharing Debugger.

Back to all articles