Schema Types for Service Business Websites (2026)

Schema markup should describe what a page visibly and truthfully contains. It should not be used to manufacture ratings, locations, prices, services, people, or FAQs that users cannot see. For most service-business websites, a small set of accurate JSON-LD entities is safer and more useful than adding every type found on Schema.org.

This guide explains how to choose between Organization, LocalBusiness, Service, BreadcrumbList, Article or BlogPosting, and FAQPage; how to connect entities; which claims need caution; and how to test a Next.js or other modern website. It distinguishes Schema.org vocabulary from Google Search rich-result eligibility.

Author and Editorial Review

By Tushar C. (Founder, VASUYASHII). Last reviewed against current Google Search Central structured-data policies and Schema.org vocabulary on July 20, 2026.

Quick Answer

A typical service-business implementation may use:

• Organization on the homepage or a primary business page
• the most specific LocalBusiness subtype for each genuine physical location
• BreadcrumbList where the visible or typical navigation path supports it
• BlogPosting or Article on editorial articles
• Service to describe a genuine service visible on a service page
• FAQPage only when the page visibly contains one answer per question, while understanding that Google generally limits FAQ rich results to eligible authoritative government and health websites

Not every Schema.org type creates a Google rich result. Google says correct markup makes a page eligible for supported features but does not guarantee a special search appearance. Use the Google Search structured-data gallery as the current source for Google-supported features and Schema.org as the vocabulary reference.

Vocabulary and Search Features Are Different

Schema.org defines a broad shared vocabulary used by search engines and other systems. Google Search documents a smaller set of structured-data features with specific required, recommended, technical, and content rules.

This means Service can be a valid Schema.org type even though adding it does not create a guaranteed standalone Google service rich result. Similarly, valid JSON-LD can be ignored for a rich feature when the page, site, content, or type is not eligible.

Google's introduction to structured data recommends relying on Google Search Central documentation for Google behaviour and testing with the Rich Results Test. The business decision is therefore:

1. describe the entity accurately for machine understanding
2. meet the specific Google rules only where a supported feature applies
3. never add unsupported or invisible claims to chase a visual result

Selection Table

Use the most specific type that remains accurate. A software consultancy is not automatically a Store; a service-area company without a walk-in branch should not invent a public address to use LocalBusiness.

Organization Markup

Use Organization to identify the company and connect its official name, URL, logo, contact data, and real profiles. Google's current Organization markup documentation recommends placing it on the homepage or a single organisation page rather than repeating an inconsistent block everywhere.

Useful properties may include:

• @id as a stable entity identifier
• name and genuine alternateName
• canonical url
• crawlable logo
• verified email and telephone
• real address, if appropriate
• official sameAs profiles controlled by the organisation
• contactPoint when it represents an actual contact route

Do not add social profiles that do not belong to the business. Do not put keywords in name. Keep the logo URL absolute and crawlable.

Example pattern:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://www.example.com/#organization",
  "name": "Example Services",
  "url": "https://www.example.com/",
  "logo": "https://www.example.com/logo.png"
}

The example is intentionally minimal. Add only verified properties the page and business support.

LocalBusiness for Real Locations

Use the most specific applicable LocalBusiness subtype for a genuine physical business location. Google's LocalBusiness documentation currently requires name and address for its rich-result eligibility and recommends useful details such as telephone, URL, hours, geo data, and the most specific business type where applicable.

For multiple branches, create one location page and entity per real branch. Use branch-specific:

• name where the branch naming is genuine
• full postal address
• telephone
• canonical location URL
• opening hours
• geographic coordinates
• image
• service or department context

Keep these values consistent with the visible page and external business profile. A Delhi service page is not a Delhi physical branch merely because the company serves Delhi.

Self-serving review markup is a common mistake. Google's local-business documentation says review and aggregateRating are recommended only for sites that capture reviews about other local businesses under the applicable review rules. Do not copy Google ratings into your own business entity markup or invent aggregate values.

Service Markup

<code>Service</code> can describe a genuine service, its provider, area served, service type, or offer catalog. It helps express relationships but does not guarantee a Google rich result.

Use it on a page whose main visible content explains that service. Suitable properties can include:

