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 #6 in Meta Tags#16 in On-Page#82 in Technical SEO#108 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 GraphOpen Graph (OG) tags are `<meta>` elements in a page's head, defined by the Open Graph protocol (ogp.me, created by Facebook), that describe a page as a shareable object — its title, description, image, URL, and type. They control how a link preview card looks when the page is shared on Facebook, LinkedIn, Slack, Discord, WhatsApp, and iMessage. They are not a direct Google ranking factor, though Google reads og:title, og:image, and og:site_name as inputs to how a result appears. 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 DiscoverGoogle Discover is a personalized, mobile-first content feed built into the Google app, Chrome's mobile New Tab page, and google.com that surfaces articles and videos based on a user's interests and activity — not a response to a search query. There's nothing to 'rank' for in the traditional sense; eligibility is governed by Discover's content policies plus the same helpful-content, image, and page-experience signals Google Search already uses.) — 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 crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. 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 tagThe title tag is the HTML title element in a page's head that specifies the document's title. It's the primary source for the SERP title link and a confirmed light ranking factor — but since August 2021 Google doesn't always show it verbatim. and the meta descriptionThe meta description is an HTML head tag — `<meta name=\"description\" content=\"…\">` — that suggests a short summary of the page for the search snippet. It's not a Google ranking factor, and Google rewrites it the majority of the time, but a good one can still lift click-through.. 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 urlHow search engines pick one canonical URL among duplicates and consolidate signals onto it. 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 crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index.. 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=canonicalA rel=\"canonical\" annotation — in the HTML <head> or an HTTP Link header — that tells search engines which URL is the preferred version of duplicate or near-duplicate content. 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 linkThe title tag is the HTML title element in a page's head that specifies the document's title. It's the primary source for the SERP title link and a confirmed light ranking factor — but since August 2021 Google doesn't always show it verbatim. — the clickable headline in results. The changelog line is direct: “Google Search can use content within og:title meta tags to automatically generate title linksThe title tag is the HTML title element in a page's head that specifies the document's title. It's the primary source for the SERP title link and a confirmed light ranking factor — but since August 2021 Google doesn't always show it verbatim.” (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.orgSchema markup is code that uses the schema.org vocabulary to label what your content means so search engines can understand it and show rich results. It's most often written in JSON-LD, and it's not a direct ranking factor.’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 OverviewsAI Overviews are the AI-generated summary box Google shows above or within its regular search results, written by Gemini models from pages retrieved out of Google's normal Search index. It's a Search feature, not a separate platform or index. as well. I could not confirm an AI OverviewsAI Overviews are the AI-generated summary box Google shows above or within its regular search results, written by Gemini models from pages retrieved out of Google's normal Search index. It's a Search feature, not a separate platform or index. 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 elementsHeader tags (heading tags) are the HTML elements <h1> through <h6> that mark the structural hierarchy of a page's content. They help users, search engines, and screen readers understand what each section is about., and other text on a home page. However, WebSite structured dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding. is most important” (Site Names doc). So og:site_name is one lever, below WebSite schema markupSchema markup is code that uses the schema.org vocabulary to label what your content means so search engines can understand it and show rich results. It's most often written in JSON-LD, and it's not a direct ranking factor. 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 CardsTwitter Card tags (now often called \"X Cards\") are <meta name=\"twitter:...\"> tags in a page's <head> that tell X's link-unfurling system what rich preview to build for a shared URL — image, headline, description, and (for player cards) an embeddable frame. The four card types are summary, summary_large_image, app, and player. Every twitter:* property falls back to its og:* equivalent if missing — except twitter:card itself, which has no fallback and must be set explicitly. They are not a Google or Bing ranking factor. 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

TIP See the fallback before a platform chooses it for you

Missing Open Graph fields do not guarantee a blank card; they force each platform to infer a preview from less-specific metadata.

Compare the share-readiness signals with my free Social Preview Free

  1. Test the server-rendered URL rather than a client-only preview.
  2. Add an absolute og:image and the core Open Graph fields.
  3. Re-scrape in the destination platform after changes because cached cards can remain stale.
The page still produces inferred previews, but you have surrendered control of the image, card type, and metadata source.

The Social Preview result scores the page 79 out of 100 for share readiness. It reports that og:image is missing so cards may have no image, twitter:card is missing so X must infer a card type, and Google uses generic HTML metadata because platform-specific metadata is unavailable.

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 descriptionThe meta description is an HTML head tag — `<meta name=\"description\" content=\"…\">` — that suggests a short summary of the page for the search snippet. It's not a Google ranking factor, and Google rewrites it the majority of the time, but a good one can still lift click-through., 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 renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM.: most social-platform crawlers do not execute JavaScript. OG tags injected client-side — say, by React after hydrationActivating server-rendered HTML in the browser by attaching JavaScript handlers. — 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 SEOMaking sure search engines can crawl, render, and index content that depends on JavaScript.). 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 descriptionThe meta description is an HTML head tag — `<meta name=\"description\" content=\"…\">` — that suggests a short summary of the page for the search snippet. It's not a Google ranking factor, and Google rewrites it the majority of the time, but a good one can still lift click-through./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 hubMeta tags are HTML elements in a page's head that pass metadata about the page to search engines and browsers. For SEO only a few matter — the title element, the meta description, and the robots meta tag — while meta keywords and most others are ignored., 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 tagThe title tag is the HTML title element in a page's head that specifies the document's title. It's the primary source for the SERP title link and a confirmed light ranking factor — but since August 2021 Google doesn't always show it verbatim. (which Google may draw from your og:title) and the meta descriptionThe meta description is an HTML head tag — `<meta name=\"description\" content=\"…\">` — that suggests a short summary of the page for the search snippet. It's not a Google ranking factor, and Google rewrites it the majority of the time, but a good one can still lift click-through. (the closest analogue: not a ranking factor, all about the click). For the image and site-name side, OG overlaps with schema markupSchema markup is code that uses the schema.org vocabulary to label what your content means so search engines can understand it and show rich results. It's most often written in JSON-LD, and it's not a direct ranking factor. — 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 renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. and JavaScript SEOMaking sure search engines can crawl, render, and index content that depends on JavaScript..

Add an expert note

Pin an expert quote

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