Open Graph Image Not Updating? How to Refresh Stale Link Previews

You changed the preview image. The live page looks right. The CMS says the new asset is published. Then you paste the link into Slack or LinkedIn and the old image comes back like nothing happened.

That does not always mean your change failed. Often it means one of three things is still old: the page HTML, the image URL, or the platform cache.

Use this checklist to find which one it is before you start changing random metadata and making the problem harder to read.

First, Check the Source of Truth

Start with the final public URL people will share.

Do not check:

• the CMS preview URL
• a staging URL
• a logged-in dashboard page
• the image as it appears inside the editor
• a local development build

Check the live page source. You want to know what a crawler gets before any client-side JavaScript runs.

Look for:

1<meta property="og:image" content="https://example.com/og/new-image.jpg" />2<meta property="og:image:width" content="1200" />3<meta property="og:image:height" content="630" />4<meta property="og:image:alt" content="..." />5<meta name="twitter:image" content="https://example.com/og/new-image.jpg" />

If the raw HTML still points to the old image, you do not have a platform cache problem yet. You have a source problem.

That source problem might be a stale build, a CMS webhook that did not fire, a page cache, a template fallback, or a different URL variant than the one you are testing.

Then Open the Image URL Itself

If the HTML points to the new image, open that image URL directly.

Check the simple things:

• Does it return 200?
• Does it show the new image in a private window?
• Is it an absolute HTTPS URL?
• Does it require cookies or a signed session?
• Is the file reasonably small?
• Is the content type an image type?
• Does the URL redirect to a different asset?

An og:image tag is only a pointer. The platform still has to fetch the file. If the URL is blocked, slow, private, or stale behind a CDN, the tag can be perfect and the card can still be wrong.

For image-specific checks, the Open Graph image size guide and the large image preview guide are good next reads.

Confirm the Page URL Is the Same One the Platform Cached

Preview caches are usually tied to a URL. Small URL differences can create different cache states.

Check whether people are sharing:

• https://example.com/page
• https://example.com/page/
• https://www.example.com/page
• https://example.com/page?utm_source=...
• an old slug that redirects
• a shortened URL

Then compare that with:

• the canonical URL
• og:url
• the final URL after redirects
• the URL you typed into the platform inspector

If those do not line up, you may be refreshing one URL while the team keeps sharing another.

Refresh Platform Caches Deliberately

Once the live HTML and image URL are correct, then it makes sense to refresh the platform.

For LinkedIn, use Post Inspector. LinkedIn says the tool can refresh a URL when an old cached image is showing, but that changes previews for new posts. Existing posts keep the preview they already had.

For Slack, remember that classic link unfurling starts when Slack spots a link, crawls it, and builds a preview. Slack also documents that its link-expanding robot caches responses globally for around 30 minutes. If you just fixed the source, a little patience may be part of the fix.

For X and other platforms, use their current validator or card preview tool when available, and always test the exact URL variant people will share.

Do Not Cache-Bust Blindly

Cache-busting is useful when it is deliberate. It is messy when it is panic.

Good cache-busting:

1<meta property="og:image" content="https://example.com/og/product-v2.jpg" />

or:

1<meta property="og:image" content="https://example.com/og/product.jpg?v=2" />

Messy cache-busting:

• changing the page URL without updating canonical or og:url
• adding random query strings to every shared link
• creating five image URLs for the same asset in one afternoon
• forgetting that old posts on some platforms will not change

If you version the image URL, keep the page canonical stable unless the page really moved. The goal is to refresh the card, not create a new URL strategy.

CMS and CDN Issues That Cause Stale Cards

The most common stale-preview incidents come from ordinary publishing systems, not exotic crawler behavior.

Look for:

• a CMS field updated but not published
• a draft image used in preview mode but not production
• a static page cache that did not revalidate
• a CDN serving an older HTML response
• a transformed image URL that still maps to the old file
• a fallback og:image from the layout template
• metadata generated client-side instead of server-side

If the same stale image appears across many pages, check templates and fallback logic first. If it appears on one URL, check that page's published metadata and image asset.

A Clean Debug Flow

Use this order:

1. Inspect the final public URL with the link preview debugger.
2. Confirm the raw HTML points to the new og:image.
3. Open the image URL directly.
4. Compare canonical URL, og:url, and the URL people are sharing.
5. Check redirects.
6. Refresh LinkedIn, Slack, X, or the platform you care about.
7. Re-test after the platform cache has had time to clear.
8. Add a recurring check if the page is important.

For launch pages, product pages, and CMS-heavy sites, it is worth testing this as part of the release workflow. The social preview testing hub pulls the main preview checks into one place so you are not jumping between five tabs every time someone changes a hero image.

When To Stop Debugging

There is a clean stopping point:

• the live HTML has the new image
• the image URL is public and fast
• the canonical URL and og:url match the shared URL strategy
• ShareScan sees the right metadata
• the relevant platform inspector has been refreshed or the cache window has passed

If a previously published social post still shows the old card after that, it may simply be frozen. Some platforms do not rewrite old posts just because the source URL changed later.

The important part is making the next share correct.