Primary entity
When a page is dedicated to a service, Service should be the primary entity. Organization can exist in the graph as provider while WebPage represents the URL.
Provider
Link provider by @id to a shared Organization when possible. This avoids repeating the company name, address and contact data in every service node.
{
"@context": "https://schema.org",
"@type": "Service",
"name": "Service example"
}URL and @id
Service.url should point to the service page, not automatically to the home page. A stable @id such as /services/example/#service makes graph relationships easier to maintain.
serviceType and description
serviceType classifies the offering and description explains it. Both values should come from real page content rather than unrelated navigation text.
Service area
Set areaServed only when the geographic scope is actually known. If the company serves a whole country, do not restrict the service to the office city simply because an address was found there.
WebPage.mainEntity
WebPage can point to Service with mainEntity. The graph then expresses a clear relationship: the page describes a service that is provided by an organization.
Breadcrumbs and FAQ
BreadcrumbList and FAQPage can be additional entities. Avoid creating a one-item breadcrumb containing only Home because it adds little meaning.
Common questions
Can structured data always be improved to 100% automatically?
Only when the required data actually exists in the JSON-LD or on the page. A tool should not invent prices, authors, ratings, addresses or other values.
Should every possible Schema.org property be added?
No. A smaller set of accurate properties is better than irrelevant or fabricated values.