How to Make a Facebook Preview Image Update After a URL Redirect

If Facebook shows the old image after a URL redirect, check the page the redirect actually reaches, make sure its Open Graph tags name the intended image, then submit the exact shared URL to Facebook’s Sharing Debugger and request another scrape. If the tags are right but the old pixels remain, give the replacement image a new URL and update og:image too. Facebook may have cached information for the URL, so changing your site alone does not guarantee every preview refreshes immediately.

1. Trace the shared URL to its final destination

Start with the exact URL people share, including its scheme, hostname, path, and any meaningful query string. Follow redirects and note the final URL. Confirm it reaches the page whose preview you intend to change, rather than a home page, an outdated page, a login screen, or an error page.

Open the shared URL in a browser and follow the redirect to its final destination.
Check that the destination loads without requiring a login or client-side interaction to reveal its metadata.
Inspect the returned HTML source and locate the Open Graph tags inside the document’s <head>.
Repeat the check for the exact URL users share. A redirecting URL and its destination can be treated as distinct inputs by preview tools.

For a quick command-line redirect check, use curl -IL. This prints response headers for the redirect chain; it does not inspect the page’s HTML metadata.

curl -IL 'https://example.com/old-path'

Look for each Location response header and verify the final response is the intended page. If the redirect chain is wrong, fix that first. Updating tags on a page Facebook never reaches will not fix the preview.

2. Set the Open Graph tags on the destination page

The Open Graph protocol defines og:title, og:type, og:image, and og:url as the basic properties. Put them in the page head. og:image identifies the representative image; og:url identifies the canonical URL for the object. See the Open Graph protocol.

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>Product update</title>
  <meta property="og:title" content="Product update">
  <meta property="og:type" content="article">
  <meta property="og:url" content="https://example.com/product-update">
  <meta property="og:image" content="https://example.com/images/product-update-share-v2.jpg">
  <meta property="og:image:alt" content="A preview of the product update">
</head>
<body>
  <h1>Product update</h1>
</body>
</html>

Replace the example values with your real page, canonical URL, and an image URL that is publicly accessible to the crawler. The metadata must be present in the HTML Facebook fetches. If your site renders tags only after JavaScript runs, check the raw response as well as the browser’s rendered DOM; the response should contain the intended tags.

Choose the canonical URL deliberately

Set og:url to the canonical page URL you intend associated with the content. A redirect can take Facebook from the shared address to a different destination, while the page’s og:url can identify a canonical URL. Check all three: the original URL people share, the redirect destination, and the page’s declared og:url. They should be consistent with your publishing and canonicalization setup.

Check multiple image tags and optional image metadata

You can provide optional og:image:width, og:image:height, and og:image:alt properties. The alt value should describe the image, rather than serve as its caption. These properties describe the image; they do not, by themselves, force a cached preview to refresh.

If the document has multiple og:image tags, inspect their order and related structured tags. The protocol says the first repeated tag takes precedence when values conflict. Put the intended image first, and remove obsolete image tags where possible. This is protocol-level precedence guidance, not a guarantee about every detail of Facebook’s implementation.

3. Ask Facebook to fetch the URL again

After publishing the corrected page, open Facebook’s Sharing Debugger, enter the exact URL that people share, and request another scrape with the “Scrape Again” control. Inspect the debugger’s reported URL and page information. If it resolves to an unexpected destination or shows old tags, return to the redirect or page configuration and fix what the fetch reveals.

Practical troubleshooting guides recommend using the debugger after correcting live metadata. Treat it as a request for a fresh fetch, not a promise that every already-published attachment or Facebook surface changes immediately. Meta’s debugger documentation could not be independently verified for this guide; refresh guidance here is based on secondary troubleshooting sources.

4. Replace the image URL if the old image still appears

If the fetched metadata names the right image but Facebook continues to show old pixels, publish the desired image at a new URL and update og:image to that address. Then submit the shared page URL to the Sharing Debugger and request another scrape. This gives the image itself a distinct address; replacing a file in place leaves the image URL unchanged.

