Twitter card tags on 26 homepages: 22 declare a card, and one has drifted from og
Twitter card tags are mostly still shipped and mostly redundant. Across 26 homepages, 22 declare twitter:card and 20 pick the same value, while the stale-override failure everyone warns about happened once, on one property, on one site.
FIELD TEST · 2026-08-27 · 26 homepages · single crawl · raw HTML only
Sample and method: the same 30-site panel in use since 2026-08-15, each homepage fetched once on 2026-08-27 with a browser user agent, no rendering. We read every <meta> element whose name or property started with twitter: or og:, and recorded the value, the attribute it was written on, and whether it sat inside <head>.
Twitter card tags are mostly still shipped, and mostly redundant. Across 26 homepages we counted 113 twitter: meta tags against 158 og: ones. Twenty-two sites declare twitter:card, and 20 of those pick the same value. The failure everyone warns about — a stale twitter: value quietly overriding a fresh og: one — happened once, on one property, on one site.
How we measured it
One HTTP request per site, no rendering, no retries. Inclusion was fixed before the run: final status 200, decoded body at least 10,000 bytes, body containing <body. Four of the 30 failed — www.canva.com returned 429, stackoverflow.com and medium.com returned 403, and www.reddit.com returned an 8,393-byte shell — leaving 26. That is one site fewer than the last four batches, and the missing one is Canva's rate limit, not a change on Canva's part.
A tag counts here if the parser saw it, regardless of which attribute carried it. That matters more than it sounds: the Open Graph protocol puts its values on property and X's card tags belong on name, and two sites in this sample do it the other way round. Counting only the correct spelling would have hidden both.
# Same count on your own page
curl -sL --compressed -A 'Mozilla/5.0' https://example.com/ \
| grep -o '<meta[^>]*\(twitter\|og\):[^>]*>' | wc -lWe did not test how any of these pages actually render when shared. That would need a live post on each surface, and the card validators that used to answer this are behind a login. Everything below is what the markup says, not what a preview showed.
Twitter card tags: 22 of 26 declare one, and 20 pick the same value
The card type is the one value with no Open Graph equivalent, and it is the one most sites remember. Two homepages ship no twitter: tag at all, and one of them ships no og: tag either.
| Tag | Sites | Falls back to |
|---|---|---|
twitter:card | 22 | og:type (partially) |
twitter:title | 20 | og:title |
twitter:description | 20 | og:description |
twitter:image | 19 | og:image |
twitter:site | 15 | nothing |
twitter:image:alt | 1 | og:image:alt |
Of the 22 cards declared, 20 are summary_large_image and 2 are summary — Substack and MDN, both of which point the card at a square logo rather than a banner. Nobody in this sample uses player or app.
X's own markup reference, archived on 2024-05-14 and read on 2026-08-27, describes the rule the whole table depends on: "The table in this section explains the OpenGraph fallback behavior for each Twitter tag." Against twitter:card it adds the case that makes the tag worth keeping: "If an og:type, og:title and og:description exist in the markup but twitter:card is absent, then a summary card may be rendered." A summary card is the small square one. If you want the wide banner, that one line is what buys it.
The live URL for that reference now returns HTTP 402, and the current documentation index at docs.x.com/llms.txt lists no Cards section at all (both checked 2026-08-27). We are citing an archived copy because there is no longer a live one to cite.
Three sites declare a card and let og supply everything else
MDN, TechCrunch and The Verge each ship twitter:card and then stop. None of the three declares twitter:image; all three declare og:image. This is the fallback used deliberately, and it is the smallest correct implementation we found: one tag that picks the shape, and one set of tags that fills it.
The opposite shape also exists. The BBC ships twitter:title and twitter:description and no twitter:card — and no og:image anywhere on the page, so there is no image for the card to fall back to. Its twitter:title is 116 characters, against the 70-character maximum the archived reference states for that tag. The New York Times ships exactly one twitter: tag, twitter:site, which names the account and describes nothing.
One page has a twitter value that has drifted from its og value
Three sites have any disagreement at all between a twitter: value and its og: counterpart. Two of the three are on purpose.
vercel.com— two different images, and the filenames say why:og-home-not-x.pngagainstog-home-x.png. One banner for X, one for everywhere else.www.wired.com— the same image URL with?mbid=social_retweetappended to the X copy. That is attribution tagging, not drift.nextjs.org—og:descriptionreads "Next.js by Vercel is the full-stack React framework for the web."twitter:descriptionstill reads "Production grade React applications that scale…", the older copy. Nothing else on the page carries that sentence.
So the headline risk of maintaining two parallel sets of tags produced exactly one stale string across 26 of the most heavily maintained homepages on the web. We are not going to inflate that into a warning. It is a real cost, and it is a small one, and the number is one.
Two spelling mistakes, and neither one broke anything visible
Open Graph values belong on property; X's card values belong on name. Two sites swap them, in opposite directions.
| Site | What it writes | Count |
|---|---|---|
developer.mozilla.org | og: on name | 10 of 10 |
www.wired.com | twitter: on property | 6 of 8 |
www.netlify.com | twitter:domain on property | 1 of 5 |
We checked all three against the saved bytes rather than the parsed output, because a parser that normalises both attributes would have erased the finding. MDN's raw markup really does read <meta name="og:url" …>. Whether any consumer rejects that, we cannot say from a crawl — most parsers accept either, and we did not verify a single rendered preview.
What this means for you
The useful conclusion is a size, not a rule: the minimum honest set is four tags plus one, and everything past that is duplication you now have to keep in sync.
- Ship the four Open Graph properties the specification calls required —
og:title,og:type,og:image,og:url— and let them do the work everywhere - Add
twitter:cardalone if you want the wide banner instead of the small square one - Do not maintain a parallel
twitter:titleandtwitter:descriptionunless the two texts are genuinely meant to differ. That is where the one stale string in this sample came from - Do not write a root-relative path into an image tag. Slack's
og:imageandtwitter:imageare both/dev-cdn/v/marketing/…, and a consumer that does not resolve against the page URL gets nothing
How big that image should be, and which surface crops it where, is a separate question with a documented answer — we wrote it up as open graph image size. For how the four required properties are actually distributed in the wild, the earlier count on this panel is open graph tags on 26 homepages. And if you want to see what an engine receives from your page before any of this is parsed, see how QueryWin works.
Common questions
How did you measure this?
One request per homepage on 2026-08-27 with a browser user agent, bodies written to disk, meta elements read by an HTML parser that recorded both the attribute name and the value, and every published number recomputed from the saved files.
Are twitter card tags still needed in 2026?
One of them is. twitter:card has no Open Graph equivalent, so without it you may get the small summary card instead of the wide one. The title, description and image tags all have a documented fallback and are optional.
Which twitter card tags are required?
The archived markup reference lists twitter:card as the type declaration used with all cards, and says either twitter:site or twitter:site:id is required for summary, summary_large_image, app and player cards. In this sample 15 of 22 carded sites ship twitter:site, so seven are shipping cards without it.
What image formats does the card accept?
The same reference states: "Images must be less than 5MB in size. JPG, PNG, WEBP and GIF formats are supported. Only the first frame of an animated GIF will be used. SVG is not supported." One site in this sample points its image tags at a .svg source, routed through a CDN transform that emits something else.
Why did your crawl see a Japanese image on slack.com?
Because our exit is in Japan. Slack's image path ends hp-revamp-unfurl.ja-JP.jpg, which is a localised asset chosen by the server, not a fixed value. Any per-country measurement of these tags inherits the vantage point it was taken from, and this one is ours.
