From page facts to JSON-LD

Start with what the page says

A service page already tells a reader what is offered and who provides it. Structured data gives software explicit labels for those facts. The useful starting point is the page itself: its service name, description, provider and public address.

Three terms describe different parts of the work. Schema.org supplies a vocabulary, including the type Service and the property provider. JSON-LD is a format for expressing linked data with those labels. Google search features have their own supported types, requirements and policies. A valid description in one vocabulary does not automatically qualify for a particular search display.

Google’s introduction to structured data explains how the markup describes page content. The JSON-LD can sit in a script element, separate from the visible text. That separation is convenient for installation, but the two still need to describe the same thing.

Check what the website already outputs

Before generating another block, inspect the page’s current markup and its CMS or plugin settings. A theme, publishing system or earlier developer may already supply the organization, service or breadcrumb details.

Searching the page source for application/ld+json is a useful first step. It is not a complete inspection: markup may also use Microdata or RDFa, or be added when JavaScript runs. The Schema.org Validator can inspect a supplied page or markup and summarize the data it finds. For a private preview, use its code input only with information you are authorized to send to that external service.

Record what describes the service, who maintains it and whether it agrees with the visible page. Update that source when practical. Several different entities on one page can be appropriate; the problem is adding conflicting descriptions of the same service or organization.

For example, if existing markup still gives an old service name, adding a second block with the new name leaves two versions to maintain. Correct the existing integration or have the maintainer connect the information coherently. Do not delete unrelated site-wide markup simply because it appears beside the service.

Build one fictional service example

The example here is Example Studio, an imaginary organization offering a website accessibility review. Assume its fictional service page visibly presents the facts below. This is demonstration content, not a Plainview client or an assessment of a real website. All example.com addresses are placeholders.

Schema.org’s Service definition fits an offering provided by an organization or person. The service’s name identifies the particular offering; serviceType gives a short description of its kind. The provider identifies who delivers it.

1. Open the Structured Data Builder and choose Service.
2. Select Try an example to load these exact values, or enter the table’s values yourself.
3. Leave Geographic areas served empty. The example does not state geographic coverage; an optional field is not a request to invent it.
4. Select Generate JSON-LD and read the notes beneath the output.

The builder requires the service name and page URL and checks its supported fields. Its required fields are this template’s rules, not a complete list of every Schema.org or Google requirement. It does not fetch the page, confirm its claims or install the result. Entries stay in this browser tab and clear on reload.

Read the result and choose an export

The example produces this HTML script. It describes one Service with a nested Organization provider. The code is shown as text here so it can be examined; it is not a claim that this article offers the fictional service.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "description": "A review of website pages with practical recommendations for accessibility improvements.",
  "@type": "Service",
  "name": "Website accessibility review",
  "url": "https://example.com/services/accessibility-review",
  "serviceType": "Website review",
  "provider": {
    "@type": "Organization",
    "name": "Example Studio",
    "url": "https://example.com/"
  }
}
</script>

@context establishes the Schema.org vocabulary, while @type identifies what the object describes. Inside provider, the type is Organization because the example names an organization as the service provider. The page URL and provider URL serve different purposes and should not be swapped.

Choose HTML script when the receiving field expects the script element. Choose JSON only when the CMS or integration supplies that wrapper itself. The copy button follows the selected view; the two download buttons each save their named format.

• Download the fictional Service JSON example — data without script tags.
• Download the fictional Service HTML script — the same data inside one JSON-LD script element.

These files match the builder’s Service example. The HTML file is a snippet, not a complete website page; opening it in a browser may look blank. Inspect it in a text editor. Neither download is a saved builder project that can be imported back into the form. Replace every fictional detail before using a version on a real site.

Install it on the page it describes

For this example, the markup belongs on the service page. Add it through the website’s documented page-level code or structured-data setting. A field that applies to every page would repeat this specific service description where it may not belong.

If you maintain the HTML, the script can be placed in the page’s head; Google also supports JSON-LD in the body. In a CMS, follow the platform’s instructions about the expected format. Pasting script tags inside a JSON-only field will not make valid JSON. Pasting JSON into an ordinary paragraph will display text rather than install structured data.

Review the change in a suitable preview before publishing. Then inspect the actual generated page, because an editor can remove tags, escape the snippet or output its own version. If the existing system uses shared entity identifiers or a combined graph, ask its maintainer to integrate the service into that structure rather than adding an unrelated duplicate.

Check the visible page at the same time. Google’s structured-data guidelines require relevant, accurate information that represents the page. Do not add unavailable services, invented reviews or coverage claims simply to fill a field.

Use the right check for each question

A single green result cannot answer every question about the markup. Work through these checks separately:

1. Is the JSON readable? Paste JSON only into the JSON Formatter & Validator. It can catch syntax problems such as missing commas or broken strings. As MDN’s JSON reference explains, JSON has its own grammar; script tags and comments are not part of it. Successful parsing does not validate Schema.org properties or the truth of the values.
2. Does it describe the intended entities? Check the script or installed page with the Schema.org Validator. Inspect the extracted Service, provider and properties, and investigate reported issues. Compare the result with the Service vocabulary and the visible page. Vocabulary checks do not establish that Example Studio exists or offers the service.
3. Does a supported Google feature apply? Consult Google’s supported-feature gallery and the relevant feature guide. Use the Rich Results Test for features it supports. Service is not listed as a dedicated rich-result feature, so a test that detects no supported item does not by itself show that this Service description is invalid.

Google’s test documentation distinguishes detected supported items, errors and warnings. Review the exact message and affected item. Do not change a truthful Service into an unrelated type merely to obtain a passing result from a test designed for another feature.

Passing a supported-feature test still does not promise that Google will show an enhanced result. Automated tests also cannot settle every content-quality issue. Keep the original task in view: accurately describing the page and confirming that the installed markup survives the publishing process.

Verify the published page and maintain it

After publication, test the public address again. Confirm that the expected page loads, the markup appears in the delivered or rendered page, the names and URLs are correct, and no old version conflicts with it. A successful code-only test does not prove the website now serves that code.

If you manage the Search Console property, URL Inspection helps distinguish Google’s stored view from a live test of the page. The live result is not a promise of indexing or a prediction of its search appearance. Public discovery also depends on the page being accessible and on applicable indexing controls.

Record where the markup is maintained and who updates it. When the service name, provider or URL changes, review its structured description alongside the visible copy. Include that check in the website maintenance routine.

Start with one representative page, complete these checks and then apply the same process where it fits. The JSON definition and structured-data definition provide shorter explanations if someone else will maintain the result.