Check that the new image address is publicly reachable and returns the intended image, not a redirect to an old asset or an access-denied response. Do not assume that changing the image URL will update an attachment already published in a post. A refreshed URL preview and an existing post attachment are separate things to check.

5. Verify the result and isolate what is stale

Confirm the exact shared URL and final redirect destination.
Read the live HTML head and verify og:title, og:url, and the first og:image value.
Open the image URL directly and confirm it serves the intended image publicly.
Submit the shared URL to the Sharing Debugger and request another scrape.
Compare the debugger’s fetched destination and metadata with the live response.
If metadata is correct but image pixels are stale, use a new image URL, update the tag, and scrape again.
Check a newly composed share separately from an attachment in an existing post.

Common problems and fixes

What you see	Likely cause	What to do
The debugger lands on an unexpected page	The redirect target or redirect rules are wrong, or the submitted URL differs from the one users share.	Trace the exact shared URL, correct the redirect, then scrape that exact URL again.
The debugger shows old Open Graph values	The change is not in the HTML response Facebook fetched, the deployment is incomplete, or the tags are injected only in the browser.	Inspect the raw destination response, deploy the tags in the page head, and request another scrape.
The correct image URL is reported, but the old picture appears	The image was replaced at the same address and the previously fetched image may still be used.	Publish the image at a new URL, change `og:image`, and scrape the page again.
A different image wins despite the intended tag	Several `og:image` tags or associated properties may conflict; order matters in the Open Graph protocol.	Put the intended image first and remove stale or conflicting tags.
A new preview looks right, but an old post still has the old attachment	Refreshing fetched URL data does not necessarily rewrite an attachment already published.	Verify with a fresh share and handle the existing post attachment separately; do not infer its behavior from the debugger alone.
The image URL does not load for a visitor without an account	The asset is private, blocked, or redirects somewhere inaccessible.	Serve the image at a public URL and verify that the address returns the image directly.

Performance, reliability, and cost

This fix is mainly a metadata and cache-refresh workflow, so there is no reliable cache duration or guaranteed refresh time to plan around. The research sources provide no authoritative Facebook cache-expiry figure. Make the metadata correct first, request a scrape, and verify the result instead of relying on a timer.

For repeatable checks during development, you can capture the destination page and inspect its rendered appearance. A screenshot confirms what a browser displays; it does not prove which Open Graph tags Facebook fetched or whether an existing post attachment changed. ScreenshotNeo is a website screenshot API and MCP server for developers. It can capture pages, but the Facebook Sharing Debugger remains the relevant tool for asking Facebook to fetch link metadata again.

Or skip the browser setup

If you need a clean visual capture of the landing page while fixing its preview, ScreenshotNeo can return a screenshot or PDF with one GET request. It is a website screenshot API and MCP server. Cookie banners, newsletter popups, and chat widgets are removed before the shot; those steps can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed, and response headers report the page verdict and billing status. Its MCP server gives AI agents tools to take screenshots, get page information, and capture PDFs.

cURL:

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://example.com/product-update -o shot.webp

Python:

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://example.com/product-update"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)

Node.js:

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://example.com/product-update'
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const fs = await import('node:fs/promises');
await fs.writeFile('shot.webp', Buffer.from(await res.arrayBuffer()));

See the ScreenshotNeo API documentation for request options. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000. Sign up for 1,000 free screenshots a month, with no card required.

FAQ

Does changing the redirect automatically change the Facebook image?

No. Check the destination page’s Open Graph metadata and ask Facebook to scrape the exact shared URL again.

Should `og:url` be the old address or the new address?

Use the canonical URL you intend Facebook to associate with the page. Verify that it matches your redirect and canonicalization setup.

Will scraping again change a link preview in a post that is already published?

Do not assume so. Check the refreshed URL preview separately from attachments already published in posts.

Can I force the refresh by adding a query parameter?

The researched sources do not establish query parameters as a reliable cache-refresh method. Correct the metadata and use the Sharing Debugger for the URL people actually share.