The type-selection process (WebPage / Service / Organization / Audience / Country)

Where this chapter sits

This is the core chapter of the guide. It organizes the decision process for choosing "which schema.org type to use on your own site" as a reproducible mental flow.

The subject is the service page of the fictional B2B SaaS Acme Workflow, introduced in the Introduction. We walk through the process of assembling the following structure.

WebPage (root type)
├── isPartOf → WebSite (parent site reference)
└── mainEntity → Service (the subject of this page)
    ├── provider → Organization (provider: Acme Inc.)
    ├── audience → Audience (target: operations staff)
    └── areaServed → Country (service area: Japan)

We explain, in order, why each type was chosen and what was rejected.

Decision 1: Choosing WebPage for the root type

What we want to express

• The metadata that this is "a single page of a corporate site"
• The page title / description / URL
• The site this page belongs to (isPartOf)
• The subject of this page (mainEntity)

Candidates

Candidate type	Suitable use	Fit this time
WebPage	A general-purpose web page	✅ Adopted
Article	News / blog posts / explanatory articles	❌ A service page is not an article
Product	A page for a physical product	❌ A service is intangible
Organization (alone)	A page with organization info only	❌ The subject is service information

WebPage is a derived type of CreativeWork and is the most general-purpose root type, representing web pages in general. When a page "does not fit any of article / product / organization," like a service page, you choose WebPage.

Subclasses of WebPage

schema.org also has WebPage subclasses like AboutPage / ContactPage / FAQPage / ItemPage. If the nature of the page is clear (e.g., AboutPage for a "company overview"), choose a more specific subclass. For a service page, choosing ItemPage (product / service introduction) is also worth considering, but this guide adopts WebPage to prioritize generality.

Decision 2: Declaring exactly one page subject with mainEntity

As stated in Chapter 02, schema.org's official view is clear.

about can refer to multiple entities/topics, while mainEntity should be used for only the primary one

It clearly states this. The principle is to narrow the page's subject down to one.

What mainEntity means

The name and description that WebPage itself has are "information about the page itself," but mainEntity declares "what this page is talking about" in a separate layer. The search engine looks at this subject to understand the essence of the page.

Reference: schema.org/mainEntity / Schema.org Data Model — background notes (checked: 2026-06)

The problem with defining multiple mainEntity

Pages that carry multiple subjects often have an underlying site-design problem: "the subject is ambiguous." From the search engine's perspective too, a page whose subject is diffuse will not rank stably. If you have no choice but to handle multiple concepts, consider a different structure, such as expressing them as parallel elements with ItemList.

Decision 3: Choosing Service for the mainEntity type

The subject is "a SaaS called Acme Workflow." The next decision is which type to express it with.

Candidates

Candidate type	Nature	Fit this time
Service	An intangible service (provided continuously)	✅ Adopted
Product	A tangible / one-time-purchase item	❌ SaaS is not a buy-once item
SoftwareApplication	Downloadable software	△ Unsuitable for SaaS (see below)
WebApplication	A web-based application	△ A possible option (see below)

Service is under Intangible and represents "an intangible service provided continuously." A service used under a continuous contract, like SaaS, makes Service the most natural choice.

Why we did not choose SoftwareApplication / WebApplication

• SoftwareApplication is mainly intended for installable software (desktop apps / mobile apps) and has a download URL / OS requirements / app store info. It does not fit SaaS.
• WebApplication is a subtype of SoftwareApplication for web apps. If you wanted to strictly model "an app you use on the web after logging in," like Acme Workflow, this is also an option, but what a corporate site's service page expresses is not "the app itself" but "the service provided," so Service fits the context better.
• If it were a page centered on "the app's feature spec" (e.g., an App Store-style feature list), consider switching to WebApplication.

Properties that are close to required for Service

Property	Range	Role
name	Text	The service name
description	Text	A concise description
provider	Organization / Person	The provider (Decision 4)
serviceType	Text	The service's category
audience	Audience	The target (Decision 6)
areaServed	AdministrativeArea, etc.	The service area (Decision 7)

Everything except name / description is optional, but to hand rich information to the search engine, filling in provider / audience / areaServed is recommended.

Decision 4: Putting Organization in provider

You declare the service's provider with provider.

Person or Organization

• Sole proprietor / freelancer → Person
• Company / organization → Organization

