Troubleshooting
Why is my X card not showing?
Twelve causes of missing or wrong X (Twitter) cards, in the order worth checking: tags, image URL and size, robots.txt, redirects, firewalls and the card cache.
Short answer
Most X cards fail for one of a few reasons: twitter:card is missing or misspelled, the image URL is relative, private, too large or an SVG, robots.txt or a firewall blocks Twitterbot, the tags are added by JavaScript, or X is still showing a cached card.
Key takeaways
- Start with the HTML: view source and confirm twitter:card and an absolute og:image or twitter:image.
- Then check access: robots.txt, firewall and bot protection rules, redirects and TLS.
- Then check the image: under 5 MB, a supported format, publicly reachable.
- Finally suspect the cache, and test with a fresh query string.
You post a link, and the preview never comes. Or it comes with last month's image. Card problems are frustrating because you cannot see what X saw. You can, though, narrow it down quickly if you check things in the right order: the page first, then access, then the image, then the cache.
Is the markup actually there?
Check the HTML the server sends, not what your browser shows after JavaScript runs. Open View Source and search for twitter:card.
- twitter:card missing or misspelled. It must be exactly
summary,summary_large_image,playerorapp.summary-large-imageandlarge_imagedo not work. - Tags injected client-side. If your single-page app adds meta tags in the browser, Twitterbot never sees them. Render tags on the server or at build time.
- Tags outside the head, or broken HTML before them. An unclosed quote or a stray
<body>early in the document can make parsers stop reading. Keep social tags near the top of<head>.
Paste the source into the Card Preview & Meta Inspector to see which values X would pick up.
Can Twitterbot reach the page?
X has to fetch the page itself, so anything that blocks bots blocks your card.
- robots.txt. X's troubleshooting guide names a blocking robots.txt as a cause of missing card data, and says Twitterbot follows Google's robots.txt rules. A
Disallow: /underUser-agent: *blocks it unless you add a more specific group forTwitterbot. Details in the robots.txt guide. - Firewalls and bot protection. WAF rules, "block AI crawlers" switches, country blocks and JavaScript challenges can stop Twitterbot even when robots.txt allows it. Check your security logs for requests with a
Twitterbotuser agent and what status they got. - Redirect chains and meta refresh. Server-side 301 and 302 redirects are followed. A
<meta http-equiv="refresh">or a JavaScript redirect is not; the crawler reads the tags on the page it was given. - TLS and response size. The guide says the crawler needs TLS 1.1 or newer and has a 2 MB limit on page responses. Very large HTML pages with inline data can hit that, and tags near the end of a huge head may be missed.
Is the image acceptable?
The image is fetched separately, and it fails more often than the page.
- Relative URL.
content="/images/card.png"will not work. Use the fullhttps://address. - Not public. The guide says the most common cause of image errors is that the
twitter:imageis not publicly accessible. Signed URLs that expire, hotlink protection and images behind a login all fail. Open the image URL in a private window to check. - Wrong format or size. It must be under 5 MB and a JPG, PNG, WEBP or GIF. SVG is not supported. Large image cards want 2:1 and at least 300x157; summary cards at least 144x144. The image checker tests a file against these rules.
Is it just the cache?
If the page used to have different tags, X may still be using the old ones.
- Page cache on X. X's troubleshooting guide says the crawler re-indexes a page's tags roughly every seven days. Test changes with a new URL variant such as
?v=2. - Image cache. Images are cached by URL separately from the page. If you replace an image but keep its file name, X can keep the old picture. Give the new image a new name or add a version parameter to its URL.
Refreshing a card covers both in detail. Remember that your own CDN may also be caching an old version of the HTML.
A one-minute checklist
| Check | How |
|---|---|
| twitter:card present and valid | View source, search twitter:card |
| Title, description, image present | Inspector "What X would use" table |
| Image URL absolute and public | Open it in a private window |
| Image under 5 MB, JPG/PNG/WEBP/GIF | Image checker |
| robots.txt allows Twitterbot | Read /robots.txt; look for Disallow |
| No bot challenge or WAF block | Security logs, filter by user agent |
| Final URL answers 200 with HTML | curl -I -A Twitterbot https://your.page/ |
| Cache ruled out | Post the URL with ?v=2 in the composer |
The curl line is a useful sanity test: it sends a request with a user agent containing "Twitterbot" so you can see what status and headers a bot-shaped request gets. It does not prove X itself is allowed, because some firewalls verify bots by IP address, but a 403 here tells you a lot.
Still nothing?
Post the link in the X composer once more with a brand-new query string. If the preview is still missing and every check above passes, look for anything that changes the response by user agent, such as A/B testing tools, consent walls or geo redirects. Pages that show a cookie or age gate to unknown visitors often show it to Twitterbot too, and the gate page's tags are what end up on the card.
Questions
My card works on LinkedIn but not on X. Why?
Usually a missing twitter:card (LinkedIn does not need it), an SVG or oversized image, or a rule that blocks the Twitterbot user agent specifically. Check each in turn.
Card shows on desktop but not in the app?
Both use the same stored card, so this is usually timing or caching in the app. Try a fresh query string on the URL and re-open the composer.
How long does a fix take to show?
A new URL is fetched when it is posted. For a URL X already has, its troubleshooting guide says tags are re-read roughly every seven days, so test with a modified URL rather than waiting.
Does X follow redirects when fetching a card?
Yes for normal server redirects; the card comes from the final page. It does not follow meta refresh or JavaScript redirects, so the tags must be on the page that answers with HTML.