Open Graph Tags vs. Twitter Card Tags for Website Link Previews

Open Graph (OG) tags describe a page for social sharing and link previews. Twitter Card tags use the twitter: namespace to specify presentation for X and provide optional X-specific overrides. For most sites, start with the four required OG properties—og:title, og:type, og:image, and og:url—then add twitter:card for the X card layout you want. Add separate Twitter title, description, or image tags only when that content should differ.

Tags are instructions to crawlers, not a guarantee of the final rendering. Check the page’s rendered HTML and the actual destination platform; parsers, image constraints, and cached previews can affect what people see.

1. What each tag system does

Open Graph: a page’s shared identity

The Open Graph Protocol describes a web page or object for social graph representations. Its four required properties are og:title, og:type, og:image, and og:url. Optional fields add context such as a description, site name, locale, and image details.

Twitter Cards: X-specific presentation

Twitter Card metadata uses names such as twitter:card, twitter:title, and twitter:image. The twitter:card value specifies a card presentation type. This guide uses summary_large_image as an illustrative choice; check the result on X rather than assuming a tag guarantees a particular display.

2. Comparison at a glance

Question	Open Graph	Twitter Card / X metadata
Purpose	Describe a page or object for social graph use and previews.	Specify X card presentation and optional X-specific content.
Tag syntax	`<meta property="og:title" content="…">`	`<meta name="twitter:card" content="…">`
Core fields	`og:title`, `og:type`, `og:image`, `og:url` are protocol-required.	Use `twitter:card` to declare a card type; current complete X requirements were not confirmed in the research for this guide.
Overlap	Provides broadly useful shared metadata.	Some implementations use OG values as fallbacks; behavior can depend on the platform or CMS.
When to add explicit values	Always provide the required core values for an OG baseline.	Add title, description, or image overrides when X should show different content.

3. Recommended baseline markup

Place metadata in the document’s <head>. Substitute the canonical URL, real title, summary, and an image URL that is publicly fetchable by the destination crawler.

<!doctype html>
<html prefix="og: https://ogp.me/ns#" lang="en">
<head>
  <meta charset="utf-8">
  <title>Page title</title>
  <link rel="canonical" href="https://example.com/page">

  <meta property="og:title" content="Page title">
  <meta property="og:type" content="website">
  <meta property="og:url" content="https://example.com/page">
  <meta property="og:image" content="https://example.com/share-image.jpg">
  <meta property="og:description" content="A concise page summary.">
  <meta property="og:site_name" content="Example">
  <meta property="og:image:alt" content="Description of the preview image">

  <meta name="twitter:card" content="summary_large_image">
</head>
<body>Page content</body>
</html>

The Open Graph protocol says a page specifying og:image should also specify og:image:alt. It defines optional image properties for details such as secure URL, MIME type, width, and height. Include those details when useful and accurate; do not invent values or treat them as a universal platform size requirement.

4. When to add separate Twitter values

If X should show the same title, description, and image as the general OG preview, the OG baseline plus twitter:card may be enough in an implementation that falls back to OG. Yoast’s documented behavior is one example: its X output uses OG metadata for many fields and emits separate title or description values when different values are configured. That describes Yoast, not every CMS or crawler.

If X needs different copy or artwork, state those values explicitly:

<meta name="twitter:title" content="Shorter title for X">
<meta name="twitter:description" content="A distinct X summary.">
<meta name="twitter:image" content="https://example.com/x-share-image.jpg">

Do not add overrides just to duplicate identical values without a reason. Keeping one shared source of truth reduces maintenance and the chance that one preview becomes stale while the other is updated.

5. Optional Open Graph fields and duplicate tags

Useful optional fields include og:description, og:site_name, and og:locale. Image structured properties can include og:image:secure_url, og:image:type, og:image:width, og:image:height, and og:image:alt. Only publish values that correctly describe the actual image and page.

Check for duplicate metadata when a CMS plugin, theme, and custom template all emit tags. The OG protocol says that when a property appears more than once, the first value from top to bottom takes precedence. A later correct value may therefore fail to fix an earlier incorrect one. Inspect the final HTML, remove the unintended duplicate, and retain a deliberate ordering only when multiple values are actually needed.

6. Add metadata to a site

Choose the canonical page URL and the page’s intended title, description, and preview image.
Render the four OG core properties in the document head. Add a useful og:description and image alt text.
Add twitter:card with the intended card type for X. Add X title, description, or image overrides only if they should differ.
Open the final rendered source, not just a template file, and verify the values occur in the delivered head.
Check that the image URL is correct and publicly reachable to the relevant crawler, and that the canonical OG URL identifies the intended page.
Test the link in its destination platform. If the displayed preview is stale, account for caching and retest after the platform refreshes it; there is no universal cache expiry established here.