Acme Workflow is a SaaS provided by the fictional Acme Inc., so we choose Organization.

The rationale from Google's guidelines

Organization Schema Markup (checked: 2026-05) recommends marking up organization information, and it is the foundation for things like logo display in the knowledge panel and search results. Beyond just referencing it as Service.provider, defining Organization uniquely across the whole site lets you reference it from multiple pages via @id (the @id strategy described later).

Key properties to fill in for Organization

Property	Role
name	The company name
url	The corporate site's URL (canonical)
logo	The logo image URL
sameAs	An array of related URLs (Wikipedia / social media, etc.)
contactPoint	Contact information (the ContactPoint type)

Organization's sameAs

In sameAs, you list URLs as an array, such as a Wikipedia page / official social media accounts / an official Crunchbase page. It becomes easier for Google to recognize that "these all point to the same organization," which improves the accuracy of knowledge panel consolidation.

Subtypes of Organization

Organization has subtypes like Corporation / EducationalOrganization / GovernmentOrganization / LocalBusiness.

• For a corporation, you may choose Corporation (though plain Organization is also fine)
• For a business with a physical storefront, LocalBusiness family is strongly recommended (it can express opening hours / address / map info)
• For a SaaS provider whose main purpose is not a physical storefront, Organization is sufficient

When in doubt, choosing Organization is the safe bet. Google interprets the parent type Organization appropriately.

Decision 5: Referencing the parent WebSite with WebPage.isPartOf

isPartOf is a property that indicates "the higher-level resource this resource belongs to." From the WebPage's point of view, it references the WebSite (the whole site) it belongs to.

Why express the parent WebSite

• You can define the whole site's name / URL in one place
• You can share the WebSite definition across multiple pages and keep things consistent
• It becomes the source for the "site name" display in Google search results (see Site names. The WebSite used for the site name must be placed on the home page)

Note that the old Sitelinks search box (SearchAction) was discontinued in 2024-11, so the search action is not included among the purposes of defining WebSite.

A minimal WebSite definition example

{
  "@type": "WebSite",
  "@id": "https://example.com/#website",
  "url": "https://example.com/",
  "name": "Acme Inc.",
  "publisher": { "@id": "https://example.com/#organization" }
}

By making @id unique on a URL basis and referencing the Organization in publisher via @id, you can express the site structure cleanly.

Decision 6: Using Audience for mainEntity.audience

You declare the service's target users with audience.

The type hierarchy of Audience

Audience is under Intangible and is a general-purpose type representing target users in general. It has the following subtypes.

A decision tree for the Audience subclass

Nature of the target users	Recommended type
By company / industry (B2B SaaS / business tools / corporate services)	BusinessAudience
Based on personal attributes (age / gender / lifestyle)	PeopleAudience
Educational (students / teachers / learning-material targets)	EducationalAudience
Medical (healthcare professionals / patients)	MedicalAudience
None of the above / unknown	Audience (general)

For Acme Workflow

Acme Workflow is a B2B SaaS for operations staff, so BusinessAudience is appropriate.

{
  "@type": "BusinessAudience",
  "audienceType": "Operations staff",
  "name": "Operations staff at small and medium-sized businesses"
}

audienceType is a property that expresses the target as a string, and it is usable on Audience (and all subtypes).

Do not write audience as a string only

You sometimes see implementations that write "audience": "Operations staff" as a simple string, but this is invalid as a type. The range of schema.org's audience property is the Audience type, so always write it as an object in the form { "@type": "...", ... }. Otherwise you also lose the benefit of leveraging the type hierarchy (Google recognizing the target as structured information).

Decision 7: Using Country for mainEntity.areaServed

You declare the area where the service is provided with areaServed.

Range candidates

The range of areaServed is AdministrativeArea / GeoShape / Place / Text.

Candidate type	Suitable use
Country	An entire country (e.g., Japan)
State	A prefecture / state
City	A municipality
AdministrativeArea	A general-purpose type for administrative divisions
GeoShape	A polygon of latitude/longitude
Place	A specific place (a venue / store, etc.)
Text	An unstructured string (not recommended)

For Acme Workflow

Acme Workflow provides its service throughout Japan, so we use Country.

{
  "@type": "Country",
  "name": "Japan"
}

Country is a subtype of AdministrativeArea and is the type that represents a country. If you provide the service in multiple countries, make areaServed an array.

Including the ISO 3166 code

