Structured Data Reference

Schema Markup by Page Type: Examples for Local and B2B Websites

Most schema markup guides are easy to read and hard to use.

They tell you that Organization, LocalBusiness, Service, Product, Article, Person, and FAQPage exist.

Then they stop.

The natural next question is:

What should this actually look like on my website?

That question gets harder when you move beyond a simple homepage.

What this guide answers

Should a plumbing service-area page contain LocalBusiness?

What should an industry page use when Schema.org has no generic IndustryPage type?

How should an engineering company's certification connect to its services?

Should a case study use Article, Project, or something else?

What belongs on a commercial real estate listing?

Should a staffing service page contain JobPosting?

What is different between a physical location page and a page targeting a city the company serves?

And if your plugin already generates Organization, WebPage, and BreadcrumbList, what should you actually add yourself?

This guide answers those questions page by page.

More importantly, it shows what the structured data can look like.

The examples cover local service businesses and B2B companies including contractors, dental practices, electricians, manufacturers, engineering firms, accounting companies, staffing agencies, IT providers, professional services firms, medical practices, and commercial real estate companies.

The goal is not to put more schema on every page.

The goal is to describe the real business, page, and relationships accurately.

Scan Web Page Understand Main Entity Implement Relationships

provider
areaServed
audience
about

Browse Schema Examples

On this page

Start Here: Schema Markup Has Three Layers

A useful structured-data implementation usually contains three different things.

1. The Web Page

First, describe the document.

Examples include:

WebPage
AboutPage
ContactPage
CollectionPage
ProfilePage
Article
RealEstateListing

These tell machines what kind of document they are looking at.

2. The Main Entity

Then identify what the page is primarily about.

Examples include:

Organization
LocalBusiness
Service
Product
Person
JobPosting
Event
Dataset
Certification

A service page is not merely a WebPage.

It is a WebPage describing a Service.

A dentist location page is not merely a WebPage.

It is a WebPage describing a real Dentist business location.

3. The Relationships

This is where structured data becomes much more useful.

Properties such as:

mainEntity
about
provider
areaServed
audience
parentOrganization
hasCertification
offers
author
publisher

connect the entities.

For example:

Entity relationship

SERVICE PAGE

mainEntity

SERVICE

provider areaServed

ORGANIZATIONCITY

View text notation

SERVICE PAGE
    │
    └── mainEntity
            │
            ▼
         SERVICE
          │    │
 provider │    │ areaServed
          ▼    ▼
     ORGANIZATION ───────► CITY

The relationship tells us:

This organization provides this service in this market.

That is much more precise than putting an unrelated LocalBusiness object on every URL.

Schema.org and Google Rich Results Are Not the Same Thing

This distinction prevents many structured-data mistakes.

Schema.org provides a vocabulary for describing entities.

Google supports only some Schema.org types and properties for specific Search features.

For example:

Service is valid Schema.org vocabulary.

That does not mean Google currently has a generic Service rich result.

Certification is valid.

There is no generic Google certification rich result.

DefinedTermSet is valid.

There is no standard Google glossary rich result.

RealEstateListing is valid.

There is not currently a general Google real-estate rich result based on that type.

Structured data can therefore serve two different purposes.

Search feature eligibility

Some markup may make qualifying pages eligible for specific Google Search presentations.

Examples include:

Product
LocalBusiness
JobPosting
Event
Article
Dataset
ProfilePage
BreadcrumbList

Entity description

Other markup helps describe the page, business, product, service, person, market, or relationship even when Google does not provide a dedicated rich result.

Examples include:

Service
BusinessAudience
Certification
DefinedTerm
DefinedTermSet
OfferCatalog
RealEstateListing

Do not judge schema solely by whether Google's Rich Results Test displays a special feature.

Before Using the Examples

Every business name, address, phone number, certification, price, URL, and credential below is fictional.

The examples show architecture and relationships.

Do not copy claims that are not visible and true on your website.

For implementation, replace:

Reference value

https://www.example.com/

with your real URLs.

Stable @id values are also used throughout the examples.

For example:

Reference value

https://www.example.com/#organization

An @id helps different structured-data objects reference the same entity without recreating it differently on every page.

Schema Markup by Page Type: Quick Reference

Page type	Usually useful schema	Primary entity	Dedicated Google feature?
Homepage	`WebPage`, `WebSite`, `Organization` or a valid `LocalBusiness` subtype	Company	Organization / LocalBusiness
About	`AboutPage`	Organization	No dedicated About feature
Contact	`ContactPage`, `ContactPoint`	Organization	Organization information may apply
Services hub	`CollectionPage`, sometimes `ItemList` or `OfferCatalog`	Collection of services	No generic services carousel
Individual service	`WebPage` + `Service`	Service	No generic Service rich result
Capability	`WebPage`, sometimes `Service`	Capability or service	Usually no
Industry page	`WebPage` + Service + `BusinessAudience` where useful	Service applied to audience	No generic Industry feature
Use case	`WebPage` + applicable Service	Service/application	Usually no
Physical location	`WebPage` + specific `LocalBusiness` subtype	Real location	LocalBusiness
Service-area page	`WebPage` + `Service` + Place	Service in market	No generic feature
Service + city	`WebPage` + `Service` + Place	Specific service in market	No generic feature
Product detail	`Product`	Product	Product
Product category	`CollectionPage`, sometimes `ItemList`	Product collection	Usually no
Case study	`Article` or `WebPage`	Case study content	Article may apply
Project	`WebPage` or `Article`	Completed work	Usually no
Expert profile	`ProfilePage` + `Person`	Person	ProfilePage
Certification	`Certification`	Credential/certification	No dedicated feature
Pricing	Service/Product + `Offer` when a real offer exists	Commercial offer	Depends on underlying entity
Cost guide	`Article`	Informational content	Article
Comparison	`Article` or `WebPage`	Comparison content	Usually no
Buyer's guide	`Article`	Educational content	Article
Glossary	`DefinedTermSet`, `DefinedTerm`	Definitions	No generic feature
Research	`Article`, sometimes `Dataset`	Research/data	Dataset when applicable
Calculator	`WebApplication` when genuinely software	Interactive application	Software app only if requirements fit
Job	`JobPosting`	Open position	Job Search
Event	`Event`	Event	Event Search
Real estate listing	`RealEstateListing`, Offer	Listing	No general real-estate feature
FAQ	`FAQPage` is still Schema.org vocabulary	Questions/answers	Google FAQ rich result deprecated

Schema Examples by Page Type

Build the Company Entity First

Most business websites should establish the company entity before worrying about individual page types.

A B2B company may use:

Reference value

Organization

A real local business may have a more specific subtype.

Examples include:

Dentist
AutoRepair
HVACBusiness
Electrician
GeneralContractor
HousePainter
Locksmith
Plumber
RoofingContractor
LegalService
AccountingService
EmploymentAgency

The most specific valid type is useful when it accurately describes the business.

Do not invent types that do not exist.

There is no need to create:

Reference value

BathroomRemodeler
PoolCleaningExpert
B2BConsultingFirm
IndustrialStaffingCompany

as custom @type values.

Use valid types and add specificity through the entity's properties and related Service entities.

Homepage Example: B2B Organization

Imagine a fictional engineering consulting company.

The relationship is simple:

Entity relationship

HOMEPAGE

WebSite

mainEntity

ORGANIZATION

View text notation

HOMEPAGE
   │
   ├── WebSite
   │
   └── mainEntity
          │
          ▼
     ORGANIZATION

Example:

JSON-LD example

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://www.northstarengineering.com/#organization",
      "name": "Northstar Engineering Group",
      "url": "https://www.northstarengineering.com/",
      "logo": {
        "@type": "ImageObject",
        "url": "https://www.northstarengineering.com/images/logo.png"
      },
      "telephone": "+1-555-555-0100",
      "sameAs": [
        "https://www.linkedin.com/company/northstar-engineering"
      ]
    },
    {
      "@type": "WebSite",
      "@id": "https://www.northstarengineering.com/#website",
      "url": "https://www.northstarengineering.com/",
      "name": "Northstar Engineering Group",
      "publisher": {
        "@id": "https://www.northstarengineering.com/#organization"
      }
    },
    {
      "@type": "WebPage",
      "@id": "https://www.northstarengineering.com/#webpage",
      "url": "https://www.northstarengineering.com/",
      "name": "Northstar Engineering Group",
      "isPartOf": {
        "@id": "https://www.northstarengineering.com/#website"
      },
      "mainEntity": {
        "@id": "https://www.northstarengineering.com/#organization"
      }
    }
  ]
}

Notice that the engineering company is created once.

Future service, case study, and professional profile pages can reference:

Reference value

https://www.northstarengineering.com/#organization

instead of rebuilding the company from scratch.

Homepage Example: Local Business

