Open Graph

Quick definition

Open Graph is a protocol of meta tags that describe a web page for sharing. When someone pastes a URL into Facebook, LinkedIn, Slack, WhatsApp, or many other apps, the platform fetches the page, reads tags such as og:title, og:description, and og:image, and builds a preview card from them.

Facebook introduced the protocol in 2010 so that any web page could become a rich object in its social graph. Today the tags are a de facto standard far beyond Facebook. They have nothing to do with rankings in Google's web results. They decide how a page looks in the places where people share links with each other.

What a preview card is made of

A typical link preview has four visible parts: an image, a title, sometimes a short description, and the domain or site name. Without Open Graph tags, each platform guesses. It may take the <title>, the first paragraph, or the first large image on the page, which is sometimes a logo, an ad, or the text of a cookie banner.

With Open Graph tags you make that choice yourself. The platform still controls the layout, the crop, and what it shows, but it works with the material you chose.

The four basic properties

The Open Graph specification at ogp.me names four properties that every page should have:

• og:title: the title of the object as it should appear in the preview.
• og:type: the kind of object, for example website or article. Pages without a type are treated as website.
• og:image: the URL of the image that should represent the page.
• og:url: the canonical URL of the page, which acts as its permanent ID in the graph.

A minimal setup looks like this:

html<head>
  <title>Trail running shoes for women | Example Shop</title>
  <meta property="og:title" content="Trail running shoes for women">
  <meta property="og:type" content="website">
  <meta property="og:url" content="https://www.example.com/women/shoes/trail-running/">
  <meta property="og:image" content="https://www.example.com/og/trail-running-women.jpg">
  <meta property="og:image:width" content="1200">
  <meta property="og:image:height" content="630">
  <meta property="og:image:alt" content="Three trail running shoes on a rocky path">
  <meta property="og:description" content="Grip, cushioning, and fit compared for 24 current models.">
  <meta property="og:site_name" content="Example Shop">
  <meta property="og:locale" content="en_US">
</head>

Note the property attribute. Open Graph is built on RDFa, so the tags use property rather than the name attribute that the meta description uses.

Useful optional properties

Beyond the basics, a few optional properties are worth setting on most sites:

• og:description: one or two sentences about the page. Some platforms show it, others hide it in most layouts.
• og:site_name: the name of the site, as distinct from the page title.
• og:locale: the language and territory in the format en_US. og:locale:alternate lists other available languages.
• og:image:alt: a text description of the image for people who cannot see it.
• og:image:width and og:image:height: the image dimensions in pixels.

For og:type set to article, the specification adds properties such as article:published_time, article:modified_time, article:author, article:section, and article:tag. Not every platform uses them, but they cost little and describe the content accurately.

If a property appears several times, for example several og:image tags, the specification says the first one takes precedence in a conflict. Put the preferred image first.

The image decides the click

In most feeds the image is the largest part of the preview, so it deserves the most attention.

Facebook's documentation recommends images of at least 1200 × 630 pixels for the best display on high-resolution screens, which is an aspect ratio of about 1.91:1. Smaller images may be shown as a small thumbnail next to the text instead of a large card. Other platforms use similar landscape formats, but their exact limits differ and change over time, so check the current documentation of the platforms that matter to you.

A few practical rules hold everywhere:

• Use an absolute HTTPS URL that is publicly reachable without login, cookies, or hotlink protection.
• Keep important content, especially text, away from the edges. Some surfaces crop to a square.
• Create the image for sharing rather than reusing a random content image. A product photo on white works, a tall portrait photo usually does not.
• Set og:image:width and og:image:height. Facebook says that without them, the image may not appear the first time a URL is shared, because it has to be processed first.
• Prefer common formats such as JPEG or PNG. Support for newer formats varies between platforms.

Compressing the share image matters less than for on-page images, because it is fetched by the platform, not by every visitor. Normal image optimization still applies to the images on the page itself.

og:url and canonical URLs

og:url should contain the same URL as the page's canonical tag. Facebook treats it as the object ID and groups interactions such as shares under that URL. If tracking parameters, session IDs, or a non-canonical variant end up in og:url, the same article can appear as several separate objects.

Use the absolute canonical URL, keep the protocol and trailing slash identical to the canonical, and update both when a page moves.

Open Graph, title tags, and structured data

Three kinds of metadata often get confused:

• The title tag and meta description address search engines and the browser. Google may rewrite them in results.
• Open Graph addresses link previews on social and messaging platforms.
• Schema.org structured data describes entities and page types for search features, for example a BreadcrumbList for breadcrumb trails or Product markup for a shop.

