Structured data tells search engines what your content means — not just what the words say, but whether a page is a product, an article, a recipe, or an FAQ. Get it right and Google surfaces your content as rich results: star ratings, FAQ accordions, breadcrumb trails, and How-to carousels. Get it wrong and the markup is silently ignored. This guide covers every method for checking structured data on any website, from view-source inspection to automated CI validation.
What is structured data?
Structured data is machine-readable metadata embedded in a web page that helps search engines understand the content beyond the visible text. The dominant format is JSON-LD — a JavaScript Object Notation script tag placed in the `<head>` of a page, using vocabulary from schema.org to describe entities like articles, products, events, recipes, and organisations.
When a search engine crawls a page, it extracts these schema blocks and uses them to generate rich results: enhanced search listings that show star ratings, price ranges, event dates, FAQ accordions, and breadcrumb navigation directly in the SERP. Rich results consistently achieve higher click-through rates than standard blue-link listings because they convey more information at a glance.
The three structured data formats
- JSON-LD: A standalone `<script type="application/ld+json">` tag containing a JSON object. Google recommends this format — easiest to add, validate, and maintain without touching the page HTML.
- Microdata: Schema attributes (`itemscope`, `itemtype`, `itemprop`) added directly to HTML elements. Tightly coupled to the page structure — harder to validate and update.
- RDFa: Linked Data attributes (`typeof`, `property`) added to HTML elements. Widely used in some CMS platforms but less common than JSON-LD for new implementations.
Note
How to check structured data
There are four practical methods for checking structured data on a page, each suited to different situations. The fastest methods require no tools at all; the most thorough require a validator and Google's own testing environment.
Method 1: View page source
Right-click any page in a browser and select View Page Source (Ctrl+U / Cmd+U). Press Ctrl+F to open find, and search for `application/ld+json`. Each result is a structured data block. This tells you immediately whether structured data exists on the page and lets you copy the JSON for validation. For pages that render content via JavaScript, view-source shows the initial HTML only — use DevTools for rendered output.
Method 2: Browser DevTools Elements panel
Open Chrome DevTools (F12), go to the Elements tab, and search for `ld+json` in the element tree. This shows the structured data as the browser currently renders it — including any blocks injected by JavaScript after page load. This is the correct approach for React, Next.js, or any framework that adds structured data client-side or via server-side rendering.
Method 3: Structured Data Validator (fastest for development)
Copy a JSON-LD block and paste it into the Structured Data Validator. It validates the JSON syntax, checks `@context` and `@type` declarations, and flags missing required properties for the declared schema type — all in your browser without submitting a URL or waiting for a crawl. This is the fastest loop during development because you can fix and re-validate in seconds.
Method 4: Google's Rich Results Test
Submit your live page URL to Google's Rich Results Test at `search.google.com/test/rich-results`. Google fetches the page, extracts all structured data, and reports which rich result types the page qualifies for. This is the authoritative test for rich result eligibility — but it requires a live URL and takes 5–30 seconds per test. Use it after local validation is clean.
Structured Data Validator
Validate any JSON-LD structured data block for syntax, required properties, and schema.org compliance — browser-local, no URL needed.
Validating JSON-LD markup
JSON-LD validation has two distinct layers: syntax validation (is the JSON structurally valid?) and schema validation (does the content conform to the schema.org type's required and recommended properties?). Both layers need to pass before a structured data block is useful.
Inspect the page for JSON-LD blocks
Right-click the page and select View Page Source. Search for `application/ld+json`. Copy the entire JSON object from inside the script tag — from the opening brace to the closing brace. If there are multiple blocks, copy each one separately for validation.
Validate syntax with the JSON-LD Validator
Paste the copied block into the JSON-LD Validator. It checks that the JSON is well-formed, that `@context` is set to `https://schema.org`, and that `@type` references a recognised schema.org type. Syntax errors are reported with line numbers; unknown type warnings identify schema types that are unlikely to produce rich results.
Check required properties for the declared type
Each schema type has required and recommended properties. A `Product` schema requires `name` and either `offers` or `review` for rich result eligibility. An `Article` requires `headline`, `author`, and `datePublished`. The Structured Data Validator checks the declared `@type` and flags every required property that is missing or incorrectly formatted.
Test rich result eligibility with Google's tool
Once local validation is clean, submit the page URL to Google's Rich Results Test. Review the list of detected schema types and confirm each one shows as eligible rather than flagged with errors. Address any "Recommended" warnings for properties that improve the quality of rich results even though they do not block them.
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "How to Check Structured Data on a Website",
"author": {
"@type": "Person",
"name": "Devvrat Hans",
"url": "https://quasartools.com"
},
"datePublished": "2026-06-11",
"dateModified": "2026-06-11",
"publisher": {
"@type": "Organization",
"name": "Quasar Tools",
"url": "https://quasartools.com"
}
}Tip
Common structured data errors
Most structured data errors fall into predictable categories. Knowing what each error type means — and why it matters — lets you fix issues in the right order: syntax first, required properties second, recommended enhancements last.
Missing required properties
Google defines required properties for each schema type that supports rich results. If any required property is absent, the entire schema is ineligible for its rich result feature. Common examples: `Product` without `name` or `offers`, `Recipe` without `name` or `recipeIngredient`, `Event` without `name`, `startDate`, or `location`. The Product Schema Completeness Checker specifically audits Product schemas for all required and recommended Google fields.
Incorrect value types
Schema.org properties expect specific value types. `url` properties must be absolute URLs beginning with `https://`; `ratingValue` must be a number (not a string like `"4.5"`); `datePublished` must be a valid ISO 8601 date string. Passing a string where a number is expected, or a relative path where an absolute URL is required, causes a type mismatch error that blocks the schema from being read correctly.
Mismatched schema type and page content
Google requires that structured data accurately reflects the visible page content. Placing `FAQPage` markup on a page that does not visibly show FAQ questions and answers, or adding `Product` markup to a category page with no specific product details, violates Google's structured data guidelines and can result in manual actions against rich result eligibility.
| Error type | Example | Impact | How to fix |
|---|---|---|---|
| Missing required property | Product without name | Blocks rich result | Add the property |
| Wrong value type | ratingValue: "4.5" (string) | Schema ignored | Use a number: 4.5 |
| Relative URL in url field | image: /photo.jpg | Validation error | Use absolute HTTPS URL |
| Invalid date format | datePublished: "June 2026" | Date not parsed | Use YYYY-MM-DD format |
| Unknown @type | @type: "BlogPosting2" | Schema not recognized | Use exact schema.org type |
| Missing @context | No @context declaration | Schema not extracted | Add schema.org context |
| Content mismatch | FAQPage on non-FAQ page | Manual action risk | Match schema to content |
Warning
Checking by schema type
Different schema types have different required properties, different rich result presentations, and different validation tools best suited to them. Here is how to approach the most commonly used types.
FAQPage and HowTo
FAQPage is one of the most impactful schema types for organic CTR — a valid FAQPage schema renders as an expandable accordion directly in Google Search results, showing questions and answers without a click. Use the FAQ Schema Generator to produce clean FAQPage markup from plain Q&A pairs, then validate the output with the JSON-LD Validator. For step-by-step instructional content, the HowTo Schema Generator builds valid HowTo markup with properly structured `HowToStep` blocks.
BreadcrumbList
BreadcrumbList markup generates the breadcrumb trail shown beneath the page title in Google Search results — replacing the raw URL with a readable hierarchy. Each `ListItem` requires a `name` and an `item` URL. Use the Breadcrumb Schema Generator to generate BreadcrumbList JSON-LD from a URL path or manual entries, ready to drop directly into your page template.
Organization and Article
Organization schema establishes your site's identity for Google's knowledge graph — name, logo, contact information, and social profiles. The Organization Schema Validator checks that all recommended fields are present and correctly formatted. For editorial content, Article schema with `author`, `datePublished`, and `publisher` increases eligibility for Google News, Top Stories, and Discover, which can drive significant traffic to news and blog pages.
Review and aggregate ratings
Star ratings in search results come from `AggregateRating` nested inside a `Product`, `LocalBusiness`, or `Recipe` schema. The `ratingValue` must be a number, `reviewCount` must be a positive integer, and both `bestRating` and `worstRating` must be specified to avoid ambiguity. The Review Snippet Eligibility Checker validates rating markup against Google's specific requirements for review rich results.
| Schema type | Rich result | Key required fields | Quasar Tools checker |
|---|---|---|---|
| FAQPage | FAQ accordion in SERP | mainEntity with Q&A | FAQ Schema Generator |
| HowTo | Step carousel in SERP | name, step, text | HowTo Schema Generator |
| BreadcrumbList | Breadcrumb trail in SERP | itemListElement, name, item | Breadcrumb Schema Generator |
| Product | Product panel with price/rating | name, offers or review | Product Schema Completeness Checker |
| Article | Top Stories, Discover | headline, author, datePublished | JSON-LD Validator |
| Organization | Knowledge Panel | name, url, logo | Organization Schema Validator |
| LocalBusiness | Local pack, maps | name, address, telephone | Structured Data Validator |
Structured data in CI/CD
Manual structured data checks work for individual pages, but large sites with templates generating structured data programmatically need automated validation. Adding a structured data check to your CI/CD pipeline catches regressions before they reach production and block rich result eligibility.
Extracting and validating in build pipelines
The most reliable approach is to extract JSON-LD from your built HTML output and validate it programmatically. After a build, parse the generated HTML files, extract every `<script type="application/ld+json">` block, and run each through a schema.org validation library like `schema-dts` (TypeScript), `jsonld` (Node.js), or Google's Structured Data Linter. Fail the build if any required property is missing or if the JSON is malformed.
# Extract all JSON-LD blocks from built HTML using grep
grep -rl 'application/ld+json' ./out/ | while read file; do
# Parse and validate each block
node scripts/validate-schema.js "$file"
done
# Or use a dedicated CLI tool
npx schema-validator ./out/**/*.html --strictSERP feature monitoring
After deployment, monitor rich result performance in Google Search Console under the "Enhancements" section. Each schema type you have implemented gets its own report showing valid items, warnings, and errors as Googlebot crawls your pages. A sudden spike in errors usually indicates a template change that broke the schema for a whole category of pages. The SERP Features Checker provides a complementary view — checking which SERP features a specific URL currently triggers.
Tip
Best practices
Following these practices ensures your structured data is correct, maintainable, and aligned with Google's guidelines — maximising rich result eligibility without risking manual actions or silent schema failures.
Keep structured data in sync with visible content
The most common source of Google manual actions against structured data is a mismatch between the schema and what users see. If your `Product` schema shows a price of $29 but the page displays $49, Google treats it as deceptive markup. Use your CMS or templating system to generate structured data from the same data source that populates the visible page content — never hardcode values in schema that are displayed dynamically elsewhere.
Use specific types, not generic ones
Schema.org has a deep type hierarchy. A page about a software product should use `SoftwareApplication`, not the generic `Product`. A local restaurant should use `Restaurant` (a subtype of `FoodEstablishment`), not the generic `LocalBusiness`. More specific types give search engines more signal about the content and can unlock richer presentation formats in search results.
Structured data must not be used to deceive users or provide misleading information. The structured data on a page must accurately represent the content of the page.
- Validate before deploying: Run the Structured Data Validator on every schema block before it goes live — catch errors before Googlebot does.
- One entity per block: Nest related entities (e.g. `author` inside `Article`) rather than creating separate top-level blocks for every sub-entity.
- Use absolute URLs everywhere: `url`, `image`, `logo`, and `sameAs` fields all require full `https://` URLs — relative paths are invalid in structured data.
- Include sameAs for organisations: Link your Organization schema to Wikipedia, Wikidata, LinkedIn, and other authoritative sources to strengthen knowledge graph association.
- Monitor Google Search Console: Check the Enhancements reports weekly — they show which pages have valid, warning, or error structured data as Googlebot crawls them.
Note
Key takeaways
- Check for structured data by searching the page source for `application/ld+json` — every script tag with that type is a structured data block.
- Use the Structured Data Validator during development for instant, browser-local JSON-LD validation with no URL submission required.
- Google's Rich Results Test is the authoritative tool for rich result eligibility — run it after local validation is clean, not instead of it.
- The most common errors are missing required properties, incorrect value types (strings where numbers are expected), and relative URLs where absolute HTTPS URLs are required.
- Generate correct schema markup for FAQPage, HowTo, BreadcrumbList, and Product types using the dedicated Quasar Tools generators and validators.
- Structured data must match visible page content — mismatches between schema values and displayed values risk Google manual actions against rich result eligibility.
- Monitor the Enhancements section in Google Search Console after deployment to track valid items, warnings, and errors as Googlebot crawls your pages.