Build a business entity graph that stays accurate.

1. Inventory the facts before choosing types

Start with approved public facts: trading name, website, locations, services and professional records. Record the source and owner of each fact. Do not begin by copying a competitor’s schema block.

Keep claims separate from evidence. A service page can explain a capability. A professional register can verify a credential. An unrelated high-authority URL does not prove either.

2. Use stable IDs to connect the graph

An @id identifies the entity. A url points to a page about it. They often share a base URL but serve different roles. Reuse the same organisation identifier across your service pages instead of creating slightly different business objects everywhere.

Choose the public canonical domain first. Avoid embedding temporary preview domains in production identities. If the canonical changes, plan the redirects and update the graph consistently.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example Studio",
      "url": "https://example.com/"
    },
    {
      "@type": "Service",
      "@id": "https://example.com/services/design/#service",
      "name": "Residential interior design",
      "provider": { "@id": "https://example.com/#organization" },
      "areaServed": { "@type": "Place", "name": "London" }
    }
  ]
}

3. Choose the narrowest truthful type

Organization can describe the company as a whole. A genuine local operation may use LocalBusiness or a suitable subtype. A service is a Service, not another business with a new identity.

Schema.org has deprecated the broad ProfessionalService type. For new work, use a current specific type where accurate, such as LegalService, AccountingService or a relevant trade type. A medical clinic and an individual clinician should not be merged just because both have healthcare information.

• Use PostalAddress for a public address rather than one unstructured string.
• Use GeoCoordinates only for a real location with accurate coordinates.
• Use OpeningHoursSpecification for known day and time rules.
• Model services independently when they have distinct pages and descriptions.

4. Connect evidence with the right relationship

sameAs is for another URL identifying the same entity. Use it for an exact verified profile, not a general regulator homepage or a page about a topic you want to rank for.

Credential modelling needs care: confirm whether the holder is the person or organisation, identify the issuing body and keep the visible credential current. A link to a public register is useful evidence; a claim of affiliation needs the actual relationship to support it.

• Check that the linked record names the same entity.
• Keep an editorial review date for registrations and expiry-sensitive claims.
• Do not invent a Wikidata entry or official profile to complete a graph.
• Keep evidence links readable and usable outside the JSON-LD.

5. Validate three separate layers

These are different tests. Valid JSON can contain a false claim. Valid Schema.org markup may not qualify for a Google search feature. Passing a feature test does not guarantee that Google will display that feature.

Google’s structured data guidance also requires markup to represent the page honestly. Do not add hidden ratings, fabricated reviews or business facts that are absent from the user experience.

6. Serialize safely and maintain one source of truth

Generate JSON-LD from trusted business records where possible. If visitor-entered text is included in an HTML script element, serialize it safely so a value containing a closing script tag cannot break out into executable HTML.

Keep one authoritative source for recurring fields and derive the visible components and structured data from it. Add a release check for duplicate organisation IDs, preview-domain URLs and mismatches between opening hours on the page and in the graph.

const json = JSON.stringify(graph).replace(/</g, '\u003c');
// Insert this serialized JSON as application/ld+json, not executable JS.