> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getcited.in/llms.txt
> Use this file to discover all available pages before exploring further.

# Open Graph Tags

> How Cited measures whether your pages declare the four core Open Graph tags AI models rely on for structured page summaries.

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](https://developers.facebook.com/tools/debug/) (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](/signals/meta-description-quality), [JSON-LD Structured Data](/signals/json-ld-structured-data).