Now consider a real HVAC contractor with a staffed physical location.

The main entity can be more specific:

Entity relationship

HOMEPAGE

HVACBusiness

physical address

phone

opening hours

website

View text notation

HOMEPAGE
    │
    ▼
HVACBusiness
    │
    ├── physical address
    ├── phone
    ├── opening hours
    └── website

Example:

JSON-LD example

{
  "@context": "https://schema.org",
  "@type": "HVACBusiness",
  "@id": "https://www.clearairheating.com/#business",
  "name": "Clear Air Heating & Cooling",
  "url": "https://www.clearairheating.com/",
  "telephone": "+1-555-555-0110",
  "image": "https://www.clearairheating.com/images/building.jpg",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "1250 Market Street",
    "addressLocality": "Boise",
    "addressRegion": "ID",
    "postalCode": "83702",
    "addressCountry": "US"
  },
  "openingHoursSpecification": {
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": [
      "Monday",
      "Tuesday",
      "Wednesday",
      "Thursday",
      "Friday"
    ],
    "opens": "08:00",
    "closes": "17:00"
  }
}

A physical address matters here because the object represents an actual business location.

That becomes important when we reach service-area pages later.

About Page Schema

An About page does not need another copy of the business entity.

Use the page to point back to the established organization.

Visual model:

Entity relationship

ABOUT PAGE

mainEntity

ORGANIZATION

View text notation

ABOUT PAGE
    │
    └── mainEntity
            │
            ▼
      ORGANIZATION

Example:

JSON-LD example

{
  "@context": "https://schema.org",
  "@type": "AboutPage",
  "@id": "https://www.northstarengineering.com/about/#webpage",
  "url": "https://www.northstarengineering.com/about/",
  "name": "About Northstar Engineering Group",
  "mainEntity": {
    "@id": "https://www.northstarengineering.com/#organization"
  }
}

If the page contains meaningful leadership information, Person entities can also be referenced.

The company should not become a new Organization simply because the visitor moved from / to /about/.

Contact Page Schema

A Contact page can use ContactPage.

Contact channels may also be represented with ContactPoint.

Visual model:

Entity relationship

CONTACT PAGE

ORGANIZATION

CONTACT POINT

View text notation

CONTACT PAGE
      │
      ▼
 ORGANIZATION
      │
      ▼
 CONTACT POINT

Example:

JSON-LD example

{
  "@context": "https://schema.org",
  "@type": "ContactPage",
  "@id": "https://www.northstarengineering.com/contact/#webpage",
  "url": "https://www.northstarengineering.com/contact/",
  "name": "Contact Northstar Engineering Group",
  "mainEntity": {
    "@type": "Organization",
    "@id": "https://www.northstarengineering.com/#organization",
    "contactPoint": {
      "@type": "ContactPoint",
      "telephone": "+1-555-555-0100",
      "contactType": "sales",
      "availableLanguage": [
        "English",
        "Spanish"
      ]
    }
  }
}

Do not generate a second company object with different contact details on this page.

The Contact page should reference the same company.

Services Hub Schema

A services hub represents a collection.

It usually should not be marked as one enormous Service.

For example, an accounting company may offer:

Fractional CFO Services

Outsourced Accounting

Financial Reporting

Audit Readiness

The page architecture looks like this:

Entity relationship

SERVICES HUB

COLLECTION PAGE

ITEM LIST

SVC SVC SVC

View text notation

SERVICES HUB
     │
     ▼
COLLECTION PAGE
     │
     ▼
  ITEM LIST
  │   │   │
  ▼   ▼   ▼
SVC  SVC  SVC

A simplified example:

JSON-LD example

{
  "@context": "https://schema.org",
  "@type": "CollectionPage",
  "@id": "https://www.harboradvisory.com/services/#webpage",
  "name": "Advisory and Accounting Services",
  "url": "https://www.harboradvisory.com/services/",
  "mainEntity": {
    "@type": "ItemList",
    "itemListElement": [
      {
        "@type": "ListItem",
        "position": 1,
        "item": {
          "@type": "Service",
          "@id": "https://www.harboradvisory.com/services/fractional-cfo/#service",
          "name": "Fractional CFO Services",
          "url": "https://www.harboradvisory.com/services/fractional-cfo/"
        }
      },
      {
        "@type": "ListItem",
        "position": 2,
        "item": {
          "@type": "Service",
          "@id": "https://www.harboradvisory.com/services/outsourced-accounting/#service",
          "name": "Outsourced Accounting",
          "url": "https://www.harboradvisory.com/services/outsourced-accounting/"
        }
      }
    ]
  }
}

ItemList describes the visible collection.

It does not automatically mean Google will create a carousel result.

Individual Service Page Schema

A service page is where Service becomes particularly useful.

Consider a commercial cleaning company.

The page:

Reference value

/services/medical-facility-cleaning/

might represent:

Entity relationship

WEB PAGE

SERVICE

providerCLEANING COMPANY

areaServedREGION

audienceMEDICAL FACILITIES

View text notation

WEB PAGE
   │
   ▼
SERVICE
   │
   ├── provider ───────► CLEANING COMPANY
   │
   ├── areaServed ─────► REGION
   │
   └── audience ───────► MEDICAL FACILITIES

Example:

JSON-LD example

{
  "@context": "https://schema.org",
  "@type": "WebPage",
  "@id": "https://www.peakfacilitycare.com/services/medical-facility-cleaning/#webpage",
  "url": "https://www.peakfacilitycare.com/services/medical-facility-cleaning/",
  "name": "Medical Facility Cleaning Services",
  "mainEntity": {
    "@type": "Service",
    "@id": "https://www.peakfacilitycare.com/services/medical-facility-cleaning/#service",
    "name": "Medical Facility Cleaning",
    "serviceType": "Medical Facility Cleaning",
    "provider": {
      "@id": "https://www.peakfacilitycare.com/#organization"
    },
    "areaServed": {
      "@type": "AdministrativeArea",
      "name": "Southern Idaho"
    },
    "audience": {
      "@type": "BusinessAudience",
      "audienceType": "Medical facilities"
    }
  }
}

This describes the actual relationship.

The company provides the service.

The service is available within a market.

The service is intended for a specific business audience.

There is currently no generic Google Service rich result.

That does not make the Service entity invalid.

It means the markup should be implemented because it accurately describes the commercial entity, not because someone promised a special search-result box.

Service Page With a Real Offer

Offer can be added when the page contains a genuine commercial offer.

Imagine a commercial cleaning company publishing a fixed monthly plan:

Small Office Maintenance Plan: $650 per month

That is different from an article saying:

Commercial cleaning commonly costs between X and Y.

The first can represent an actual offer.

Example:

JSON-LD example

{
  "@context": "https://schema.org",
  "@type": "Service",
  "@id": "https://www.peakfacilitycare.com/services/office-cleaning/#service",
  "name": "Office Cleaning",
  "provider": {
    "@id": "https://www.peakfacilitycare.com/#organization"
  },
  "offers": {
    "@type": "Offer",
    "name": "Small Office Maintenance Plan",
    "price": "650",
    "priceCurrency": "USD",
    "url": "https://www.peakfacilitycare.com/services/office-cleaning/"
  }
}

Do not add Offer simply because a page discusses cost.

Capability Page Schema

A capability is not automatically a Service.

Consider an engineering company with a page about:

Finite Element Analysis

The question is:

Can customers actually hire the company to perform this work?

If yes, modeling it as a Service may be appropriate.

Entity relationship

CAPABILITY PAGE

SERVICE

provider

ENGINEERING FIRM

View text notation

CAPABILITY PAGE
      │
      ▼
    SERVICE
      │
      └── provider
              │
              ▼
      ENGINEERING FIRM

Example:

JSON-LD example

{
  "@context": "https://schema.org",
  "@type": "WebPage",
  "name": "Finite Element Analysis",
  "url": "https://www.northstarengineering.com/capabilities/finite-element-analysis/",
  "mainEntity": {
    "@type": "Service",
    "@id": "https://www.northstarengineering.com/capabilities/finite-element-analysis/#service",
    "name": "Finite Element Analysis",
    "serviceType": "Finite Element Analysis",
    "provider": {
      "@id": "https://www.northstarengineering.com/#organization"
    },
    "audience": {
      "@type": "BusinessAudience",
      "audienceType": "Manufacturers and industrial companies"
    }
  }
}

If the capability is merely an internal skill and is not independently provided, a general WebPage describing the subject may be more accurate.

Do not let your navigation label determine your schema type.

Industry Page Schema

There is no general Schema.org type called:

Reference value

Industry

or:

Reference value

IndustryPage

That is one of the most common places where people start inventing unnecessary schema.

Instead, describe what the page actually represents.

Consider a staffing company with:

Reference value

/manufacturing-staffing/

The page represents a staffing Service for a manufacturing audience.

