Skip to main content
Open Graph tags shape how AI models — and the systems that summarize content for them — interpret your pages. Without OG tags, AI gets inconsistent representations of the same page across different LLMs; with them, every model sees the same structured summary you intended.

​
Methodology

Cited checks the first 3 sampled pages for four core Open Graph properties:
  • og:title — the page’s title for OG consumers (often shorter and punchier than the HTML <title>)
  • og:description — the page’s description for OG consumers (often more compelling than the standard meta description)
  • og:image — the URL of a representative image for the page (used by AI summarizers and social platforms)
  • og:type — the content category (article, product, website, book, etc.) — this is the property AI models use to classify the page’s purpose
Each page contributes 4 expected tags. With 3 sampled pages, the total expected is 12. The score is based on the completion rate — how many of those 12 tags are actually present:
  • 80% or more present (10-12 of 12) → 6/6. Full score.
  • 50-79% present (6-9 of 12) → 3/6. Partial — meaningful adoption but gaps.
  • Any tags present → 1/6. OG is on the radar but most pages aren’t covered.
  • No OG tags found → 0/6. AI has no structured summary signal.
The signal scores out of 6. Status thresholds: pass at 5/6, partial at 2/6, fail below. Why only 3 pages instead of all 5 sampled? OG tags are usually template-driven — if the homepage and one blog post have them, every page likely does. Checking 3 pages catches the common failure modes (template missing OG entirely, certain page types missing certain tags) without inflating the sample. The scanner also tracks which specific tags are missing across all checked pages — a diagnostic that surfaces patterns like “every page is missing og:image” or “the type tag is on the homepage but missing everywhere else.” This drives the fix recommendation in the Opportunity card.

​
Verification

You can verify our finding yourself in a browser. Step 1: Open the pages we sampled. Cited reports the URLs we tested. Open each in a new tab. Step 2: Check the OG tags in source. Right-click the page, View Page Source (Cmd+U / Ctrl+U), and search (Cmd+F / Ctrl+F) for property="og:. Every match is one OG tag. The four to look for: og:title, og:description, og:image, og:type. Each should have a non-empty content attribute. Step 3: Inspect via the OG debugger. Paste the page URL into Meta’s Sharing Debugger (which still works for any OG tags, despite the Meta branding — it’s the canonical OG tester). It returns a structured view of every OG tag, plus any errors or warnings. The same data AI models consume from your page is visible here. Step 4: Spot-check the image. If og:image is present, the image URL should be a working absolute URL (starts with https://, returns a 200) and the image should be at least 600×315 pixels per Open Graph spec recommendations. The scanner doesn’t check the image itself — just the tag presence — so a broken og:image URL passes this signal but fails downstream consumers. If your verification disagrees with Cited’s finding, that’s a bug — let us know.

​
Technical detail

The Open Graph protocol was introduced by Facebook in 2010 and remains the dominant convention for declaring how web content should be represented in external summaries. AI models, search engines, social platforms, and link preview generators all read the same OG meta tags. The four tags Cited checks are the original “basic metadata” set — the minimum subset that downstream consumers expect. Extraction logic. Cited’s scanner uses regex against the raw HTML for each of the four properties:
  • Primary pattern: <meta property="og:…" content="…"> with property before content
  • Reversed pattern: <meta content="…" property="og:…"> with content before property
  • Both patterns are case-insensitive and tolerate arbitrary additional attributes
  • Non-empty content (matching [^"']+) is required — empty content attributes (content="") don’t count
The scanner uses regex (not DOM parsing) for the same reasons as meta descriptions — speed across many pages, and the structure is regular enough that edge-case HTML rarely matters. Score calculation. Per page checked: count of unique OG properties found (out of 4). Across all checked pages: total found ÷ total expected. The scoring tier is taken from the higher-value rate the rate hits. Diagnostic output. Beyond the score, the scanner reports which tags are missing on every checked page (the frequentlyMissing set). This identifies patterns like “your template doesn’t include og:image” — actionable in a single template fix. Edge cases the scanner handles:
  • OG tags inside conditional blocks — some CMSes wrap OG tags in {% if og_image %}…{% endif %} template logic. The scanner reads the rendered HTML after server-side or JavaScript rendering, so conditional tags appear (or don’t) based on the actual conditional outcome.
  • Duplicate OG tags — pages with two og:title tags (often a CMS plugin issue) still register as og:title present because the scanner only checks existence, not uniqueness.
  • OG-equivalent tags from other vendors — Twitter’s twitter:title, Schema.org name properties, and Pinterest’s pinterest:title don’t satisfy this signal. Only the OG namespace counts.
  • Empty content attributes — <meta property="og:image" content=""> matches the tag-existence regex but the content extraction returns empty. The scanner treats these as not present.
  • Property attribute variations — name="og:title" (using name instead of property) is technically invalid OG but used by some CMSes. The scanner only matches property= — name=-form OG tags don’t satisfy this signal.
What this signal does not measure:
  • Image URL validity. The scanner detects og:image presence but doesn’t fetch the URL or verify the image dimensions. A broken og:image URL still passes this check.
  • Tag content quality. A page with og:title="Untitled" scores the same as og:title="Best Coffee Beans for French Press 2026". The scanner counts presence, not editorial value.
  • Extended OG properties. Tags like og:url, og:site_name, og:locale, article:published_time, and product:price:amount aren’t checked. These are useful for richer AI consumption but aren’t required for the core summary path.
  • Twitter Cards. twitter:card, twitter:title, twitter:description, twitter:image are a parallel system that some AI models also consume. They’re not scored here; sites with both OG and Twitter Cards get more consistent representation than OG-only sites, but the signal evaluates OG alone.
For brands scoring 0-1/6, the highest-leverage fix is adding the four core OG tags to the site’s base layout template. Most modern CMSes (Webflow, WordPress with Yoast or RankMath, Shopify) have built-in OG configuration in the SEO settings — but custom themes often need explicit additions in the <head>. See also: Meta Description Quality.