A page can display a new hero image while its shared link still points to an older preview image. Those images may come from different fields and may have different cached copies. Diagnose the chain before replacing artwork: the page response, its preview metadata, the image response and the sharing platform's saved preview.
Inspect the preview reference, not only the visible page
Ask the website owner or developer to inspect the public page's head metadata. The Open Graph protocol defines a dedicated image reference alongside title, type and URL. Changing a visible image element does not prove that the page's og:image value changed.
Record the exact page URL and the exact preview-image URL returned in a fresh page response. Check for a staging hostname, a private image link, a redirect to a login screen or an older filename. If several image tags exist, document their order and ask the implementation owner which value the target platform is likely to read. Do not guess based on what the design editor displays.
Separate the page response from the image bytes
Open the preview-image URL directly in a clean browser session. Confirm that it returns the intended image without an account. Then compare a downloaded copy with the approved export. If the same image URL still returns the old picture, the problem is upstream of the social preview.
MDN's caching guide explains that HTTP responses may be reused by caches. A browser refresh therefore answers only part of the question. Ask the hosting owner to examine response headers and any CDN cache behavior; do not remove caching indiscriminately from the entire site to repair one asset.
Worked example: an invented retreat announcement
In this fictional example, a retreat page originally uses a beach portrait. The approved revision uses a mountain portrait. The visible page changes, but its og:image still names the beach file. The correct first repair is the metadata reference, not a more dramatic mountain generation.
After that repair, the direct image URL shows mountains but one platform's preview remains a beach. The editor now records two pieces of evidence: fresh HTML names the new file, and an unauthenticated request returns the mountain image. That narrows the unresolved issue to the downstream preview rather than the source image.
Request a fresh preview carefully
Use the target platform's own link inspector or refresh control when it provides one. Availability and refresh behavior vary; do not assume a button on one platform applies to another. Test a newly composed share as well as an existing message. A retained preview in an old post may behave differently from a new share.
For an image you control, a versioned asset name can make the revision explicit. Keep the page's intended canonical address stable and update its preview reference coherently. Randomly appending query strings to every page link can create confusing share variants without explaining the real cause.
Keep a small handoff record
Deliver the approved export, page URL, resolved image URL and a timestamped observation for each target platform. Record whether the failure involved metadata, image delivery or downstream preview storage. This makes future revisions reproducible and prevents another person from overwriting the correct image in frustration.
If you need new art, start with Image Prompt, then give the web owner the verified export. The final acceptance check is the public link preview in the intended sharing environment, not the generation result or the website hero alone.