Visual model:

Entity relationship

INDUSTRY PAGE

SERVICE

providerEMPLOYMENT AGENCY

audienceMANUFACTURERS

View text notation

INDUSTRY PAGE
      │
      ▼
    SERVICE
      │
      ├── provider ─────► EMPLOYMENT AGENCY
      │
      └── audience ─────► MANUFACTURERS

Example:

JSON-LD example

{
  "@context": "https://schema.org",
  "@type": "WebPage",
  "@id": "https://www.workforcepartners.com/manufacturing-staffing/#webpage",
  "url": "https://www.workforcepartners.com/manufacturing-staffing/",
  "name": "Manufacturing Staffing Services",
  "mainEntity": {
    "@type": "Service",
    "@id": "https://www.workforcepartners.com/manufacturing-staffing/#service",
    "name": "Manufacturing Staffing",
    "provider": {
      "@id": "https://www.workforcepartners.com/#organization"
    },
    "audience": {
      "@type": "BusinessAudience",
      "audienceType": "Manufacturing companies"
    }
  }
}

The staffing provider has not become a manufacturing company.

The manufacturing market describes the intended customer.

That distinction matters.

Industry Classification vs Industry Page

Schema.org also supports business classification properties.

For example, an Organization can have a legitimate industry classification.

That is different from the audience of an industry page.

An accounting company serving construction businesses is still an accounting company.

A commercial insurance company serving trucking businesses is still an insurance business.

An IT provider serving law firms is still an IT provider.

Structured data should preserve those relationships instead of collapsing them together.

Use-Case Page Schema

There is no generic UseCase Schema.org type.

Consider an HR consulting company with:

Reference value

/succession-planning/

The page describes a Service applied to a business problem.

Example:

JSON-LD example

{
  "@context": "https://schema.org",
  "@type": "WebPage",
  "name": "Succession Planning Consulting",
  "url": "https://www.peoplebridgeconsulting.com/succession-planning/",
  "mainEntity": {
    "@type": "Service",
    "name": "Succession Planning Consulting",
    "provider": {
      "@id": "https://www.peoplebridgeconsulting.com/#organization"
    },
    "audience": {
      "@type": "BusinessAudience",
      "audienceType": "Privately held businesses"
    }
  }
}

Again, the semantic meaning comes from the relationships.

You do not need a special schema type for every marketing page label.

Problem Page Schema

Consider an auto repair company with a page about:

Car Overheating

That page is not necessarily a Service.

The visitor is researching a problem.

The page may work as an Article or WebPage that connects the problem with appropriate services.

Example:

JSON-LD example

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Why Is My Car Overheating?",
  "url": "https://www.rivercityauto.com/resources/car-overheating/",
  "author": {
    "@type": "Organization",
    "@id": "https://www.rivercityauto.com/#business"
  },
  "publisher": {
    "@id": "https://www.rivercityauto.com/#business"
  },
  "about": [
    {
      "@type": "Thing",
      "name": "Vehicle overheating"
    },
    {
      "@type": "Service",
      "@id": "https://www.rivercityauto.com/services/cooling-system-repair/#service",
      "name": "Cooling System Repair"
    }
  ]
}

Do not create imaginary schema types such as:

Reference value

CarProblem
CustomerPainPoint
BusinessProblem

Schema.org vocabulary is controlled.

Physical Location Page Schema

A physical location page is where a real LocalBusiness entity becomes especially important.

Imagine a dental company operating three clinics.

The Boise location has a real:

street address

phone number

staff

business hours

customer-facing facility

Visual model:

Entity relationship

PARENT COMPANY

parentOrganization

BOISE DENTAL CLINIC

address

telephone

hours

geo

View text notation

PARENT COMPANY
      │
      │ parentOrganization
      ▼
 BOISE DENTAL CLINIC
      │
      ├── address
      ├── telephone
      ├── hours
      └── geo

Example:

JSON-LD example

{
  "@context": "https://schema.org",
  "@type": "Dentist",
  "@id": "https://www.smilegroup.com/locations/boise/#location",
  "name": "Smile Group Boise",
  "url": "https://www.smilegroup.com/locations/boise/",
  "telephone": "+1-555-555-0120",
  "parentOrganization": {
    "@id": "https://www.smilegroup.com/#organization"
  },
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "400 Main Street",
    "addressLocality": "Boise",
    "addressRegion": "ID",
    "postalCode": "83702",
    "addressCountry": "US"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 43.61500,
    "longitude": -116.20230
  }
}

Google's current LocalBusiness requirements treat the address as the physical location of the business.

That is one reason a physical location page and a service-area page should not use the same schema architecture.

Service-Area Page Schema

Suppose an electrician is physically located in Spokane but also works in nearby Coeur d'Alene.

The company has no office in Coeur d'Alene.

The website has:

Reference value

/service-areas/coeur-dalene/

What should the structured data say?

Not this:

Entity relationship

Coeur d'Alene Electrician

fake Coeur d'Alene address

View text notation

Coeur d'Alene Electrician
    │
    └── fake Coeur d'Alene address

Instead:

Entity relationship

COEUR D'ALENE PAGE

ELECTRICAL SERVICE

providerEXISTING ELECTRICIAN

areaServedCOEUR D'ALENE

View text notation

COEUR D'ALENE PAGE
       │
       ▼
  ELECTRICAL SERVICE
       │
       ├── provider ─────► EXISTING ELECTRICIAN
       │
       └── areaServed ───► COEUR D'ALENE

Example:

JSON-LD example

{
  "@context": "https://schema.org",
  "@type": "WebPage",
  "@id": "https://www.inlandelectric.com/service-areas/coeur-dalene/#webpage",
  "url": "https://www.inlandelectric.com/service-areas/coeur-dalene/",
  "name": "Electrician Serving Coeur d'Alene, Idaho",
  "mainEntity": {
    "@type": "Service",
    "@id": "https://www.inlandelectric.com/service-areas/coeur-dalene/#service",
    "name": "Electrical Services in Coeur d'Alene",
    "provider": {
      "@id": "https://www.inlandelectric.com/#business"
    },
    "areaServed": {
      "@type": "City",
      "name": "Coeur d'Alene"
    }
  }
}

This communicates the correct relationship:

The electrician serves Coeur d'Alene.

It does not claim:

The electrician has a business location in Coeur d'Alene.

Physical Location vs Service Area: Visual Comparison

Entity relationship

PHYSICAL LOCATION

Company

LocalBusiness

Address: 125 Main St

Phone

Hours

Geo

SERVICE AREA

Company

Service

areaServed

City

View text notation

PHYSICAL LOCATION

Company
   │
   ▼
LocalBusiness
   │
   ├── Address: 125 Main St
   ├── Phone
   ├── Hours
   └── Geo


SERVICE AREA

Company
   │
   ▼
Service
   │
   └── areaServed
          │
          ▼
        City

These are different business relationships.

Your schema should reflect that.

Service + Location Page Schema

Now assume that the electrician has a more specific page:

Reference value

/emergency-electrician-coeur-dalene/

The pattern remains similar.

JSON-LD example

{
  "@context": "https://schema.org",
  "@type": "WebPage",
  "name": "Emergency Electrician in Coeur d'Alene",
  "url": "https://www.inlandelectric.com/emergency-electrician-coeur-dalene/",
  "mainEntity": {
    "@type": "Service",
    "name": "Emergency Electrical Service",
    "serviceType": "Emergency Electrical Service",
    "provider": {
      "@id": "https://www.inlandelectric.com/#business"
    },
    "areaServed": {
      "@type": "City",
      "name": "Coeur d'Alene"
    }
  }
}

The city modifies the service coverage.

It does not create another branch.

This becomes especially important when a website contains:

10 services20 cities200 pages

You still have one company.

You do not have 200 LocalBusiness entities.

Product Page Schema

Manufacturers, industrial suppliers, equipment companies, flooring suppliers, medical-equipment companies, and other B2B businesses may have true Product pages.

Consider an industrial equipment manufacturer.

Entity relationship

PRODUCT PAGE

PRODUCT

manufacturer

brand

model

specifications

View text notation

PRODUCT PAGE
     │
     ▼
   PRODUCT
     │
     ├── manufacturer
     ├── brand
     ├── model
     └── specifications

Example:

JSON-LD example

{
  "@context": "https://schema.org",
  "@type": "Product",
  "@id": "https://www.apexindustrial.com/products/ax500-compressor/#product",
  "name": "AX500 Industrial Air Compressor",
  "url": "https://www.apexindustrial.com/products/ax500-compressor/",
  "description": "Industrial rotary screw air compressor for manufacturing facilities.",
  "sku": "AX500",
  "brand": {
    "@type": "Brand",
    "name": "Apex Industrial"
  },
  "manufacturer": {
    "@id": "https://www.apexindustrial.com/#organization"
  }
}

