When someone shares your page on Facebook, LinkedIn or WhatsApp, Open Graph tags determine the title, description and image that appears in the preview. Without them, social platforms pick content randomly — often with poor results.
| Tag | Purpose | Recommended value |
|---|---|---|
| og:title | Title shown in social preview | Page title — can differ from title tag |
| og:description | Description shown in preview | 2-3 sentence summary, under 200 characters |
| og:image | Image shown in preview | 1200 x 630px, HTTPS URL, under 8MB |
| og:url | Canonical URL of the page | Absolute URL with https:// |
| og:type | Type of content | website for homepages, article for blog posts |
| og:site_name | Name of your site | Your brand name |
Run the OG Tag Generator — enter your page title, description, image URL and other details and it generates the complete set of Open Graph meta tags ready to paste into your page head.
Open Graph is an RDFa-based protocol, and its tags use the property attribute — not name. This one detail accounts for a very large share of all broken link previews on the web.
<meta property="og:title" content="…"><meta name="og:title" content="…">The Twitter Card tags use name, not property. So a correct head contains both conventions side by side, which looks like a mistake and is not:
<meta property="og:title" content="…"><meta name="twitter:card" content="summary_large_image">The good news is that X falls back to Open Graph tags when the Twitter equivalents are absent. So in practice you need only twitter:card to declare the layout you want, and the OG tags will supply the title, description and image. Duplicating every tag in both namespaces is a common waste of effort.
This is the second great source of missing previews, and it is invisible if you only ever look at your page in a browser.
The crawlers that build link previews — Facebook's, LinkedIn's, Slack's, WhatsApp's, Discord's — fetch your HTML and parse it. Most of them do not execute JavaScript. So if your Open Graph tags are injected client-side by a framework, a tag manager, or a head-management library that runs after hydration, the scraper sees a document with no OG tags at all.
The page looks perfect when you inspect it, because DevTools shows you the DOM after JavaScript has run. The scraper saw the document before. These are different documents.
curl and read the raw response. If the OG tags are not in that output, they do not exist as far as social platforms are concerned, regardless of what your browser shows. Anything you want in a link preview must be server-rendered into the initial HTML.The same applies to any bot-blocking you have in place. If robots.txt or a WAF rule blocks facebookexternalhit, Twitterbot, LinkedInBot, Slackbot or Discordbot, those platforms cannot fetch your page and will render a bare, unclickable link. Bot-blocking configured to stop scrapers routinely takes out link previews as collateral damage, and nobody connects the two.
The size is settled — 1200 × 630. These are the requirements that actually cause failures.
/images/og.png fails. The scraper is not on your site; it has no base to resolve against.og:image:width and og:image:height. Without them, the platform does not know the dimensions until it has downloaded and measured the image — so the first share of a URL frequently renders as a small thumbnail rather than the large card you designed, and by the time the cache is warm the post is already published. Declaring the dimensions makes the first share correct.og:image:alt. Screen reader users encounter your preview card too.Every platform caches what it scraped, and the cache is keyed on the URL. Change the tags and re-share, and the platform will cheerfully serve you the preview it built weeks ago. This produces a specific and maddening failure: you fix the tags, share the link, see the old broken preview, and conclude the fix did not work.
The fix is to force a re-scrape:
curl and confirm the tags exist in the raw HTML. If they do not, it is a rendering or blocking problem and no amount of cache clearing will help. Only when the tags are provably in the served HTML does clearing the cache become the right next step. Doing it the other way round wastes a great deal of time.og:url is doing something you may not realiseIt looks like the least interesting tag on the list. It is not — it is the tag that decides which URL your social engagement accumulates against.
Platforms treat og:url as the canonical identity of the content. When a page is shared with tracking parameters — ?utm_source=newsletter, ?fbclid=…, a campaign tag, a referral code — the platform uses og:url to recognise all of those as the same piece of content. Reactions, comments and share counts consolidate onto one entry.
Get it wrong and they fragment. If your page emits og:url reflecting whatever parameters it was loaded with, then a link shared five ways becomes five separate pieces of content in the platform's eyes, each starting from zero engagement. The post that should have shown 400 shares shows five posts with 80 each.
og:url should always be the clean, canonical, absolute URL of the page — the same one in your rel="canonical".og:type, and the tags nobody setsog:type is not decoration — it determines which additional properties the protocol permits, and platforms use them.
website — the default. Correct for a homepage or a landing page.article — for anything with an author and a publication date. It unlocks article:published_time, article:modified_time, article:author and article:section, which some platforms surface and which help correctly attribute a piece to a writer.product, video, profile — for their obvious cases.And a distinction worth stating explicitly, because it catches people out: og:title and og:description are not your title tag and meta description, and should frequently differ from them. They serve different readers with different intent.
og:title is read by someone idly scrolling a feed who was not looking for you at all. It has to earn attention from a standing start.Reusing the SEO title for both is the default in almost every CMS, and it means your social previews are written for the wrong audience. A title optimised to satisfy a search query is rarely the sentence that stops a thumb.
Open Graph tags are meta tags in your page head that control how your content appears when shared on social media platforms. They were created by Facebook and are now used by Facebook, LinkedIn, WhatsApp, Slack, Discord and most other platforms that generate link previews. The key tags are og:title, og:description, og:image and og:type.
The recommended og:image size is 1200 x 630 pixels — a 1.91:1 aspect ratio. This renders correctly on Facebook, LinkedIn and Twitter/X. The minimum size is 600 x 315 pixels. Images smaller than this may not render on some platforms. Use PNG or JPEG format. Avoid text-heavy images as platform compression can make small text unreadable.
Open Graph tags do not directly affect Google rankings — Google does not use them as ranking signals. However, they indirectly affect SEO through social sharing. Pages with well-configured OG tags that generate attractive social previews get shared more, which generates backlinks and direct traffic. The og:image in particular significantly affects whether people click shared links.
Three causes account for most of them. The tags may use name= instead of property= — Open Graph is RDFa-based and scrapers look for the property attribute, so name="og:title" is silently ignored. The tags may be injected by JavaScript, which most social scrapers never execute; they parse the served HTML, so anything added after hydration does not exist to them. Or the crawler may be blocked — a robots.txt or firewall rule that stops facebookexternalhit, Twitterbot, LinkedInBot, Slackbot or Discordbot will prevent the preview from being built at all.
Every platform caches what it scraped, keyed on the URL, so re-sharing serves you the preview it built weeks ago. Force a re-scrape with Facebook's Sharing Debugger, which also prints exactly which tags it found and is the best diagnostic available. LinkedIn caches especially aggressively and needs its Post Inspector. First, though, confirm with curl that the tags are actually in the raw served HTML — if they are not, it is a rendering problem and clearing caches will achieve nothing.
Mostly no. X falls back to Open Graph tags when the Twitter equivalents are absent, so you generally need only twitter:card to declare the layout you want — the OG tags supply the title, description and image. Note the attribute flips: Open Graph tags use property=, while Twitter Card tags use name=. A correct head therefore contains both conventions side by side, which looks wrong and is not.
Because platforms treat og:url as the canonical identity of the content, and use it to consolidate engagement from every variant of the link — tracking parameters, campaign tags, click IDs. If og:url reflects whatever parameters the page was loaded with, one piece of content becomes several as far as the platform is concerned, each starting from zero, so reactions and share counts fragment across them. It should always be the clean absolute URL, matching your rel=canonical.
Run the OG Tag Generator and get results in minutes. Pay as you go.
Generate OG Tags →aiwebpageseo.com is a data-driven SEO and AEO (Answer Engine Optimisation) platform providing a free suite of technical website tools. Rather than relying on AI-theorised assumptions, the platform analyses live URL performance, delivering objective diagnostics, page speed metrics, CLS debugging, and site crawl data alongside actionable technical tutorials.