• stable @id
• name
• accurate description
• canonical url
• provider pointing to the organisation entity
• areaServed when the area is factual
• serviceType
• hasOfferCatalog when the visible page presents the catalog
• offers only when price and conditions are real and maintained

Do not add a long list of cities in areaServed without genuine service capability. Do not mark an internal future roadmap item as an available service. If a quote depends on scope, avoid a fake fixed Offer.

BreadcrumbList

BreadcrumbList helps represent a typical navigation path. Google's breadcrumb documentation requires an ordered itemListElement with ListItem, position, and names, plus item URLs where required.

The structured trail should match how users understand the site, not blindly mirror every URL segment. For example:

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Services",
      "item": "https://www.example.com/services"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Web Applications"
    }
  ]
}

Keep canonical URLs consistent. Do not produce a non-www breadcrumb item when the page canonical is final www.

Article and BlogPosting

Use BlogPosting or Article for editorial pages. Google's Article structured-data documentation recommends properties that help identify headline, representative image, publication and modification dates, and all authors.

Important fields include:

• headline matching the article
• canonical main entity or URL
• crawlable relevant image
• datePublished preserving the original publication date
• dateModified changing only after meaningful updates
• author as Person or Organization with a useful identity URL
• publisher organisation where appropriate

Do not replace the original publish date every time a typo is corrected. Do not use a logo as the only article image when a relevant cover exists. The author shown in the markup should match the visible byline.

Google's author guidance says author.name should contain only the person's name, with job title stored separately. A visible byline such as "Tushar C. (Founder, VASUYASHII)" may therefore need parsing into name, jobTitle, and url in the generated JSON-LD rather than copying the entire display string into author.name.

FAQPage: Valid Markup, Limited Google Visibility

Use FAQPage only when the business publishes one authoritative answer for each question and all marked questions and answers are visible on the page. Do not use it for a forum where users submit multiple answers; that is a different content model.

Google announced that FAQ rich results are generally shown only for eligible, well-known authoritative government and health sites. For most commercial service websites, FAQ markup may have no visible Google result even when valid. See Google's FAQ and HowTo rich-result change.

Therefore:

• write FAQs because they help buyers, not to force extra SERP space
• keep answers visible and consistent with JSON-LD
• do not add hidden keyword-stuffed FAQs
• do not mark testimonials or multiple community answers as FAQPage
• do not promise FAQ rich results to a normal service business

You may retain accurate FAQ markup for machine understanding, but its absence is not an SEO emergency for a commercial site.

Reviews and Ratings

Never create Review or AggregateRating from invented, selected, or copied numbers. The review must be genuine, visible, attributable under the relevant policy, and about an eligible subject.

Common unsafe patterns include:

• adding a 5.0 rating with no visible review source
• marking up testimonials the business selected about itself
• copying Google Business Profile rating into website JSON-LD
• using employee or owner reviews
• marking one review as an aggregate
• leaving an old aggregate after visible reviews change

Structured data does not make an unsupported claim safe. It makes the claim easier for machines to read.

Connect Entities With Stable IDs

Use stable @id values so pages can refer to the same organisation or location instead of defining inconsistent duplicates.

Example entity graph:

• https://www.example.com/#organization
• https://www.example.com/location/delhi/#localbusiness
• https://www.example.com/services/web-apps/#service
• https://www.example.com/blog/post/#article

The service can point to the organisation as provider. The article can point to the organisation as publisher. A webpage can identify its primary entity. Keep names, URLs, and IDs stable across builds.

JSON-LD in Next.js

Generate JSON-LD from the same server-side data used for visible content and metadata. This reduces disagreement between title, canonical, image, author, dates, and schema.

Implementation principles:

• render JSON-LD in the initial HTML
• build all public URLs from one final canonical base
• serialise trusted structured objects, not user-written script fragments
• prevent unsafe < characters from breaking the script context
• keep dates in ISO 8601 format
• omit unknown optional properties instead of sending empty strings
• use page-specific schema rather than one giant universal block
• ensure static-exported pages contain the final JSON-LD

For the project-specific pattern, read how to add schema in Next.js MDX blogs.

Content and Schema Must Agree

