5
min read
Structured data describes entities on a page, such as an article, product, organisation or breadcrumb trail, giving systems a more explicit form of information.
It does not replace visible text or guarantee special search presentation. Its purpose is to describe what is genuinely present on the website.
Schema.org and JSON-LD
Schema.org is a vocabulary of types and properties. JSON-LD is one method of expressing structured data in page code.
Not every JSON fragment is structured markup. It must use appropriate definitions and describe the entity correctly.
Accuracy matters more than line count: what the page is, which information is available and which types the intended system supports.
Potentially useful types
Articles
Use Article or a suitable subtype for a publication. Provide the genuine title, author, image and dates.
Do not give an old article today's publication date to make it look new. Modification dates should reflect real edits.
Breadcrumbs
BreadcrumbList describes a structural path. It should reflect the website's logic and use working URLs.
Avoid arbitrary keywords that do not represent sections. Navigation should remain meaningful to people.
Organisations and people
Describe an organisation when the entity is actually an organisation. Person may be more accurate for an independent professional in the relevant context.
Do not invent a legal name, office, contact or identifier. Match real ownership and published information.
Products
Product markup needs a current offer. Price, availability and other details must match visible content and real terms.
Do not fabricate ratings to obtain attractive stars. Reviews and ratings need a basis and must meet the relevant presentation rules.
Where to begin
Check existing platform or template markup first. Duplicate descriptions of the same entity may conflict.
Choose a specific goal, such as describing articles or breadcrumbs. Do not add every type from a generator.
List source data: title, author, main URL, image and actual dates. Assign responsibility for updates.
Validating the result
Syntax and vocabulary
Check syntax and allowed properties. The Schema.org validator examines structure, but passing it does not prove eligibility for a search engine's rich result.
Search-engine requirements
Check current documentation for the chosen type. Google Rich Results Test evaluates supported search features rather than every Schema.org type.
For Yandex, use its current validation tools and Webmaster documentation. Do not assume one engine's rules apply to another.
The published page
Open the public URL after implementation. Confirm the code is present and matches the content.
For automatic data, test several pages rather than a single demo. Missing authors or outdated prices may occur only in certain items.
Setting realistic expectations
Supported types and rich results change. An FAQ section does not guarantee an FAQ search feature.
Do not promise rankings or click-through growth from adding markup alone. Establish accuracy, then monitor outcomes.
Rich presentation depends on the system's rules and display decisions as well as error-free markup.
Checklist
- The type fits the page.
- Existing automatic markup has been reviewed.
- Visible content supports the data.
- Main URLs and images are accessible.
- There are no invented ratings or dates.
- Relevant validation passes.
- The published version is checked.
- A data-update process exists.
Frequently asked questions
Can I paste a template from another website?
Do not copy its data and structure without checking. A valid example may describe another entity or an unsupported use.
Must markup be added manually?
Not always. The platform may already generate it. Add manual data only after checking.
Getting started
We can review current data, select appropriate pages, prepare markup using real information and verify the public result without promising automatic rich results.
