Open Graph Protocol: OG Tags Explained (with Examples)

Q: What are the required Open Graph tags?

Four: og:title, og:type, og:image, and og:url. Most consumers render a card with less, but the full set is what makes previews consistent. og:description and og:site_name are the two optional properties worth treating as mandatory, since preview cards look incomplete without them.

Q: Do Open Graph tags help SEO?

Not directly. OG tags are not a Google ranking factor and are not used for rich results, which come from schema.org markup instead. They control how a link looks when it is shared or cited, including in some AI and chat surfaces, so they influence click-through and the traffic a page earns rather than its ranking.

The Open Graph protocol is a specification for describing a web page as a structured object using <meta property="og:…"> tags in the document head, so that social networks, messaging apps, and other link-preview consumers can render a title, description, and image for a shared URL. It was introduced by Facebook in 2010 and is specified at ogp.me.

Open Graph is built on RDFa. Every og: property is an RDF predicate in a vocabulary whose namespace is declared with prefix="og: https://ogp.me/ns#", so an OG tag is a triple whose subject is the page. That makes Open Graph the most widely deployed piece of RDF on the web.

The four required properties

The specification names four properties as required for a page to become a valid Open Graph object.

Property	What it holds
`og:title`	The object’s title, without site branding
`og:type`	The object type, such as `website` or `article`
`og:image`	An absolute image URL for the preview
`og:url`	The canonical, permanent URL of the object

<meta property="og:title" content="RDFa: How It Works, Syntax & When to Use It">
<meta property="og:type" content="article">
<meta property="og:image" content="https://knowledgegraphnavigator.com/og/rdfa.png">
<meta property="og:url" content="https://knowledgegraphnavigator.com/languages/rdfa/">

Most consumers are tolerant, and a page with only og:title and og:image usually renders. Treat the four as required anyway: og:url is what makes cache entries and engagement accumulate against one address rather than a dozen tracked variants.

Optional basic properties

og:description, a one- or two-sentence summary. Preview cards truncate it, so put the essential clause first.
og:site_name, the name of the overall site, for example “Knowledge Graph Navigator”.
og:locale, the content’s locale in language_TERRITORY form. The default when absent is en_US.
og:locale:alternate, other locales the same page is available in, repeatable.
og:audio and og:video, accompanying media, each with sub-properties (og:video:url, og:video:secure_url, og:video:type, og:video:width, og:video:height).
og:determiner, the word preceding the title in a sentence: a, an, the, "", or auto.

<meta property="og:description" content="RDFa embeds RDF in HTML attributes. The RDFa Lite attribute set, a worked example, and when to prefer JSON-LD.">
<meta property="og:site_name" content="Knowledge Graph Navigator">
<meta property="og:locale" content="en_US">
<meta property="og:locale:alternate" content="es_ES">

Structured image properties

og:image accepts a bare URL, but the image is also a structured object with its own properties. Each applies to the og:image tag that precedes it, the ordering rule that makes arrays work.

Property	Purpose
`og:image:url`	Identical to `og:image`; the explicit long form
`og:image:secure_url`	An `https` alternative, for consumers served over TLS
`og:image:type`	MIME type, such as `image/png` or `image/jpeg`
`og:image:width`	Width in pixels
`og:image:height`	Height in pixels
`og:image:alt`	A text description of the image, for accessibility

<meta property="og:image" content="https://example.com/og/wide.png">
<meta property="og:image:type" content="image/png">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:alt" content="Diagram of an RDF triple: subject, predicate, object.">

Declaring og:image:width and og:image:height lets a consumer lay out the card before the image downloads, which is why previews sometimes appear without an image on the first share and correctly on the second.

Arrays work by repetition: repeating og:image offers several candidates, each one’s sub-properties following its own og:image tag. Consumers generally treat the first as the default.

<meta property="og:image" content="https://example.com/og/wide.png">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image" content="https://example.com/og/square.png">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="1200">

The same repetition-plus-sub-property pattern applies to og:audio and og:video.

Object types and their properties

og:type selects a vocabulary of type-specific properties. The types defined at ogp.me:

website, the default, with no extra properties.
article, for news stories, blog posts, and reference pages.
book: book:author, book:isbn, book:release_date, book:tag.
profile, a person: profile:first_name, profile:last_name, profile:username, profile:gender.
video.movie, video.episode, video.tv_show, video.other: video:actor, video:director, video:writer, video:duration, video:release_date, video:tag, and video:series for episodes.
music.song, music.album, music.playlist, music.radio_station: music:duration, music:album, music:musician, music:song.

These properties are not prefixed with og:. They live in their own namespaces (article:, book:, music:), which is the RDFa inheritance showing through.

article is the type most publishers need. It adds article:published_time and article:modified_time (ISO 8601 datetimes), article:expiration_time, article:author (the URL of a profile object, repeatable), article:section (one category name), and article:tag (repeatable keywords).