This is valid entity modeling.

However, Google's Product search enhancements have additional eligibility requirements.

A Product object does not automatically qualify for a product rich result just because the syntax is valid.

Product With a Real Offer

If the product can genuinely be purchased for a visible price:

JSON-LD example

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Commercial Floor Scrubber X200",
  "sku": "X200",
  "brand": {
    "@type": "Brand",
    "name": "FacilityPro"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://www.facilitypro.com/products/x200/",
    "price": "2499.00",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock"
  }
}

The Offer works because an actual offer exists.

Do not invent a price simply to satisfy product markup requirements.

Product Category Page Schema

Consider:

Reference value

/products/industrial-pumps/

The page lists 35 different pumps.

The entire page is not one Product.

A more natural model is:

Entity relationship

COLLECTION PAGE

ITEM LIST

P1 P2 P3

View text notation

COLLECTION PAGE
      │
      ▼
   ITEM LIST
   │  │  │
   ▼  ▼  ▼
  P1 P2 P3

Example:

JSON-LD example

{
  "@context": "https://schema.org",
  "@type": "CollectionPage",
  "name": "Industrial Pumps",
  "url": "https://www.example.com/products/industrial-pumps/",
  "mainEntity": {
    "@type": "ItemList",
    "itemListElement": [
      {
        "@type": "ListItem",
        "position": 1,
        "url": "https://www.example.com/products/pump-a/"
      },
      {
        "@type": "ListItem",
        "position": 2,
        "url": "https://www.example.com/products/pump-b/"
      }
    ]
  }
}

Google specifically recommends focusing Product rich-result markup on pages about a specific product or variants of that product rather than broad category pages.

Technology or Platform Page Schema

Imagine an IT services company with:

Reference value

/microsoft-365-migration/

The company provides the migration Service.

Microsoft 365 is the technology involved.

Do not accidentally describe the IT company as the creator of Microsoft 365.

Example:

JSON-LD example

{
  "@context": "https://schema.org",
  "@type": "WebPage",
  "name": "Microsoft 365 Migration Services",
  "mainEntity": {
    "@type": "Service",
    "name": "Microsoft 365 Migration",
    "provider": {
      "@id": "https://www.exampleitcompany.com/#organization"
    }
  },
  "about": {
    "@type": "SoftwareApplication",
    "name": "Microsoft 365"
  }
}

The relationships remain clear:

The provider owns the Service.

The page discusses another company's technology.

Compliance Page Schema

Compliance pages require extra care because structured data can accidentally make a false credential claim.

Suppose an IT consulting company helps clients prepare for a security framework.

That does not mean the IT company is certified under the framework.

A safe conceptual structure is:

Entity relationship

WEB PAGE

mainEntityCONSULTING SERVICE

aboutSTANDARD / FRAMEWORK

View text notation

WEB PAGE
   │
   ├── mainEntity ─────► CONSULTING SERVICE
   │
   └── about ──────────► STANDARD / FRAMEWORK

Only use:

Reference value

hasCertification

when a real certification exists.

Understanding a standard is not the same as being certified under it.

Certification Schema Example

Schema.org now has a useful Certification type.

This can represent a legitimate authoritative certification held by an Organization, Person, Service, Product, or Place.

Imagine a manufacturer with a current certification.

Visual model:

Entity relationship

MANUFACTURER

hasCertification

CERTIFICATION

issuedBy

CERTIFYING BODY

View text notation

MANUFACTURER
     │
     └── hasCertification
               │
               ▼
        CERTIFICATION
               │
               └── issuedBy
                       │
                       ▼
                 CERTIFYING BODY

Example:

JSON-LD example

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://www.precisionworks.com/#organization",
  "name": "Precision Works Manufacturing",
  "hasCertification": {
    "@type": "Certification",
    "name": "Example Quality Management Certification",
    "certificationIdentification": "CERT-12345",
    "issuedBy": {
      "@type": "Organization",
      "name": "Example Certification Body"
    },
    "validFrom": "2026-01-01",
    "expires": "2028-01-01"
  }
}

Only publish certification details that can be substantiated.

A logo in the footer is not automatically evidence that the company holds the credential you are describing.

Case Study Schema

There is no universal Schema.org CaseStudy type.

For most business case studies, Article or WebPage is a practical starting point.

The interesting part is what the article connects.

Imagine a restoration company publishes a commercial flood restoration case study.

Entity relationship

CASE STUDY ARTICLE

aboutRESTORATION SERVICE

aboutCOMMERCIAL PROPERTY

publisherRESTORATION COMPANY

View text notation

CASE STUDY ARTICLE
       │
       ├── about ─────► RESTORATION SERVICE
       │
       ├── about ─────► COMMERCIAL PROPERTY
       │
       └── publisher ─► RESTORATION COMPANY

Example:

JSON-LD example

{
  "@context": "https://schema.org",
  "@type": "Article",
  "@id": "https://www.restorepro.com/case-studies/commercial-water-damage/#article",
  "headline": "Commercial Water Damage Restoration After a Sprinkler Failure",
  "url": "https://www.restorepro.com/case-studies/commercial-water-damage/",
  "publisher": {
    "@id": "https://www.restorepro.com/#organization"
  },
  "about": [
    {
      "@type": "Service",
      "@id": "https://www.restorepro.com/services/commercial-water-restoration/#service",
      "name": "Commercial Water Damage Restoration"
    },
    {
      "@type": "Thing",
      "name": "Commercial property water damage"
    }
  ]
}

If the client is publicly identified and permission exists, the client can also be represented.

Do not expose confidential customer relationships in structured data that the visible page does not disclose.

Project and Portfolio Page Schema

Schema.org has a type called Project.

That does not mean every page your website calls a "project" should automatically use it.

A kitchen remodeling project page may simply be:

WebPage

or:

Article

describing:

the service

location

materials

completed work

provider

A project gallery is a website content format.

A Schema.org Project is an actual organized enterprise planned to achieve an aim.

Do not choose schema based only on the label in your navigation.

Example for a remodeling project:

JSON-LD example

{
  "@context": "https://schema.org",
  "@type": "WebPage",
  "name": "Downtown Kitchen Remodeling Project",
  "url": "https://www.example.com/projects/downtown-kitchen-remodel/",
  "about": [
    {
      "@type": "Service",
      "name": "Kitchen Remodeling"
    },
    {
      "@type": "Place",
      "name": "Boise, Idaho"
    }
  ],
  "provider": {
    "@id": "https://www.example.com/#business"
  }
}

The markup describes the content that matters without forcing the URL into an unnecessary Project type.

Professional Profile Schema

Individual expertise can be important for:

law firms

dental practices

plastic surgery practices

engineering firms

accounting companies

consulting firms

medical practices

staffing businesses

Google currently supports ProfilePage, and an employee page on a company website is an accepted use case.

Visual model:

Entity relationship

PROFILE PAGE

mainEntity

PERSON

worksForORGANIZATION

jobTitle

credentials

View text notation

PROFILE PAGE
      │
      └── mainEntity
              │
              ▼
            PERSON
              │
              ├── worksFor ───► ORGANIZATION
              ├── jobTitle
              └── credentials

Example:

JSON-LD example

{
  "@context": "https://schema.org",
  "@type": "ProfilePage",
  "@id": "https://www.northstarengineering.com/team/elena-morris/#profile",
  "url": "https://www.northstarengineering.com/team/elena-morris/",
  "name": "Elena Morris, PE",
  "mainEntity": {
    "@type": "Person",
    "@id": "https://www.northstarengineering.com/team/elena-morris/#person",
    "name": "Elena Morris",
    "jobTitle": "Structural Engineer",
    "worksFor": {
      "@id": "https://www.northstarengineering.com/#organization"
    },
    "knowsAbout": [
      "Structural engineering",
      "Industrial facility design",
      "Structural analysis"
    ]
  }
}

A team page containing 25 employees is not one ProfilePage.

A ProfilePage should primarily focus on one person or organization.

Medical and Dental Profiles

Medical structured data requires more careful classification.

For example, a plastic surgery practice may involve:

Entity relationship

MedicalClinic

medicalSpecialtyPlasticSurgery

employeePhysician

View text notation

MedicalClinic
      │
      ├── medicalSpecialty ──► PlasticSurgery
      │
      └── employee ──────────► Physician

PlasticSurgery in Schema.org is a MedicalSpecialty.

It is not simply another arbitrary page type.

A practitioner page may still use:

Entity relationship

ProfilePagePerson

View text notation

ProfilePage → Person

while the Person or medical provider carries the appropriate specialty information.

This lets the page describe:

the clinic

the physician

the specialty

without treating all three as the same entity.

Law Firm Schema

Older structured-data guides often recommend:

Reference value

Attorney

or:

Reference value

