What is JSON-LD Validator and what does it validate?
A schema validator is also needed when the JSON appears valid. Code may be successfully processed as JSON but contain an inappropriate schema type, missing properties, or malformed data. Therefore, Schema.org validation must consider the entity structure, field values, and the consistency of the markup with the page content.
JSON-LD Validator checks structured data code and helps identify areas that may interfere with correct markup processing. Basic validation includes JSON syntax, @context, @type, schema properties, nested objects, and values. If the markup contains multiple entities, relationships via @id and the @graph structure are checked separately.
Schema validator is useful for Product, Organization, LocalBusiness, Article, BreadcrumbList, WebSite, WebPage, and other Schema.org types. The set of required and recommended properties depends on the specific entity. Therefore, the same set of fields cannot be used for all markup types.
JSON-LD syntax checker
Validation begins with syntax. JSON-LD is typically placed within <script type="application/ld+json">, and the contents must comply with JSON rules. Common JSON syntax errors include extra commas, incorrect quotes, unclosed parentheses, and incorrect nesting of arrays and objects.
An online schema checker should show where the error occurred so the developer doesn't have to manually reread the entire JSON-LD code. After fixing the error, the code is rechecked. A single missing character can disrupt the processing of the entire block, so it's best to perform syntax validation before migrating the markup to the live site.
Typical causes of error:
- An extra comma was left after the last property of the object, which prevents the JSON from being parsed correctly;
- Instead of regular double quotes, typographic symbols copied from a text editor are used;
- an array or object is closed with an incorrect parenthesis, thus breaking the structure of the nested data;
- The value was inserted without quotes where a string was expected, or the string contained incorrectly escaped characters.
After correcting the syntax, you need to proceed to checking the Schema.org markup itself. Valid JSON only confirms the technical correctness of the format and does not indicate the quality of the described entity.
How is a JSON error different from a Schema.org error?
A JSON error means that the code violates the rules of the format itself. For example, the parser can't process an object due to an extra comma or an unclosed parenthesis. A Schema.org error appears in otherwise valid JSON when an unknown @type, an inappropriate property, or a value of the wrong data type is used.
Therefore, the json ld checker must check both levels. First, the code must be successfully parsed as JSON, then schema validation is performed. This order helps to distinguish a technical document error from an error in the structured data markup logic and quickly identify the root cause of the problem.
Validating @context, @type, and Schema.org properties
@context specifies the vocabulary used to interpret JSON-LD markup properties. For Schema.org, the corresponding Schema.org context is typically used. The @type field specifies the entity the block describes: Product, Organization, Article, LocalBusiness, or another type.
After defining an entity, the JSON LD validator checks for properties acceptable for the selected type. For example, the data set for Product differs from Organization Schema or BreadcrumbList. Nested objects, URLs, dates, numeric values, and references between related entities must also be validated.
Errors and warnings – what's the difference?
An error typically indicates an error that must be corrected before validation is complete. This could be due to invalid syntax, a missing required value, or a structure that the validator cannot process correctly. Such validation errors are checked first.
A warning indicates a potential problem or missing recommended property. Validation warnings also require verification, but a warning doesn't always invalidate the entire JSON-LD. The decision depends on the Schema.org type, the purpose of the markup, and the search engine's requirements for a specific search feature.
What errors does JSON-LD Validator find?
The microdata validator helps find both simple syntax errors and issues with the Schema.org structure. Some errors arise from manual editing, while others are related to the CMS, templates, data import, or incorrect JSON-LD generation logic.
In practice, problems often recur. Therefore, it's worth checking not just one URL, but a page template and several different data samples: a product with a price, a product out of stock, an article with an author, a local page with a URL, and other variations that are actually used on the site.
| Error type | Example | What to check |
|---|---|---|
| JSON syntax | Extra comma or incorrect quotation mark | JSON structure |
| @context | The context is missing or incorrect. | Vocabulary used |
| @type | Unknown or inappropriate type | The type of entity being described |
| Property | The property does not match the selected type. | Schema.org documentation |
| Data type | The date, price, or URL is incorrect. | Value format |
| @id | The link leads to a missing entity | Relationships between entities |
| Duplicate schema | One entity is output multiple times | CMS, template, and SEO modules |
The table helps guide the direction of the check, but each error must be assessed in the context of the specific Schema.org type and the page content.
JSON syntax errors
Most syntax issues arise after manually editing code. A common situation is when a developer adds a new field and leaves an extra comma before the closing parenthesis. Another scenario is when JSON-LD is copied from a document where regular quotation marks were automatically replaced with typographic ones.
When generating markup via a CMS, errors can arise due to improper escaping of user data. For example, a title might contain quotation marks or special characters, and the template inserts the string without properly processing it. In this case, you need to check the generation logic rather than manually correcting each page.
Schema.org errors
A Schema.org error occurs when the syntax is correct, but the data structure is incorrect. This could include an inappropriate @type, a missing required property, incorrect nesting, or a property that doesn't belong to the selected entity.
The Schema markup validator helps detect such issues before publishing. After fixing them, it's recommended to check the Schema.org documentation and search engine requirements if the markup is being created for a specific rich result.
Date, price, and URL errors
The date must be passed in a suitable format, and the price must be a separate numeric value. The currency must be specified separately using the priceCurrency field. A string like "20,000 UAH" in the price field may lead to misinterpretation of the data.
URLs also need to be checked carefully. Stable absolute URLs are usually used for related entities. When transferring a domain, old links in@id, image or other properties may remain unnoticed, although the visible part of the page is already working at the new address.
@id and @graph errors
@id helps link multiple objects that describe a single page, organization, author, or other entity. If an @id reference points to an entity that isn't in the markup, the relationship becomes invalid. Such errors are common in complex @graphs.
When using @graph, it's best to stick to stable identifiers and avoid creating multiple independent versions of a single entity. For example, "Organization" shouldn't be randomly duplicated in each block with different names, URLs, or logos.
Duplicates and conflicting micro-markup
Duplicates occur when markup is created simultaneously by the CMS, SEO plugin, and additional template code. A single page may contain multiple Product or Organization blocks with different values. Technically, each block can pass separate validation, but the entire page contains conflicting data.
Therefore, Schema.org validation must include analysis of the entire page. If multiple descriptions of the same entity are found, the source of each block must be determined and a single, consistent version must be maintained, or the entities must be linked correctly.
I don't consider JSON-LD valid just because the parser doesn't show syntax errors. I separately check the Schema.org type, required properties, @id and @graph relationships, and whether the data matches what the user actually sees on the page. After making corrections, I re-check the published URL and, if the markup is intended for a rich Google result, I additionally run the Rich Results Test.
How to check JSON-LD online?
Validating JSON LD takes several steps. The code is inserted into the validator field, the analysis is run, and the results are examined. If the tool detects errors, they are corrected sequentially, starting with the syntax and basic structure, and then the validation is repeated.
After successfully checking the fragment itself, it's a good idea to check the published page. This helps you see the markup as it actually appears to the browser and search engine crawler after processing templates, CMS modules, and server-side rendering.
JSON-LD code verification
To validate, copy the JSON-LD from the template or page source code and run markup validation. First, fix any JSON syntax issues, then check @context, @type, entity properties, value types, and associated elements.
The work order looks like this:
- Paste the JSON-LD code into the validation field and run the validator.
- Correct syntax errors if found in the code.
- Check the schema type and property set for the selected entity.
- Check the markup values against the actual data on the page.
- Please re-run the scan after making changes.
After successful verification, do not save the result without verifying the implementation. The code in the editor and the JSON-LD that is actually displayed on the page may differ due to the template, CMS, or additional SEO module.
Validating JSON-LD by Page URL
Checking the published page URL is useful after implementing markup. It shows the structured data that actually exists in the page's HTML. This approach helps identify duplicates, outdated Schema.org blocks, and data added automatically by the CMS.
URL verification is especially useful after updating a site, migrating to a different CMS, or changing the overall template. If multiple modules simultaneously output Organization, Product, or other entities, manually checking a single source fragment may not reveal a conflict.
How to read the test result?
First, check the detected schema type and whether there are any critical errors. Then, check for messages about missing properties, invalid value formats, and problems with related entities. For large blocks, it's useful to parse the results one entity at a time.
After fixing one set of errors, the validation is run again. This makes it easier to identify remaining issues and avoid mixing old and new messages. If JSON-LD is used for Google's rich results, the page is further validated using the Google Rich Results Test after the schema markup validator.
What we actually did
Dental clinic · Kyiv and Chernihiv
+44% clicks from search
A domain with no history on a website builder. We built the semantic core for both cities, reworked the landing pages and built the link profile from zero. Four months: 34.8k clicks, impressions 1.32 → 1.76M, DR 0 → 41.
E-commerce · international
+96% clicks in two months
A catalog of digital 3D models. We clustered the semantics, rebuilt the hub pages and closed duplicates and indexing errors. Google users 247 → 532, CTR 2.4% → 4%.
Medical center · Ukraine
+68.75% visibility in the first month
Narrow visibility and a small semantic core at the start. Semantics, landing page structure, metadata and internal linking, then gradual link building.
Answers to your questions
What does JSON-LD Validator check?
JSON-LD Validator checks JSON syntax, @context, @type, Schema.org properties, nested object structure, and related entities. Depending on the tool, the validation may also show missing properties, warnings, and value format errors.
After technical validation, it's advisable to compare the markup with the visible page content. The validator cannot replace the actual data the CMS transfers in JSON-LD.
How to check JSON-LD online?
Copy the JSON-LD code from a page or template and paste it into the validation field. After running, correct any syntax errors, then check the Schema.org types, properties, and values.
After making corrections, rerun the check and test the published URL. This approach helps you spot changes that only appear after the page is processed by the CMS or server-side template.
Why is JSON-LD valid, but rich results are not appearing?
A valid Schema.org does not guarantee a rich result. Google applies specific requirements to supported structured data types and independently decides which type of result to display in search results.
You need to check the data's relevance to the page, the requirements for a specific type, the URL indexing, and the markup status in Google Search Console. After changing the code, you also need to re-crawl the page.
How is Schema Markup Validator different from Google Rich Results Test?
The Schema Markup Validator is used for general validation of the Schema.org structure. It helps analyze the types, properties, and technical correctness of markup, independent of any specific Google feature.
Google Rich Results Test checks markup against supported Google rich results. Therefore, it's best to use these tools consistently during SEO testing.
What are the most common errors in JSON-LD?
The most common errors are extra commas, incorrect quotes, missing @context, incorrect @type, incorrect price or date format, and incorrect relationships. @id and duplicates of entities.
On CMS-based sites, there are also outdated values that continue to be displayed in structured data after visible content changes. These issues are easily visible when inspecting the live URL.
Is it possible to validate multiple Schema.org types on one page?
Yes, a single page can contain multiple related entities. For example, a WebPage might be related to an Organization, a BreadcrumbList, and an Article. For complex structures, @graph is often used.
Moreover, the entities must be logically related and not contradict each other. If one object is repeated multiple times with different values, the source of each block must be checked.
Do I need to recheck the markup after correction?
Yes, because a single edit can change an adjacent part of the JSON-LD or the structure of a nested object. After making the edit, you need to run the validator again to ensure that old errors have been removed and no new ones have appeared.
After publishing, it's worth checking the working URL. This helps ensure that the corrected code has reached production and hasn't been modified by a template or cache.
Does JSON-LD Validator replace Google's validation?
No. The general JSON-LD check and Google tests accomplish different tasks. They first check the syntax and Schema.org markup, then run the Google Rich Results Test if necessary.
For an already indexed site, data is additionally monitored in Google Search Console. This procedure helps separate technical validation from search engine requirements for a specific result type.
Related services
FAQ Schema Generator
The FAQ Schema generator creates valid FAQPage JSON-LD markup. Add questions and answers, copy the code, and validate it online at Schema.org.
Organization Schema Generator
Free Organization Schema Generator: Create JSON-LD markup for your company, add your name, logo, address, contact information, and sameAs, copy the code, and validate it.
BreadcrumbList Schema Generator
Breadcrumb Schema Generator for creating JSON-LD markup for BreadcrumbList. Add names and URLs, get the finished code, and validate it for Google.
Article Schema Generator
Free Article Schema Generator: Generate JSON-LD for Article, BlogPosting, and NewsArticle, copy the code, and validate the markup before publishing.
Product Schema Generator
Online Product Schema Generator: create JSON-LD microdata for your product with price, availability, brand, rating, and offer information. Copy the code and test it before publishing.
JSON-LD Validator helps check syntax, Schema.org markup, entity properties, and relationships between them before publishing a page. After correcting the code, you should re-check the working URL and ensure that the data matches the site content.
Paste the JSON-LD into the validator, run the check, and fix any errors before publishing. For markup intended for Google's rich results, additionally check the page using the Rich Results Test.
We reply within one business day. No newsletters, no “just a reminder” calls.
He will look at the site himself instead of passing it to a manager.
More on: JSON-LD Validator – Schema.org validation
What Schema.org types can be validated?
The JSON-LD Validator is used for various Schema.org markup types. Common options include Organization, LocalBusiness, Product, Article, BlogPosting, BreadcrumbList, WebSite, WebPage, Service, and VideoObject. The specific set of supported checks depends on the validator used.
Each entity requires its own data set. The Product Schema handles the product, offer, price, and availability, while the Organization Schema describes the company. LocalBusiness can also contain the address and other local business data. Article and BlogPosting require a different structure.
There's no need to add a schema type just for the sake of having microdata. The type should correspond to the actual page content, and the values in JSON-LD should correspond to user-accessible information.
JSON-LD Validator and Google Rich Results Test – What's the Difference?
Schema Markup Validator and Google Rich Results Test serve different purposes. The general schema validator checks the Schema.org structure and helps find technical errors in markup. Google Rich Results Test focuses on the structured data types Google uses for supported rich results.
Therefore, a valid result from standard validation does not automatically result in a rich snippet appearing. The page must also meet Google's requirements for the specific result type, and the search engine itself decides whether to show the rich view or the standard snippet.
When to use Schema Markup Validator?
Schema Markup Validator is suitable for general structured data testing. It conveniently validates the types, properties, syntax, and structure of JSON-LD, regardless of whether Google supports rich results for a particular entity.
This type of check is convenient to perform during development, after template changes, or during a technical SEO audit. It helps identify issues in the data model itself before moving on to search engine-specific checks.
When to use Google Rich Results Test?
Google Rich Results Test is used when creating markup for a Google-supported rich result. It's recommended to run the test before publishing, after fixing errors, and again on the live URL after implementation.
The test results should be evaluated alongside the page content. Even technically appropriate markup should not contain information that is not present on the page itself or that is inconsistent with the visible data.
Can JSON-LD be valid but not produce a rich result?
Yes. Valid Schema.org markup confirms the correctness of the structure, but it does not guarantee that a rich result will be displayed. This may be due to an unsupported type, insufficient data for a specific search feature, or a mismatch between the JSON-LD and the page content.
Page indexing and Google's decision on a specific search result also affect how the page is displayed. Therefore, after correcting structured data, it's a good idea to check Google Search Console and wait for the search engine robot to crawl the page again.
When should you validate JSON-LD?
It's best to check structured data after every change that could affect HTML, page templates, or Schema.org data. This includes CMS updates, SEO modules, product templates, site migrations, and bulk content uploads.
Particular attention should be paid to changes that are automatically applied to hundreds of URLs. An error in one template can immediately affect an entire section of the site.
Verification is required in the following cases:
- after the first implementation of JSON-LD and before publishing a new template;
- after updating the CMS, theme or SEO module that generates structured data;
- after moving a website, changing the domain or URL structure;
- after a mass update of prices, availability, ratings and other data;
- after structured data errors appear in Google Search Console;
- after changes to the common component that Schema.org generates for different pages.
After creating the list, it's worth testing several pages with different data sets. A single successfully tested URL doesn't guarantee that the template will work correctly for all possible content variations.
What else should I check besides JSON-LD validity?
Technically correct code should be compared with the page itself. The title, price, address, image, author, and other values in the JSON-LD must match the actual data. Fields that update automatically are checked especially carefully.
It's also helpful to ensure the page is indexable, returns the correct HTTP status, has a valid canonical, and isn't closed by meta robots. An indexing error isn't related to JSON-LD, but it can render further work with structured data pointless.
Does the micro-markup match the page content?
The markup must describe what is actually on the page. You cannot include a non-existent rating, a different price, a different product name, or information about the organization that the user cannot confirm based on the site's content.
Discrepancies especially often arise after data changes in the CMS. The visible portion of the page is updated, but a separate JSON-LD block continues to receive the old value from another field or the cache.
Are there multiple descriptions of the same entity?
Multiple JSON-LD blocks on a page are acceptable when they describe different related entities. Problems arise when a single Organization, Product, or AggregateRating is repeated multiple times and contains different values.
If this happens, you should check your CMS, plugins, and template. If the markup is generated automatically, it's often better to remove the manual additional block than to maintain two independent versions of the same entity.
Does the search engine see the page correctly?
After markup validation, check the URL for search engine crawlability, meta robots, canonical, and server response status. Then, ensure that JSON-LD is present in the resulting HTML and isn't missing due to a rendering error.
If the page is already indexed, the state of structured data can be further monitored through Google Search Console. This approach helps distinguish a microdata error from a general technical issue with the URL.
What to do after fixing JSON-LD?
After correcting the code, you need to re-run the JSON-LD validator. Then, check the working page URL to ensure that the edit was actually included in the final HTML, and that the old version wasn't left in the cache or another template.
The further order depends on the purpose of the markup:
- Please re-validate JSON-LD after fixing the error.
- Open the live URL and verify that the new version of the markup has already been published.
- Compare Schema.org data with the visible content of the page.
- Check Google-supported markup using Rich Results Test.
- After re-crawling the page, check the status in Google Search Console.
After checking, it's a good idea to save the cause of the error and the corrective action in the project's technical documentation. This is especially useful for common issues that may recur after the next CMS update.
Check priority
| Verification stage | Priority |
|---|---|
| JSON syntax | 100% |
| @context and @type | 100% |
| Schema properties | 90% |
| @id and @graph | 80% |
| Page Matching | 100% |
| Rich Results Test | 70% |
| Google Search Console | 70% |
First, you need to fix any errors that prevent the code from being parsed correctly, then move on to the Schema.org structure and factual data verification. Rich Results Test and Search Console are used after a basic technical review.