Open Graph Protocol
debt(d5/e1/b3/t7)
Closest to 'specialist tool catches it' (d5). The detection_hints list Lighthouse, Screaming Frog, and opengraph.xyz — all specialist tools rather than a default linter or compiler. Missing OG tags produce no runtime error; they are silent until someone shares a link and notices a broken preview, but the specialist tools listed can catch them proactively.
Closest to 'one-line patch or single-call swap' (e1). The quick_fix is adding a handful of <meta> tags to each page's <head> — a minimal, localized change requiring no structural refactor. Even adding absolute URLs for og:image is a straightforward string change.
Closest to 'localised tax' (b3). OG tags live in the <head> of individual pages. They impose a small ongoing tax (remembering to add/update tags on new pages, keeping og:image absolute and correctly sized), but this is confined to the HTML layer and doesn't shape architecture or slow down other work streams.
Closest to 'serious trap' (t7). The misconception field directly states that developers believe OG tags only matter for Facebook, when in reality every major platform (LinkedIn, Twitter/X, Slack, Discord, WhatsApp, iMessage) reads them. This contradicts the intuition that platform-specific needs require platform-specific solutions, and the failure mode (broken or empty previews everywhere) is invisible during development — only surfacing when links are shared in production.
Also Known As
TL;DR
Explanation
Open Graph (OG) was introduced by Facebook in 2010 and has since become the universal standard for social sharing metadata, adopted by all major platforms. The four required tags are og:title, og:description, og:image, and og:type. Twitter/X reads OG tags as fallback for its own twitter:card tags. When a URL is shared in Slack, Discord, WhatsApp, LinkedIn, or Facebook, the platform's crawler fetches the page and reads OG tags to build the link preview. Without them, platforms show the page URL with no image and often wrong or empty title/description. og:image has strict requirements: must be an absolute URL (https://), recommended minimum 1200×630px for optimal display, and the server must allow the crawler's User-Agent. Dynamic OG image generation (via serverless functions or edge workers) enables per-page preview images at scale.
Common Misconception
Why It Matters
Common Mistakes
- Using a relative URL for og:image — must be absolute (https://domain.com/image.jpg), not /image.jpg.
- og:image smaller than 600×315px — many platforms will not display undersized images.
- Same og:image on every page — generic brand image on a product page looks wrong in social previews.
- og:title duplicating the page title verbatim — social titles can be different and more compelling than SEO titles.
- Missing og:type — defaults to 'website' but article pages should use og:type='article' for enhanced previews.
Avoid When
- Do not set og:image to a relative URL — it will not resolve correctly for external crawlers.
- Do not use og:image dimensions below 600x315px — platforms may ignore undersized images.
When To Use
- Add OG tags to every page that could be shared on social media or messaging platforms.
- Use og:type='article' for blog posts and news articles to enable enhanced preview metadata.
- Use per-page og:image rather than a global brand image for product, article, and landing pages.
Code Examples
<!-- No OG tags — social platforms generate fallback with no image -->
<head>
<title>Product Page</title>
</head><head>
<meta property="og:title" content="Blue Ceramic Coffee Mug — ShopName">
<meta property="og:description" content="Handcrafted 350ml mug with bamboo lid. Free shipping on orders over £30.">
<meta property="og:image" content="https://example.com/images/mug-og.jpg">
<meta property="og:url" content="https://example.com/products/blue-mug">
<meta property="og:type" content="product">
<!-- Twitter/X fallback -->
<meta name="twitter:card" content="summary_large_image">
</head>