A Guide to Open Graph Types for Perfect Social Shares

You share a link to your latest landing page in Slack. The preview pulls an old logo, the headline gets cut off, and the description sounds like it came from a random paragraph halfway down the page.

Then you paste the same link into LinkedIn. Different image. Different text. Still wrong.

A common assumption is that social previews are a platform problem. They aren't. They're usually a metadata problem, and the fix starts with understanding Open Graph types.

Why Your Links Look Bad on Social Media and How to Fix It

A bad link preview feels small until it happens in front of a client, a prospect, or your own team. Marketing writes a polished headline. Design makes a share image. The page goes live. Then someone posts the URL and the preview ignores all that work.

What you see instead is usually one of three things:

The wrong title gets pulled from the browser title or a fallback field
The wrong image shows up because the platform guessed
No useful preview appears at all, so the link looks bare and forgettable

That isn't random behavior. Social platforms and messaging apps scrape your page and look for clues in the HTML. If those clues are missing, weak, or inconsistent, the platform fills in the blanks on its own.

A social preview is often the first version of your page that another person sees. If that first impression is messy, the page feels less trustworthy before anyone clicks.

Open Graph serves this purpose. Open Graph is a standardized protocol for telling platforms what title, image, URL, description, and content type to use when your page is shared. Instead of letting Facebook, LinkedIn, Slack, or another tool improvise, you hand them the exact preview you want.

That matters for more than appearance. It affects brand consistency, message control, and whether the shared link looks intentional or neglected. If you want a page to travel well across channels, Open Graph tags are part of the publishing process, not an optional technical extra.

If you're trying to troubleshoot a preview that's already broken, this guide on for developers to debug OG tags is a useful companion because it helps you inspect what platforms are likely seeing.

Understanding the Open Graph Protocol

Think of Open Graph as a business card for your webpage. Your page already contains lots of information, but social platforms don't want to guess which parts matter. Open Graph gives them a clean summary in the page's <head>.

According to the public specification at the Open Graph protocol documentation, Open Graph is a standardized web protocol created by Facebook in 2010. Its core model centers on tags like og:type, og:title, og:image, and og:url, and major platforms including LinkedIn and Pinterest adopted it.

An infographic explaining the Open Graph protocol, showcasing its purpose, meta tag location, and core properties.

What lives in the head of the page

These tags are meta tags. They don't show up in the visible body copy of your page. They reside in the HTML <head> and describe the page for machines that need to build previews.

The essential set is small:

og:title gives the preview headline
og:type tells the platform what kind of object the page represents
og:url identifies the canonical page URL
og:image points to the preview image
og:description is strongly recommended because it adds context

If you want a broader refresher on how these fit alongside other metadata, this LPagery meta tags overview gives a helpful high-level map.

Why `og:type` matters

Title and image are readily understood. og:type is where confusion starts.

og:type classifies the page. It answers the question, "What is this thing?" A homepage is usually a website. A blog post is often an article. A product page may use product.

That classification matters because it changes what extra properties you can attach. An article can carry article-specific fields. A product can carry product-related fields. If you use a generic type for everything, the preview may still work, but you lose precision.

Practical rule: If a page has a clear primary purpose, use the Open Graph type that matches that purpose. Don't choose based on what sounds more sophisticated.

A simple example

A basic Open Graph setup often looks like this:

<meta property="og:title" content="Spring Campaign Landing Page">
<meta property="og:type" content="website">
<meta property="og:url" content="https://example.com/spring-campaign">
<meta property="og:image" content="https://example.com/images/spring-share.jpg">
<meta property="og:description" content="See the new spring campaign and download the launch kit.">

That small block gives social platforms a much cleaner instruction set than "scan the page and do your best."

A Guide to Common Open Graph Types

Regarding open graph types, the typical desire is for one practical answer: which type should I use on this page?

For most business websites, three types cover the majority of use cases. If you pick the right one and support it with sensible companion tags, you'll avoid most preview problems.

Quick reference table

og:type	Best For	Key Associated Properties
`website`	Homepages, landing pages, main marketing pages	`og:title`, `og:url`, `og:image`, `og:description`
`article`	Blog posts, news updates, resource pages	`article:author`, `article:section`, `article:tag`
`product`	Ecommerce product pages, catalog items, sales pages	`product:price:amount`, `product:price:currency`

`website` for general pages

Use website when the page represents a general web destination rather than a specific editorial or catalog object. Homepages, feature pages, contact pages, and campaign landing pages often fit here.

This is the safest default when you don't need a more specialized content model.

