Open Graph Types: What og:type Actually Controls on Your Shared Link

Somewhere in your page's head section, one small tag decides which flavor of content a scraper thinks it found. That tag is og:type, and it's probably the most misunderstood property in the whole Open Graph spec. Ask three site owners what open graph types actually do and you'll get three different answers. Some swear the tag reshapes how a link looks on every platform, others have set it wrong for years and never noticed a thing.

Both camps are partly right, and the reason is structural: og:type doesn't own the visual layer most people think it owns. It owns something narrower, and knowing exactly what that is saves you from fixing the wrong problem.

What Is og:type?

Open Graph is the tagging system Facebook introduced so any page could describe itself to a scraper the way a rich object, not just a plain URL, would. og:type is one of four required properties in that system, alongside og:title, og:image and og:url. Per the canonical Open Graph protocol spec at ogp.me, og:type's job is to declare which "vertical" a page belongs to, and that declaration determines which extra, type-specific properties are valid for that page. If you don't set it, most platforms treat the page as the default: website.

Here's the part that trips people up. og:type is not a style switch, it's a namespace switch. Setting og:type to article doesn't hand you a new layout, it hands you permission to use six additional tags (article:author, article:published_time and the like) that a scraper will only bother reading if the type matches.

Get the type wrong and those extra tags don't error out. They just get ignored, quietly, with no warning in your source code.

One more mechanical detail worth knowing: Meta's own developer documentation states that a URL can declare exactly one og:type, never a list. If a CMS plugin or theme accidentally outputs two og:type tags on the same page, most scrapers will just take the first one and disregard the rest, which is its own quiet source of bugs.

The full list of Open Graph types

The ogp.me spec groups its vertical types into a handful of families. Below is the full core list, plus the one extension that trips up more e-commerce owners than any other tag on this list.

Notice that product sits apart from the rest. The ogp.me spec's own "Types" section lists website, article, book, profile, and the video and music families as the core vertical taxonomy, and product isn't in that list. It originated as a Facebook-specific extension for Facebook's old Product Ads and Commerce tooling, and plenty of e-commerce platforms still emit it out of habit.

That distinction matters more than it looks like it should, and I'll get to why in a moment.

Which og:type should a blog post use?

Article. That's the short answer, and there's rarely a reason to deviate from it for a standard post. Setting og:type to article enables the six properties in the table above, the most useful of which are article:published_time and article:author. Neither of these changes how your card renders visually on most platforms (more on that below), but they do give any scraper that reads them a structured way to know when a piece was published and who wrote it.

If you run WordPress, there's a good chance this is already handled for you without your input. Yoast SEO, the most widely installed SEO plugin for WordPress, sets og:type to article by default on every Post and automatically outputs article:published_time and article:modified_time alongside it, according to Yoast's own documentation. Which means a lot of blog authors have a technically correct open graph article setup right now and don't know it, because a plugin quietly did the work years ago. Worth checking anyway, because plugin defaults change and themes sometimes override them without telling you.

What extra tags does og:type article allow?

Once og:type is set to article, the ogp.me spec opens up a small namespace of six optional properties, all scoped under the article: prefix. None are required. All of them get silently dropped if og:type isn't set to article when a scraper reads the page.

<meta property="og:type" content="article" />
<meta property="article:published_time" content="2026-09-16T08:00:00+00:00" />
<meta property="article:modified_time" content="2026-09-16T10:15:00+00:00" />
<meta property="article:author" content="https://example.com/authors/selim-aydin" />
<meta property="article:section" content="Technical SEO" />
<meta property="article:tag" content="open graph" />
<meta property="article:expiration_time" content="2027-01-01T00:00:00+00:00" />

Quick rundown of what each one does. article:published_time and article:modified_time mark when the piece went live and when it last changed. article:author points to a profile URL, not a plain text name, which trips up a lot of people writing this by hand. article:section is a free-text category label, and article:tag can repeat multiple times for multiple tags.

article:expiration_time exists mostly for time-sensitive news content that shouldn't be surfaced after a certain date. None of these are load-bearing for how your link renders. They're metadata for whatever system chooses to read them, which today is mostly Facebook's own crawler and a handful of aggregation tools, not the wider set of platforms your readers actually click through.

og:type=product: what it does and doesn't do

This is where I see the most wasted effort, so let's be precise about it. Setting og:type to product on a product page enables product:price:amount, product:price:currency, product:availability and a couple of retailer-facing fields. In principle, this open graph product setup lets a Facebook-aware scraper attach a price to your link. In practice, it's a legacy Open Graph extension that many e-commerce platforms still emit by default, but it isn't what powers the product rich results you see in Google search or Google Shopping.

