Open Graph Tags: The Complete Guide to Social Media SEO
Open Graph tags control how your pages appear when shared on Facebook, LinkedIn, Twitter, and messaging apps. Learn every essential OG tag, image specifications, Twitter Card variants, and how to debug sharing previews.
When someone shares a link on Facebook, LinkedIn, Twitter, Slack, Discord, or iMessage, the platform renders a preview card. That card typically shows a title, a description, and an image. Whether those elements are compelling and accurate, or missing and broken, depends entirely on the Open Graph tags in your HTML.
Open Graph is a protocol created by Facebook in 2010 to give web pages structured metadata that social platforms can consume. The idea was simple: let page authors control how their content appears in social feeds instead of leaving it up to each platform's scraping heuristics. The protocol succeeded so thoroughly that it is now the de facto standard for link previews across virtually every major platform and messaging app.
Getting Open Graph right is not optional for any page you expect to be shared. Pages without proper OG tags generate bland, text-only previews that get scrolled past. Pages with broken OG images look unprofessional. And pages with well-crafted OG metadata consistently earn more clicks, more engagement, and more traffic from social channels.
The Essential Open Graph Tags
Every page should include these core OG tags at minimum. They go in the <head> section of your HTML.
<head>
<meta property="og:title" content="Open Graph Tags: The Complete Guide" />
<meta property="og:description" content="Learn how to control how your pages appear when shared on social media." />
<meta property="og:image" content="https://example.com/images/og-guide.jpg" />
<meta property="og:url" content="https://example.com/blog/open-graph-guide" />
<meta property="og:type" content="article" />
<meta property="og:site_name" content="Example Blog" />
<meta property="og:locale" content="en_US" />
</head>
og:title
The title displayed in the share card. This does not have to match your <title> tag. In fact, it often should not. Your HTML title might include a brand suffix or be optimized for search results, while your OG title should be optimized for social feeds where you are competing for attention in a scroll.
Keep OG titles under 60 characters. Facebook truncates around 65-70 characters, and LinkedIn is even more aggressive.
og:description
A brief summary shown below the title in the share card. Not all platforms display this — Twitter summary cards show it, but large image cards may not. Keep it under 155 characters and make sure it adds context that the title alone does not provide.
og:image
The most important OG tag from a click-through perspective. Studies have consistently shown that posts with images see significantly more engagement than text-only shares — social platforms are inherently visual, and OG images ensure your content takes advantage of this.
The image URL must be absolute (not relative) and must use HTTPS on any page served over HTTPS. A relative path like /images/og.jpg will not work. Use the full URL: https://example.com/images/og.jpg.
og:url
The canonical URL for the content. This tells platforms which URL to associate with the shared content, which matters for aggregating share counts and avoiding duplicates. If you have the same content accessible at multiple URLs, all of them should point to a single canonical og:url.
og:type
Defines the type of content. The most common values are website (for homepages and general pages) and article (for blog posts, news articles, and similar content). The type you choose determines which additional properties are available.
og:site_name
The name of your overall site, displayed separately from the title. Facebook shows this above the title in smaller text.
og:locale
The language and territory of the content in the format language_TERRITORY, such as en_US, sv_SE, or fr_FR. Defaults to en_US if omitted. If your content is available in multiple languages, you can also add og:locale:alternate tags for each additional locale.
Image Specifications
Getting your OG image right is worth extra attention because a broken or awkwardly cropped image is often worse than no image at all.
Recommended dimensions: 1200 x 630 pixels. This gives you a 1.91:1 aspect ratio, which is the standard across Facebook, LinkedIn, and Twitter's large image cards.
Minimum dimensions: Facebook requires at least 200 x 200 pixels, but images below 600 x 315 will render as small thumbnails rather than large preview cards. Always aim for 1200 x 630.
File size: Keep images under 8 MB. Facebook's documentation says their crawler times out on images that take too long to fetch, and large file sizes slow that down. In practice, keeping images under 1 MB is a good target.
Format: JPG, PNG, and WebP are all supported. JPG is the most reliable across all platforms. PNG works well for graphics with text. WebP is supported by Facebook and Twitter but may not render correctly on older clients.
HTTPS: If your page is served over HTTPS (it should be), the image URL must also be HTTPS. Mixed content will cause the image to fail to load on many platforms.
<meta property="og:image" content="https://example.com/images/og-guide.jpg" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta property="og:image:type" content="image/jpeg" />
<meta property="og:image:alt" content="A visual guide to Open Graph tags" />
Including og:image:width and og:image:height is a small detail that helps platforms render the preview correctly on the first share, before they have finished downloading and measuring the image.
Article-Specific Tags
When you set og:type to article, several additional properties become available. These are particularly useful for news sites, blogs, and content-heavy sites.
<meta property="og:type" content="article" />
<meta property="article:published_time" content="2026-03-28T09:00:00Z" />
<meta property="article:modified_time" content="2026-03-28T14:30:00Z" />
<meta property="article:author" content="https://example.com/authors/jane-doe" />
<meta property="article:section" content="Tutorials" />
<meta property="article:tag" content="SEO" />
<meta property="article:tag" content="Social Media" />
article:published_time and article:modified_time use ISO 8601 format. These dates may be displayed on the share card and are used by platforms to assess content freshness. article:section represents the high-level category, while article:tag can be repeated for multiple tags.
Other og:type values include product (useful for e-commerce), profile (for author or user pages), and book, music.song, video.movie, among others. The website type is the safe default for any page that does not fit a more specific category.
Twitter Cards
Twitter has its own card system that works alongside Open Graph. Twitter's crawler first looks for twitter: meta tags, then falls back to the equivalent og: tags. This means you can often rely on your OG tags alone, but adding Twitter-specific tags gives you more control over how your content appears on Twitter specifically.
Card Types
summary — A small card with a square thumbnail, title, and description. Good for articles and general content.
summary_large_image — A large card where the image spans the full width above the title and description. This is the most common choice for blog posts and landing pages because the large image is much more attention-grabbing in the timeline.
player — For embedded video or audio content. Requires additional tags for the player URL, dimensions, and stream URL.
app — For promoting mobile applications, with direct links to app stores.
<!-- Twitter Card tags -->
<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:site" content="@yourbrand" />
<meta name="twitter:creator" content="@authorhandle" />
<meta name="twitter:title" content="Open Graph Tags: The Complete Guide" />
<meta name="twitter:description" content="Learn how to control social sharing previews." />
<meta name="twitter:image" content="https://example.com/images/og-guide.jpg" />
<meta name="twitter:image:alt" content="A visual guide to Open Graph tags" />
Note that Twitter meta tags use name rather than property. The twitter:site tag should be the Twitter handle of the website or brand, while twitter:creator is the handle of the individual author. Both are optional but recommended.
Twitter Fallback Behavior
If no twitter:title is present, Twitter uses og:title. If no og:title is present, Twitter uses <title>. The same cascade applies to description and image. This means a minimal implementation can skip the twitter: tags entirely and rely on OG tags. However, explicitly setting twitter:card is important because without it, Twitter defaults to a basic summary card regardless of your image size.
Platform-Specific Behavior
Different platforms interpret and render OG tags with notable differences.
Facebook renders the full trifecta: image, title, and description. Images display at the 1.91:1 aspect ratio. Title truncation happens around 65-70 characters. Facebook aggressively caches scraped data, sometimes for weeks.
LinkedIn also shows image, title, and description, but LinkedIn's crawler is slower and more sensitive to page load times. LinkedIn truncates titles around 50-60 characters. Image rendering is similar to Facebook's.
Twitter/X behavior depends on the card type. With summary_large_image, the image appears above the title and description. With summary, the image is a small square to the left. Twitter strips the description from summary_large_image cards in some views, making the image and title the only visible elements.
Slack renders a rich preview that typically includes the site name (from og:site_name), the title, description, and image. Slack is generally faithful to the OG tags and renders them well, but it caches aggressively.
Discord renders previews similar to Slack. It respects og:site_name, title, description, and image. Discord uses a colored sidebar based on the theme color meta tag if one is present.
iMessage/Messages shows a link preview with the image and title. It is one of the more minimal renderers and does not always show the description.
Debugging OG Tags
You cannot rely on simply sharing a link and hoping the preview looks right. Each major platform provides debugging tools.
Facebook Sharing Debugger
The Facebook Sharing Debugger lets you enter a URL and see exactly what Facebook's crawler sees. It shows all detected OG tags, any warnings or errors, and a preview of how the share card will look. Most importantly, it lets you force Facebook to re-scrape the page.
Twitter/X Card Testing
Twitter/X removed their standalone Card Validator. To test Twitter Cards, post the URL in a tweet (or use the tweet composer preview) or use third-party tools like opengraph.xyz which can preview how your page will render across multiple platforms including Twitter/X.
LinkedIn Post Inspector
The LinkedIn Post Inspector works similarly. Enter a URL, see the preview, and force a re-scrape.
Manual Inspection with curl
Platforms send specific user agents when scraping. You can simulate this to see what they see:
# Simulate Facebook's crawler
curl -A "facebookexternalhit/1.1" -L https://example.com/page
# Simulate Twitter's crawler
curl -A "Twitterbot/1.0" -L https://example.com/page
# Simulate LinkedIn's crawler
curl -A "LinkedInBot/1.0" -L https://example.com/page
This is useful for catching issues where your page returns different content to bots versus browsers, or when client-side JavaScript renders OG tags that the crawler cannot see.
Cache Invalidation
One of the most frustrating aspects of Open Graph is platform caching. When you update your OG tags, the old preview often persists in social feeds because platforms cache the scraped data.
Facebook caches aggressively. Use the Sharing Debugger and click "Scrape Again" to force a refresh. For programmatic cache clearing, Facebook offers an API endpoint: POST https://graph.facebook.com/?id={url}&scrape=true.
Twitter caches cards for about seven days. Since the standalone Card Validator has been removed, you can force a re-scrape by posting the URL in a tweet or using third-party tools. There is no public API for programmatic cache busting.
LinkedIn caches for about seven days as well. The Post Inspector forces a re-scrape when you inspect a URL.
Slack caches link previews per-workspace. There is no official way to clear the cache other than waiting or having a workspace admin clear it.
If you regularly update OG tags and need changes to propagate quickly, consider adding cache-busting query parameters to your og:image URL (e.g., ?v=2) when you update the image. This forces platforms to treat it as a new resource.
Common Mistakes
Missing og:image. This is the single most impactful mistake. A share without an image is easy to scroll past. Always provide an image, even if it is a generic branded fallback.
Wrong image dimensions. Using a square image for a 1.91:1 slot results in awkward cropping or letterboxing. Using a very tall image means the most important content gets cropped from the sides. Always test at 1200 x 630.
Relative URLs. Both og:image and og:url require absolute URLs including the protocol and domain. /images/og.jpg will not work. Use https://example.com/images/og.jpg.
HTTP images on HTTPS pages. Mixed content will cause images to fail on most platforms. Ensure your image URLs use HTTPS.
Duplicate tags. Having multiple og:title or og:description tags confuses crawlers. Most will use the first occurrence and ignore the rest, but the behavior is not guaranteed. Ensure each tag appears exactly once per page.
Using page content as a fallback. When OG tags are missing, platforms fall back to scraping the page title and first paragraph of visible text. This fallback is rarely accurate or compelling. Do not rely on it.
Client-side rendered tags. Facebook, Twitter, and LinkedIn crawlers have limited JavaScript execution capability. If your OG tags are rendered by client-side JavaScript rather than being present in the initial HTML response, most crawlers will not see them. Always server-render your meta tags.
Dynamic OG Images
For sites with hundreds or thousands of pages, creating a unique OG image per page by hand is impractical. Dynamic OG image generation solves this by creating images programmatically based on page data.
Approaches
Server-side image generation — Most modern frameworks offer built-in or library-supported OG image generation. You define a template that accepts page data (title, category, brand colors) as parameters and renders a 1200×630 PNG on the server. This is the most flexible approach and produces unique images for every page without manual design work.
CDN-based image transformation — Services like Cloudinary and Imgix offer URL-based transformation APIs that overlay text on a base template image. The OG image URL itself contains the text as a parameter, so no server-side rendering is needed. This is simpler to set up but less flexible in design.
Headless browser rendering — For maximum design control, a headless browser service (Puppeteer, Playwright) renders an HTML template to a screenshot. This gives full CSS support but adds infrastructure complexity.
When Dynamic OG Images Are Worth It
Dynamic OG images are worth the effort when you have a large number of pages that are frequently shared and where the default generic image would not accurately represent the specific content. E-commerce product pages, blog posts, and profile pages are strong candidates. Internal tools and rarely-shared pages are not.
Managing OG Tags at Scale
On a site with thousands of pages, you need a systematic approach to OG tags rather than setting them individually.
Template-Based OG Tags
Define OG tag templates per content type. For a blog, you might have:
og:title = "{post_title}"
og:description = "{post_excerpt}"
og:image = "https://example.com/api/og?title={post_title}&category={category}"
og:type = "article"
For product pages:
og:title = "{product_name} - {price}"
og:description = "{short_description} | Free shipping on orders over $50"
og:image = "{product_image_url}"
og:type = "product"
This template approach ensures every page has proper OG tags without requiring manual entry. When you want to update the format of all product OG titles, you change the template once.
Testing at Scale
After implementing template-based OG tags, validate them programmatically. Crawl your site and check that every page has the required OG tags, that all image URLs resolve and return the correct content type, that no titles exceed the recommended character limits, and that no duplicate tags exist.
Tools like Screaming Frog, Sitebulb, or a custom crawler can extract and audit OG tags across your entire site. Dynamic SEO's URL-first approach lets you manage and audit metadata templates at scale, catching issues before they affect your social sharing previews.
Conclusion
Open Graph tags are a small amount of HTML that has an outsized effect on how your content performs in social channels. The core implementation is straightforward: add the essential tags to every page, use the correct image dimensions, and test with the platform debugging tools.
Set og:title and og:description independently from your SEO title and meta description — social sharing and search results serve different intents. Use 1200x630 images, test with Facebook's Sharing Debugger before launching campaigns, and template your OG tags at scale rather than editing them per page.