<meta property="og:title" content="Acme Studio">
<meta property="og:type" content="website">
<meta property="og:url" content="https://example.com/">
<meta property="og:image" content="https://example.com/images/home-share.jpg">
<meta property="og:description" content="Brand strategy and design for growing companies.">

Use website when the preview should represent the page as a destination, not as a piece of media or editorial content.

`article` for posts and publications

If the page is clearly a written piece, article is a better fit than website. It tells platforms that the shared object is content someone can read, cite, or save.

That often applies to:

Blog posts
Help center articles
Editorial features
Press releases
Long-form guides

Here is a common pattern:

<meta property="og:title" content="How to Build Better Social Previews">
<meta property="og:type" content="article">
<meta property="og:url" content="https://example.com/blog/social-previews">
<meta property="og:image" content="https://example.com/images/social-preview-guide.jpg">
<meta property="og:description" content="A practical guide to Open Graph tags, previews, and debugging.">

<meta property="article:author" content="Jamie Lee">
<meta property="article:section" content="Marketing">
<meta property="article:tag" content="Open Graph">
<meta property="article:tag" content="Social Media">

Those article:* properties add useful context. They aren't required for every implementation, but they make the page model more descriptive.

`product` for things people can buy

Use product when the page centers on a specific item or offer. This type is useful for ecommerce catalogs, software pricing pages tied to a product object, or product detail pages with a clear buy intent.

<meta property="og:title" content="Acme Noise-Canceling Headphones">
<meta property="og:type" content="product">
<meta property="og:url" content="https://example.com/products/acme-headphones">
<meta property="og:image" content="https://example.com/images/headphones-share.jpg">
<meta property="og:description" content="Wireless headphones with active noise canceling and all-day comfort.">

<meta property="product:price:amount" content="199.00">
<meta property="product:price:currency" content="USD">

Use this only when the page is product-focused. A blog post reviewing headphones is still an article, not a product.

If you're torn between two types, pick the one that reflects the page's primary job. A mixed page still needs one main identity.

A simple decision shortcut

If the page exists to welcome visitors, it's probably website.

If the page exists to be read, it's probably article.

If the page exists to present something for sale, it's probably product.

That simple filter handles most real-world decisions without overthinking the taxonomy.

Exploring Advanced and Niche OG Types

Once you've handled the basics, the wider Open Graph family starts to make more sense. Many teams never go beyond website and article, which is fine for a lot of sites. But some pages benefit from more specific modeling.

A vintage 16mm film movie projector with reels, glowing lens, and film strip set in a studio.

Profile and identity types

The profile type is useful when a page represents a person rather than a company page or article. Think speaker bios, founder profiles, or team pages where the individual is the central object.

That specificity gives platforms a cleaner signal. Instead of "this is just a page," you're saying "this page is about a person."

Video-related types

Media publishers can get more precise with types like:

video.movie for a film page
video.episode for a show episode
video.tv_show for the show as a whole
video.other for video content that doesn't fit a narrower label

A movie page and an episode page aren't the same thing. Because of this, if you run a media library, using the more accurate type helps keep your metadata model organized and can support richer interpretation on platforms that recognize those distinctions.

Music-related types

Music publishers have their own set of options:

music.song
music.album
music.playlist
music.radio_station

If your site hosts artist pages, album releases, or music libraries, these types are more meaningful than a generic website. They also make your metadata easier to maintain because the page type matches the corresponding object.

Specific types are worth the effort when the page is part of a catalog, library, or media system. On a simple marketing site, they often aren't necessary.

When niche types are worth using

Use advanced Open Graph types when at least one of these is true:

Situation	Better approach
You manage a media archive	Use media-specific types
You publish person-centric profile pages	Use `profile`
You maintain a structured product or content catalog	Match the type to the object
You only need standard marketing previews	Stay with `website` or `article`

The benefit isn't novelty. It's clarity. More specific open graph types help machines understand what your page is, and that tends to produce cleaner, more predictable previews.

Best Practices for Implementation and Debugging

You can choose the perfect Open Graph type and still get a broken preview. In practice, most problems come from implementation details, stale caches, or rendering methods that social crawlers can't see.

The implementation checklist

Start with the basics and get them right consistently.

Use a strong og:title. Write it like a headline someone would want to click.
Keep og:description useful. It should support the title, not repeat it word for word.
Match og:type to the page. Don't label every page as website out of habit.
Set og:url to the canonical URL. That reduces confusion when the same content is reachable from multiple paths.
Point og:image to a direct image URL. Avoid fragile image paths and unnecessary redirects.
Use HTTPS URLs throughout. Mixed protocols create avoidable issues.

A common image recommendation used in OG guidance is 1200x630 pixels for og:image, and that's included in the checklist visual above as a practical design target for teams building share assets.

