OG Image Not Updating? Check the Source, Image and Platform
Find where the old image is coming from before changing another setting or redeploying again.
Updated
How do you fix an OG image that will not update?
Check three things in order: the image URL in the live page's metadata, the actual file returned by that URL, and the preview used by the sharing platform. A change in your CMS is only the beginning; the public response must contain the intended tags and image.
If you are sharing somebody else's page, send the findings to its owner. For app-side checks, use the WhatsApp or iMessage guide.
Debug your Open Graph tags free
Check for missing OG tags and an image that fails to load before working through the checklist. No account or payment required.
This reads page HTML and image responses. Local card simulations are separate from actual platform rendering and cache refreshes.
1. Check the image URL in the live page source
Run the checker against the exact URL you share, including any meaningful query string. Review the final URL after redirects and the declared og:image. If it still names the old asset, update the page's metadata source or cached page response first.
Check your CMS's page-level image field as well as the site-wide default. A template, plugin or metadata function can override the value you changed. Keep one intentional set of image tags, and confirm that it appears in the fetched HTML.
curl --location --silent --show-error "https://example.com/your-page"This command displays the response HTML for manual inspection. It does not run browser JavaScript or prove what a social app rendered. Apple's Messages guidance specifically requires metadata available without executing page JavaScript.
2. Check the file returned by that image URL
Open the declared image URL and confirm that it serves the new image publicly. Check the response itself: a successful page request does not mean its image was fetched or decoded successfully.
| Observed result | Next step |
|---|---|
| The image URL serves the old file | Inspect the uploaded asset and your host's documented cache revalidation. A new asset filename can make the changed file explicit. |
| The image request fails or returns HTML | Fix the path, public access, redirects or protection that prevents the image from being served. |
| The new file is served and dimensions are readable | Continue to the destination platform. These results establish fetched-image evidence only. |
| Dimensions could not be verified | Keep the result as unknown. Inspect the returned file and its format before drawing a conclusion about size. |
If you publish a new filename, update the existing og:image and any separate twitter:image references. Update declared width and height to match the new file. A new URL does not guarantee that every old post or cached preview will change.
3. Inspect the destination platform
Use the Sharing Debugger to inspect Facebook's fetched metadata. After fixing the public page and image, use its scrape controls and review the result. This is Facebook evidence, not a guarantee about WhatsApp or another app.
Use Post Inspector after the source is fixed. LinkedIn's link-update guidance explains that updated information is used for new shares; an existing post can retain its original preview.
X
Check the card in the post composer and inspect the declared card metadata. The old Card Validator preview was removed, as recorded in X's official announcement. Do not rely on old instructions promising a preview button or a guaranteed cache reset.
WhatsApp and Messages
After checking the public source, prepare a fresh share in the intended app and inspect the result. The WhatsApp guide covers its link-preview privacy setting; the Messages guide covers Apple's resource-fetch requirements. There is no universal refresh deadline that this checker can establish.
Save evidence for the person making the fix
Keep the checked URL, time, declared image URL, observed image result and the app where the old preview appears. Save the completed diagnostic report, make the change, and run a fresh check. Compare those actual results; a new check cannot reconstruct an earlier response that was never saved.
If the problem comes back after template changes, track a small set of representative pages using the deployment-check guide.
Check the other pages using this template
A shared metadata field can affect more than one URL. Review up to five public pages together and export the findings for your repair work.