Twitter Cards: which tags you still need, and which are redundant
Most of what people write in the twitter: namespace is a second copy of markup they already have. One tag in it is genuinely not expressible in Open Graph, and the rest is a decision about how many places you want to keep the same sentence.
The short answer
X reads Twitter Card tags first and falls back to Open Graph for anything missing, so most twitter: tags duplicate og: tags for no gain. One exception is real: twitter:card itself, which decides whether the link renders as a large image or a small thumbnail, and Open Graph has no equivalent for it.
What X reads first, and what it falls back to
The card markup was introduced as its own vocabulary, and it has been documented for years as falling back to Open Graph. A twitter:title takes precedence when it is present; when it is absent, og:title is used instead. The same is true of description and image.
Which means a page with a complete Open Graph set and not a single twitter: tag renders as a card. That is the fact the whole check turns on, and it is not widely believed, because the received advice is still to ship a matched pair of everything.
<!-- already present, and already read for the card -->
<meta property="og:title" content="Sharpening a carbon steel knife" />
<meta property="og:description" content="Angle, grit progression, and two mistakes." />
<meta property="og:image" content="https://example.com/img/sharpening-1200x630.jpg" />
<!-- worth writing: no Open Graph equivalent exists -->
<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:site" content="@fieldingcutlery" />
<meta name="twitter:creator" content="@mirandafielding" />
<!-- redundant: identical strings, in a second place, to go stale in -->
<meta name="twitter:title" content="Sharpening a carbon steel knife" />
<meta name="twitter:description" content="Angle, grit progression, and two mistakes." />
<meta name="twitter:image" content="https://example.com/img/sharpening-1200x630.jpg" />Note the attribute: twitter: tags use name, and Open Graph uses property. Copying a line from one block to the other and changing only the prefix produces a tag nothing reads, which is the same trap the Open Graph guide describes from the other direction. Readers are mostly forgiving about this and there is no reason to rely on it.
The one tag Open Graph has no equivalent for
twitter:card selects the shape of the card, and there is nothing in Open Graph that expresses it. Two values matter in practice. summary is the compact card with a small square thumbnail beside the text. summary_large_image is the wide card where the picture is the object and the text sits beneath it.
That choice is not cosmetic, because it decides which crop your image goes through. Declare summary and your 1200 by 630 picture is squeezed into a small square, which is how a carefully composed image ends up as an unreadable smudge next to two lines of text. Declare summary_large_image and the wide frame is used as authored. Most content pages want the second one, and the reason to think about it at all is that the default, when the tag is missing, is the compact form.
The other two values in the vocabulary, app and player, exist for app install cards and for embedded media, and both come with their own required tags. If you are not shipping an app or a video player, they are not decisions you have.
twitter:site and twitter:creatorare account handles, and what any platform chooses to display from them is the platform's decision, not yours.
X has changed how much text and attribution a card renders more than once, and it will change again. Two handles in a layout template cost nothing and stop being your problem; treating their display as a feature you are building toward is how you end up rewriting markup because someone else shipped a redesign.
Reading a namespace one fetch does not carry
The manual version is a single command: curl -s https://example.com | grep 'twitter:'. What that gives you is one page. The question worth answering is whether your templates emit these tags consistently across a site, and whether the copies still match the Open Graph values they were pasted from.
This one needs the full crawl
The twitter: namespace is not in the single-page payload we read, so confirming which of those tags exist means parsing the head of every page, which is what the full crawl does.
The instant search on this site audits a single page, so rather than show you a verdict it cannot support, this guide sends you to the place the check actually runs.
Two copies of one sentence, drifting apart on their own
The argument against a duplicated set is not that the tags are harmful. It is that a duplicated string is a string with two owners and no reconciliation. Somebody edits the headline, updates og:title because that is the one they know about, and the page now declares two different titles. Whichever reader prefers the twitter:value is serving last quarter's copy, and nothing will ever flag it.
The image version of this is worse, because it fails rather than looks wrong. A share image is renamed or regenerated at a new path, og:image is updated by the template, and a stale twitter:image pointing at the old file means one set of clients gets a picture and another gets a 404 they render as no image.
There is one situation where a separate value is deliberate rather than accidental: when the copy genuinely differs by audience, which is the argument the share copy guide makes about descriptions. If you are writing a different line on purpose, write it. The failure is duplication by default, where nobody decided anything and the second copy exists because a checklist said to have one.
And a smaller trap worth knowing about: some non-X clients read this namespace too. Several chat and collaboration tools consult both vocabularies when they unfurl a link, which is why a stale twitter:image can produce a broken preview in a workplace tool that has nothing to do with X. The tags are not as platform-specific as their prefix suggests.
Does this affect AI search?
No, and this is the clearest no in the social group. There is no retrieval pathway here at all. Card markup describes how one platform should draw a box around your link. It is not content, it is not indexed as content, and an assistant reading your page has the entire body available and no reason to consult a tag that exists to select a thumbnail shape.
The weaker claim, that another declaration of your title is another signal about your subject, does apply to twitter:title in the same trivial way it applies to any repetition. But since the recommendation on this page is to not write that tag when Open Graph already carries the value, the honest position is that doing this check properly means having fewer tags, and fewer tags cost you nothing here.
The connection that does exist is one step removed. Getting the card type right means the image renders at the ratio it was authored for, and the image is what makes a cited link worth clicking. That is a human-attention argument, not a machine-readability one.
Why a mostly redundant tag set is only a Refinement
Because the honest fix for most of it is deletion, and a finding whose remedy is to remove three lines cannot reasonably outrank a finding whose remedy is to start publishing something that does not exist. That is what the bottom of the scale is for: work that improves a page which is already functioning.
The one part of this check with a visible consequence, the card type, is a single line with a default that is merely smaller rather than broken. A compact card is a real card. It is less prominent than the wide one, on one platform, for the subset of your traffic that arrives through it.
It is worth noticing that this rating is a statement about the state of the platform rather than about the markup. When these tags were the only way to get a card, the check would have been Important. Fallback to Open Graph is what demoted it, which makes this one of the few items in the catalogue where the right answer has become smaller over time. The remaining value is in the type declaration and in the handles, and both are set once in a layout and never thought about again.
Questions this check raises
- Do I need Twitter Card tags if I already have Open Graph?
- Mostly no. X falls back to og:title, og:description and og:image when the twitter: equivalents are absent, so duplicating them creates two copies of one sentence that drift apart on the next edit. The tag worth setting is twitter:card, because the layout choice has no Open Graph counterpart.
- What is the difference between summary and summary_large_image?
- The layout. summary renders a small square thumbnail beside the text; summary_large_image renders a full-width image above it. For anything with a designed share image, the large form is what makes the card worth having, and the default without the tag is the small one.
- Does the twitter:site tag matter?
- It attributes the card to an account and shows the handle on the card in some contexts. It is a small benefit and it is the one twitter: tag besides the card type that Open Graph cannot express, so it is cheap to include if the account exists.