Which Schema Type Should I Use? Let the Page Answer
Choose the main type by asking what the page gives a visitor. The narrowest accurate answer beats the most ambitious label.
Use the schema type that best describes the main thing a visitor gets from the page. A product page is not the same as an article about a product. A business page is not the same as an event hosted by that business.
The narrowest accurate type is usually the right start. A more specific type is not better when the page cannot support it.
Use the page job as the first decision
| Page job | Likely main type | What must be visible |
|---|---|---|
| Publish an article | Article or a narrower article type | Headline, author, dates, body |
| Sell one product | Product | Product identity and matching offer facts |
| Describe a company | Organization or a narrower subtype | Name, URL, identity details |
| Describe a local business | LocalBusiness subtype | Real location and business facts |
| Describe an event | Event subtype | Name, date, location, status |
| Answer visible questions | FAQPage only when eligible and accurate | The same questions and answers |
| Publish a normal page | WebPage | Page name, URL, subject |
Article: the page itself is editorial content
Use Article when the main page is an editorial work with a headline, author, publication date, and body. NewsArticle and BlogPosting are narrower choices when the page and publisher support those meanings.
Do not use Article as a wrapper for every page simply because the page contains paragraphs. A product detail page with descriptive copy is still primarily a product page.
Product: the page presents a specific product
Use Product when the page describes a particular product and the markup matches the visible identity and offer information. Product data may include brand, model, SKU, images, offers, availability, ratings, or reviews when those facts are real and visible.
An article comparing coffee grinders should not become Product just because it mentions several models. The article can mention products without claiming the page itself is the canonical product detail page.
Organization: the page establishes a company or group
Use Organization for a company, nonprofit, association, or other group. Narrower subtypes can add meaning when they fit.
Organization often belongs in a site-wide graph as a stable entity. Reuse the same @id, name, URL, and identity links instead of creating a slightly different company on every page.
LocalBusiness: the business serves a real place
LocalBusiness is an Organization subtype for a physical local business. Schema.org offers narrower types for restaurants, stores, medical businesses, professional services, and other categories.
Use the narrow type only when it fits the actual business. Keep the name, address, telephone number, hours, and URL aligned with the visible page and current business information.
Event: the page is about something happening at a time and place
Use Event or a narrower event subtype when the page gives a real event name, start date, location or online attendance mode, and status. Add offers only when the page shows or links to the matching ticket information.
An article recapping an event is an Article. An event detail page for the upcoming event is an Event. The subject may be the same, but the page job changed.
FAQPage: visible questions are the main page content
FAQPage describes a page with questions and answers that visitors can read. Do not generate invisible FAQs only for markup.
Google currently limits FAQ rich-result availability to well-known authoritative government and health sites. That does not make the vocabulary invalid elsewhere, but it changes what most publishers should expect from Google.
WebPage: the honest answer for many URLs
WebPage is not a failure or a placeholder. It describes a page. AboutPage, ContactPage, CollectionPage, ProfilePage, and other subtypes can add meaning when the page fits.
A clean WebPage node connected to the WebSite, publisher, breadcrumb, and subject is better than an inaccurate Product or Event chosen only for a hoped-for display.
Supporting types can join the main type
A page can contain more than one valid node. An Article page may also define its WebPage, BreadcrumbList, author, publisher, and WebSite. A Product page may connect Product, Offer, Organization, WebPage, and BreadcrumbList.
One type should still describe the main reader-facing job. Supporting nodes explain the relationships around it.
When two types seem equally possible
- Read the first screen. What does the page promise the visitor?
- Look at the primary action. Is the visitor reading, buying, booking, attending, or learning about an entity?
- Check the visible facts. Which type can the page support without invented fields?
- Check current feature rules. If a Google feature matters, confirm that Google supports the type and that the page meets its specific rules.
- Choose the honest main type. Add the other entity as a related node when it still belongs in the graph.
Do not choose by rich-result envy
A type does not create content the page lacks. Review markup does not create reviews. Product markup does not turn an article into a store page. Event markup does not create an event.
Choose the page type first. Then read the complete schema markup examples and build the matching graph.
Common Questions
Can one page use more than one schema type?
Yes. A page can contain connected nodes for the main content, WebPage, WebSite, Organization, author, breadcrumbs, offers, and other accurate entities.
Should every page use a rich-result type?
No. Use the type that accurately describes the page. WebPage and its subtypes are valid when no narrower feature type fits.
Can an article about a product use Product as its main type?
Usually the article remains Article. It can mention or connect a Product node without claiming the editorial page is the canonical product detail page.