The structural data describe the importance of the content in a machine-readable format. It is not a way to add information that the user does not see or guarantee a special result. A good implementation organizes the company's identity, page type and relationship between materials.
Select the right page type first
The home page usually connects WebSite and Organization. Service subpage can use Service, guide entry with Article, contact ContactPage, and navigation with BreadcrumbList. The type should correspond to the dominant function of a particular address.
It is not worth placing all possible types on each subpage. Excess is difficult to maintain and increases the risk of contradictions.
Organization as a coherent identity
The organization should have a permanent @id ID and real data: name, page address, logo, phone and e-mail if public. Other graph elements can refer to the same identifier as the author, publisher or service provider.
The data must match the visible foot, contact and information about the company. The schema is not a place for hidden keywords.
Article and Editorial Information
The article is worth describing with a header, address, image, date of publication and modification, author and publisher. On the page the user should see the author and date. The update of the tag makes sense when the material has actually been corrected.
The image should be available at a stable address and represent the content. Reproduction of one accidental photo in all articles lowers the quality of the entire library.
Validation and monitoring
After the code is implemented, we test the Schema.org validator and Google tool for results with extended elements if the type supports them. We also check the code generated on the user side, not only the template.
Changes in search engine requirements are natural, so structural data should be part of the maintained system rather than a one-time addition.
How we implement this in BxM
The SEO layer stores the page type, canonical, indexing, Open Graph data and JSON-LD extension. The template generates the base graph, and the editor can manage metadata without editing the code.
The most important is the compatibility of three layers: visible content, metadata and structural data.
Checklist
- Assign Schema.org type in accordance with the address function.
- Use one organization identifier in the entire graph.
- Show the author's details and article updates on the website.
- Do not signify opinions, FAQs or services that are not included in the content.
- Validate the code after any major template change.
Distinguish the data dictionary and search engine function
Just because Schema.org describes a specific object type, does not mean Google offers a separate extended result for it. The dictionary validator and the tool checking supported presentations answer different questions. The lack of a given type in the extended result test does not necessarily imply an entire graph syntax error.
Google Principles for Structural Data The correct test result does not guarantee that an additional item is displayed in the search engine. In the collection report it is worth to clearly separate these issues.
Check data after normal content changes
The editor can improve the service name, article date or photo, while separately saved JSON-LD section will keep the old value. It is best to limit such double entry. Where necessary, the publication control should include a comparison of both versions.
- Change the title of the test article and check its description in the data.
- Verify image addresses after moving files.
- Make sure the author and publisher are not accidentally switched.
- Check that the redirected address has not remained the main address of the object.
Try the generated page. Watching the template itself will not show errors resulting from an empty field or unexpected value entered by the user of the panel.
Update performance promises
Support for presentations in Google changes independently of the Schema.org dictionary itself. An example is FAQ: Google has reported the withdrawal of this function and the deletion of documentation in updates from 2026. Leaving questions on the website may make sense, but their usefulness does not depend on the former extension of the results.
When reviewing the service, check also the SEO service descriptions, documentation for editors and the list of reception tests. They should not promise a function that the search engine no longer provides. It is better to maintain a smaller, compatible and understandable set of data than an extended graph filled with outdated information.
The most common questions
Is Schema.org improving the position?
It is not a direct position guarantee. It helps the search engine understand the content and can allow specific presentations.
Is JSON-LD better than microdata?
Google usually recommends JSON-LD due to easier implementation and maintenance.
Is FAQPage worth adding anywhere?
No. Questions and Answers may continue to help the reader, but Google withdrew the extended FAQ results. Do not promise such a presentation after adding the FAQPage.
Related BxM guides