ProfessionalService

Current Schema.org vocabulary has deprecated the generic ProfessionalService, and Attorney has been deprecated in favor of LegalService.

A law firm's business entity can therefore use:

Reference value

LegalService

when appropriate.

An individual lawyer should generally remain a:

Reference value

Person

on a:

Reference value

ProfilePage

A legal service page can describe:

Reference value

Service

These are three different things:

Entity relationship

LEGAL SERVICE BUSINESS

providesIMMIGRATION SERVICE

employeeATTORNEY PERSON

View text notation

LEGAL SERVICE BUSINESS
       │
       ├── provides ─────► IMMIGRATION SERVICE
       │
       └── employee ─────► ATTORNEY PERSON

That architecture is cleaner than trying to make every URL an Attorney entity.

Pricing Page Schema

There is no generic PricingPage schema type.

Start by asking:

Is the page presenting an actual commercial offer?

Suppose a management consulting company sells a defined assessment for $5,000.

The page could contain:

JSON-LD example

{
  "@context": "https://schema.org",
  "@type": "Service",
  "name": "Operations Assessment",
  "provider": {
    "@id": "https://www.exampleconsulting.com/#organization"
  },
  "offers": {
    "@type": "Offer",
    "name": "Operations Assessment Engagement",
    "price": "5000",
    "priceCurrency": "USD",
    "url": "https://www.exampleconsulting.com/services/operations-assessment/"
  }
}

The visible page should support that claim.

Do not hide a completely different price in structured data.

Cost Guide Schema

Now compare the previous example with:

How Much Does Management Consulting Cost?

That is a research task.

The page might discuss:

hourly pricing

retainers

project fees

company size

scope

specialization

Those numbers are not necessarily prices being offered by the publisher.

A better structure may simply be:

JSON-LD example

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How Much Does Management Consulting Cost?",
  "author": {
    "@type": "Organization",
    "@id": "https://www.exampleconsulting.com/#organization"
  },
  "publisher": {
    "@id": "https://www.exampleconsulting.com/#organization"
  },
  "about": {
    "@type": "Service",
    "name": "Management Consulting"
  }
}

The distinction is:

Entity relationship

PRICING PAGE

What WE charge

OFFER

COST GUIDE

What buyers may expect

ARTICLE

View text notation

PRICING PAGE
    │
    └── What WE charge
             │
             ▼
           OFFER


COST GUIDE
    │
    └── What buyers may expect
             │
             ▼
           ARTICLE

Do not turn editorial price ranges into commercial Offers.

Comparison Page Schema

There is no universal ComparisonPage.

A comparison is usually content.

For example:

In-House Accounting vs Outsourced Accounting

Visual model:

Entity relationship

COMPARISON ARTICLE

aboutIN-HOUSE MODEL

aboutOUTSOURCED SERVICE

View text notation

COMPARISON ARTICLE
       │
       ├── about ───► IN-HOUSE MODEL
       └── about ───► OUTSOURCED SERVICE

Example:

JSON-LD example

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "In-House Accounting vs Outsourced Accounting",
  "about": [
    {
      "@type": "Thing",
      "name": "In-house accounting"
    },
    {
      "@type": "Service",
      "name": "Outsourced accounting"
    }
  ],
  "publisher": {
    "@id": "https://www.harboradvisory.com/#organization"
  }
}

The Article is the content entity.

The things being compared are its subjects.

Buyer's Guide Schema

Consider:

How to Choose a Commercial Cleaning Company

The page helps someone evaluate providers.

That is usually an Article.

Example:

JSON-LD example

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How to Choose a Commercial Cleaning Company",
  "about": {
    "@type": "Service",
    "name": "Commercial Cleaning"
  },
  "publisher": {
    "@id": "https://www.example.com/#organization"
  }
}

Do not mark the article as a Service simply because it discusses the service.

The page's job matters.

Process Page and HowTo Schema

A company process is not automatically a HowTo.

Consider:

Our Commercial Construction Process

The page explains what the contractor does after engagement.

Now compare:

How to Prepare Your Facility for a Commercial Renovation

That page gives instructions the reader can follow.

Those are different content tasks.

Google deprecated the HowTo rich-result feature years ago.

So even when HowTo remains semantically appropriate Schema.org vocabulary, do not build your structured-data strategy around obtaining a Google HowTo result.

The content should justify the markup.

FAQ Schema in 2026

This requires an important update from many older structured-data guides.

Google fully deprecated its FAQ rich-result feature in May 2026.

That means local and B2B businesses should not add FAQ markup because they expect expandable FAQ results in Google Search.

FAQPage still exists within Schema.org.

But the Google search-feature opportunity is gone.

So if your service page has useful questions such as:

How quickly can a technician arrive?

Does your company work with commercial facilities?

Do you provide emergency service?

Keep the questions because customers need them.

Do not justify the section with:

"We need FAQ schema so Google will show the questions."

That is no longer a valid reason.

QAPage Is Not a Replacement for FAQPage

Do not respond to the FAQ change by turning business FAQs into QAPage.

Google's QAPage implementation is designed around a page focused on one question and its answers.

A page containing:

Question 1

Question 2

Question 3

Question 4

is not automatically a QAPage.

Schema types should describe the content rather than work around feature changes.

Reviews and Testimonials

This is another area where valid Schema.org vocabulary and Google eligibility diverge.

A business may publish genuine testimonials on its website.

That does not mean adding:

Reference value

AggregateRating

to its own LocalBusiness will make star ratings appear.

Google's current review-snippet policies make self-serving LocalBusiness and Organization reviews ineligible for the star-review feature when the reviewed entity controls the reviews on its own website.

That includes situations where the business embeds third-party review widgets about itself.

For example:

Entity relationship

PLUMBING COMPANY WEBSITE

reviews about itself

NOT ELIGIBLE FOR

SELF-SERVING LOCALBUSINESS

REVIEW STARS

View text notation

PLUMBING COMPANY WEBSITE
      │
      └── reviews about itself
                 │
                 ▼
       NOT ELIGIBLE FOR
       SELF-SERVING LOCALBUSINESS
       REVIEW STARS

That does not mean testimonials are useless.

They still help customers evaluate the business.

It means you should not promise a search feature that Google's policies do not support.

Glossary Schema

Glossaries have more specific Schema.org vocabulary than many implementations use.

A glossary can be represented as:

DefinedTermSet

Individual entries can use:

DefinedTerm

Visual model:

Entity relationship

GLOSSARY

DEFINED TERM SET

TERM TERM TERM

View text notation

GLOSSARY
    │
    ▼
DEFINED TERM SET
   │    │    │
   ▼    ▼    ▼
TERM  TERM  TERM

Example:

JSON-LD example

{
  "@context": "https://schema.org",
  "@type": "DefinedTermSet",
  "@id": "https://www.example.com/resources/glossary/#glossary",
  "name": "Commercial Property Glossary",
  "url": "https://www.example.com/resources/glossary/",
  "hasDefinedTerm": [
    {
      "@type": "DefinedTerm",
      "name": "Triple Net Lease",
      "description": "A lease structure in which the tenant is responsible for specified property expenses in addition to rent.",
      "inDefinedTermSet": {
        "@id": "https://www.example.com/resources/glossary/#glossary"
      }
    },
    {
      "@type": "DefinedTerm",
      "name": "Capitalization Rate",
      "description": "A ratio used to compare a property's net operating income with its value.",
      "inDefinedTermSet": {
        "@id": "https://www.example.com/resources/glossary/#glossary"
      }
    }
  ]
}

This is a strong example of useful entity modeling even without a dedicated Google glossary result.

Statistics and Research Pages

Not every page containing numbers is a Dataset.

Consider:

25 Logistics Industry Statistics

If the article compiles numbers from external studies, the main entity may simply be an Article.

Now consider a logistics consultancy that publishes its own structured survey results and downloadable dataset.

That may deserve:

Reference value

DATASET

Example:

JSON-LD example

{
  "@context": "https://schema.org",
  "@type": "Dataset",
  "name": "2026 Warehouse Operations Benchmark Dataset",
  "description": "Anonymized warehouse operations benchmark data collected from participating distribution companies.",
  "creator": {
    "@id": "https://www.examplelogistics.com/#organization"
  },
  "datePublished": "2026-08-15",
  "license": "https://creativecommons.org/licenses/by/4.0/"
}

A supporting research article could separately use Article.

Conceptually:

Entity relationship

RESEARCH ARTICLE

based on

DATASET

View text notation

RESEARCH ARTICLE
       │
       └── based on
              │
              ▼
            DATASET

Do not label an article a Dataset just because it contains a table.

Report and White Paper Schema

A report can be modeled separately from the webpage hosting it.

For example:

Entity relationship

LANDING PAGE

hosts

DIGITAL DOCUMENT

View text notation

