Why Your Link Preview Is Not Showing on X, Threads, Bluesky or LinkedIn and How to Fix It
When a link preview fails to appear, shows the wrong image or keeps an old headline, the cause is almost always in one of three places: the page's metadata (the Open Graph and Twitter card tags in the HTML head), the platform's access to that page (its crawler was blocked, redirected or served something else), or the platform's cache (it fetched the page earlier and is still showing that version). Fixing it means finding which of the three is responsible, and knowing that each platform builds and stores previews differently. A fix that works instantly on LinkedIn does nothing for a post already published on Bluesky.
How a link preview is actually built
A link preview is not a screenshot. When you paste a URL, the platform, or on some networks your own app, requests the page and reads a small set of tags from the HTML <head>:
html
<meta property="og:title" content="How we rebuilt our newsletter archive">
<meta property="og:description" content="What moved, what broke, and what readers asked for.">
<meta property="og:image" content="https://example.com/images/archive-card-1200x630.jpg">
<meta property="og:url" content="https://example.com/blog/newsletter-archive">
<meta name="twitter:card" content="summary_large_image">The Open Graph tags (og:) originated at Facebook and are now read by most platforms. X also reads its own twitter: card tags, most importantly twitter:card, which decides between a large-image card (summary_large_image) and a small thumbnail card (summary), and falls back to Open Graph for the title, description and image when its own tags are missing.
Everything the platform shows comes from that <head>, as the requesting server sees it at the moment it asks. It does not see what a browser displays after JavaScript runs, cookies are accepted or a login completes. Whether the link points to a news article, a product page, a browser game, a web app or a homepage such as the Crazy Tower kasyno one, the preview reflects only what the platform's request received. That single fact explains most failures.
Why each platform fails differently
The general mechanism is shared, but where the preview is built, and when, differs a lot between platforms. That changes how you fix it.
X
X builds cards on its own servers, fetching the page with its crawler, which identifies itself as Twitterbot. The card is cached on X's side, so a page fixed after it was first shared can keep showing the old version for some time.
The presentation of link cards on X has changed several times. In late 2023, X removed the headline and description text beneath link images, leaving an image-led card with the domain. Since then, the display of titles and the way links open have been adjusted and tested more than once. In October 2025, X announced a test of a new link experience on iOS, keeping the post's engagement controls visible while the linked page is open. Because the interface varies by app version and test group, "the preview looks different from last year" is not necessarily an error on your side.
X no longer offers a card validator that renders a preview; it was reduced to a basic check some years ago. The practical test is to paste the link into the post composer and look at the preview there, without publishing.
Meta platforms, Facebook and Threads
Facebook fetches pages with its own crawler (facebookexternalhit) and caches the result. Meta's Sharing Debugger shows exactly what the crawler received, lists missing or invalid tags, and has a button to fetch the page again, which refreshes the cache for future shares. Threads also generates previews from page metadata, following the same Open Graph conventions.
LinkedIn works the same way: server-side fetch by LinkedInBot, then a cache. Its Post Inspector shows what LinkedIn sees and refreshes the cached data. LinkedIn caches aggressively, so the inspector is usually the only quick way to replace an outdated image or title.
Bluesky
Bluesky is fundamentally different, and this is where much of the confusion comes from. On the AT Protocol, which Bluesky is built on, a link card is part of the post itself. When you compose a post in the Bluesky app, the app fetches the page's metadata (through a helper service) and embeds the title, description and a thumbnail into the post record when you publish.
Two consequences follow. First, fixing your page's metadata does not change posts already published. The card was written into the post and is displayed as stored. The only way to get a corrected card on Bluesky is to post again. Second, the card depends on the app you used. Third-party Bluesky clients generate cards their own way, and some post links without one.
Mastodon and the fediverse
Mastodon has a third model. Each server fetches the page independently when a post containing the link reaches it. A popular post can therefore trigger hundreds or thousands of requests to the same page within minutes, from servers all over the network. Sites with aggressive rate limiting or bot protection often block part of this traffic, so the same post shows a card on some servers and none on others.
Mastodon also supports a fediverse:creator meta tag, which lets a page name its author's fediverse account so that the preview can show an author byline linking to that profile:
html
<meta name="fediverse:creator" content="@author@example.social">The most common causes, and what to check
The tags are missing or added by JavaScript
On single-page applications and many modern site builders, metadata is inserted into the page by JavaScript after it loads. Browsers see the tags. Link-preview crawlers generally do not run JavaScript. They read the initial HTML, and if the tags aren't there, there is no card. The fix is server-side rendering or pre-rendering of the <head> for shareable pages. Framework features that manage metadata only on the client do not solve it.
The image URL doesn't work for the crawler
A surprising number of failures come from the og:image itself:
A relative URL (
/images/card.jpg) instead of an absolute one (https://example.com/images/card.jpg).An image that is too large, or in an unsupported format. Each platform sets size limits. X's documentation for large image cards specifies a 2:1 aspect ratio, a maximum file size of 5 MB, and JPG, PNG, WEBP or GIF formats. An image around 1,200 × 630 pixels works well across most platforms.
An image blocked separately by hotlink protection or a CDN rule, even though the page itself is reachable.
An image behind a signed or expiring URL, which works when the crawler first fetches it and fails afterwards.
The crawler is blocked
This is the most underestimated cause. Firewall rules, bot protection services, geo-blocking and rate limits are designed to stop automated traffic, and preview crawlers are automated traffic. A site can work perfectly in every browser while X, LinkedIn or Mastodon servers receive a challenge page, a 403 error or a redirect to a cookie wall, and build a card from that page, or build none.
Robots.txt matters too. Some crawlers, including X's, respect robots.txt, so a blanket Disallow rule can block previews. Allowing the preview crawlers explicitly avoids that:
text
User-agent: Twitterbot
Allow: /
User-agent: facebookexternalhit
Allow: /
User-agent: LinkedInBot
Allow: /You can approximate what a crawler receives with a request that sends its user agent:
bash
curl -sL -A "Twitterbot/1.0" https://example.com/blog/newsletter-archive | grep -i 'og:\|twitter:'If the output is empty, or shows a challenge page instead of your tags, the problem is access, not markup. A user-agent test is only an approximation: some protection services verify crawlers by IP address, not by user agent. The platforms' own debugging tools remain the definitive check.
Redirects, logins and consent walls
Crawlers follow redirects, but only up to a point, and they read metadata from the final page. A link that redirects to a login page, a regional homepage or a consent screen produces a card for that page, not the one you intended. URL shorteners and tracking redirect chains add more points where this can go wrong.
The platform is showing a cached version
If you fixed the page but the old title or image persists, the platform is serving its cache. On Facebook and LinkedIn, use the Sharing Debugger or Post Inspector to fetch again. On X there is no public refresh tool; the cache expires on its own after a while. A common workaround is to share a new URL variant, for example with an added query parameter (?v=2), which the platform treats as a different page. Only do this if your site returns the same page and canonical URL for the variant. On Bluesky, as explained above, existing posts never update.
Link previews and reach, what is known and what isn't
A persistent claim is that posts with links get less distribution, or that a missing card "kills" a post. The evidence is mixed and platform-specific, so it is worth separating what is documented from what is assumed.
What is documented: platforms control how links are displayed, and those displays change. On X, head of product Nikita Bier acknowledged in October 2025 that creators commonly complain that posts with links get lower reach. His explanation was that the in-app browser covers the post, so people forget to like or reply, and the platform gets weaker engagement signals. The new link experience being tested was designed to address that.
What is not established: a universal rule that any platform suppresses all external links, or that a particular card format guarantees more distribution. Creator experiments and anecdotes are real, but they rarely control for content, timing and audience. A failed card does reduce clarity, because a bare URL gives readers less reason to click, but that is a user-behaviour effect, not a documented ranking rule.
The practical advice holds regardless: write the post so it makes sense without the card, and make sure the card works when it appears.
A quick diagnostic sequence
When a preview is wrong or missing, work through the causes in order of likelihood:
View the page source (not the rendered page) and check that the
og:andtwitter:tags are present in the initial HTML, with an absolute image URL.Open the image URL directly in a private browser window to confirm it loads without cookies or login.
Run the platform's debugger where one exists: Meta's Sharing Debugger for Facebook, LinkedIn's Post Inspector. These show exactly what the crawler received.
Check access with a user-agent request, and review firewall, bot protection and geo-blocking logs for blocked crawler requests.
Refresh the cache with the debugger, or share a URL variant on X.
On Bluesky, repost after fixing the page. Existing posts will not change.
What to watch toward 2027
Two trends are likely to make link previews a more frequent problem, not a less frequent one.
The first is the spread of decentralised networks. On Bluesky, the preview is a snapshot stored in the post. On Mastodon, every server fetches the page separately. Both behave very differently from the cache-and-refresh model most site owners learned on Facebook and X, and bot protection tuned for the old model will increasingly break previews on the new ones.
