Schema markup: types, JSON-LD and validation

Choose a type that fits the page’s main content. A service can be described as Service, an article as Article or BlogPosting, and a breadcrumb trail as BreadcrumbList.

Google requires relevant markup to match visible content and not be misleading. Read the structured data guidelines.

How do you distinguish the page type from what it describes?

The web page, its main subject and its publisher can be separate objects. An article is a content object, a service is an offering and the organisation is its provider. Do not choose the same main type for every page merely because they share a design.

Type selection describes the content. For a particular search feature, also read Google’s documentation on supported result types. The existence of a Schema.org type does not automatically mean Google offers a dedicated rich result for it.

Should every Schema.org property be filled in?

No. Include relevant, confirmed information, then follow the requirements of the Google feature you are actually targeting. Required and recommended properties differ between features. A missing required field can make an item ineligible for that particular result. An unknown fact does not become true because a testing tool asks for it. Read Google’s content and completeness guidelines.

Reuse stable identifiers and the same confirmed business name, address and contact details. In JSON-LD, @id identifies the object being described. Keep the same identifier when other pages refer to the same business. A reference using the business’s @id points to that object rather than describing a new provider. The business, service and web page are different objects and can each have their own identifier. The W3C JSON-LD specification explains identifiers and node references.

Do not invent founding dates, customer ratings, offices or authors to fill optional fields. Mark up a price only when its scope and conditions match the page’s offering.

What if several templates describe the same business?

Multiple descriptions need to refer to the same identity and provide compatible information. Review which templates, plugins and data sources generate JSON-LD. An outdated business name from a plugin can otherwise remain alongside new code describing the correct name. The number of script blocks is not itself the error; conflicting information is what needs resolving.

Practical check: search for the business name and identifier across every JSON-LD block on the page. Compare names, URLs and contact details with the visible information. Then identify the confirmed data source for each fact. Do not make every object identical: the business identifier must still differ from the article or service identifier.

A service page can connect a Service object to the agency’s Organization and the relevant WebPage. The name and description should come from the visible page. This describes the service; it does not mean Google offers a special search result for every Service object.

Schema.org describes the Service type and its properties.

What does a minimal JSON-LD example look like?

A bounded JSON-LD example can identify a service and connect it to its provider and web page. Illustrative visible text: “Example company offers website maintenance with agreed content updates.” In this example, the text appears on example.com/underhall. The objects can be described as follows: {"@context": "https://schema.org", "@graph": [{"@type": "Organization", "@id": "https://example.com/id/company", "name": "Example company"}, {"@type": "WebPage", "@id": "https://example.com/underhall", "name": "Website maintenance"}, {"@type": "Service", "@id": "https://example.com/id/maintenance", "name": "Website maintenance", "description": "Agreed content updates", "provider": {"@id": "https://example.com/id/company"}, "mainEntityOfPage": {"@id": "https://example.com/underhall"}}]}. provider refers to the business’s @id, while mainEntityOfPage refers to the web page’s. Each reference reuses the identifier assigned to its object. The example shows these connections, not a complete implementation or a promise of rich results.

The code example does not describe an actual SOVRA Digital product and must not be published as the website’s own service markup. In a real project, only information confirmed for the service is added. A price, rating or provider must not be filled in by copying values from an example.

How do you read the connections in the code example?

The organisation describes who provides the service, the service describes the offering, and the web page identifies where it is explained. The example graph contains three separate objects. The service’s provider refers to the business identifier and mainEntityOfPage to the page identifier. If the business name changes, update its own description; the service reference should still point to the same real provider.

Test the example as text first: can every statement be found on the page? Does the named provider and described service actually exist? If not, correct the underlying information before adapting the code. This check prevents valid syntax from being used to describe incorrect content.

Where is JSON-LD placed on a page?

JSON-LD can sit in a script block of type application/ld+json in the page’s head or body. It is structured information for machines, not the visible article text. Google describes the format in its introduction to structured data. A code example displayed in an article is not automatically active markup for the page’s business.

Where the implementation allows it, use a shared data source for visible facts and relevant markup. Then check the delivered page: filling in an administration field does not establish that the correct code reaches the visitor or search engine.

Check the syntax, the meaning of the information and the markup actually present on the published page. Complete these checks before treating the work as finished:

1. That the JSON-LD can be read without syntax errors.
2. That types and properties are used appropriately.
3. That the information is true and appears on the page.
4. That references and addresses point to the correct destinations.
5. That the published page contains the correct markup without conflicting duplicates.

Passing a tool test does not guarantee that Google will show a rich result. FAQ, HowTo and ratings are not a package to add to every page.

What is the difference between Schema Markup Validator and Rich Results Test?

Schema Markup Validator checks Schema.org markup generally, while Rich Results Test assesses support for Google’s rich results. Passing a schema test therefore does not mean that a particular Google feature is supported or will be displayed. Google explains the difference between the testing tools.

What must be checked on the published page?

Check that the published URL contains the correct JSON-LD, that the objects describe the same business and that the values match the visible text. Google’s introduction to structured data explains support, formats and testing. Testing tools do not replace checking that the facts are accurate.

When the page’s text and markup give different information, trace the error to the correct template or data source. SOVRA Digital’s technical SEO work can include this kind of review of the website’s implementation.

In what order should the tests be performed?

Test the bounded code first, then the actual URL, and finally whether the information matches the content. This separates a JSON typing error from a template error or an incorrect business fact.

1. Check the code’s syntax and fix errors preventing interpretation.
2. Review types, properties and identifiers in Schema Markup Validator.
3. If a Google feature is relevant, use Rich Results Test and follow that feature’s requirements.
4. Test the published address, including the correct language version, and compare the result with the intended code.
5. Read the corresponding headline, name, image and facts on the page. Record discrepancies and who will correct them.
6. Repeat the affected checks when text, templates or business information changes.

A useful report states the URL, date, testing tool, error found and the information requiring correction. “Schema passed” is not a sufficient conclusion if fact checking remains unfinished. A valid Article object can still contain the wrong author name if the underlying information was incorrect.