No traditional cache

Bluesky has no server-side link preview cache. No background crawler re-fetching URLs, no cache TTL, no debugger tool.

Card data is fetched once at post creation time and permanently embedded in the AT Protocol post record. There is nothing to expire or refresh.

Immutable post records

When you create a post with a link, the client:

1. Calls CardyB to fetch and parse the page’s OG tags
2. Downloads the og:image, compresses it under 1 MB, and uploads it as a blob
3. Writes the title, description, URI, and blob reference into an app.bsky.embed.external record
4. Publishes the post record to the AT Protocol network

Once published, this record is immutable. The card data is part of the post itself, not fetched dynamically when someone views it. Updating your OG tags after the fact changes nothing about existing posts.

Two posts, two different cards

There’s no shared “cached version” of a URL. Each post contains its own snapshot of the OG data from the moment it was created. Two users posting the same URL an hour apart can end up with different cards if the page changed in between.

Delete and re-post

If a card shows wrong information, the only fix is to delete the post and create a new one. There’s no way to edit embed data on an existing post.

No debugger tool

Bluesky has no Card Validator or Sharing Debugger. To preview what CardyB will return without publishing a post:

curl "https://cardyb.bsky.app/v1/extract?url=https://example.com/your-page"

This returns the JSON the Bluesky web app uses to construct the card.

API-level spoofing

Since the AT Protocol is open, any API client can construct app.bsky.embed.external records with arbitrary title, description, and image data that don’t match the actual page. This is inherent to the protocol’s design, and link cards on Bluesky don’t guarantee accuracy about the linked page.