Why the same link can show a different preview across social platforms

First decide whether the link or the card is wrong

Open the exact link from the published post. If it reaches the intended page, the problem may be presentation rather than navigation. Record whether the title, description, thumbnail, or entire card is missing. Also note whether the issue appears in the composer preview, the final post, or only one client. Those observations narrow the investigation much more than a screenshot captioned 'the link does not work.'

Bluesky documents a concrete card model: a client fetches and embeds an external object's URI, title, description, and optional thumbnail into the post record. The card is not simply a live view of your website. That means changing the page later does not establish that an existing embedded card will change. Other networks and posting paths should be checked against their own current behavior rather than assumed to match Bluesky.

Check the page and image independently

Use a logged-out browser to inspect the final page and its chosen image. Follow any redirects and confirm the content is available without a session. A thumbnail that loads for you from a private dashboard may be unavailable to a platform fetcher. If you control the website, check the metadata in the returned HTML as well as what appears visually after client-side rendering.

The Open Graph protocol defines properties such as title, type, image, and URL. These give publishers descriptive inputs; they do not force every client to display an identical card. Use a representative image, an absolute public URL, and a title that matches the page. If the problem began after an image or hostname change, verify that the old and new references are not mixed across deployments.

1. Copy the exact published URL, including tracking parameters, and follow its redirects.
2. Check that the final page and intended image respond without authentication.
3. Compare the page's metadata with the actual card title, description, and image.
4. Compare the same URL in a native composer and the publishing tool without sending repeated public posts.
5. Record whether the issue affects a new preview, an existing post, or both.

Compare posting paths without assuming a universal rule

For an illustrative comparison, the website says 'Spring workshop' while an older Bluesky card says 'Workshop registration.' Verify whether the older wording was embedded when the post was created. If a new native preview differs from a new tool preview, the integration's card construction may be relevant. If both are wrong, inspect the website and any documented caching behavior before changing the publishing workflow.

For Threads or another destination, repeat the observation rather than importing a Bluesky diagnosis. A network can have different rules for attachments, card selection, and refresh behavior. Multiple URLs or an attached image can make comparisons less controlled. Begin with one URL and no unrelated attachment, then add the real post's other elements to identify the change that affects presentation.

Repair the responsible layer and verify a reader's path

If the website metadata is wrong, correct it at the source. If the integration is embedding the wrong information, give support the page URL, expected card fields, destination post URL, and a native-versus-tool comparison. For a stale public post, use only the platform's supported correction options. Repeatedly appending arbitrary query parameters can create confusing variants without repairing the underlying cause.

A successful repair means the reader can identify the destination and reach the right page. It does not require pixel-identical cards across every app. Keep important context in the post's visible text so the message still makes sense when no card is shown. In Ferryman, check the integration and final destination output; a preview in one workflow is not a guarantee of every network's rendering.