Structured data purpose and formats
Understand structured data before choosing the format.
Separate the meaning of Schema.org terms from JSON-LD, RDFa and Microdata. Describe the visible page with supported facts, then check the platform’s current rules.
Free learning from Semantec SEO.
Separate the vocabulary from its writing format.
Structured data expresses descriptions that software can read: a thing has a type, properties and relationships. Schema.org supplies a shared vocabulary such as Article, Person, headline and author. JSON-LD, RDFa and Microdata are ways to express those descriptions. Choosing a format does not decide if a claimed author, date or organization is true.
A vocabulary answers “what does this term mean?” A syntax answers “how is this description written?” The same supported article description can be expressed through more than one syntax. Changing from Microdata to JSON-LD does not turn an ordinary article into a product or create missing evidence. Start with the visible page, its purpose and the things it describes.
The Schema.org data model explains types and properties with expected relationships. Its vocabulary covers more than any single search platform’s feature set. A recognized Schema.org type is not a promise that a search service offers a special display for that type.
Choose a format the site can keep accurate.
JSON-LD places a JSON description in a data script block, usually separated from the visible HTML. This makes connected objects easier to express, but it also allows the data to drift away from a changed heading or author unless both use the same approved source. The block is data, not an instruction to run a calculator or another user-facing tool.
Microdata adds attributes such as itemscope, itemtype and itemprop to HTML elements. RDFa also expresses relationships through HTML attributes, using terms such as typeof and property. Both can stay close to the visible text, but template edits can break or detach the relationships. A site may encounter any of these formats in theme, plugin or component output.
Google’s structured data introduction describes support for all three and usually recommends JSON-LD for maintainability. Follow the feature’s current documentation and the site’s constraints. Do not add a second emitter simply to change format: first inspect if the existing output already describes the same entity.
Keep the visible statement and the data in agreement.
A reader should find the facts represented by the markup on the relevant page. Approve the article title, author attribution, publisher, dates and other candidate facts before encoding them. A syntactically valid field can still be hidden, stale, misleading or attached to the wrong thing. An author is not automatically the publisher, and a person is not the page describing that person.
Use a brief evidence record for each proposed fact: owning entity, visible source, controlling record, date checked, permitted scope, reviewer and change trigger. Some facts are volatile. A changed byline or corrected publication date needs a data review even when the JSON still parses. Missing optional facts can be omitted; filling them with plausible guesses makes the description less reliable.
The Google structured data policies place accuracy and relevant visible representation alongside technical requirements. That is a separate check from the question of correctly formed braces and commas are valid. Do not encode an award, rating, qualification or service condition that the source cannot support.
Describe this fictional article in JSON-LD.
This is an educational example using reserved example.com URLs and invented people and publication details. It is not production markup for Semantec SEO. Suppose the visible article is titled “Choosing a content home,” credited to Jo Ellis, published by Example Editorial, with its publication date visibly shown as 1 October 2026. Its fictional page URL is https://example.com/articles/content-home/. The following description represents only those stipulated facts.
{
"@context": "https://schema.org",
"@type": "Article",
"@id": "https://example.com/articles/content-home/#article",
"url": "https://example.com/articles/content-home/",
"headline": "Choosing a content home",
"datePublished": "2026-10-01",
"author": {
"@type": "Person",
"@id": "https://example.com/people/jo-ellis/#person",
"name": "Jo Ellis",
"url": "https://example.com/people/jo-ellis/"
},
"publisher": {
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "Example Editorial",
"url": "https://example.com/"
}
}The example omits image, modified date, credentials and ratings because the fictional brief does not establish them. Omitting a field is not a shortcut around feature-specific requirements: if a chosen platform feature requires a missing field, obtain the supported fact or stop that feature release. This compact illustration teaches description and relationships; it does not claim eligibility for any current search treatment.
Read each line as a claim with a source.
| Term | Meaning here | Evidence or caution |
|---|---|---|
| @context | Uses Schema.org terms | Vocabulary context, not a trust seal |
| @type: Article | The described work is an article | Supported by the stipulated visible article purpose |
| @id | Identifier for this article node | Fragment differs from its page URL; reuse consistently |
| url | Location of the article page | Must be the approved URL, not promotional text |
| headline | Visible article title | Match the article’s title without adding a claim |
| datePublished | Visible publication date | ISO date of the stipulated publication, not the rebuild date |
| author | Person credited for writing | Jo Ellis is fictional; no qualifications inferred |
| publisher | Organization publishing the work | Separate organization node, not the author’s page |
JSON-LD uses quoted property names, strings and nested objects. The author object carries a Person description; publisher carries an Organization description. The @id is used to identify a node, while url records a page location. A graph can reference the same person from other articles without creating a new person identity for every page.
For an HTML page, a developer normally places JSON-LD inside a script element with type=”application/ld+json”. Keep explanatory comments outside the JSON: standard JSON does not allow inline comments. The visible annotation table explains the example without turning those explanations into unsupported properties.
Inspect platform support separately from vocabulary correctness.
Schema.org describes a broad set of things and relations. A search platform selects which data it consumes, which features it supports and which policies apply. An accepted vocabulary term can remain useful as a description without yielding a special search appearance. Never infer a display promise from a validator recognizing the type.
Use the current documentation for the specific feature and page purpose. Check required facts, recommended facts, access requirements and quality policies. A general vocabulary checker and a platform feature test answer different questions. A feature test may not report every Schema.org type; that alone does not make the entire graph meaningless. A clean technical test also does not establish factual truth.
Production review should inspect all output sources, including theme, plugins and rendered additions. Two individually readable blocks can disagree about the author or organization ID. Resolve the source conflict and reuse the accepted identity. More blocks do not compensate for contradictory facts.
Maintain the description after release.
Before release, review parsing, term selection, relationships, visible facts, URLs and current feature rules. Test the delivered page as well as a copied code fragment, because templates and serving conditions can change the final output. Do not mark a live test complete merely because the educational example parses.
After an authorized release, use the available platform inspection and reporting tools to check acquisition and errors. Keep the source record and assign a reviewer for changes to dates, authorship, publisher, URLs or page purpose. Recheck the description when the content changes, and remove stale optional fields while evidence is unresolved.
The structured data hub connects this foundation with property evidence and stable identity. Return to the semantic SEO learning overview when the page’s purpose or source ownership still needs work. Accurate structured data describes an accepted page; it does not repair an unclear or unsupported page by itself.