That job belongs to a completely different system: schema.org Product markup, delivered as JSON-LD. Google's own ecommerce structured-data documentation confirms that Google's product rich results and Merchant Center feeds read schema.org structured data, not Open Graph product:* tags. These two systems share a word ("product") and not much else. One is a social-share signal read by Meta's crawler, the other is a structured-data signal read by Google.

Confusing them means a store owner can spend an afternoon perfecting og:type=product and product:price:amount, feel like they've covered "product SEO," and never touch the schema.org markup that actually earns a price and star rating in a Google result. If you want to check what Google is indexing for a given page rather than what a social scraper sees, a tool like indexcheck.tools is the right layer to look at that, not this one.

Worth saying plainly, since a few competing guides get this wrong: og:type is not a Google ranking factor of any kind. It's a social-metadata tag, full stop. Setting it correctly doesn't move you in search results; it just makes sure the right optional properties get read by the platforms that do check for them.

Does og:type change how a link looks?

Sometimes, and only on one platform. This is the honesty section most og:type guides skip, so let's map it out properly.

Meta's Sharing/Webmasters documentation states directly that og:type "impacts how your content shows up in Feed," which is the strongest first-party confirmation available that the tag changes anything visible at all. That's Facebook, specifically the Feed unit. If a scraper sees article, it can attach a byline or timestamp treatment in some Feed contexts that a plain website type wouldn't get.

Everywhere else, the story is different. Discord, Slack, LinkedIn, iMessage and X all build their link previews from og:title, og:description and og:image, falling back to the twitter: equivalents where relevant. None of these platforms document og:type as an input to their unfurl behavior. It's not that they're secretly reading it and ignoring edge cases; their published and observed unfurl logic simply never asks the question.

So if you set og:type to article expecting your Slack preview to change shape, it won't. The card looks identical to what a website type would produce, because Slack was never looking at that field in the first place.

This is exactly the kind of platform-by-platform gap that's easy to get wrong from a desk and hard to get wrong once you've actually watched seven different previews render side by side. If you want to see this directly rather than take my word for it, run your URL through the socialpreview.tools checker, which draws the card as X, Facebook, LinkedIn, Discord, Slack and iMessage would render it, plus a Google result for contrast. Set og:type to article, then to website, and compare. On six of those seven cards, nothing moves.

What happens if og:type is missing or wrong

Nothing dramatic, which is part of why this tag flies under the radar for so long. If og:type is absent, Meta's crawler defaults to website, per its own documentation. Your card still renders; you just lose access to the type-specific properties you might have set elsewhere on the page.

If og:type is set but doesn't match your extra tags (say, you left og:type as website but still have article:published_time floating in your head), those extra properties simply get ignored. No console error, no broken card, no visible symptom at all. That silence is exactly why this is worth checking deliberately instead of assuming a plugin got it right three years ago and never touching it again.

How to check your og:type is working

Two ways to close the loop here, depending on where you're starting from. If you already have a live page and want to confirm what's actually in the markup and how it resolves across platforms, paste the URL into the socialpreview.tools checker; it lists every og and twitter tag along with the fallback each field resolves to, so you can see at a glance whether og:type and its companion properties are present and correctly paired. If you're building tags from scratch, whether for a new blog template, a product page, or a landing page you want typed correctly from day one, the tag generator lets you set the type alongside title, description, image and the rest, with live previews so you can see the actual output before you ship it. And if this is your first pass at Open Graph tags generally rather than just the type field, the site's Open Graph guide covers the full tag set and what to do when a platform is still showing a cached, stale version of your card.

Frequently Asked Questions

What is og:type?

og:type is one of four required Open Graph properties, alongside og:title, og:image and og:url. It declares which content vertical a page belongs to (website, article, product, and so on) and that declaration determines which type-specific extra properties, like article:author or product:price:amount, a scraper will treat as valid. If the tag is missing, most platforms default to website, per Meta's developer documentation.

Which og:type should a blog post use?

Article. It enables article:published_time, article:modified_time, article:author, article:section, article:tag and article:expiration_time, all optional but useful for anything that wants to know when a piece was published or who wrote it. WordPress sites running Yoast SEO already set this by default on every Post, along with the published and modified timestamps, so many blogs have this configured correctly without any manual setup.

Does og:type change how a link looks?

Only on Facebook, and only in the Feed unit specifically. Meta's own documentation confirms og:type affects Feed rendering. Discord, Slack, LinkedIn, iMessage and X build their previews from og:title, og:description and og:image, and none of them document og:type as part of that process, so changing the type on those platforms produces no visible difference in the card.

What extra tags does og:type article allow?

Six optional properties under the article: namespace: article:published_time, article:modified_time, article:expiration_time, article:author, article:section and article:tag. All of them are ignored by scrapers if og:type isn't set to article, and none of them change your card's visual layout on their own; they're metadata for whatever system chooses to read them.