Check what readers will open
Twitter link preview not showing? What to check first
The link opens the right page, but its preview shows an old image or nothing at all. Find which part is wrong before changing your post or publishing it again.
On this page
The page can work while its preview is wrong
You share a guide on X/Twitter and get an old logo instead of the image you prepared. The page looks right when you open it, so you rewrite the post and try again. The same preview appears.
If your Twitter link preview is missing or wrong, check the exact shared URL, the page's sharing metadata, and the image it names. Keep a screenshot of the mismatch before changing anything. A working destination and a correct preview are separate checks.
X's instructions for posting a link explain that shared URLs go through t.co. That shortened address is normal; it doesn't tell you why an image is missing. Open the destination and inspect the preview separately rather than treating every unexpected result as a broken link.
This guide covers organic links to web pages. An image you attach to a post is a different thing from a website preview. If you don't control the website, collect the evidence and send it to its owner instead of looking for a setting on your Twitter profile.
Work through these five checks before reposting
- Open the exact URL you shared in a signed-out browser window. Check the destination after any redirects. A homepage, a page for another language, or a login screen is different from the article you intended to share. Include tracking parameters when checking the original URL, but remove private information before sending a report to anyone else.
- Inspect the page source, or ask the site owner to do it. Look for sharing metadata in the HTML head, including
og:title,og:image, andog:url. Also check anytwitter:title,twitter:image, andtwitter:cardvalues the site emits. Read their actual values; the title visible at the top of the page is not enough. - Open the image URL named by that metadata without signing in. Confirm that it returns the intended picture rather than an error page, an expired download link, or a different image. Note the final image URL if it redirects.
- If the page or image cannot be fetched, ask the site owner to inspect the response and relevant server logs. Record access errors, redirects, or an authentication requirement. A successful browser visit doesn't prove that X fetched the same response. Keep access controls in place while the owner diagnoses the public resource.
- After a confirmed correction, inspect the exact URL in X's composer without publishing a test post. Compare what appears with your saved screenshot and record when you checked. If no preview appears there, record that too; don't describe it as a successful refresh.
The Open Graph protocol defines metadata for a page's shared representation: a title, type, representative image URL, and canonical URL, with an optional description. These are useful fields to inspect. They aren't a promise that X will display every field or use a particular layout.
When your site offers a social-image setting, change the value for the affected page and publish that page update. Then check the live source again. A setting saved in an editor or a correct image in your media library doesn't establish what the public URL currently serves. Avoid adding a second metadata plugin just because you haven't located the first set of tags.
Match the correction to what you actually found
Use the evidence to narrow the next action. These are diagnostic examples, not a claim that every missing preview has the same cause.
| What you can observe | What it establishes | Next useful check |
|---|---|---|
| The page source names the old image | The published metadata still points to that asset | Correct the page's social-image value and inspect the live source again |
| The named image opens an error or login page | That request didn't retrieve the intended public picture | Ask the owner to fix the image URL or its intended public delivery |
| The current source and image look right, but X shows something else | Your current page check and X's displayed result disagree | Save both results with times; ask the owner to inspect fetch evidence before assigning a cause |
| The expected image appears, but important text is cropped | The artwork doesn't fit the display you observed | Move essential content away from the cropped area and check the revised composition |
An old image can suggest cached data, but a screenshot alone cannot distinguish that from a different response being served to the platform. Clearing your browser's cache doesn't verify X's copy. Nor does an attractive preview in another service prove what X fetched or displayed.
Don't turn adding a random query parameter into the fix. It changes the URL you're checking and doesn't correct wrong metadata on the original page. Likewise, replacing an image file is different from confirming that a published post now shows it. Keep those outcomes separate in your notes.
If the URL itself is correct and the post remains useful, a missing card isn't by itself a reason to delete the post. If the destination or written claim is wrong, use the guide to editing a tweet or publishing a correction to decide how to correct it clearly.
Send a report the site owner can reproduce
"Twitter is broken" leaves the owner to guess which page, image, and version you mean. Give them the exact mismatch and a way to repeat your check. This template is for your private troubleshooting notes:
Exact shared URL: [public URL, without private credentials]
Expected destination: [page]
Destination after redirects: [page actually reached]
Observed in X: [no preview / wrong image / unexpected crop]
Checked at: [date, time, timezone, app or browser]
Current source image value: [URL or not yet inspected]
Image request result: [intended picture / error / login / unknown]
Evidence: [screenshots and relevant sanitized response details]
Last confirmed site change: [what changed and when, or unknown]
Next owner: [website owner / publisher / platform support]
If you can't inspect the source or logs, leave those fields unknown. A screenshot is still useful evidence, but it isn't a server diagnosis. Don't send cookies, authorization headers, private preview links, or credentials to a public debugging tool.
This check doesn't require posting repeatedly. Prepare the report, make one confirmed site correction at a time, and compare the next observation with the original. A successful page correction can be recorded even when the platform's displayed preview remains unresolved.
Review clicks without treating them as a preview detector
PilotMyX can help you find the published wording and available results for a link post. It doesn't tell you which card each reader saw. Keep the preview screenshot and check time in your own notes, beside the post URL.
For a practical review, inspect original link posts from the last seven complete days alongside the previous seven, within your available history. Read the wording, publication times, impressions, and available URL clicks. Keep replies separate and note any preview problem you actually observed. Don't label every low-click post as a card failure.
X's metrics reference separates impressions from URL clicks. Non-public click metrics are available through the API only for posts created within the last 30 days; an unavailable figure isn't zero. Neither count establishes the state of the preview or the cause of a change in clicks.
Use website traffic tracking to check what happened after visitors arrived. If the destination works but the invitation is vague, improve the copy using the link placement guide. Review the full draft before saving or scheduling it in PilotMyX, and keep the website diagnosis separate from that writing decision.
Use your own account