<meta property="og:type" content="article">
<meta property="article:published_time" content="2026-09-08T09:00:00Z">
<meta property="article:modified_time" content="2026-09-08T09:00:00Z">
<meta property="article:author" content="https://knowledgegraphnavigator.com/about/">
<meta property="article:section" content="Languages &amp; Formats">
<meta property="article:tag" content="RDFa">
<meta property="article:tag" content="structured data">

article:section is a single string, not a list, and article:author expects a URL rather than a name, which is a frequent source of empty bylines in previews.

A complete head block

A copy-paste starting point for a typical article page, with Twitter Card tags included.

<head>
  <meta charset="utf-8">
  <title>RDFa: How It Works, Syntax &amp; When to Use It | KG Navigator</title>
  <meta name="description" content="RDFa embeds RDF in HTML attributes. The RDFa Lite attribute set, a worked example, and when to prefer JSON-LD.">
  <link rel="canonical" href="https://knowledgegraphnavigator.com/languages/rdfa/">

  <!-- Open Graph -->
  <meta property="og:type" content="article">
  <meta property="og:title" content="RDFa: How It Works, Syntax &amp; When to Use It">
  <meta property="og:description" content="RDFa embeds RDF in HTML attributes. The RDFa Lite attribute set, a worked example, and when to prefer JSON-LD.">
  <meta property="og:url" content="https://knowledgegraphnavigator.com/languages/rdfa/">
  <meta property="og:site_name" content="Knowledge Graph Navigator">
  <meta property="og:locale" content="en_US">
  <meta property="og:image" content="https://knowledgegraphnavigator.com/og/rdfa.png">
  <meta property="og:image:secure_url" content="https://knowledgegraphnavigator.com/og/rdfa.png">
  <meta property="og:image:type" content="image/png">
  <meta property="og:image:width" content="1200">
  <meta property="og:image:height" content="630">
  <meta property="og:image:alt" content="RDFa attributes annotating an HTML organization card.">
  <meta property="article:published_time" content="2026-09-08T09:00:00Z">
  <meta property="article:author" content="https://knowledgegraphnavigator.com/about/">
  <meta property="article:section" content="Languages &amp; Formats">

  <!-- Twitter / X -->
  <meta name="twitter:card" content="summary_large_image">
  <meta name="twitter:site" content="@kgnavigator">
  <meta name="twitter:creator" content="@kgnavigator">
</head>

OG tags use property , and Twitter Card tags use name. This is the RDFa distinction again: property carries a predicate, name is an ordinary meta name. Most consumers accept either, but writing them as shown matches both specifications.

Twitter/X Cards and how OG acts as a fallback

Twitter Cards are a separate vocabulary with overlapping fields. The tags with no OG equivalent are twitter:card (the layout: summary, summary_large_image, app, or player), twitter:site (the publishing account’s @handle), and twitter:creator (the author’s).

twitter:title, twitter:description, and twitter:image also exist, but the documented behaviour is to fall back to og:title, og:description, and og:image when they are absent. So the three Twitter-only tags plus a complete OG set covers both, and duplicating title, description, and image into twitter: tags only creates a second copy to keep in sync. Add those when a page needs a different card than its OG object, such as a differently cropped image.

Image sizing and aspect ratio

Exact pixel requirements differ by platform and change over time, so check current platform documentation before treating any number as fixed. The general practice that works across consumers:

Serve a large image, around 1200 by 630 pixels, for a wide card, close to the 1.91:1 ratio most large-format previews use.
Add a square or near-square second og:image for compact layouts, since many messaging apps crop to a small thumbnail.
Keep the file well under a megabyte. Some crawlers abandon slow fetches.
Use PNG or JPEG. Crawler support for WebP, AVIF, and SVG is inconsistent.
Keep text away from the edges, because consumers crop to different ratios.
Always give an absolute https URL.

Debugging and cache busting

Every preview consumer caches OG data per URL, often for days, so a corrected tag doesn’t change an existing preview. Each platform has its own validator, and fetching a URL through it is the documented way to force a re-scrape: Meta’s Sharing Debugger, which shows the parsed properties, any warnings, and a “Scrape Again” action; LinkedIn’s Post Inspector; and X’s Cards validator where the account has it.

For a first check before sharing, fetch the page and read the head. That catches the most common failure, a tag rendered client side that no preview crawler executes.

curl -sL https://example.com/article/ | grep -iE 'og:|twitter:'

Verify two things: that the tags are in the HTML the server returns rather than injected by JavaScript, and that the crawler is not served something different, whether by a Vary header, a geographic redirect, a cookie wall, or a consent interstitial that returns a page with no OG tags at all.

Open Graph and schema.org

Open Graph and schema.org are different vocabularies for different consumers, and a page should carry both. OG serves link previews; schema.org, usually as JSON-LD, serves search engines and feeds their knowledge graphs.

