Why Social Preview Cards Don't Update After You Fix OG Tags
Paste a link into KakaoTalk or Facebook and a preview card pops up automatically — title, description, thumbnail, all generated for you. But it's a common headache: you clearly changed the page's og:title or og:image, yet the card for a link that was already shared stays exactly the same. Refreshing over and over doesn't help, and even sending the link to someone else still shows the old card. The cause isn't your page code — it's that social platforms cache your OG tags on their own servers. This guide explains why that caching exists and how to force it to refresh.
1. Why Open Graph was created
The Open Graph protocol is a standard Facebook introduced at its f8 developer conference in 2010. Before that, when you shared a link, each platform crawled the page on its own and grabbed whatever image or text it could find, so the resulting preview was inconsistent every time. Facebook wanted to treat webpages as "objects in the social graph," so it proposed a standard set of meta tags — og:title, og:description, og:image, og:url — and most other platforms (LinkedIn, KakaoTalk, Slack, Discord, and more) later adopted the same standard as-is. Try building og:title and og:description yourself with the Open Graph Generator and you'll immediately see that these four tags are the core of the whole system.
2. Crawling only happens "once"
Here's the key mechanism: each platform crawls the page and reads its OG tag values the first time a link is shared, then stores that result on its own servers. When the same URL is shared again later, the platform doesn't revisit the actual page — it just serves the cached result. The reason is obvious: if a request went back to the origin server every single time someone pasted the link, responses would be slow and the origin site would take on unnecessary traffic load. In other words, this caching isn't a bug — it's a deliberate performance optimization. The catch is that the cache doesn't expire quickly, so changing the og:image URL or og:title on the origin page won't be reflected in an already-cached card.
3. How to force a cache refresh on each platform
| Platform | Refresh tool | Method |
|---|---|---|
| Sharing Debugger | Enter the URL at developers.facebook.com/tools/debug → click "Scrape Again" | |
| KakaoTalk | Kakao Developers Share Debugger | Request a re-check of the URL via the tool at developers.kakao.com |
| Post Inspector | Enter the URL at linkedin.com/post-inspector to trigger a re-crawl | |
| Slack | No dedicated tool | Append a dummy query string like ?v=2 to the end of the URL so it's treated as a new URL |
The common principle across all of them is explicitly telling the platform's server "please re-crawl this URL." For services without a dedicated tool, the workaround is appending a query string to the URL so it's recognized as an entirely new URL (though in that case, the card for the previously shared link stays unchanged). It's also worth double-checking how og:title and og:image should actually be marked up with the Meta Tag Generator.
4. Another reason og:image might not show up at all
Separate from the caching issue, sometimes og:image simply never gets read in the first place. If the image URL isn't an absolute path (starting with https://), if robots.txt blocks crawler access to the image, if the file size is too large (keep it under roughly 8MB), or if the og:image:width/height values don't match the actual image's aspect ratio, some platforms will skip the card entirely. The recommended image size is 1200×630px (a 1.91:1 ratio). The most reliable way to confirm your tags are actually being generated correctly is to check the rendered head with the Schema Validator or directly in your browser's DevTools Elements panel.
5. Twitter (X) behaves differently
Twitter prioritizes its own twitter:card meta tags over the OG tag set. If twitter:card isn't present, it automatically falls back to og:title, og:description, and og:image — but if it is present, Twitter reads that first. Twitter also caches the same way, so after building your tags with the Twitter Card Generator, you'll need to separately request a cache refresh through its card validation tool.
Frequently Asked Questions
Q. Does a page get cache problems even the very first time OG tags are deployed?
No. The cache only builds up for "a URL that has been shared at least once." If a page has never been shared before, the very first share will read the latest tags directly.
Q. Does refreshing with the Facebook Debugger also update the KakaoTalk preview?
No. KakaoTalk runs its own crawler and cache, so Facebook's Sharing Debugger has no effect on it. You need to use the dedicated tool provided by Kakao Developers.
Q. I refreshed the cache but the old image still shows up.
If you replaced the image file without changing the og:image URL itself, CDN- or browser-level image caching is likely the culprit. Adding a version query (e.g. ?v=2) to the end of the image URL turns it into a new URL and guarantees a refresh.
Q. Do Open Graph tags affect search ranking too?
Not directly. OG tags are for social share previews, while Google's search snippet primarily uses the title tag and meta description. That said, a more compelling share card can indirectly drive more traffic through clicks.