twitter:card type is explicitly set
Why it matters
Without an explicit twitter:card tag, Twitter/X selects the card type automatically based on available OG tags. This fallback produces inconsistent results: pages with large hero images may get a summary card (small thumbnail) instead of summary_large_image, and the card format can differ between share events as Twitter's heuristics change. The twitter:card type determines whether your link preview shows a prominent full-width image or a small inline thumbnail. Per the Twitter Cards spec, explicit configuration is the only way to guarantee card format. A page that should render with a large image card but falls back to a summary card shows a thumbnail that competes poorly in image-forward social feeds.
Severity rationale
High because the absence of an explicit twitter:card declaration puts card type selection under Twitter's control, producing inconsistent preview formats that may significantly underperform the intended design.
Remediation
Set twitter:card in the root layout as a default, then override per content type where needed:
// app/layout.tsx
export const metadata: Metadata = {
twitter: {
card: 'summary_large_image',
},
}
The summary_large_image type is appropriate for most content pages. Override with summary on utility pages like /login, /settings, and /404 where a large image card is not appropriate. This single root layout addition is the minimum required to pass this check.
Detection
-
ID:
twitter-card-type-set -
Severity:
high -
What to look for: Check for explicit
twitter:cardconfiguration across the project. In Next.js App Router, look formetadata.twitter.cardin layout or page files. For other frameworks, look for<meta name="twitter:card">tags. Twitter/X does not require explicit card tags if OG tags are present — it will fall back — but explicit configuration is strongly preferred to ensure correct card type rendering. Count every page template and enumerate which include twitter:card, twitter:title, twitter:description, and twitter:image tags. -
Pass criteria:
twitter:cardis explicitly set at least in the root layout (as a default), with appropriate overrides for content pages that need a different card type. At least 1 implementation must be confirmed. -
Fail criteria: No
twitter:cardis set anywhere in the project. (Note: if OG tags are fully present, Twitter will render a card, but the card type is undefined — this still fails this check.) -
Skip (N/A) when: Project type is
apiwith no public-facing pages. -
Cross-reference: The
twitter-card-type-appropriatecheck verifies the card type is correctly matched to the content type. -
Detail on fail:
"No twitter:card meta tag set anywhere in the project. Twitter/X will use OG fallback but card rendering type is uncontrolled." -
Remediation:
twitter:cardcontrols how your link previews appear on Twitter/X. Without it, Twitter chooses a card type automatically, which may not be what you want. Set it explicitly:// app/layout.tsx — root default export const metadata: Metadata = { twitter: { card: 'summary_large_image', }, }For pages where a large image card is not appropriate (e.g., a simple profile page), override with
summary. Thesummary_large_imagetype produces a prominent image-forward card and is appropriate for most content pages.
External references
- external · twitter-cards — Twitter Cards — Cards Markup Tag Reference
Taxons
History
- 2026-04-18·v1.0.0·Initial import from marketing-social-sharing·automated