Telegram Shows the Open Graph Image but LinkedIn Does Not: Debugging Social Preview Caches

After changing a cover image or SEO metadata, you may see a strange result: Telegram already displays the new og:image, while LinkedIn still shows the old image or no image at all.

The first reaction is usually simple: "Open Graph is configured incorrectly."

But if one platform already reads the correct image, that is a strong signal that the problem may not be the tags themselves. It may be when and how a particular platform last crawled the page.

Telegram, LinkedIn, and other services do not have to fetch a page at the same time.

Each service has its own crawler, re-fetch behavior, and cache.

The same URL can therefore show different previews on different platforms at the same moment.

Do not start by blaming cache until you confirm that the current HTML response actually contains the expected values.

This matters especially for client-rendered applications. If meta tags change only after JavaScript runs in the browser, a social crawler may never see them.

For that case, SSR or server-rendered meta tags are often essential.

If Telegram already shows the correct image, og:image is probably reachable by at least one external crawler.

Still, verify the full tag set, absolute URLs, and the absence of conflicting values.

The image must be reachable without authentication or a private browser session.

Check the HTTP status, Content-Type, redirects, and whether a crawler can actually fetch the file.

If the URL works only in your browser because of cookies or private access, a social platform may fail to retrieve it.

Imagine that /media/post-cover.jpg was replaced with a new file while the URL stayed the same.

Your browser may show the new file correctly, especially after clearing local cache.

But a social platform may already have cached the old asset under that URL and have no reason to download it again immediately.

That is why "I changed the tag" does not automatically mean "LinkedIn already sees the new tag."

The first debugging goal is to identify which layer still holds the stale state.

If Telegram shows the new cover, that proves Telegram was able to retrieve it.

It does not prove that LinkedIn has re-crawled the page.

Likewise, an old LinkedIn preview does not prove that the current Open Graph markup is wrong.

Another separate case appears when a link was already attached to a post and the page or cover changed later.

Even after the URL is re-crawled, the card already attached to an existing post may behave differently from a fresh insertion of the same link.

During debugging, compare a newly generated preview with the card that was already attached to an older post.

This is one of the most frustrating traps.

When a preview looks wrong, it is easy to start changing SSR, meta tags, canonical URLs, or media generation even though the current HTML is already correct.

You can create a new bug while trying to fix a stale cache.

The important idea is not the exact query format. It is that changed image content can receive a new resource identifier.

This reduces dependence on when an external crawler decides to refresh the old URL cache.

In a Vue/Inertia application, the browser may show the correct title and meta after hydration while a social crawler only sees the initial HTML response.

That means checking DevTools after the page fully loads is not always enough.

A stronger check is to inspect raw HTML with curl or another client that does not execute JavaScript.

Normally, the page should serve the same Open Graph data regardless of crawler.

If a reverse proxy, middleware, or bot-protection layer changes the response for a particular User-Agent, that becomes a separate cause of incorrect previews.

If it is unclear whether the platform actually revisited the page, web-server logs can help.

They may show request time, User-Agent, HTTP status, and whether the crawler fetched the og:image resource separately.

This is stronger evidence than assuming that a manual refresh action necessarily caused a new crawl.

When Telegram already sees the new Open Graph image while LinkedIn still shows the old one, that is not a reason to immediately rewrite your SEO logic.

First prove the current server HTML, og:image accessibility, HTTP response, and SSR output.

If those are correct, the next suspect is the platform-specific cache or an already stored card attached to an older post.

Debug social preview as a chain: HTML -> image URL -> HTTP -> crawler -> platform cache -> specific post card.