How to Fix an OG Image That Won't Update on Social

You changed the og:image on a page, redeployed, and shared the link again. The old picture still shows up. You clear your own browser cache, try incognito, even wait a day. Nothing changes. Meanwhile a customer, a hiring manager, or a client is seeing a broken or outdated preview every time your link lands in their feed, and there is no error message telling you why.

An Open Graph (OG) image is the preview picture social platforms pull from a page's og:image meta tag whenever that page's URL is shared. The image itself is not the problem — the cache sitting between your page and the platform is.

Why Does an OG Image Stay Cached After You Change It?

Facebook, LinkedIn, Slack, and most other platforms do not re-read your page every time someone shares its link. The first time a URL is shared, the platform's crawler fetches the page once, reads the og:image, og:title, and og:description tags, and stores that snapshot keyed to the exact URL string.

Every future share of that same URL pulls the stored snapshot instead of re-fetching the page. This is deliberate — re-crawling every page on every share would be wasteful for the platform and slow for the person sharing. The snapshot is keyed to the URL, not to the image file, so changing the file on your server does nothing until something tells the platform to look again.

How Do You Force Facebook and LinkedIn to Re-Scrape Your Page?

Both platforms publish a debugging tool that exists specifically to trigger a fresh crawl on demand.

1. Open Facebook's Sharing Debugger and paste in the exact URL you shared.
2. Click “Scrape Again” — this forces Facebook's crawler to re-fetch the page right now, ignoring the stored snapshot.
3. Confirm the new image, title, and description show up in the debugger's preview.
4. Open LinkedIn's Post Inspector and paste the same URL.
5. Click “Inspect” — LinkedIn re-crawls the page the same way and shows you the refreshed preview.
6. Re-share the link. Both platforms now serve the updated snapshot to anyone who opens it.

This clears the cache on Facebook, Instagram, and LinkedIn because all three expose a public, official way to force it. Not every platform does.

What Do You Do When There Is No Official Refresh Tool?

Slack, X, iMessage, and most chat apps unfurl links the same way — crawl once, cache by URL — but none of them ship a public tool that lets you trigger a re-crawl on demand.

Since the cache is keyed to the exact URL string, the reliable workaround on platforms without a refresh tool is to change the URL. Append a query parameter the platform has never seen — ?v=2, ?og=refresh, a build hash, anything unique — and share that version instead. The platform treats it as an unseen URL and crawls it fresh, pulling your current og:image.

Why Does This Get Worse as a Site Grows?

One stale preview on one landing page is a five-minute fix — open the debugger, click the button, done. The problem compounds on a site with dozens or hundreds of dynamic pages: blog posts, product pages, category pages, each with its own preview image that changes whenever the content changes. Re-scraping each one by hand, on every platform, every time content updates, does not scale past a handful of pages.

This is the exact gap the OG Image Generator Boilerplate is built to close. Instead of one static image file per page that goes stale the moment content changes, each page's preview is generated on request from a template endpoint — point og:image at /api/og/[template]?title=… and the query string itself becomes part of the URL the platform caches. Change the title or template parameter and the platform sees a new URL automatically, without a manual re-scrape.

That structural fix matters most for sites that publish or update pages often. If you only ship one or two static pages a year, the manual debugger workflow above is genuinely enough — you do not need a templating layer for a page you will not touch again.

Does It Matter If the og:image Tag Is Rendered on the Server?

Yes, and this is the most common reason a fix looks like it should work but doesn't. Facebook's, LinkedIn's, and Slack's crawlers fetch the raw HTML your server sends and read the og:image meta tag from that response — they do not run your page's client-side JavaScript. If your framework injects or swaps the meta tag after the page loads in a browser (a common pattern in single-page apps that update <head> tags on the client), the crawler never sees the updated value, because it never executes the script that would set it.

Check this by fetching the page with a plain request instead of a browser — for example curl -s https://yoursite.com/page | grep og:image — and reading the tag straight out of that response. If the value there is stale or missing even though the browser shows the right image, the fix is on the server-rendering side, not the social platform's cache, and no amount of re-scraping in Facebook's debugger will change what the crawler receives.

This is also why a file-based image convention beats a hand-written meta tag for anything dynamic. When each page's OG image comes from a route that runs on the server and returns a real image response, the og:image value is correct in the very first HTML the crawler fetches, with no client-side timing gap to get wrong.

Does a Query-String Cache Fix Break Anything Else?

No, as long as the destination page itself does not depend on that query string for its logic. The parameter exists purely to give the social platform's cache key something new to look at; your page can ignore it entirely. The one thing to watch is analytics — a query string that changes on every share can fragment a single page's traffic across multiple “URLs” in tools that treat query strings as distinct pages, so strip or normalize it before it reaches your analytics event, not before it reaches the social crawler.

What Should You Check Before You Ship an OG Image Fix?

Confirm the fix worked by pasting the URL back into Facebook's Sharing Debugger or LinkedIn's Post Inspector and reading the preview it renders, not by trusting your own feed — your browser and the platform's crawler are two different caches, and clearing one does nothing to the other. If the debugger still shows the old image after a scrape, check that the og:image tag actually changed in the page's server-rendered HTML, not just in client-side JavaScript the crawler never executes.

Generate a page's OG preview from a template with a query string that changes automatically and you get the cache-busting behavior above for free, on every page, without remembering to visit two separate debugger tools every time content changes. Browse the full BuyCoded catalog and see the boilerplate's templates and setup — it takes a few minutes to wire an existing Next.js project to it.

Browse the BuyCoded catalog to see the OG Image Generator Boilerplate alongside the rest of the products, compare what each one ships, and download the one that fits your stack.