7. Troubleshooting link previews

Symptom	Likely cause	What to check or fix
Wrong title or description	Incorrect or duplicate tags, or an X-specific value differs from OG.	Inspect the delivered head and all matching tags. Remove unintended duplicates; add an explicit X override if the X copy should differ.
Wrong preview image	`og:image` points to an old or unintended asset, or another image tag wins.	Check the exact URL and duplicate order. Confirm the chosen asset is the one intended for sharing.
No image appears	The image URL may be wrong or inaccessible to the crawler, or the platform may not accept the image as served.	Check the final HTML and image response from a public context; verify the resource loads. Test in the destination platform.
Tags are missing	Metadata was added to a template but is absent from the final response, or the page is rendered in a way the crawler does not receive.	View the delivered source and confirm tags are in `<head>`. Make server-rendered metadata available in the response.
Updated tags do not change preview	The destination may be showing a cached preview.	Verify the source is now correct, then test again after the platform refreshes its cached data. Cache timing varies.
OG looks right but X differs	X-specific overrides or platform fallback behavior may affect the selected value.	Set explicit `twitter:title`, `twitter:description`, or `twitter:image` where needed and test on X.

Do not rely on a guessed universal image dimension. OG allows image width and height metadata, but current size limits for every destination platform were not verified for this article. Follow the destination’s current requirements when available and validate the actual rendered preview.

8. Capture a rendered page to inspect it

When debugging, inspect the actual page response and metadata, then compare it with the preview shown by the destination. A screenshot can help document what the page itself renders, but it does not reveal which metadata a social crawler parsed or force a platform to refresh a cached card.

For browser-based capture, open the page in a real browser and capture the rendered state after its head and content load. Keep metadata inspection separate: view source or use a page inspection method to read the tags. This distinction helps isolate whether the issue is your HTML, the page’s visual content, or the platform’s interpretation and cache.

9. Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server for developers. One GET request returns a screenshot or PDF; its capture process accepts consent banners like a visitor and removes 60+ known consent platforms, newsletter popups, and chat widgets before the shot. Each step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers report the page verdict and billing status.

Use it to capture the rendered page while you inspect its metadata separately. The API accepts common screenshot parameters used by other screenshot APIs. See the ScreenshotNeo API documentation.

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://example.com/page \
  -o shot.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://example.com/page"},
    timeout=90,
)
r.raise_for_status()
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://example.com/page'
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const fs = await import('node:fs/promises');
await fs.writeFile('shot.webp', Buffer.from(await res.arrayBuffer()));

Cookie banners, popups, and chat widgets are removed before the shot. Bot checks, blank pages, and failed loads are never billed. An MCP server lets AI agents use take_screenshot, get_page_info, and capture_pdf. The Free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000. Create a free ScreenshotNeo account.

10. Performance, reliability, and cost notes

Keep metadata simple. A compact, server-delivered head is easier to inspect and maintain than multiple competing outputs.
Use canonical values consistently. Keep og:url aligned with the page’s canonical URL and update the image and copy when the page changes.
Plan for caches. A correct deployment may not appear immediately in a cached preview. No single refresh interval applies to every platform.
Validate in the destination. Markup correctness and final platform rendering are separate checks.
Screenshot capture has separate usage economics. ScreenshotNeo charges only for clean shots; failed loads, bot checks, blank pages, timeouts, and cache hits are not billed. Its plans are Free (1,000/month), Starter ($5/3,000), Growth ($15/15,000), Pro ($39/60,000), Scale ($99/250,000), and Business ($249/1,000,000); yearly billing gives two months free. Every feature is on every plan.

11. FAQ

Does X use Open Graph tags?

Some implementations use OG fields as fallbacks. Yoast documents this behavior for its X output, but do not assume every crawler handles every field identically.

Do I need both sets of tags?

Use the OG core for the broad metadata baseline and add twitter:card for the desired X card type. Separate X fields are useful when their values should differ or when your implementation requires explicit values.

Will correct tags guarantee the same preview everywhere?

No. The tags describe the page, while each destination controls parsing, rendering, and caching. Verify the link where it will be shared.

Should `og:image` be an absolute URL?

Use a complete, publicly fetchable image URL so a remote crawler can locate the intended asset without depending on the page’s relative path.

Sources

Open Graph Protocol: The Open Graph protocol — core and optional properties, image metadata, and repeated-property precedence.
Yoast developer portal: Yoast SEO X Tags functional specification — Yoast’s documented X and Open Graph fallback behavior.