Why this happens

Preview card data doesn’t federate. Every instance fetches your page independently and maintains its own cache. If you change your OG tags at 2:00 PM:

• Instance A fetched at 1:00 PM and shows the old data
• Instance B fetches at 3:00 PM and shows the new data
• Instance C hasn’t fetched yet, so it will show whatever is current when someone shares it there

The fediverse hug of death

When a post goes viral and gets boosted across hundreds of instances, each one fetches your page independently. If your server can’t handle the burst, returning errors or timing out for some requests, those instances cache a failed state (no card at all), while instances that got through show a normal card. The result is a patchwork of working and missing previews across the fediverse.

Tag changes while a post is spreading

If you fix a typo in og:title while a post is actively being boosted:

• Instances that already fetched see the typo
• Instances that fetch afterward see the correction
• Both versions persist in their respective caches for 14 days

Minimizing inconsistency

• Get your tags right before sharing, as this is the only reliable strategy
• Put your pages behind a CDN that can absorb distributed fetch traffic from hundreds of instances at once
• Make sure your server responds within Mastodon’s strict timeouts (5s connect, 10s read)
• Don’t change tags after sharing, since there’s no way to force a coordinated refresh

No universal fix

There’s no tool to clear the cache across all instances. Each one is independently operated. Inconsistencies persist until the 14-day cache TTL expires naturally.

For critical corrections, you can contact admins of large instances (like mastodon.social) and ask them to run tootctl, but this doesn’t scale.