Structured Data for Local Businesses: JSON-LD and Validation

Plan the data before writing JSON-LD

A maintainable implementation starts with a small set of accurate records: the business, its services, its pages, and its authors. Each record should have an owner who can correct it when the underlying facts change.

This guide is for the person implementing or reviewing the code. For an introduction, read what schema markup means.

Give entities stable identifiers

Use a stable identifier for the organization so service and article data can refer to the same publisher or provider. Keep page URLs canonical and consistent. Avoid producing a separate business identity every time a template renders.

An illustrative service relationship looks like this. Replace the example values with actual visible facts:

{
  "@context": "https://schema.org",
  "@type": "Service",
  "@id": "https://example.com/services/drain-cleaning#service",
  "name": "Drain cleaning",
  "url": "https://example.com/services/drain-cleaning",
  "provider": {
    "@id": "https://example.com/#organization"
  },
  "areaServed": {
    "@type": "City",
    "name": "Boise"
  }
}

This example describes a service. It does not establish an office, verify credentials, or promise a particular Google result. Publish the referenced organization record using accurate information.

Keep shared values in one place

Pull the business name, public URL, and contact details from a maintained configuration. Generate article data from the same record that supplies the visible title, author, and dates. Generate an offer from the same pricing policy used by the page.

Avoid copying a block of markup into dozens of pages and editing each separately. That makes missed updates harder to detect.

Serialize safely

Use a proper JSON serializer rather than building JSON from string concatenation. When embedding JSON in a script element, use the application's safe JSON-LD serialization helper so user-controlled text cannot terminate the script element.

Validate the resulting document, including values that contain quotation marks, angle brackets, or line breaks.

Test content, syntax, and eligibility separately

1. Compare the facts against the visible page.
2. Check that referenced URLs and images resolve.
3. Validate the schema vocabulary and JSON syntax.
4. Check any supported Google feature against its specific requirements.
5. Inspect the deployed page after release.

Google's structured data introduction distinguishes markup from supported search presentation. Do not interpret a syntax pass as guaranteed eligibility or performance. For a quick reference block that already uses the right LocalBusiness subtype for a given trade, the free local business schema generator is a useful starting point before you wire the values into shared templates.

Avoid outdated feature promises

FAQ content can be useful without an enhanced Google listing. Google retired FAQ rich results in May 2026; see the documentation changelog.

Self-serving LocalBusiness and Organization reviews are excluded from Google's review-star feature, including when a business embeds a third-party review widget. Refer to the review snippet policy.

Review the implementation when facts change

Update markup alongside business details, prices, author records, and service changes. Keep representative URLs in a release checklist so template changes get checked consistently.

Use the local-business schema checklist for a handover review. The webIQ package scope explains how this fits into the broader website setup.