How to add schema markup to a website.
Schema markup adds machine-readable structured data to a page so search engines can understand the entities the page describes and qualify the page for specific rich result types. Google supports three formats and recommends JSON-LD. Validation runs through the Rich Results Test and the Schema Markup Validator. The implementation works when the markup accurately represents the user-visible content and follows the per-feature documentation.
Schema implementation is one of the structural surfaces the agency reads against on every site. The JSON-LD block is small; the entity graph it surfaces is load-bearing for the broader trust signal.
A script block in the head or body, decoupled from the visible HTML structure.
JSON-LD (JavaScript Object Notation for Linked Data) embeds the schema markup inside a script tag with type application/ld+json. The block can live in the head or anywhere in the body. The crawler reads the JSON-LD and reconciles its entity claims with the rest of the page. The decoupling from visible HTML structure is the operational advantage: the schema lives in one block, named and maintained in one place, rather than scattered through visible elements as Microdata or RDFa attributes.
The crawler parses JSON-LD even when it is injected into the DOM dynamically via JavaScript. Server-Side Rendering and Client-Side Rendering both work as long as the markup is present in the DOM by the time Googlebot executes the page. Sites whose rendering layer fails to ship the JSON-LD block to the crawler (e.g., hydration timing issues) lose the rich result eligibility without losing the page index.
The pattern that scales is one JSON-LD block per page carrying the primary schema (Article, Product, Service, FAQPage, etc.) plus the supporting nodes (Person for the author, Organization for the publisher, BreadcrumbList for the navigation chain). Each node carries an @id that other nodes reference via @id, building the entity graph the crawler reads.
Rich Results Test for eligibility, Schema Markup Validator for schema.org conformance.
The Rich Results Test (search.google.com/test/rich-results) is the eligibility surface. It validates the JSON-LD against the per-feature documentation Google publishes for each rich result type. The test surfaces required fields, recommended fields, errors, and warnings against the specific rich result the page is trying to qualify for. The test result is what Google actually uses to decide whether to show the rich result.
The Schema Markup Validator (validator.schema.org) is the conformance surface. It validates the JSON-LD against the schema.org vocabulary generically without scoring rich-result eligibility. The validator is useful for catching schema.org-level syntax and vocabulary errors but does not tell you whether the markup will produce a rich result. The Rich Results Test is the more operationally important of the two.
The consistency requirement is the published constraint. Google's documentation specifies that structured data must accurately represent the user-visible content. Marking up content the user cannot see, marking up generic items as specific entities, marking up review data the site or service provider wrote rather than independent customers, all trigger manual actions for spammy structured data. The consistency rule is the most common cause of denied rich results and the most common cause of structured-data manual actions.
Validates JSON-LD against the per-feature documentation. Surfaces required fields, errors, and warnings against the specific rich result the page is targeting.
Search Central →Generic schema.org vocabulary conformance check. Useful for syntax errors; does not score rich result eligibility.
Search Central →Manual actions for marking up hidden content, marking up generic items as specific entities, or marking up self-written reviews.
Search Central →The catalog of schema types with implementation examples per type.
The Article schema properties that carry the author and publication-date signals for editorial pages.
The engagement that wires schema to the entity-trust signal layer.
What operators ask about adding schema markup before the implementation work starts.
- 01.Which structured data format does Google recommend?
- JSON-LD. Google supports three formats (JSON-LD, Microdata, RDFa) but the published recommendation is JSON-LD. The format embeds the semantic markup inside a script tag in the head or body, decoupling it from the user-visible HTML structure. This decoupling prevents the nesting errors common in Microdata and simplifies maintenance because the markup lives in one named block rather than scattered across visible elements.
- 02.How does Google validate schema markup?
- Two surfaces. The Rich Results Test (search.google.com/test/rich-results) validates eligibility for specific rich result types and surfaces field-by-field errors against the per-feature documentation. The Schema Markup Validator (validator.schema.org) validates the markup against the schema.org vocabulary generically without scoring rich-result eligibility. The Rich Results Test is the operationally important surface because it surfaces what Google specifically requires for each rich result, which is sometimes a subset of what schema.org allows.
- 03.Can schema markup hurt rankings if implemented wrong?
- Yes, in two ways. Deceptive structured data triggers a manual action: marking up content the user cannot see, marking up generic items as specific entities (a company as a Product, a coupon as an Event), marking up review data that the site or service provider wrote rather than independent customers. The manual action carries the standard remediation requirement: fix the violation, submit a Reconsideration Request. Strict consistency failures (markup that does not match the visible content) cause the rich result to be denied even when no manual action issues; the page indexes normally but loses the SERP enhancement.
- 04.Where does the JSON-LD block actually go?
- The block can go in the head or the body. The script tag has type application/ld+json. The crawler parses the JSON-LD even when it is injected into the DOM dynamically via JavaScript, which means Server-Side Rendering and Client-Side Rendering both work as long as the markup is in the DOM by the time the crawler executes. The most common pattern is one JSON-LD block per page carrying the primary schema (Article, Product, Service, etc.) plus the supporting nodes (Person for the author, Organization for the publisher, BreadcrumbList for the navigation chain).
If you want schema implemented as a load-bearing entity-signal layer rather than a checkbox, see how we work.
Two-week diagnostic. The schema work sits inside the broader technical foundation, alongside rendering parity, crawl budget, and the editorial signals the named-author surface carries.