They can and often should carry different wording. A title tag may include the brand and a qualifier for search. An og:title can be shorter and more conversational, because the platform usually shows the domain anyway.

Google does not document Open Graph as a ranking signal. It does name two tags in its documentation. og:site_name is one of the sources Google's site name system may consider, next to WebSite structured data, the title, and headings. And og:image is one of the metadata hints Google may use when choosing a preferred image for a page. Both are hints, not controls.

X, LinkedIn, and other platforms

X uses its own Twitter Card tags, such as twitter:card with values like summary or summary_large_image. According to X's documentation, its card processor first looks for the twitter: tags and falls back to the matching Open Graph tags for title, description, and image when they are missing. In practice, most sites add twitter:card and let the Open Graph tags supply the rest.

LinkedIn, Slack, Discord, WhatsApp, Microsoft Teams, and many other apps read Open Graph tags directly. Their layouts and crops differ, which is another reason to keep the image simple and centered.

Caching and testing

Platforms cache what they scrape. After you change a title or image, an old preview can persist for days or weeks. Most large platforms offer a tool to fetch the page again:

• Facebook's Sharing Debugger shows the tags Facebook found, warnings, and a button to scrape again.
• LinkedIn's Post Inspector shows how LinkedIn reads the URL and refreshes its cache.
• For X, the preview in the post composer is the practical test, since the Card Validator no longer shows previews.

These tools also reveal a common server problem: firewalls or bot protection that block the platform's crawler. If the debugger reports an error or an empty response, check the server logs and the protection rules for crawlers such as facebookexternalhit.

JavaScript and single-page apps

Most link preview scrapers read the HTML response without running JavaScript. In a single-page application that sets its meta tags in the browser, the scraper sees the generic tags from the app shell, often the same title and image for every URL.

The solution is to put Open Graph tags into the server response through server-side rendering, static generation, or a framework's metadata API. The same applies to images. A share image that only becomes real after a lazy loading script swaps a placeholder is invisible to a scraper that never runs the script.

A worked example

The investigation finds three causes. The site is a single-page app, so the scraper only sees the default tags from the app shell. The default og:image is a 300 × 300 pixel logo. And og:url points to the homepage for every route.

After the fix, each guide renders its tags on the server: its own og:title, a 1200 × 630 pixel image with the guide's topic, og:url matching the canonical, and og:type set to article. A new scrape in the Post Inspector shows the large card, and new shares display the right preview.

Common mistakes

• leaving og:image empty so that platforms pick a logo, an ad, or a banner
• using relative image URLs or images behind login or hotlink protection
• setting the same og:url on every page, often the homepage
• adding tracking parameters to og:url
• setting Open Graph tags only with client-side JavaScript
• using portrait images or text near the edges that gets cropped
• forgetting to refresh the cache after changing tags
• blocking platform crawlers with bot protection
• expecting Open Graph tags to improve Google rankings

A practical check

1. View the page source, not the inspector, and confirm the og: tags are in the server's HTML.
2. Check that og:title, og:type, og:image, and og:url are present on every template.
3. Compare og:url with the canonical URL.
4. Open the og:image URL in a private window and check its size, format, and crop.
5. Paste the URL into Facebook's Sharing Debugger and LinkedIn's Post Inspector.
6. Check for errors that point to blocked crawlers or redirects.
7. Add twitter:card if previews on X matter to you.
8. After changes, scrape again so the platforms update their cache.

The Crawl Foundry perspective

A link preview is assembled by each platform from the HTML it fetches, so the platform's own debugger is the final authority on how a shared URL looks. We do not present Crawl Foundry's Site Audit as an Open Graph validator.

What Site Audit adds is the technical base around those previews. Its crawler checks the rendered HTML of your pages and keeps a crawl history, so runs can be compared after a template release. Keep in mind that most preview scrapers read the raw HTML without JavaScript. If a tag appears in a rendered view but not in the page source, a scraper may still miss it. If you want to see how a crawl is set up, the Site Audit overview explains it. Site Audit is a paid data action, and the price is shown before you start.

Related terms

• Meta description
• Schema markup
• Image optimization
• JavaScript rendering SEO
• Organic click-through rate
• robots.txt

Review sources

• The Open Graph protocol
• Meta for Developers: Sharing for webmasters
• Meta for Developers: Sharing Debugger
• X Developer Platform: Cards markup reference
• LinkedIn: Post Inspector
• Google Search Central: Site names in Google Search
• Google Search Central: Image SEO best practices