Languages

Open Graph Tags: Not a Ranking Factor, Still an SEO Deliverable

What Open Graph tags are, why they're not a Google ranking factor, what Google actually does with og:title/og:image/og:site_name, documented per-platform og:image sizing, per-platform fallback and caching behavior, and how to force a re-scrape.

First published: Jul 2, 2026 · Last updated: Jul 18, 2026 · Advanced
demand #3 in Meta Tags#12 in On-Page#65 in Technical SEO#86 on the site
AIAuthored byAI v2

Open Graph (OG) tags are <meta> elements in your head, from the Open Graph protocol (ogp.me, built by Facebook), that describe your page as a shareable object. The four required properties are og:title, og:type, og:image, og:url; add og:description, og:site_name, og:locale, and og:image:alt. Their main job is the link preview card people see when your URL is shared on Facebook, LinkedIn, Slack, Discord, WhatsApp, and iMessage — so they're a CTR lever, not a ranking factor. But Google does read them: og:title is listed among the sources it can use for the SERP title link (added Aug 2024), og:image is one documented input to Google's automated image-thumbnail selection for Search and Discover, and og:site_name is a lower-priority input to the site name shown in results — none of this is a guarantee your value gets used as-is. Practical spine: og:image needs an absolute URL and a documented alt description; each platform publishes its own size guidance (LinkedIn: 1200×627 min, 1.91:1; Google Discover: at least 1200px wide, 16:9) rather than one universal figure, though 1200×630 (1.91:1) is the long-standing cross-platform convention; missing tags cause an uncontrolled (not blank) preview; every platform caches the scrape, so editing tags doesn't fix already-shared links — force a re-scrape with the Facebook Sharing Debugger or LinkedIn Post Inspector. Most social crawlers don't run JavaScript, so the tags must be in the server-rendered HTML.

TL;DR — Open Graph tags are <head> <meta> elements from the Open Graph protocol (ogp.me, built by Facebook) that describe your page as a shareable object. Required: og:title, og:type, og:image, og:url; common optional: og:description, og:site_name, og:locale, and og:image:alt. Repeated properties form arrays, with the first tag preferred on conflicts. They are not a ranking factor — they’re the appearance layer for social/chat-app link previews (Facebook, LinkedIn, Slack, Discord, WhatsApp, iMessage). Search-engine handling is separate and should not be inferred from Open Graph validity. The protocol itself sets no pixel dimensions for og:image — each consumer publishes its own sizing (LinkedIn, Google Discover) — so ship an absolute-URL og:image sized for the platforms you support; know that missing tags produce an uncontrolled, not blank, preview; and remember every platform caches the scrape — editing tags doesn’t fix already-shared links, so force a re-scrape. Most social crawlers don’t run JavaScript, so the tags must be in the server-rendered HTML.

Evidence for this claim The Open Graph protocol defines og:title, og:type, og:image, and og:url as basic metadata for representing a page as a graph object. Scope: Open Graph protocol vocabulary; platform rendering can vary. Confidence: high · Verified: Open Graph protocol Evidence for this claim Meta's sharing crawler uses server-rendered Open Graph metadata and provides Sharing Debugger tools to inspect and refresh scraped information. Scope: Meta/Facebook sharing behavior, distinct from search ranking. Confidence: high · Verified: Meta for Developers: Webmasters sharing guide

What Open Graph tags actually are

Open Graph tags are <meta> elements in your page’s <head>, defined by the Open Graph protocol — a spec Facebook created and published at ogp.me. The protocol’s premise is that a web page can be turned into a rich “object” with a small, consistent vocabulary of properties, so any platform can build the same preview from the same tags. Google’s own developer explainer puts the origin plainly: the Open Graph protocol “provides Facebook with the metadata necessary to allow web pages to have the same functionality as other Facebook objects,” per web.dev’s Social discovery article.

The spec marks four properties as required — og:title, og:type, og:image, and og:url — and the ones you’ll almost always add on top are og:description, og:site_name, and og:locale, plus structured sub-properties like og:image:width, og:image:height, and og:image:alt (the spec’s own guidance: a page that specifies og:image should specify og:image:alt too).