LANDING PAGE
     │
     └── hosts
           │
           ▼
    DIGITAL DOCUMENT

If the downloadable asset is a PDF report, it can be represented as a DigitalDocument or another appropriate CreativeWork type.

Example:

JSON-LD example

{
  "@context": "https://schema.org",
  "@type": "DigitalDocument",
  "name": "2026 Manufacturing Workforce Report",
  "url": "https://www.example.com/reports/manufacturing-workforce-2026.pdf",
  "author": {
    "@id": "https://www.example.com/#organization"
  },
  "about": {
    "@type": "Thing",
    "name": "Manufacturing workforce"
  }
}

The web page describing the report and the downloadable report itself do not need to be treated as the same entity.

Calculator and Interactive Tool Schema

A real browser-based tool may sometimes be represented as:

WebApplication

Examples could include:

commercial lease calculators
staffing cost calculators
construction material estimators
project cost planners
facility capacity tools
shipping calculators

Consider a commercial lease calculator.

JSON-LD example

{
  "@context": "https://schema.org",
  "@type": "WebApplication",
  "@id": "https://www.example.com/tools/commercial-lease-calculator/#application",
  "name": "Commercial Lease Cost Calculator",
  "url": "https://www.example.com/tools/commercial-lease-calculator/",
  "applicationCategory": "BusinessApplication",
  "browserRequirements": "Requires a modern web browser",
  "description": "Calculates estimated commercial lease costs from rent, square footage, and operating expenses."
}

A contact form is not automatically a WebApplication.

A calculator that does not calculate anything should not be marked as one simply because users enter information.

Job Posting Schema

Staffing and recruiting websites need to distinguish two very different page types.

Staffing service page

Reference value

/manufacturing-staffing/

This is a:

Reference value

Service

Actual job page

Reference value

/jobs/maintenance-technician-boise/

This may be a:

Reference value

JobPosting

Visual model:

Entity relationship

JOB PAGE

JOB POSTING

hiringOrganization

jobLocation

datePosted

title

salary

View text notation

JOB PAGE
   │
   ▼
JOB POSTING
   │
   ├── hiringOrganization
   ├── jobLocation
   ├── datePosted
   ├── title
   └── salary

Example:

JSON-LD example

{
  "@context": "https://schema.org",
  "@type": "JobPosting",
  "title": "Industrial Maintenance Technician",
  "description": "<p>Maintain and repair production equipment in a manufacturing facility.</p><p>Applicants should have at least three years of industrial maintenance experience.</p>",
  "datePosted": "2026-09-01",
  "validThrough": "2026-10-15T23:59",
  "employmentType": "FULL_TIME",
  "hiringOrganization": {
    "@type": "Organization",
    "name": "Example Manufacturing Company"
  },
  "jobLocation": {
    "@type": "Place",
    "address": {
      "@type": "PostalAddress",
      "streetAddress": "600 Industrial Way",
      "addressLocality": "Boise",
      "addressRegion": "ID",
      "postalCode": "83705",
      "addressCountry": "US"
    }
  },
  "baseSalary": {
    "@type": "MonetaryAmount",
    "currency": "USD",
    "value": {
      "@type": "QuantitativeValue",
      "minValue": 30,
      "maxValue": 38,
      "unitText": "HOUR"
    }
  }
}

Google's JobPosting search feature requires the structured data to live on the individual job page.

Do not put a collection of JobPosting objects on a general staffing service page just because the company works in recruiting.

Event Schema

Real event detail pages can use Event.

Examples include:

professional seminars
facility open houses
recruiting events
training sessions
industry workshops
public business events
Visual model:

Entity relationship

EVENT DETAIL PAGE

EVENT

LOCATION

ORGANIZER

View text notation

EVENT DETAIL PAGE
       │
       ▼
     EVENT
      │ │
      │ └────► LOCATION
      │
      └──────► ORGANIZER

Example:

JSON-LD example

{
  "@context": "https://schema.org",
  "@type": "Event",
  "name": "Manufacturing Safety Workshop",
  "startDate": "2026-11-12T09:00:00-07:00",
  "endDate": "2026-11-12T13:00:00-07:00",
  "eventStatus": "https://schema.org/EventScheduled",
  "eventAttendanceMode": "https://schema.org/OfflineEventAttendanceMode",
  "location": {
    "@type": "Place",
    "name": "Boise Convention Center",
    "address": {
      "@type": "PostalAddress",
      "addressLocality": "Boise",
      "addressRegion": "ID",
      "addressCountry": "US"
    }
  },
  "organizer": {
    "@type": "Organization",
    "name": "Example Manufacturing Association"
  }
}

An Events hub containing twelve events is not itself one Event.

Each actual event should have its own entity and, when appropriate, its own detail URL.

Commercial Real Estate Listing Schema

Commercial real estate deserves more attention than it receives in generic schema guides.

Schema.org now includes:

RealEstateListing
It also includes newer transactional types such as:
OfferForLease
OfferForPurchase
A commercial listing can therefore distinguish three concepts:

Entity relationship

REAL ESTATE LISTING PAGE

aboutPROPERTY

offersOFFER FOR LEASE

offeredBy

BROKER

View text notation

REAL ESTATE LISTING PAGE
        │
        ├── about ─────► PROPERTY
        │
        └── offers ────► OFFER FOR LEASE
                              │
                              └── offeredBy
                                      │
                                      ▼
                                    BROKER

Example:

JSON-LD example

{
  "@context": "https://schema.org",
  "@type": "RealEstateListing",
  "name": "25,000 SF Industrial Space for Lease",
  "url": "https://www.examplecommercial.com/listings/industrial-park-101/",
  "about": {
    "@type": "Place",
    "name": "Industrial Park Building 101",
    "address": {
      "@type": "PostalAddress",
      "streetAddress": "101 Industrial Parkway",
      "addressLocality": "Spokane",
      "addressRegion": "WA",
      "addressCountry": "US"
    }
  },
  "offers": {
    "@type": "OfferForLease",
    "priceCurrency": "USD",
    "offeredBy": {
      "@id": "https://www.examplecommercial.com/#organization"
    }
  }
}

This vocabulary does not currently correspond to a general Google commercial-property rich result.

The value is accurate modeling.

That still matters.

Schema Opportunities Across Local Business Industries

Different industries produce different entity graphs.

The business model should determine the markup.

Industry	Business entity	Important related entities
Auto repair	`AutoRepair`	Services, real shop location, technicians where useful
Bathroom remodeling	Often `GeneralContractor` or another accurate business type	Remodeling Services, service areas, completed projects
Construction	`GeneralContractor` where accurate	Services, projects, certifications, locations
Dental	`Dentist`	Locations, dentists, treatments/services
Dumpster rental	Appropriate LocalBusiness/Organization	Rental Services, service areas, Offers where real
Electrician	`Electrician`	Electrical Services, physical location, service markets
Home remodeling	`GeneralContractor` where accurate	Services, markets, projects
HVAC	`HVACBusiness`	HVAC Services, locations, service areas
Kitchen remodeling	Often contractor entity	Remodeling Services, projects, products/materials
Landscaping	Appropriate LocalBusiness	Landscaping Services, service areas, projects
Locksmith	`Locksmith`	Locksmith Services, location, service areas
Plumbing	`Plumber`	Plumbing Services, physical location, service markets
Pool service	Appropriate LocalBusiness	Pool Services, areas served
Roofing	`RoofingContractor`	Roofing Services, projects, markets
Veterinary	Appropriate veterinary/medical organization vocabulary	Clinic, practitioners, services
Wildlife removal	Appropriate Organization/LocalBusiness	Removal Services, service areas
Limo rental	Appropriate LocalBusiness/Organization	Transportation/rental Services, markets
Solar and generator installation	Contractor/business entity	Installation Services, Products, certifications
Restoration	Contractor/business entity	Restoration Services, service areas, case studies
Cleaning	Appropriate LocalBusiness/Organization	Cleaning Services, business audiences, areas served
Flooring	Appropriate business entity	Installation Services, Products/materials, projects
Immigration law	`LegalService`	Legal Services, attorney profiles, locations
Plastic surgery	Medical provider entity	Physicians, specialties, procedures, clinic

The same idea applies to B2B companies.

B2B industry	Core entities
Accounting and advisory	Organization, AccountingService where appropriate, Service, Person, BusinessAudience
Commercial real estate	Organization/RealEstateAgent where accurate, Service, RealEstateListing, Offer
Engineering consulting	Organization, Service, Person, Certification, technical subjects
HR consulting	Organization, Service, BusinessAudience, Person
IT services	Organization, Service, certifications, technologies, experts
Logistics and supply chain	Organization, Service, areas served, facilities, BusinessAudience
Management consulting	Organization, Service, Person, BusinessAudience, research
Staffing and recruiting	EmploymentAgency where appropriate, Service, JobPosting, BusinessAudience