Google's current general structured-data guidelines state that markup should represent the main visible page content, avoid misleading or irrelevant information, use up-to-date original information, and include complete required properties for the supported feature.

Audit consistency across:

• visible business name and schema name
• canonical URL and schema URL
• visible address and PostalAddress
• displayed hours and openingHoursSpecification
• visible author and schema author
• publish or update date and schema dates
• cover image and article image
• FAQ text and mainEntity
• displayed offer and structured offer

A Rich Results Test pass checks syntax and supported properties. It cannot prove that a business claim is true or that the visible page is high quality.

Validation Workflow

Before deployment

1. inspect the rendered HTML, not only React source
2. parse every application/ld+json block
3. compare URLs with canonical and final domain
4. run Google's Rich Results Test
5. use Schema.org Validator for vocabulary-level review
6. check visible content against marked properties
7. test representative templates, not only the homepage

After deployment

1. inspect the live canonical page
2. use Search Console URL Inspection
3. monitor rich-result and unparsable structured-data reports
4. verify pages remain crawlable and indexable where intended
5. re-test after template, data model, or deployment changes

Structured-data errors can appear across hundreds of pages when one template changes. Add generated-output checks to the release process.

Audit Checklist

• [ ] Every entity is real and visible or clearly supported by the page.
• [ ] The most specific accurate type is used.
• [ ] Google-supported features follow their current feature guide.
• [ ] Final absolute URLs use https://www.vasuyashii.com or the site's real canonical host.
• [ ] @id values are stable.
• [ ] Organisation details are consistent.
• [ ] LocalBusiness exists only for real locations.
• [ ] Service markup describes an available service.
• [ ] Article author and dates match the page.
• [ ] Breadcrumb order represents a real path.
• [ ] FAQ content is visible and expectations are realistic.
• [ ] Reviews and ratings are not self-invented.
• [ ] Images are relevant, crawlable, and indexable.
• [ ] JSON-LD parses in generated HTML.
• [ ] Rich Results Test errors are resolved.

Common Mistakes

• Adding every schema type to every page.
• Assuming a valid Schema.org type guarantees a Google rich result.
• Using LocalBusiness without a genuine physical location.
• Marking future services as currently offered.
• Publishing hidden FAQs only in JSON-LD.
• Copying self-ratings into AggregateRating.
• Using redirected, non-canonical, or relative URLs inconsistently.
• Showing one author while marking another.
• Updating datePublished during every edit.
• Validating source code but not generated HTML.
• Ignoring errors after a shared template deployment.

Current VASUYASHII Approach

VASUYASHII uses final-www canonical URLs, page-specific metadata, article data, and structured output generated from the content source. Schema work should remain tied to visible page truth and current Google documentation.

Use the local SEO and web development hub, website development services, or contact VASUYASHII with the page templates, current JSON-LD, Search Console enhancement reports, and the entities you need to describe.

FAQs

Which schema should a service company use first?

Start with an accurate Organization entity and page types that match real content, such as BreadcrumbList and BlogPosting. Add LocalBusiness only for genuine locations and Service only for visible offered services.

Does Service schema create a rich result?

Not as a guaranteed standalone Google feature. It is valid Schema.org vocabulary for describing services, but Google determines supported appearances through its Search gallery and feature rules.

Should every page include Organization schema?

It is usually enough to define it consistently on the homepage or primary organisation page and reference its stable @id where needed. Avoid inconsistent duplicated definitions.

Should a normal company use FAQ schema?

Only when visible FAQs genuinely fit the type. Do not expect regular FAQ rich results for most commercial sites because Google generally limits that display to eligible authoritative government and health sites.

Is a Rich Results Test pass enough?

No. It confirms many technical requirements but not truth, relevance, content quality, indexing, or guaranteed search appearance. Compare markup with the visible page and feature policy.

Can schema improve rankings directly?

Structured data helps systems understand content and can enable supported search features. Google does not promise a direct ranking increase merely for adding markup.

Final Decision

Implement fewer, complete, accurate entities connected through stable IDs. Validate the live generated page, follow the feature-specific Google guide, and treat schema as a representation of content rather than a substitute for content.

• Request a structured-data audit
• Review local and technical SEO guidance
• Explore the Next.js schema guide