Repeated tags and structured properties follow specific rules. The protocol lets you repeat a root property to describe multiple objects (say, several candidate images) — when consumers see conflicting values for the same property, the first tag in document order wins. A structured sub-property like og:image:width applies to the og:image tag immediately before it, not to every image on the page, so keep each image’s og:image and its structured sub-properties grouped together in source order. This is protocol-level behavior from ogp.me itself, not a per-platform quirk.

The framing I want you to keep: this is the social/chat appearance layer, the sibling of the SERP appearance layer you already manage with the title tag and the meta description. Same idea — control how your page presents itself — just on a different surface.

The core Open Graph tags, one by one

Google’s web.dev explainer gives the per-tag purpose in one line each: og:title is “the title of the web page,” og:description is “the description of the web page,” og:image is the “URL to an image attached to the shared post,” og:url is “the canonical url of the web page,” and og:type is “a string that indicates the type of the web page” (web.dev). Practically:

  • og:title — the card headline. Keep it to roughly what shows on mobile/desktop cards; use the raw title without site-name branding tacked on. This is separate from your HTML <title> element, though Google may draw on either for the title link (see below).
  • og:description — the card blurb. A sentence or two; longer text truncates on most platforms.
  • og:image — the thumbnail, and the property that makes or breaks the card. It must be an absolute URL (https://…) — a relative path is silently ignored by crawlers. Add og:image:width/og:image:height so platforms can lay out the card before the image finishes loading, and og:image:alt with a real description — the protocol itself recommends it whenever you specify og:image.
  • og:url — the canonical URL for the page (align it with your rel=canonical so shares consolidate on one address).
  • og:type — declares the object type. website is the default (and what any unmarked page is treated as); article unlocks extra properties like article:author, article:published_time, and article:section; there are also profile, book, video.*, and music.* types. This matters for platform features, not for SEO directly.
  • og:site_name and og:locale — the optional-but-useful pair. og:site_name names the brand behind the page; og:locale (default en_US) is only needed when content isn’t in American English.

Are Open Graph tags a ranking factor? No — but here’s what Google does with them

There is no official Google source stating that OG tags influence ranking. They control appearance, not position — the exact same bucket John Mueller put the meta description in: it’s “primarily used as a snippet in the search results page. And that’s not something that we would use for ranking” (via Search Engine Journal’s write-up). No named Google rep has given an equivalent on-the-record quote specifically about Open Graph and ranking, so I won’t invent one — the evidence is the documented mechanism, and the mechanism is all appearance. There are three confirmed places Google’s own documentation says it reads your OG tags — and in every case, valid markup is one input Google may draw on, not a guarantee of a particular display, a particular crop, or any ranking or traffic outcome. Absence from one of these docs isn’t proof Google ignores the tag elsewhere, either — treat this as “what’s documented,” not an exhaustive list of everything Google’s systems might touch.

Since August 26, 2024, Google’s documentation lists “Content in og:title meta tags” among the sources it can use to automatically generate the title link — the clickable headline in results. The changelog line is direct: “Google Search can use content within og:title meta tags to automatically generate title links” (Search Central changelog). It’s one of roughly nine sources Google blends from (title-link docs) — not a guarantee your og:title gets used verbatim.

og:image as an image-thumbnail source

Google’s Image SEO best practices has a “Specify a preferred image with metadata” section that names two metadata sources you can use to influence which image gets picked for Search: schema.org’s primaryImageOfPage (or an image on the main entity), or “the og:image meta tag.” Google is explicit that “Google’s selection of an image preview is completely automated” and warns you to “avoid using a generic image (for example, your site logo) or an image with text in the schema.org markup or og:image meta tag.” Its Discover doc gives the same two options for Discover images and adds concrete guidance: at least 1200px wide, more than 300,000 total pixels, and a 16:9 aspect ratio (its own example is 1280×720) — note that’s a different ratio than the 1.91:1 convention used for social-card images below, so a single image sized for social sharing won’t automatically be Discover’s preferred crop.

Trade press (Search Engine Land, Search Engine Journal, Search Engine Roundtable) covered this Images/Discover documentation as new around early March 2026 and reported that og:image’s role now extends to AI Overviews as well. I could not confirm an AI Overviews mention on Google’s own Images or Discover pages directly — neither page currently names AI Overviews or “AI surfaces” — so treat the Search/Discover role as the documented fact and the AI Overviews extension as third-party-reported, not something Google’s own docs state outright. Either way, this is selection, not ranking: og:image is one input among several, with no guarantee of exact display.

og:site_name as a site-name source

For the site name shown next to your results, Google says its system “will also consider content in og:site_name, <title>, heading elements, and other text on a home page. However, WebSite structured data is most important” (Site Names doc). So og:site_name is one lever, below WebSite schema markup in priority. (For video pages there’s a fourth touchpoint: Google supports OGP and reads og:video:image for video thumbnails, per the Video SEO docs.)

Tie them together and the honest headline is: Google reads your OG tags, but only to help decide how your result looks — never where it ranks.

How social platforms and chat apps use OG tags

The primary, everyday job of OG tags is the link preview card. Facebook, LinkedIn, Slack, Discord, WhatsApp, iMessage, and Telegram all read them to build the card shown before a click.

X/Twitter is the special case. Twitter Cards are, in Google’s words, “an extension to the Open Graph Protocol applicable for Twitter” (web.dev). X checks twitter:card / twitter:* tags first and falls back to OG tags per-property; if twitter:card is absent entirely, X still may build a card from OG data but defaults to the plain summary card type. Worth knowing: the old Twitter Card Validator tool was deprecated around 2022 when the platform rebranded — several competitor guides still reference it as if it’s live. There’s no official X-specific validator anymore; third-party OG debuggers fill the gap.

The Open Graph protocol itself sets no pixel dimensions or aspect ratio for og:image — ogp.me only defines the structured properties (og:image:width, og:image:height, og:image:type, og:image:alt), not a required size. Sizing is a per-consumer decision, and consumers don’t all agree:

  • LinkedIn documents its own minimum directly: 1200 × 627px, 1.91:1 ratio; images narrower than ~401px render as a small thumbnail only.
  • Google Discover documents at least 1200px wide, more than 300,000 total pixels, 16:9 aspect ratio (example given: 1280×720) for its preferred-image metadata — a noticeably different ratio than the social-card convention below.
  • Facebook’s current sharing documentation asks for images “at least 1080 pixels in width” without pinning a universal ratio; it points you to a separate best-practices guide for specifics.

Given that spread, 1200 × 630px (about 1.91:1) remains the practical cross-platform default most implementers use — it’s close to LinkedIn’s own minimum and renders acceptably (if not always pixel-perfect) on Facebook, Slack, Discord, WhatsApp, and iMessage, and X displays it as a large-image card. Treat it as a sensible convention, not a rule any single spec mandates — if a specific platform matters a lot to you, check that platform’s current documentation rather than assuming this figure is guaranteed correct there.

Two things that are hard rules, not conventions:

  • Absolute URL required. og:image must point to a full https://… URL; a relative path is ignored by crawlers.
  • No generic logos or text-heavy images if you also want the image eligible for Google’s thumbnail selection — Google explicitly warns against both, and against extreme aspect ratios. Set og:image:alt with a real description, too.

What happens when Open Graph tags are missing

A common myth is that “no OG tags” means “plain text link, no image.” It doesn’t — platforms fall back, they don’t blank out. Facebook fills the gaps from the page’s <title>, meta description, and first usable content image; LinkedIn behaves similarly and treats images narrower than ~401px as thumbnail-only. So the real risk of omitting OG tags is an uncontrolled, worse preview — a random in-body image, a truncated <title> — not a missing one. If you care how a page looks when shared (and for anything you’d promote, you should), set the tags rather than letting each platform guess.

Why your updated OG tags aren’t showing up — caching and re-scraping

This is the number-one practical pain point. Facebook, LinkedIn, and Slack all cache the scraped OG data, so editing your tags doesn’t retroactively update links that were already shared. Facebook’s own webmaster docs confirm one specific mechanism worth knowing: “images are cached based on the URL and won’t be updated unless the URL changes” — so if you’re troubleshooting a stuck image, changing the og:image filename (not just its contents) can force a fresh fetch. I don’t have a first-party source for exactly how long each platform’s cache lives before it expires on its own, so don’t treat any specific duration you see quoted elsewhere as a documented guarantee — force a re-scrape per platform instead of waiting it out:

  • Facebook Sharing Debugger (developers.facebook.com/tools/debug) — paste the URL and use “Scrape Again” to trigger a fresh fetch.
  • LinkedIn Post Inspector — re-fetches and previews the card; if the image still won’t pull, check it isn’t blocked or behind auth.
  • X/Twitter — no official validator since ~2022. Since X falls back to OG tags, a generic OG debugger plus a fresh share is the practical route.

Because crawlers cache and content changes, OG tags aren’t truly set-and-forget: after a significant content or image update on a high-value page, re-scrape it.

Implementation gotchas: JavaScript, byte limits, absolute URLs

The biggest one ties straight back to rendering: most social-platform crawlers do not execute JavaScript. OG tags injected client-side — say, by React after hydration — are invisible to them; the crawler sees an empty <head>. The tags must be present in the raw, server-rendered HTML. This is the same crawl-vs-render distinction that bites JavaScript-heavy sites elsewhere (see JavaScript SEO). Slack has been reported (not documented in an official spec) to fetch only a limited number of bytes from the start of a page, so as a safety margin put your OG tags early in <head> rather than after a large inline script or style block. And, once more because it’s the quiet killer: og:image must be an absolute URL.

Bing, Microsoft, and Open Graph

Bing is far less documented here than Google. Bing’s Markup Validator (in Bing Webmaster Tools) lists Open Graph among the structured-markup formats it recognizes, alongside schema.org, Microdata, Microformats, and RDFa, and Bing’s migration guidance flags OG metadata as something to keep current during a move — but Bing hasn’t published Google-style specifics on whether or how OG data feeds its snippets or thumbnails. In practice the stronger Microsoft-ecosystem consumer of OG tags is LinkedIn (Microsoft-owned), which reads og:title, og:description, og:image, and og:url to build its share cards. Don’t overclaim a Bing mechanism that isn’t documented.

Common Open Graph myths, debunked

  • “OG tags are a Google ranking factor.” No — no official source says so. They affect appearance (title-link, image-thumbnail, site-name sources), not position.
  • “OG is only for Facebook, irrelevant to real SEO.” Out of date. Google’s own docs list og:title (title links, added Aug 2024), og:image (a Search/Discover image-selection input), and og:site_name (a lower-priority site-name input) as three separate appearance features it reads OG tags for — though “AI Overviews” specifically is trade-press reporting, not a claim on Google’s own Images/Discover pages as of this check.
  • “No OG tags means a plain, image-less link.” No — platforms fall back to <title>/meta description/first image, giving an uncontrolled preview, not a blank one.
  • “Updating og:image instantly fixes every already-shared link.” No — Facebook/LinkedIn/Slack cache the scrape; you must force a re-scrape, and CDN caching can delay it further.
  • “Use the Twitter Card Validator to fix X previews.” That tool was deprecated ~2022; there’s no official X validator now.
  • “Any image size/URL works for og:image.” No — it must be an absolute URL, and Google warns against generic logos, text-in-image, and extreme aspect ratios for its own thumbnail selection.

Where to go next

This page is a deep dive under the Meta Tags for SEO hub, the on-page cluster’s map of which head elements actually matter. Open Graph is the social/chat appearance layer — its siblings on the SERP appearance side are the title tag (which Google may draw from your og:title) and the meta description (the closest analogue: not a ranking factor, all about the click). For the image and site-name side, OG overlaps with schema markup — Google treats og:image and schema’s primaryImageOfPage as alternative thumbnail sources. And because most social crawlers don’t run JavaScript, the whole topic sits downstream of rendering and JavaScript SEO.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin an expert quote first.