The debugging routine

When a preview looks wrong, don't guess. Inspect in this order:

View page source and confirm the OG tags are present in the raw HTML.
Check the exact shared URL. A preview may be scraping a variation of the page you didn't intend.
Use platform tools such as Facebook Sharing Debugger and LinkedIn Post Inspector to refresh and inspect the preview.
Verify the image URL loads directly in a browser.
Look for stale caches if you've recently changed the title or image.

If you manage many pages or generate metadata programmatically, good documentation helps. Teams building automated workflows often benefit from reviewing the NotionSender API documentation alongside their content systems so preview-related page data stays consistent.

Later in the troubleshooting process, it helps to watch someone walk through the workflow. This video gives a practical view of OG implementation and review:

The modern problem with JavaScript-rendered tags

This is the issue many older guides miss.

Prerender.io notes in its Open Graph implementation guidance that OG tags need to be rendered in the initial HTML. Social crawlers often don't execute client-side JavaScript, which means tags generated after page load may be missed.

That has big consequences for sites built with React, Vue, Next.js, Nuxt, or other SPA-style setups. If your app injects Open Graph tags only after hydration, a crawler may never see them.

What to do on modern stacks

For JavaScript-heavy sites, reliable options include:

Server-side rendering so tags are in the first response
Pre-rendering for pages that need crawlable metadata
Static head output for public content pages
Validation before launch using the same URL a platform will scrape

If a crawler can't see the tag in the first HTML response, treat that tag as missing.

That's the practical rule that saves the most debugging time.

Getting Perfect Previews for Your Notion Pages

Notion users run into a special version of the same problem. A public Notion page is easy to share, but easy doesn't always mean polished. The preview may be acceptable for internal use and still feel off-brand for clients, partners, or campaign distribution.

A comparison chart showing pros and cons of optimizing open graph preview tags for Notion pages.

Why Notion previews can feel inconsistent

Notion does generate some sharing metadata for public pages, which is convenient. The tradeoff is control. You may not get the exact title treatment, image choice, or description quality you want for external sharing.

That matters when the page is doing real business work, such as:

Client proposals
Project portals
Public documentation
Event pages
Shared campaign briefs

Seobility's Open Graph reference notes that when essential tags such as og:title, og:type, og:url, and og:image are omitted, social networks may auto-generate the preview. That can hurt brand consistency, which is exactly the risk teams feel when a Notion page preview looks generic or mismatched.

How to improve the outcome

You don't always need full low-level control to get a better result. Often, the practical path is to improve the source content and be deliberate about what gets shared.

Focus on:

Page title quality so the shared title reads cleanly
First visible summary content in case a platform falls back to body text
Cover and media choices because they may influence what appears in previews
Stable public URLs for pages meant to circulate externally

If you're publishing pages that need a more polished delivery flow, it's worth reviewing the options on NotionSender create for workflows that turn structured Notion content into outward-facing communication.

Why this matters for email too

Open Graph is usually discussed in the context of social media, but preview quality affects email workflows as well. Teams often drop links into newsletters, updates, handoff messages, or follow-up emails. When that destination page looks sharp in a preview, the whole message feels more considered.

A good Notion page preview does three things at once:

Benefit	Why it matters
Cleaner presentation	The link looks intentional, not accidental
Better message alignment	The preview matches the actual purpose of the page
More professional delivery	Clients and leads see a polished experience

For Notion users, open graph types aren't just a developer concern. They're part of how your workspace shows up in the outside world.

Frequently Asked Questions About Open Graph Types

Some questions come up again and again because the protocol looks simple on the surface but has a few easy traps.

What happens if I don't specify an `og:type`

Platforms may still generate a preview, but you're leaving classification up to inference or fallback behavior. That usually means less control and fewer page-specific properties. If the page clearly represents an article, product, or profile, it's better to say so directly.

Can I use multiple `og:type` tags on one page

You shouldn't. A page needs one primary identity for Open Graph. If the page contains a video inside an article, choose the main object the page represents. In that case, the page is usually still an article.

How do Open Graph tags relate to Twitter Cards

They solve a similar problem. Open Graph is widely used across multiple platforms. Twitter Cards are Twitter's own metadata format. Some services can fall back to Open Graph data when Twitter Card tags aren't present, but you shouldn't assume perfect parity for every platform. If social sharing is important, check both metadata systems on important pages.

For more practical publishing and workflow ideas around pages, links, and communication, the articles on the NotionSender blog are a good next read.

If you want a cleaner way to turn Notion-based work into polished outbound communication, NotionSender helps you send and manage email directly from Notion so your pages, updates, and workflows feel as organized on the outside as they do inside your workspace.