How to check the presence and correctness of micro-markup on your website

Micro-markup is one of those technical elements that are invisible to the user but are critical for SEO. It helps search engines to «understand» the content of a page: whether it is a product, article, event, or review. It is thanks to that a website can get extended snippets in search results – with ratings, prices, photos, or additional links.

For businesses, this means more visibility, clicks, and brand trust. But even properly implemented microdata can work incorrectly due to syntax errors, template conflicts, or outdated data types. Therefore, regular checking of its availability and validity is a necessary part of a technical SEO audit.

In this article, we’ll look at how to check for the presence and correctness of microdata on your website, which tools to use, which format to choose, and how to interpret the results of the check.

How to check for microdata

Before checking the correctness of microdata, you need to make sure that it is present on the page at all. You can do this without any special tools – directly through your browser.

1. Open the desired page of the site. To do this, simply go to any page where you think the markup should be structured: for example, a product card, blog post, or testimonial page.
2. Check the source code of the page. In most browsers, press Ctrl+U or right-click → View page source. Alternatively, open DevTools by pressing F12.
3. Find the fragments with micro-markup.

For JSON-LD formats, look for the tag:

This is the most common version of micro-markup and usually contains a block of structured data in JSON format.

If you are using Microdata or RDFa, look for the itemscope, itemtype, itemprop attributes in the HTML elements. For example:

4. Assess the presence and number of blocks.

If none of the above fragments are present, it means that the page does not have microdata markup. In this case, you need to check the site templates or CMS – perhaps the markup was not added during development.

If there is a block, copy it in its entirety – from the opening to the closing <script> tag or the corresponding HTML structure. You will need this fragment for further validation using special tools.

5. Make sure the data matches the page content.

Even if the markup is present, it is important to check that the information provided (product name, price, rating, date of publication) matches what the user sees. Discrepancies can lead to the rejection of structured data by the search engine.

Quick syntax validation: local JSON checker

After copying a JSON-LD block from a page, you should check its syntax. After all, even one mistake in the format will make the markup unsuitable for search engines.

1. Paste the code between the <script type=«application/ld+json»> tags into an online JSON checker (for example, jsonlint.com) or use an editor with syntax highlighting (VS Code, Sublime).
2. Make sure there are no errors in the structure. Extra or missing commas, incorrect quotes, unclosed brackets.
3. If there are any errors, correct them and repeat the check until the validator confirms that the code is correct.

This step helps you quickly verify that the JSON-LD format is correct before moving on to deeper validation using Google or Schema.org tools.

Validate conformance to Schema.org

After making sure that the microdata syntax is correct, the next step is to check whether the data structure complies with Schema.org standards. This is necessary so that search engines can correctly interpret each type of object.

1. Open the official Schema.org validator – validator.schema.org. In this tool, you can paste the URL of the page or a snippet of JSON-LD code if you are checking it locally.
2. Run the validation. The validator will analyze the code and display the results in the form of a tree of structured elements – for example, Article, Product, Organization, etc.
3. Review the warnings and error messages. Pay special attention to:

• • unknown types – when the specified object does not exist in the Schema.org vocabulary;
  • undefined or deprecated properties – properties that are no longer supported or have a different name;
  • missing required fields – for example, name, image, price for the Product type.

4. Read the validator’s recommendations. The tool often suggests which properties should be added to make the markup more complete (for example, brand or aggregateRating for products).
5. Fix inconsistencies in templates. Go to the page template or CMS, make changes to the microdata code, save the page, and repeat the validation.

This validation ensures that the data structure complies with the official Schema.org standards and that search engines can interpret it correctly.

Validation in Google services

After checking for compliance with Schema.org standards, it is important to test the microdata using Google tools.

1. Open one of the official Google tools:

• • Rich Results Test – checks whether the page can display rich results (rating stars, prices, breadcrumbs, FAQ, etc.).
  • URL Inspection Tool in Google Search Console – shows how Google sees the page, including the recognized types of structured data.

2. Enter the page address or paste the code. Both services allow you to test both the public URL and a separate JSON-LD fragment if you haven’t posted it on your site yet.
3. Run the test and see the results. The report displays:

• • types of structured data recognized by Google;
  • Success, warning, or error status;
  • details of each error, explaining why the element cannot be used in search results.

4. Pay attention to warnings. Warnings do not block the display of advanced results, but indicate that the data is incomplete. For example, an image or description is missing. Adding them will improve the quality and completeness of the markup.
5. Make changes and retest. After correcting templates or tags, check the page again until all errors disappear.

Google validation is the final stage of the check. It shows how ready the markup is for indexing and whether it meets the requirements for displaying in the advanced search results, which directly affects the CTR and visibility of the site.

What is the difference between validators and which one to choose?

Each tool for checking microdata has its own purpose, and the best result is achieved by using them in combination. Here’s a brief overview:

How to decipher the results of microdata validation

Validation results in validators may look complicated, but the key is to interpret statuses and messages correctly.

1. Errors are critical issues that cause the markup to be unreadable by search engines. For example, the mandatory name field in the Product type is missing or the date format is incorrect. Such errors must be corrected first, otherwise the rich snippet will not appear in the search results.
2. Warnings – do not block the display of structured data, but signal incompleteness. For example, an image, brand, or description is missing. It is worth eliminating these comments to make the markup more informative and increase the chance of getting a better result.
3. Info messages are system prompts that explain how the code is interpreted. They help you understand whether the tool recognized the correct type of object and properties.
4. Google support status. If you are testing a page in Rich Results Test, pay attention to whether the markup type is marked as «Google supported». Some types, such as Event or FAQ, are used in search, while others only help algorithms better understand the content but do not affect the appearance of the snippet.
5. Check data consistency. It is important that structured data matches the content of the page. If the code contains a price or description that is not visually present, Google may reject such data as manipulative.

And remember: correct microdata is not a one-time action, but a process. Systematic checks at the development stage, after release, and as part of regular audits will ensure consistent visibility and convenient analysis of the effectiveness of enhanced search results.

Oleksandr Shmidko

SEO Specialist

Author's page