Industry Schema: Valid Types, Service Areas, and Product Limits
Industry schema begins with a subject, not a label. A company, local office, professional, service, product, offer, course, event, and geographic region are different things. Assigning a valid class to the wrong thing is still a factual error. This guide gives fourteen editorial starting points, then separates those vocabulary examples from what ClickRadius currently accepts and renders.
Schema-guidance evidence boundary. Schema.org validity answers whether terms and relationships exist; Google's feature rules and every provider outcome are separate questions. Vocabulary validity does not prove Google rich-result eligibility, AI retrieval, citation, recommendation, or timing. The current ClickRadius generator maps a confirmed address ZIP to PostalAddress.postalCode and does not currently accept or emit areaServed.
Choose the subject before the type
Source checkpoint (reviewed September 13, 2026). Google's Local Business structured-data documentation tells publishers to define each local business location as a LocalBusiness and use the most specific applicable subtype. That is guidance for Google's Local Business feature. It does not say that every organization is a local location, that a subtype proves a license or service, or that structured data controls an AI answer.
Use the current Schema.org hierarchy for vocabulary validity and the responsible first-party or authoritative record for the fact itself. Then check the destination's rules. Google's general structured-data policies, for example, govern Google feature eligibility and require markup to represent the page it describes. Schema.org acceptance, Google feature support, observed indexing, and any later provider result remain separate states.
- Organization or business: the legal or operating entity responsible for the claim.
- Location: a particular office, store, clinic, restaurant, hotel, or service point, with its own address and hours.
- Person: an individual professional, employee, author, or license holder; do not give a person a business or place class.
- Service, product, offer, or event: the thing provided and its terms, separate from the provider.
- Evidence: the source, subject, jurisdiction, effective date, observation date, reviewer, and limits supporting each rendered value.
Service areas: postal codes are values, not classes
Schema.org does not define a PostalCode type. Its current postalCode definition is a Text-valued property used on DefinedRegion, GeoCoordinates, GeoShape, and PostalAddress. The current areaServed definition accepts AdministrativeArea, GeoShape, Place, or Text.
A postal code in a physical PostalAddress describes that address. It does not automatically declare the business's service territory. When a supported service-area fact really is a postal region, DefinedRegion can carry both addressCountry and postalCode. Because postal formats and identifiers are country-specific, do not publish an unqualified code when the country is unknown. A supported city can be a City, which is an AdministrativeArea; a governed boundary can be a GeoShape; and Text remains valid when the source supports only a textual description.
Service-area intake must bind inclusion, exclusion, overlap, multi-location ownership, source, and observation date to the exact organization, service, offer, or contact point that owns the claim. Record what is not covered as well as what is. Recheck changes in staffing, licensing, delivery policy, branch ownership, and geographic scope before re-rendering; a once-confirmed region can become stale.
Fourteen editorial starting points
These are subject maps for human review, not automatic facts and not the ClickRadius template inventory. Verify every type against the current vocabulary and every value against the exact visible page and responsible source.
1. Legal services
Use LegalService for an applicable firm or office. Model an individual lawyer as Person; Attorney is a deprecated business type, not an individual-lawyer class. Keep firm, office, person, role, jurisdiction, license, service, and outcome claim separate. A topic property does not prove expertise or professional authority.
2. Medical practices
Distinguish the operating entity, clinic or location, individual clinician, credential, specialty, and service. MedicalClinic, MedicalBusiness, Physician, and IndividualPhysician have different published semantics; choose only after identifying the exact subject. A registry identifier does not prove current licensure, credentialing, scope, privacy compliance, or clinical efficacy.
3. Dental practices
Dentist is in the LocalBusiness and MedicalOrganization hierarchies, so use it for an applicable dental practice or location rather than an individual clinician. Represent a clinician as a person and bind each license, credential, service, insurance, hours, and price assertion to its real holder and source.
4. Home and construction services
Use a current trade subtype such as Plumber, Electrician, HVACBusiness, RoofingContractor, HousePainter, or Locksmith only when it truthfully describes the business or location. Model service geography with a valid areaServed value and the evidence controls above. Keep trade licenses, service terms, emergency availability, locations, and covered regions separate.
5. Restaurants
Use Restaurant for the particular restaurant location. A menu can be a separate Menu graph containing MenuSection and MenuItem nodes when those nodes mirror current visible items, prices, availability, and dietary facts. Reservations, delivery, hours, reviews, and offers each need their own current source.
6. Real estate
Represent an individual licensee as Person; RealEstateAgent is a LocalBusiness type for an applicable real-estate business, office, or location. Keep brokerage, team, office, person, role, license, membership, service area, listing, residence, and offer as separately identifiable subjects. Listing and transaction claims also need current display rights and factual authority.
7. E-commerce
Separate the seller or store from each Product and its Offer. Product identifiers, variant, price, currency, availability, shipping, return terms, seller, and review provenance must describe the exact item and offer shown to the user. Do not copy an aggregate rating or inventory value from another subject or stale feed.
8. Software
Use an Organization for the provider and a separate SoftwareApplication for the product when those subjects exist. Bind each Offer, platform, version, feature, price, eligibility condition, and availability statement to the current product documentation. A product class does not type its maker.
9. Financial services
An applicable business may use FinancialService, AccountingService, InsuranceAgency, or another current subtype. Individuals, firms, branches, registrations, licenses, appointments, products, jurisdictions, and disclosures remain separate. An identifier is not automatically a license or credential.
10. Fitness
Use ExerciseGym or HealthClub only for a location that the class accurately describes. Treat memberships as offers, scheduled classes as events, and instructors as people. Hours, amenities, accessibility, eligibility, cancellation terms, credentials, and health claims require their own current facts.
11. Education
Separate an EducationalOrganization or school from a Course, its scheduled instance, instructor, credential, and offer. Delivery mode, dates, prerequisites, tuition, accreditation, completion claim, and provider must match the actual program and visible page. A PDF or template example is not a fact source.
12. Automotive
Use AutoRepair or AutoDealer for an applicable business or location. Represent each inventory item as the correct product or vehicle subject and each sale or lease as its own offer. Mileage, condition, model year, availability, warranty, price, and fees must come from the current authoritative inventory record.
13. Hospitality
Use Hotel or the applicable LodgingBusiness subtype for the actual property, not the parent brand or a room offer. Keep property, room, amenity, accessibility fact, policy, rate, availability window, and offer separate. Values that vary by room, date, occupancy, or channel need those qualifiers.
14. Professional services
ProfessionalService is deprecated because it was confused with Service. Use an accurate Organization or applicable LocalBusiness for the provider or location, separate Service nodes for offerings, and Person nodes for principals. Do not manufacture specificity when the vocabulary has no narrower truthful class.
Six controls for every implementation
- Bind each claim to one subject. Use stable identifiers to reference the same entity without merging a person, organization, location, product, or service.
- Validate vocabulary at the output boundary. Reject unknown types, unknown properties, and invalid property domains. Also review property ranges and destination-specific requirements; a partial validator is not complete proof.
- Require fact authority. A type library can suggest structure but cannot supply a client name, license, price, service, credential, coverage area, rating, or availability fact.
- Mirror the visible source. Generate changing values from the same governed records that render the page, with explicit handling for missing, conflicting, and stale data.
- Separate release states. Draft generation, approval, delivery acceptance, public readback, feature eligibility, indexing, and provider outcomes are different evidence events.
- Test boundaries, not only happy paths. Include wrong-subject, unknown-type, missing-country, inclusion, exclusion, overlap, multiple-location, stale-coverage, and unauthorized-field fixtures.
A valid vocabulary example for review
This hypothetical example demonstrates one physical address and two separately governed postal service regions. It is not a claim about a real business, not a promise of Google feature support, and not current ClickRadius generator output.
{
"@context": "https://schema.org",
"@type": ["Plumber", "LocalBusiness"],
"@id": "https://acmeplumbing.example/#denver-location",
"name": "Acme Plumbing Co.",
"url": "https://acmeplumbing.example/",
"address": {
"@type": "PostalAddress",
"streetAddress": "412 Mill St",
"addressLocality": "Denver",
"addressRegion": "CO",
"postalCode": "80202",
"addressCountry": "US"
},
"areaServed": [
{"@type": "DefinedRegion", "addressCountry": "US", "postalCode": "80202"},
{"@type": "DefinedRegion", "addressCountry": "US", "postalCode": "80203"}
]
}The physical address and service regions are distinct. Before using this pattern, confirm that the named location owns both coverage claims, that the two codes are included rather than excluded, that another branch does not own or overlap them in a conflicting way, and that the dated source remains current.
What ClickRadius currently does
ClickRadius's schema engine exposes 40 template keys. Those templates are suggestions and do not supply client facts. The generation path takes the business name and type from the CRM/client fact authority; it can also use confirmed description, phone, email, street, city, state, ZIP, and country values. The site URL comes from the bound site record.
The current builder maps a confirmed address ZIP to PostalAddress.postalCode. It does not currently accept or emit areaServed. A nonempty areaServed field submitted to /generate receives HTTP 409 with schema_fact_confirmation_required, and no schema optimization is inserted. That refusal is intentional until service-area ownership, provenance, country, inclusion and exclusion, overlap, multi-location assignment, review date, and staleness have a governed intake path.
Generated schema is returned as draft_generated; generation does not itself publish it. The current emit validator rejects unknown types, unknown properties, and property-domain violations. It does not by itself establish every property-range rule, factual truth, Google feature eligibility, public delivery, indexing, AI use, citation, recommendation, or outcome.
Frequently asked questions
Is PostalCode a Schema.org type for a service area?
No. Schema.org does not define a PostalCode type. postalCode is a Text-valued property used on DefinedRegion, GeoCoordinates, GeoShape, and PostalAddress. areaServed accepts AdministrativeArea, GeoShape, Place, or Text. A postal service area can therefore be plain Text or, when evidence supports it, a country-bound DefinedRegion carrying postalCode.
What evidence should govern service-area markup?
Bind every covered region to the business, location, offer, or service that actually owns it. Record country, inclusion, exclusion, overlap, multi-location ownership, source, and observation date; then review stale coverage before rendering it. A street address, directory category, or nearby city does not by itself authorize a service-area claim.
Does ClickRadius currently generate areaServed markup?
No. The current ClickRadius generator maps a confirmed address ZIP to PostalAddress.postalCode. It does not currently accept or emit areaServed; a nonempty areaServed field on /generate receives HTTP 409 with schema_fact_confirmation_required. Its 40 template keys are starting points and do not supply client facts. Generated output remains a draft until a separate authorized delivery path applies an approved exact revision.
Use the free AI Readiness Score to inspect current inputs at a submitted URL, or review ClickRadius plans and pricing. A scan finding, valid vocabulary, generated draft, or sampled provider answer is evidence of that exact event only.