Structured Data Checker

Screpy's Structured Data Checker inspects JSON-LD from a public page or pasted code. It identifies parsing errors, lists declared entities and flags selected property issues for five supported schema types. Use the report to decide what needs correction and what needs a broader check. Valid syntax, supported checks and eligibility for a Google rich result are separate questions; a green status here does not answer all three.

Choose a page URL or pasted JSON-LD

Select Page URL to inspect a published page, such as a product detail page or a business contact page. Enter that page's public HTTP or HTTPS address rather than the homepage by default: different templates can contain different markup. URL mode reads the HTML returned by the page. A private or password-protected page cannot provide the same public evidence, and a fetch failure is not proof that its structured data is broken.

Select Paste code to review a draft, an extracted script or HTML you already have. Choose JSON-LD for the JSON itself, without a surrounding <script> element. Choose HTML when your input contains <script type="application/ld+json"> blocks. A standalone JSON file's address is not an HTML page; paste its contents in JSON-LD mode instead. Pasted input is limited to 256 KiB measured as UTF-8 bytes, so the allowed character count depends on the text.

URL checks do not execute JavaScript. Markup inserted after the page loads may be absent from the fetched source. Google can process dynamically injected JSON-LD, so a missing block in this report does not prove Google sees none. Inspect the relevant rendered markup or use Google's feature test when that distinction matters. Pasting code checks what you supplied; it does not establish what the live page serves.

Read the structured data report

Start with coverage, then read the findings and entity table. JSON-LD blocks counts the scripts detected in HTML; pasted JSON-LD is treated as one block. Entities counts retained typed objects whose JSON parsed successfully; one script can contain several entities. Syntax errors counts processed blocks that could not be parsed. These are different quantities, so a page with three blocks need not have three entities. A partial report's detected block count does not prove that every block was examined.

Each row separates Syntax from Scope. Green valid syntax means the JSON parser accepted the block. Green supported checks means the entity qualified for this tool's selected property checks. Read its findings too: neither label establishes that every property is correct. Red identifies parsing errors or error findings, amber highlights warnings and partial coverage, and gray marks unsupported or unavailable evidence. Use the written status alongside the color.

The Path column helps locate nested objects. For example, $.author points to an author's object inside the root, while $.@graph[1] points to the second object in an @graph array. Paths are relative to their JSON-LD block, so the same path may occur in several scripts; the downloaded JSON includes block numbers to distinguish them.

The Name column reads name, not every type's display property. An Article with a valid headline can therefore have an empty Name cell. Inspect the relevant property and finding before treating that blank as a content defect.

Fix JSON syntax before property warnings

An invalid block cannot supply reliable entity findings. Start by repairing the JSON, then rerun the check before interpreting missing-property warnings. Common causes include single quotes around names or strings, an extra comma after the final property, a missing closing bracket and an unescaped quotation mark inside text. JSON uses double-quoted strings and commas between members; RFC 8259 defines the grammar.

This fictional Organization is a minimal syntax example for Paste code → JSON-LD:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Example Studio",
  "url": "https://example.com/"
}

The example supplies the two properties this checker looks for on Organization. It is not a complete template for any Google search feature. Replace fictional values with accurate page facts and consult the appropriate feature requirements before deployment.

Valid JSON alone does not establish usable structured data. A standalone string or number can be valid JSON but cannot describe the expected entity; this tool reports that the root needs an object or array. Likewise, a parsed object without a declared @type may produce no entity rows. Check the actual structure before adding properties just to clear the report.

Which schema properties are checked?

The Structured Data Checker applies selected checks to five exact types when their context is recognized. Use this table to understand a finding, rather than treating it as a complete list of Schema.org properties or Google's required fields.

Most of these are presence checks. A value can exist while its URL, date, image, object structure or factual content is wrong. An empty object may satisfy a presence check, and whitespace-only values are not rejected by every check. A supported status therefore does not confirm that an address, author or offer is complete.

Breadcrumb checks go further by checking the selected item values, but they do not establish sequential or unique positions, correct item URLs, or complete ListItem semantics. The report retains at most 100 property findings per entity. A long trail or an entity with many repeated defects can need additional review after those findings.

Fix a finding in the context of the page. If an article's author is a person, preserve the accurate author structure even when the nested Person appears outside this checker's scope. Changing truthful markup solely to obtain green labels can hide the original issue rather than solve it.

Why is valid markup marked unsupported or partial?

Unsupported means the tool did not apply its selected property checks to that entity. It does not mean Schema.org forbids the type. For example, a supported Article can contain a nested Person author. The Article receives its selected checks, but Person appears as unsupported, making coverage partial. A Restaurant also falls outside the five exact supported types, even though it is a more specific business type. Keep the type that accurately describes the subject and use a broader validator for the remaining checks.

Context can produce the same distinction. This checker recognizes a plain http://schema.org or https://schema.org context, with or without the trailing slash, including one inherited from a parent object. It does not resolve object or array contexts. Those forms can be legitimate under the W3C JSON-LD context specification. When an entity declares several types, all must belong to the supported set for its property checks to run.

Coverage is also bounded. The checker considers the first 50 JSON-LD blocks and retains up to 500 result rows, including invalid-block rows. It stops traversal beyond 32 nesting levels or 10,000 visited values per block. These limits can leave later entities unchecked. Microdata or RDFa detected in HTML also makes the report partial because those formats are not validated here.

For large pasted inputs, split complete JSON-LD blocks into separate checks; do not cut an object midway and create a new syntax error. Retain the original source and identify which parts each report covers. None of these checks automatically combine into a complete page audit.

Verify the page after correcting the markup

First compare the markup with what a visitor can read on the page. Check identities, dates, addresses, product details and any reviews against real content. Google's structured data guidelines require relevant, accurate information and applicable feature requirements; a parser cannot confirm those facts. Do not add fabricated details to satisfy a property warning.

Choose the next check according to the unresolved question. Use the Schema.org Markup Validator for broader Schema.org markup inspection, including Microdata and RDFa. It has its own limits: it does not fetch or interpret other context URLs. Use Google's Rich Results Test to inspect supported Google search features and their reported errors or warnings. Passing a test does not guarantee that Google will display a rich result.

If you are preparing business markup, the Local Business Schema Generator can produce JSON-LD from your actual details. Review its output before publishing. Specific business types and nested PostalAddress objects can remain unsupported in this checker; generation and selected validation are separate tasks.

After applying a correction, rerun the relevant check on the published page, not only the draft. Confirm that the served markup contains the intended change and compare the remaining findings. Use Download JSON to retain block numbers, entity paths, findings and coverage for that run. Keep the input and scope alongside the export so another reviewer can understand the evidence. A saved report records a check; it is not a continuing monitor of future template or content changes.