What Are the Four Types of Schema Markup? A Guide for Business Websites

If you searched for the four types of schema, you're probably staring at a technical SEO report that flagged "missing structured data" and wondering what that actually means in practice. Schema.org, the vocabulary most search engines use for structured data, defines several hundred types. But almost no business site needs more than a handful of them. For a typical company website, four cover nearly everything worth doing: Organization, LocalBusiness, Article, and FAQPage.

What schema markup actually is

Schema markup is a standardized way of labeling the content already on your page so search engines don't have to guess what it means. A phone number in your footer looks like a phone number to a human. To a crawler, it's just a string of digits until you mark it up as a telephone property. Schema doesn't change how your page looks to visitors; it's invisible code (usually written in JSON-LD, a script block) that sits alongside your visible content and describes it more precisely. Google's own documentation on structured data is the most reliable place to see exactly what it recognizes and rewards.

The vocabulary is huge, but you don't need most of it

Schema.org currently defines over 800 types and more than 1,500 properties, covering everything from recipes to medical conditions to airline reservations (see the official schema.org type list). That scale is useful context, but it's also why "add schema markup" as a line item on a technical audit can feel vague. The practical question isn't which types exist, it's which types apply to your site. For a services business, an ecommerce store, or a professional practice, the answer is almost always a subset of four.

Organization schema: telling search engines who you are

Organization schema states your company's name, logo, official website, and social profiles (via the sameAs property) in a format search engines can trust. It's foundational, not decorative: it's part of the signal set that contributes to a knowledge panel and to Google treating your brand as a distinct, verifiable entity rather than just a domain. If you've read about entity SEO and wondered where structured data fits into that picture, Organization schema is the most direct implementation of it. We cover the broader mechanism in our guide to entity SEO and how verification signals connect to it in our piece on knowledge panels.

LocalBusiness schema: for a physical or service-area presence

LocalBusiness is technically an extension of Organization, adding properties that matter for a company operating from a location or serving a defined area: address, geo-coordinates, opening hours, telephone, and price range. Examples in schema.org's own documentation include restaurants, bank branches, and medical practices (schema.org/LocalBusiness). If your business has a storefront, an office people visit, or a service radius, this is usually the single highest-value schema type to get right, since it feeds directly into how Search displays local listings (Google's LocalBusiness structured data guide shows the expected fields).

Article schema: for blog posts and editorial content

Article schema marks up headline, author, publish date, and a representative image on content pages, which matters if you publish articles, guides, or news-style updates regularly. It's not something every business site needs. A five-page brochure site with no blog gets little benefit from it; a site publishing a steady stream of articles benefits more, since it gives search engines a clearer read on authorship and freshness.

FAQPage schema: what it does now, and what changed

FAQPage schema marks up genuine question-and-answer content already visible on a page. For a long time, this was worth implementing partly because it could trigger an expandable FAQ dropdown directly in Google's search results. That changed: Google's changelog documented removing the FAQ rich result feature from Search generally in a 2026 update. FAQPage is still a valid schema.org type, and leaving existing markup on a page won't cause harm, but it's no longer a reason on its own to add new FAQ markup. If you have real FAQ content already on the page, structuring it is still reasonable practice; adding it purely to chase a visual result that no longer appears isn't worth the effort. You can check what a page currently qualifies for with Google's Rich Results Test.

Implementing schema without breaking anything

JSON-LD is the format worth using; it's a single script block that doesn't touch your visible HTML, which makes it lower-risk than the older microdata or RDFa approaches that require marking up inline elements. For static, well-defined data, a free generator is genuinely enough: business name, address, hours, logo, and a handful of FAQ pairs don't need custom development. This is exactly the gap our Schema Generator fills, producing valid JSON-LD you can paste directly into a page without touching code elsewhere.

Where it gets riskier is when schema needs to stay in sync with a database or CMS, when a site already has conflicting or duplicate markup from a previous developer or plugin, or when multiple locations, products, or content types need to be templated correctly rather than hand-written per page. Those situations are less about generating a snippet and more about auditing what's already there, since duplicate Organization blocks or mismatched data between the page and the schema can cause search engines to distrust the markup entirely. That level of review is part of what a technical SEO review covers, alongside the other crawlability and indexation issues outlined in our technical SEO checklist.

Which one to fix first

If a site has none of the four, Organization schema is the sensible starting point since it establishes the base identity everything else builds on. A business with a physical location or defined service area should add LocalBusiness next, since it has the most direct connection to how the business appears in local search. Article schema is worth adding once there's a real publishing rhythm, not before. FAQPage is worth doing last, and only where genuine FAQ content already exists on the page, rather than as a standalone project chasing a search feature that no longer displays.