No single plugin setting accurately captures all of those relationships.

The Most Important Schema Relationships

Choosing types gets most of the attention.

Relationships often carry more meaning.

`mainEntity`

Use this when the page has one clear primary entity.

Examples:

Entity relationship

ProfilePagemainEntityPerson

View text notation

ProfilePage → mainEntity → Person

Entity relationship

Service WebPagemainEntityService

View text notation

Service WebPage → mainEntity → Service

Entity relationship

Location WebPagemainEntityDentist

View text notation

Location WebPage → mainEntity → Dentist

`about`

Use this for important subjects discussed by a CreativeWork.

For example:

Entity relationship

Article

aboutCommercial Cleaning

aboutMedical Facilities

View text notation

Article
   │
   ├── about → Commercial Cleaning
   └── about → Medical Facilities

A page can be about several things.

Only one entity may be the main focus.

`provider`

This connects a Service to whoever provides it.

Entity relationship

ServiceproviderOrganization

View text notation

Service → provider → Organization

This is one of the most useful relationships for service companies.

`areaServed`

This describes where a Service or Organization is available.

Entity relationship

ServiceareaServedCity

View text notation

Service → areaServed → City

It is especially useful for service-area businesses because it expresses coverage without inventing a physical office.

`audience`

This identifies the intended audience.

Example:

Entity relationship

Outsourced Accounting

audience

Construction Companies

View text notation

Outsourced Accounting
       │
       └── audience
               │
               ▼
       Construction Companies

`parentOrganization`

This can connect a genuine branch or subordinate organization with its parent.

Entity relationship

Parent Organization

Physical Branch

View text notation

Parent Organization
       │
       ▼
Physical Branch

`hasCertification`

This connects a real Certification to an eligible Organization, Person, Service, Product, or Place.

`offers`

Use this when a real commercial offer exists.

Do not confuse:

Reference value

"Projects commonly cost $25,000 to $60,000"

with:

Reference value

"We sell Package A for $25,000"

The second is much closer to an Offer.

`author` and `publisher`

These connect informational content with the people and organizations responsible for it.

Use real authorship.

Do not assign executives as authors to articles they did not create or meaningfully review solely because their credentials look stronger.

One Entity Graph Is Better Than Hundreds of Disconnected Schema Blocks

One of the most common implementation problems is duplication.

Imagine the same company appears as:

Reference value

Homepage:
ABC Engineering LLC

Service page:
ABC Engineering

About:
ABC Engineering Company

Article:
ABC Engineering, LLC.

Contact:
ABC Engineering Group

with different:

phone numbers
URLs
social profiles
logos
addresses
schema types

Structured data is supposed to clarify entity identity.

That implementation creates ambiguity.

Instead:

Reference value

https://www.example.com/#organization

should consistently refer to the same organization.

Then different pages can reference it.

For example:

JSON-LD example

"provider": {
  "@id": "https://www.example.com/#organization"
}

or:

JSON-LD example

"publisher": {
  "@id": "https://www.example.com/#organization"
}

or:

JSON-LD example

"worksFor": {
  "@id": "https://www.example.com/#organization"
}

You do not need to rebuild the entire Organization every time.

Breadcrumbs are one of the most broadly applicable structured-data patterns.

For example:

Reference value

Home
   >
Services
   >
Medical Facility Cleaning

can be represented as:

JSON-LD example

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Home",
      "item": "https://www.example.com/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Services",
      "item": "https://www.example.com/services/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "Medical Facility Cleaning",
      "item": "https://www.example.com/services/medical-facility-cleaning/"
    }
  ]
}

A plugin often handles this correctly.

If it does, there is usually no reason to generate a second BreadcrumbList manually.

What a Plugin Can Usually Handle

A competent structured-data plugin can often cover foundational elements such as:

WebSite
WebPage
basic Organization information
Article markup
BreadcrumbList
basic author relationships
basic LocalBusiness information

That is useful.

The problem begins when templates are expected to understand the entire business.

A plugin cannot reliably infer whether:

a city is a branch or service area

a capability is a commercial Service

a price represents an Offer

a certification belongs to the company or one employee

a case study should reference a particular service

a product category should not be Product

a market page targets a BusinessAudience

a commercial property is for lease or sale

an engineer's credential applies to the organization

a job is currently open

a project is a real Schema.org Project

Those decisions require business context.

Schema Markup That Should Not Be Added Automatically

The fastest way to make structured data worse is to optimize for quantity.

Do not add LocalBusiness to every city page

If there is no physical business there, do not invent one.

Use Service + areaServed where that accurately represents the relationship.

Do not add Product to category pages

A collection of products is not itself necessarily one Product.

Do not add Offer because a number appears on the page

Market pricing guidance and commercial offers are different.

Do not add JobPosting to recruiting service pages

A staffing service is not a job opening.

Do not add Event to an Events archive

The individual event is the Event.

Do not add Review and AggregateRating to chase self-serving business stars

Google's review eligibility rules are narrower than Schema.org's vocabulary.

Do not add HowTo because a page contains numbered steps

A company process is not necessarily an instructional task.

Do not add FAQPage expecting a Google FAQ rich result

That feature was deprecated in 2026.

Do not invent types

Types such as these do not become valid because they sound logical:

Reference value

CaseStudy
IndustryPage
PricingPage
ServiceAreaBusiness
BuyerGuide
B2BService
CapabilityPage
BusinessProblem

Use valid entities and relationships.

More Schema Is Not Better Schema

Compare these two implementations.

Version A

Reference value

WebPage
Organization
LocalBusiness
Service
Product
Offer
Person
Review
FAQPage
HowTo
Article

all placed on one service page because each type exists.

Version B

Entity relationship

WebPage

mainEntity

Service

provider areaServed

Organization City

View text notation

WebPage
   │
   └── mainEntity
          │
          ▼
       Service
        │   │
provider│   │areaServed
        ▼   ▼
Organization City

Version B may contain fewer objects.

It communicates a much clearer meaning.

The purpose of structured data is not to maximize schema count.

It is to reduce ambiguity.

Structured Data Cannot Repair a Weak Page

Schema can describe information.

It cannot create it.

If a service-area page contains nothing specific about the market, adding:

Reference value

areaServed

does not make the page locally useful.

If an industry page contains generic copy, adding:

Reference value

BusinessAudience

does not make the company understand that industry.

If an expert profile contains no qualifications, Person does not create expertise.

If a case study contains no evidence, Article does not create evidence.

If your pricing page hides all pricing information, Offer does not make the business transparent.

If the company does not have an office in a city, LocalBusiness markup does not create one.

The visible page and the structured description should tell the same story.

How to Validate Schema Markup

Validation needs several layers because no single test answers every question.

Schema.org Validator

Use the Schema.org validator to answer:

Is the vocabulary and structure valid Schema.org markup?

A Service entity may pass this test even though Google has no generic Service rich result.

That is normal.

Google Rich Results Test

Use Google's Rich Results Test to answer:

Does this page contain structured data associated with a Google-supported search feature?

Examples can include:

Product
LocalBusiness
JobPosting
Event
Article
ProfilePage
Dataset
Breadcrumb

Do not expect every valid Schema.org object to appear there.

Google Search Console URL Inspection

After deployment, inspect real URLs.

Confirm that Google can crawl and render the page.

Then confirm that the structured data present in the rendered page matches what you intended to publish.

Manually Compare the Markup Against the Page

Check claims such as:

address
phone
price
business name
service
job title
salary
certification
opening hours
event date
product availability
location
author
review count

The markup should not contain information that contradicts or materially exceeds what the visitor can verify.

Validate Templates at Scale

Do not validate one URL and assume 300 template-generated pages are correct.

If you have:

50 service-area pages
100 product pages
80 staff profiles
300 jobs
500 property listings

sample different conditions.

Look for template errors such as:

stale prices
wrong city
duplicated IDs
wrong provider
placeholder addresses
incorrect canonical URL
old job expiration date
wrong product SKU
credentials inherited by the wrong person
one review count repeated on every page

Schema can be conceptually correct and still fail during implementation.

A Practical Schema Planning Framework

Before generating any JSON-LD, answer this table.

Question	Example
What is this page?	Service-area page
What is the primary entity?	Electrical Service
Who provides it?	Inland Electric
Does that entity already have an ID?	Yes, `/#business`
Is there a real physical branch here?	No
What geography matters?	Coeur d'Alene
How should geography be expressed?	`areaServed`
Is a real Offer visible?	No
Is a Google-supported rich result relevant?	No generic Service result
What schema may the plugin already output?	WebPage, Organization, Breadcrumb
What custom relationship is missing?	Service → provider → business; Service → areaServed → city
Can every claim be verified on the page?	Yes

That exercise is more valuable than starting with:

Which schema plugin should I install?