They differ in depth as well. OG describes the page as one flat object with about a dozen usable properties. schema.org describes entities and their relationships: an Article whose author is a Person with a sameAs link to a Wikidata Q-ID, whose publisher is an Organization with its own identifiers. OG cannot express a graph, and that is the whole difference. See structured data for the schema.org half. Keep the two consistent where they overlap; og:title and headline describing one page differently signals a template problem.

For developers

Emit OG tags from the same data structure that produces the page, never as hand-written strings in a layout. Next.js, Nuxt, SvelteKit, Astro, and Remix all expose a per-route metadata mechanism; the pattern is one function that takes the page’s data object and returns title, description, canonical URL, and image, so the OG tags, the <title>, and the canonical link cannot disagree.

Server-side rendering is not optional here. Some preview crawlers execute no JavaScript, so a client-rendered application that sets OG tags at runtime shows a preview of whatever sits in the static HTML shell, usually the homepage card for every URL. Prerender the head or serve it from an edge function.

Dynamic OG images are worth the effort for pages with many distinct titles. The usual approach is an endpoint that renders an image from URL parameters, either by rasterizing HTML and CSS in a headless browser or by compositing text over a template. Cache aggressively, keyed on the parameters, since crawlers hit these endpoints in bursts, and return a static fallback rather than an error if generation fails.

Then test the head: every published route returns the four required properties, og:url matches the canonical link, and the image URL responds with a 200 and an image content type.

For SEOs

Open Graph is not a Google ranking factor and not an input to rich results, which come from schema.org markup. Google may fall back to og:title or og:description when it has no better material for a snippet, but that is a fallback, not a lever.

What OG controls is how a link looks everywhere it gets pasted: social feeds, Slack, WhatsApp, iMessage, Discord, email clients that render previews, and increasingly the citation cards shown by AI and chat surfaces that read a page’s head. That affects whether a shared link is clicked, and so the traffic and links a page earns. OG is a click-through asset rather than an SEO tag. See knowledge graphs, AI search, and LLMs.

An audit checklist: OG tags on every template, og:url matching the canonical URL, an image per important page rather than a site-wide default, and tags that survive whatever the CDN or consent layer does to the response.

Common mistakes

Relative image URLs. content="/og/image.png" fails in most consumers. og:image must be absolute, with the scheme.

A missing or non-canonical og:url. Leaving it out, or emitting the request URL with campaign parameters attached, splits caches and engagement across many addresses for one page.

Images behind authentication or blocked by robots.txt. A preview crawler is an anonymous client. If the image path is disallowed in robots.txt, behind a login, or on a CDN that blocks unknown user agents, the card renders without an image.

og:title copied from the title tag verbatim. A title tag ends with site branding for search results. In a preview card the site name already appears separately, so og:title should drop the suffix.

Multiple conflicting tags. A theme, an SEO plugin, and a hand-edited layout each emitting og:image leaves the consumer to pick, and which it picks is undefined. Audit the rendered head so each property appears once, except where repetition is deliberate for an array.

Assuming a preview updates itself. After fixing a tag, re-scrape through the platform’s validator.

FAQ

What is the Open Graph protocol?

The Open Graph protocol is a specification, introduced by Facebook in 2010 and published at ogp.me, for describing a web page as a structured object using og: meta tags in the document head. Social networks, messaging apps, and other consumers read those tags to build a link preview with a title, description, and image.

What are the required Open Graph tags?

Four: og:title, og:type, og:image, and og:url. Most consumers render a card with less, but the full set is what makes previews consistent. og:description and og:site_name are the two optional properties worth treating as mandatory, since preview cards look incomplete without them.

What size should an og:image be?

Exact requirements vary by platform, so check current platform documentation. As general practice, serve a large image around 1200 by 630 pixels for wide cards, roughly a 1.91:1 ratio, keep the file well under a megabyte, use PNG or JPEG, give an absolute https URL, and keep text away from the edges because consumers crop differently.

Do Open Graph tags help SEO?

Not directly. OG tags aren’t a Google ranking factor and aren’t used for rich results, which come from schema.org markup instead. They control how a link looks when it is shared or cited, including in some AI and chat surfaces, so they influence click-through and the traffic a page earns rather than its ranking.

Sources and further reading

The Open Graph protocol: https://ogp.me/
Meta for Developers, webmasters and sharing documentation: https://developers.facebook.com/docs/sharing/webmasters/
Meta Sharing Debugger: https://developers.facebook.com/tools/debug/
LinkedIn Post Inspector: https://www.linkedin.com/post-inspector/
X developer documentation, Cards markup reference: https://developer.x.com/en/docs/twitter-for-websites/cards/overview/abouts-cards
RDFa 1.1 Primer (W3C): https://www.w3.org/TR/rdfa-primer/
schema.org: https://schema.org/