Including the ISO 3166-1 alpha-2 code (JP, etc.) in the identifier property makes it easier for the search engine to uniquely identify the country.

The @id strategy — designing references between objects

In a JSON-LD that contains multiple objects, how you assign @id greatly affects maintainability.

Conventions

• Make the @id URL unique by appending a fragment (#xxx) to a URL base that represents the object
• Use a concept name (#organization, #website, #webpage, #service) for the fragment name
• Use the same @id across the whole site for the same concept

Examples

@id	The object it represents
https://example.com/#organization	The site-wide Organization (Acme Inc.)
https://example.com/#website	The site-wide WebSite
https://example.com/services/workflow/#webpage	The WebPage of this service page
https://example.com/services/workflow/#service	The Service called Acme Workflow

Why these conventions

• URL-based: it becomes globally unique as an identifier (@id is a URI, so using a URL is conventional)
• Fragment: everything after # is not sent to the server, so it has no side effect as a URL
• Concept name: just reading the @id tells you what object it is
• Unified across the whole site: even if multiple pages reference the Organization, the search engine recognizes them as "the same Organization" as long as the @id matches

Typical @id collision patterns

• Using a different Organization @id per page (https://example.com/page-a/#organization and https://example.com/page-b/#organization) → they are recognized as separate organizations
• A dynamically generated @id (containing a timestamp or UUID) → it is treated as a different object when the page is updated
• Writing @id as a simple string instead of a URL ("@id": "organization") → weak as an identifier, with a chance of clashing across multiple sites

A decision tree for applying this to your own site

So far we have shown the decision process using Acme Workflow as the subject. Below is a generalized set of branches for applying this to your own site.

Step 1: Decide the root type

Choose a WebPage subclass based on the nature of the page.

Nature of the page	Recommended root type
Service / product page / general	WebPage (or ItemPage)
Company overview	AboutPage
Contact	ContactPage
FAQ	FAQPage
Checkout	CheckoutPage
Search results	SearchResultsPage

Step 2: Decide the mainEntity type

Decide what the page's subject is, and choose the type that represents it.

Page subject	mainEntity type
An intangible service (SaaS / consulting / professional services)	Service
A tangible product / one-time purchase	Product
An article / blog post	Article (or BlogPosting / NewsArticle)
An organization-introduction page	Organization
An event announcement	Event
A whole FAQ page	When it is FAQPage, the subject is the QA list
A job posting	JobPosting
A recipe	Recipe
A video	VideoObject
A landing page (composite subject)	Narrow it down to the single most primary entity

Step 3: Decide provider / publisher / author

Express the relevant parties according to the subject.

Subject type	Related property	Range
Service	provider	Organization / Person
Product	manufacturer / brand	Organization / Brand
Article	author / publisher	Person / Organization
Event	organizer / performer	Organization / Person
Recipe	author	Person / Organization

Step 4: Decide the target / area (as needed)

Declaring target / area	Property	Range
Target users	audience	Audience family (the decision tree in Decision 6)
Service area	areaServed	Country / State / City / Place
Language	inLanguage	Language / Text (IETF BCP 47, e.g., ja)

Step 5: Tie the relationships together with @id

Define the site-wide Organization / WebSite in one place, and reference them from each page via @id.

A summary of the rejected alternatives

To leave a trace of the decisions, here we organize the "options we did not adopt."

Situation	Adopted type	Rejected type	Reason for rejection
Root type	WebPage	Article	A service page is not an article
Root type	WebPage	Product	A service is intangible
Root type	WebPage	ItemPage	The more general WebPage is sufficient (easier to reuse on other pages when the site structure changes in the future)
Subject	Service	Product	A continuous-contract service is not a Product
Subject	Service	SoftwareApplication	It is not installable software
Subject	Service	WebApplication	A service page is not an app feature spec
Provider	Organization	Person	A company, not an individual
Target	BusinessAudience	Audience (general)	We want to express the industry context with a subtype
Target	BusinessAudience	A string only	A range violation
Area	Country	Place	It is an entire country, so Place is excessive
Area	Country	Text	Structured information is lost

What's next

So far we have completed the type-selection process. In the next chapter, 04. Implementation + validation + operations, we combine the types decided here to present the finished JSON-LD for Acme Workflow, and cover the validation steps with the Google Rich Results Test and the conventions for ongoing operations.