Page-Type-First Schema Workflow

A scalable structured-data system starts with the website architecture.

First identify the real entities:

Reference value

Company
Locations
Services
Products
People
Markets
Certifications
Jobs
Properties
Events
Datasets
Publications

Then identify which pages primarily represent them.

For example:

Entity relationship

Organization

/services/commercial-cleaning/

Service

/locations/boise/

LocalBusiness

/service-areas/meridian/

Service + areaServed

/team/jane-smith/

Person

/case-studies/warehouse-cleaning/

Article about Service

/jobs/facility-manager/

JobPosting

/listings/industrial-park/

RealEstateListing

View text notation

/
      → Organization

/services/commercial-cleaning/
      → Service

/locations/boise/
      → LocalBusiness

/service-areas/meridian/
      → Service + areaServed

/team/jane-smith/
      → Person

/case-studies/warehouse-cleaning/
      → Article about Service

/jobs/facility-manager/
      → JobPosting

/listings/industrial-park/
      → RealEstateListing

Then connect the entities.

Entity relationship

Organization

providesService

employeePerson

parent ofLocation

certificationCertification

Service

areaServedPlace

audienceBusinessAudience

Article

aboutService

authorPerson

publisherOrganization

View text notation

Organization
     │
     ├──── provides ────────► Service
     │
     ├──── employee ────────► Person
     │
     ├──── parent of ───────► Location
     │
     └──── certification ───► Certification


Service
     │
     ├──── areaServed ──────► Place
     └──── audience ────────► BusinessAudience


Article
     │
     ├──── about ───────────► Service
     ├──── author ──────────► Person
     └──── publisher ───────► Organization

That is a structured-data architecture.

It represents the business as a connected system instead of a collection of unrelated JSON snippets.

Frequently Asked Questions

What schema should a service page use?

A true commercial service page can commonly use a WebPage whose mainEntity is a Service.

The Service can then reference properties such as provider, areaServed, audience, offers, or certifications when those relationships are accurate.

Google does not currently offer a generic Service rich result.

Should LocalBusiness schema be placed on every page?

No.

The business entity may be referenced throughout the website, but you do not need to create a separate LocalBusiness entity for every URL.

Use location-specific LocalBusiness entities for real business locations.

What schema should a city service-area page use?

A useful pattern is:

Entity relationship

WebPage

Service

provider

areaServedCity

View text notation

WebPage
  → Service
      → provider
      → areaServed → City

Do not invent a LocalBusiness branch unless a physical business location actually exists there.

What schema should an industry page use?

There is no generic IndustryPage type.

For many service businesses, the page can describe a Service provided by an Organization for a BusinessAudience.

What schema should a case study use?

Often Article or WebPage.

Use about and other properties to connect the content with the Service, market, technology, product, problem, or organization discussed.

There is no general Schema.org CaseStudy type that should automatically be applied.

What schema should a physical location use?

A genuine location can use the most specific accurate LocalBusiness subtype.

Google currently requires the physical address and business name for LocalBusiness rich-result eligibility.

Should a law firm use Attorney schema?

Attorney has been deprecated in current Schema.org vocabulary in favor of LegalService.

Individual lawyers can be represented as Person entities on appropriate ProfilePages.

Should an accounting company use AccountingService or Service?

They describe different entities.

AccountingService is a LocalBusiness subtype that can describe an accounting business.

Service describes something the business provides.

An accounting company might therefore be an AccountingService while separately providing Services such as outsourced accounting or financial reporting.

Should testimonials have Review schema?

The answer depends on what is being reviewed and why the markup exists.

Google does not allow a business to obtain LocalBusiness or Organization review stars from self-serving reviews it controls about itself.

Testimonials can still be useful for customers even when no rich-result opportunity exists.

Does FAQ schema still create FAQ rich results?

No.

Google deprecated the FAQ rich-result feature in May 2026.

FAQPage still exists as Schema.org vocabulary, but ordinary businesses should not add it expecting expandable FAQ results in Google Search.

Does every Product object qualify for product rich results?

No.

Google has separate requirements for Product search experiences.

For product snippets, the page should focus on a specific product or variants rather than a broad category, and additional required properties apply.

Is ItemList enough to get a Google carousel?

No.

Google's normal carousel support applies only to specific supported structured-data features.

An ItemList of general business services does not automatically generate a carousel.

Does Service schema improve rankings?

There is no documented direct ranking boost from adding Service schema.

Use it to accurately describe services and entity relationships.

Does valid schema guarantee a rich result?

No.

Validity makes structured data understandable and may establish eligibility for supported features.

It does not guarantee how Google will display a result.

Does every page need custom schema?

No.

Many pages may be adequately described by the website's foundational markup.

Add page-specific structured data when there is a meaningful entity or relationship worth describing.

Can a plugin implement all of this?

A plugin can provide strong foundational markup.

It usually cannot understand all of the business relationships required for a complex website.

That is especially true for:

multi-location businesses

service-area businesses

industry architectures

B2B services

professional credentials

product catalogs

property listings

jobs

specialist profiles

certifications

case studies

research

custom tools

The more complex the business becomes, the more useful explicit entity architecture becomes.

The Rule to Remember

Do not start by asking:

What schema type can we add to this page?

Start with:

What does this page represent?

Then ask:

What is the primary entity?

Does that entity already exist elsewhere on the website?

Which other entities matter?

How are they related?

Are those relationships visible and true?

Does Schema.org provide a valid way to describe them?

Does Google currently support a search feature for any of them?

That sequence prevents most structured-data mistakes.

A city does not become a business branch because you want visibility there.

A testimonial does not become eligible for star ratings because Review exists.

A market cost estimate does not become an Offer because it contains a dollar amount.

A staffing service does not become a JobPosting because the company recruits people.

A case study does not automatically become a Project.

An industry page does not require an invented Industry type.

A compliance page does not prove certification.

A product category does not become one Product.

Good structured data does something much simpler.

It gives machines a structured representation of the same business users can see.

The company.

Its services.

Its real locations.

Its markets.

Its people.

Its products.

Its credentials.

Its offers.

Its jobs.

Its properties.

Its research.

Its evidence.

And the relationships connecting all of them.

That is the difference between adding schema markup and building a structured-data architecture.

Need Help Mapping Schema to Your Website?

The right structured-data architecture depends on the way your website and business are actually organized.

Before adding markup, Diakachimba maps the pages, entities, services, locations, audiences, people, products, proof, and business relationships behind them.

Then the structured-data layer can describe that system accurately instead of applying the same plugin settings to every URL.

Get Your Free Growth Plan

Browse All SEO Resources

Local

B2B

Local

B2B

Build the SEO system

Plan and estimate

Research faster

Browse Schema Examples

Start Here: Schema Markup Has Three Layers

1. The Web Page

2. The Main Entity

3. The Relationships

Schema.org and Google Rich Results Are Not the Same Thing

Search feature eligibility

Entity description

Before Using the Examples

Schema Markup by Page Type: Quick Reference

Schema Examples by Page Type

Build the Company Entity First

Homepage Example: B2B Organization

Homepage Example: Local Business

About Page Schema

Contact Page Schema

Services Hub Schema

Individual Service Page Schema

Service Page With a Real Offer

Capability Page Schema

Industry Page Schema

Industry Classification vs Industry Page

Use-Case Page Schema

Problem Page Schema

Physical Location Page Schema

Service-Area Page Schema

Physical Location vs Service Area: Visual Comparison

Service + Location Page Schema

Product Page Schema

Product With a Real Offer

Product Category Page Schema

Technology or Platform Page Schema

Compliance Page Schema

Certification Schema Example

Case Study Schema

Project and Portfolio Page Schema

Professional Profile Schema

Medical and Dental Profiles

Law Firm Schema

Pricing Page Schema

Cost Guide Schema

Comparison Page Schema

Buyer's Guide Schema

Process Page and HowTo Schema

FAQ Schema in 2026

QAPage Is Not a Replacement for FAQPage

Reviews and Testimonials

Glossary Schema

Statistics and Research Pages

Report and White Paper Schema

Calculator and Interactive Tool Schema

Job Posting Schema

Staffing service page

Actual job page

Event Schema

Commercial Real Estate Listing Schema

Schema Opportunities Across Local Business Industries

The Most Important Schema Relationships

mainEntity

about

provider

areaServed

audience

parentOrganization

hasCertification

offers

author and publisher

One Entity Graph Is Better Than Hundreds of Disconnected Schema Blocks

Breadcrumb Schema

What a Plugin Can Usually Handle

Schema Markup That Should Not Be Added Automatically

Do not add LocalBusiness to every city page

Do not add Product to category pages

`mainEntity`

`about`

`provider`

`areaServed`

`audience`

`parentOrganization`

`hasCertification`

`offers`

`author` and `publisher`