schema Technical SEO

Structured Data Extractor

List the structured data a page gives search engines, in JSON-LD, Microdata, and RDFa formats.

Enter a page URL and see the structured data (schema markup) it gives search engines and AI systems. We list JSON-LD entities by type, flag missing names, and count Microdata and RDFa, so you know what they can read.

build_circle Try the free tool
list On this page expand_more
star

Key takeaways

  • check_circle Structured data is the clearest way to state what a page is about, and extracting it shows exactly what machines can read.
  • check_circle JSON-LD is the format Google recommends, and this tool lists its entities by type and name.
  • check_circle A good page carries a site-level entity plus a page-specific type, both with names.
  • check_circle Microdata and RDFa are detected and counted, not itemized, so inspect the source if they appear.
  • check_circle Duplicate entities from overlapping themes and plugins are a common problem that extraction reveals quickly.
  • check_circle Extraction is an inventory, so validate features separately with Google's Rich Results Test.
  • check_circle Schema added by JavaScript after load is not in the served HTML and will not appear in the results.
data_object

What is Structured Data Extractor?

Structured data is markup that describes a page in a vocabulary machines understand, most often schema.org. Instead of leaving a search engine to infer that a line of text is a business name or a price, the markup says so explicitly. It can be written as JSON-LD in a script tag, as Microdata attributes on visible elements, or as RDFa attributes. Because the vocabulary is shared, the same markup can be read by search engines, assistants, and other crawlers.

The HeyLead Structured Data Extractor fetches a page and lists what it exposes. For JSON-LD, it unpacks arrays and @graph containers, then reports each entity by type and name, along with a count of blocks that fail to parse. It also detects Microdata and RDFa by their attributes and reports the formats found. Five checks summarize the result: JSON-LD present, blocks parse, a business or site entity, a page-specific type, and names on entities. A preview shows the entity list and the first blocks.

The tool is an inventory, not a rich-results validator. It shows what is there so you can spot missing types, duplicate entities, and gaps in properties, then move on to specialist testing. It reads the served HTML only, so it reflects what most crawlers fetch without running JavaScript. That makes it a useful reality check on plugin output, template changes, and competitor pages.

insights

Why structured data matters

Search engines and AI systems increasingly rely on explicit entities to decide who a business is, what a page offers, and whether to surface it. Markup that is missing, duplicated, or contradictory weakens that understanding. Extracting it turns invisible code into something you can review and fix. Clear markup also reduces the chance of a wrong name, address, or category being shown.

arrow_forward Clear entities help search engines connect a page to the right business, product, or topic.
arrow_forward Correct markup can make a page eligible for rich results in search.
arrow_forward Duplicate or conflicting entities create mixed signals that are hard to spot in the browser.
arrow_forward Regular extraction catches markup that disappears after a theme or plugin update.
play_circle

How to use this tool

  1. 1

    Enter a URL

    Use a page that should carry schema, like a service or product page.

  2. 2

    Review entities

    See each entity type and a preview of the JSON-LD.

  3. 3

    Fill the gaps

    Add missing entity types and properties.

fact_check

What this tool checks

verified

JSON-LD blocks present

Finds every script tag of type application/ld+json in the served HTML and counts them. JSON-LD is the format Google recommends, so a page with none fails this check.

verified

Blocks parse as valid JSON

Attempts to parse each block and counts the ones that fail, such as blocks with trailing commas or unescaped quotes. A block that does not parse is ignored by search engines.

verified

Business or site entity

Looks for an Organization, LocalBusiness, ProfessionalService, Corporation, Person, or WebSite entity, or any type containing business or service, so machines know who publishes the page.

verified

Page-specific type

Checks for a type that describes the page itself, such as Article, BlogPosting, Product, FAQPage, Service, BreadcrumbList, HowTo, Event, Course, or WebPage, beyond the publisher entity.

verified

Entities carry a name

Counts entities with no name property. Supporting types such as BreadcrumbList, ListItem, PostalAddress, Question, Answer, and WebPage are exempt, since they rarely need one. Missing names are a common sign of thin markup.

verified

Formats detected

Reports which of JSON-LD, Microdata, and RDFa appear. JSON-LD entities are listed by type and name; Microdata and RDFa are detected by their attributes but not itemized.

engineering

Technical guide

Signals, standards, and what to fix when checks fail.

code

What gets extracted and how

The tool reads the served HTML, pulls out each JSON-LD script, and parses it. Arrays and @graph containers are unpacked, and every object with an @type becomes one entity in the list. Types may be a single string or an array, and both are handled. Objects nested inside an entity, such as a PostalAddress inside a LocalBusiness, are part of the parent and are not counted as separate entities. The results show an entity total, the first few types, and the formats found. This gives a fast view of the markup a crawler receives on first fetch.
code

Reading the entity preview

The preview begins with an ENTITIES list of up to twenty lines in the form Type - name, followed by the first three JSON-LD blocks pretty-printed and truncated at about four thousand characters. Use the list to see the overall shape: which types exist, whether names are present, and whether duplicates appear. Use the pretty-printed blocks to inspect properties such as sameAs, address, and url, and to spot values that do not match the visible page. Longer blocks are cut off, so open the page source when you need the rest.
code

Microdata and RDFa detection

Microdata is detected by elements carrying itemscope with an itemtype, and RDFa by typeof attributes. The tool counts them so you know these formats exist, but it does not list their entities or properties. If a page shows Microdata or RDFa alongside JSON-LD, look for two markup systems describing the same thing, often a theme and a plugin. Duplicates that disagree on name or address are a common source of confusing results. Reviewing the source of those attributes is the quickest way to trace where they came from.
code

What extraction cannot tell you

This is an inventory, not an eligibility test. It does not confirm that markup satisfies the required and recommended properties for Google rich results, and it does not judge whether the markup is truthful. It also reads only the served HTML, so schema injected by JavaScript after load is not seen. Pair it with Google's Rich Results Test and the Schema Markup Validator for feature checks and syntax validation. Treat the checks here as a starting point for review, not a pass mark.
school

Deep dive

code

JSON-LD, Microdata, and RDFa compared

All three formats express schema.org data, but they live in different places. JSON-LD is a script block, usually in the head or body, that describes the page without touching visible markup. That separation makes it easy to generate from templates and to audit, which is why Google recommends it. Microdata is woven into the HTML of visible elements, so the data and the display stay together, but templates become harder to read and change. RDFa is similar in spirit, using attributes such as typeof and property, and appears mostly in older or specialized systems. Mixed formats on one page are a warning sign. They often mean an old theme uses Microdata while a new plugin adds JSON-LD, and the two may describe the same entity differently. Standardize on JSON-LD and retire the rest.

Why JSON-LD wins

It is decoupled from presentation, easy to validate, and simple to generate programmatically. A design change rarely breaks it, and one block can describe many related entities at once.

When Microdata persists

Older themes and some ecommerce templates still print Microdata. It works, but it is tied to the HTML structure and easily breaks when markup is redesigned. Removing it needs care to avoid losing needed data.

Mixed-format clean-up

When the extractor reports more than one format, compare the entities. Keep the most complete and accurate set, and disable the source of the redundant output. Then retest.

account_tree

Entities, types, and the connected graph

Good structured data describes real things and how they relate. An Organization or LocalBusiness represents the publisher. A WebSite entity represents the site. A page-level type such as Article, Service, or Product represents the content, and a BreadcrumbList describes navigation. The strongest implementations connect these with @id references, so a Service points to its provider and an Article points to its author and publisher rather than repeating full details each time. The extractor lists each top-level entity with its type and name, which makes gaps obvious. If you see only a WebPage and nothing about the business, machines learn little about who is behind the page. If you see three Organization entities, decide which is correct and remove the others.

Publisher entity

Organization or LocalBusiness anchors identity: name, url, logo, and sameAs profiles. Describe it once per site and reference it by @id from page-level markup.

Page-level type

Choose the type that matches the page purpose, not the most impressive one. A service page suits Service; a blog post suits Article or BlogPosting. Accuracy beats ambition. Subtypes such as ProfessionalService are fine when they are accurate.

Names and identifiers

Every main entity should have a name, and reusable ones should have a stable @id. Names should match visible headings and brand usage. Reuse the same identifier everywhere.

verified

Accuracy, visibility, and duplicate control

Search engines expect markup to describe content visitors can actually see. Prices, ratings, opening hours, addresses, and FAQs in schema should match the page. Marking up invisible or invented content risks losing rich result eligibility and can erode trust. Duplicates are the more common practical problem. WordPress sites frequently run an SEO plugin, a theme, and a page builder that each emit markup. The extractor makes this visible: repeated Organization entities, two WebSite entities, or conflicting names. Decide which source is authoritative, turn off the others, and re-extract to confirm. Treat markup as content that needs an owner, since it drifts when addresses change, products retire, or teams switch plugins. A short review after each release keeps it accurate.

Match the visible page

Every fact in schema, from price to phone number, should be visible or derivable on the page. If the page changes, the markup changes with it.

Remove duplicate sources

List which theme, plugin, or builder outputs each entity. Keep one source of truth for each type and disable the rest to avoid conflicting values. Repeat the extraction to verify the result.

Assign ownership

Give someone responsibility for schema after releases and content changes. Markup without an owner slowly diverges from the truth. Add it to the release checklist.

travel_explore

A testing workflow for multi-region sites

Extraction fits early in a testing workflow. Start with the extractor to see what is present, then run Google's Rich Results Test for feature eligibility and the Schema Markup Validator for syntax and vocabulary. Fix issues in the template, not on individual pages, then re-extract a sample of each page type. For businesses serving the US, UK, Australia, and Singapore, check every regional version. Confirm that address, telephone, currency in offers, and areaServed reflect the local market, and that language tags such as en-GB, en-AU, and en-SG match the page. A US Organization entity copied unchanged onto a UK page is a common error. Record the expected entities per template in a short table so reviewers know what good looks like, and repeat the sample after each theme or plugin update.

Sequence the tools

Extract first to inventory, validate syntax next, then test rich result eligibility. Each tool answers a different question, so use them in order. Run all three before launch.

Localize regional markup

Regional pages need local addresses, phone formats, currency codes such as GBP, AUD, or SGD, and accurate areaServed values, not copies of the US markup. Verify each region before launch.

Document expected entities

For each template, write down the entities and key properties it should output. A checklist turns extraction results into a fast pass or fail review. Update it as templates change.

compare

Examples

thumb_up Strong examples

Site entity with identity

{"@type":"Organization","name":"HeyLead","url":"https://heylead.com/","sameAs":["https://www.linkedin.com/company/heylead"]}

Names the publisher, gives a canonical URL, and links official profiles, so machines can tie the site to one consistent entity across the web.

Page-level type

{"@type":"Service","name":"SEO Services","provider":{"@id":"https://heylead.com/#org"}}

Describes what the page offers and points to the publisher by @id, so the graph is connected instead of repeating the organization details. That keeps the markup compact and consistent.

Named breadcrumbs

{"@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home"}]}

Mirrors the visible breadcrumb trail with positions and names, which is the kind of consistent, visible-content markup search engines trust.

thumb_down Weak examples

Invalid JSON block

{"@type":"Organization","name":"HeyLead",}

The trailing comma makes the whole block unparseable, so search engines ignore it. The extractor counts it as an invalid block. One character can hide the entire entity.

Entity with no name

{"@type":"LocalBusiness","telephone":"+1 555 0100"}

Without a name property the entity cannot be identified, and the checker flags it. Add the business name exactly as shown on the page.

Markup for invisible content

{"@type":"FAQPage","mainEntity":[...questions not shown on the page...]}

Marking up FAQs that visitors cannot see breaks the rule that markup must reflect visible content, and it risks losing rich result eligibility. Only mark up what the page shows.

rule

Best practices and common mistakes

check_circle Best practices

  • done Include a site-level entity such as Organization or LocalBusiness plus the type that matches the page, for example Service, Article, or Product.
  • done Give every main entity a clear name property that matches the visible page heading or brand.
  • done Keep markup consistent with the visible content, including prices, addresses, and phone numbers.
  • done Use one system, preferably JSON-LD, and remove duplicate output from overlapping themes and plugins.
  • done Link entities with @id references and sameAs URLs so a business is described once and reused across the graph.
  • done Re-extract after template, theme, or plugin changes to confirm the markup survived.

cancel Common mistakes

  • close Marking up content that visitors cannot see on the page, such as invented reviews or hidden FAQs.
  • close Letting several plugins each print their own Organization entity with different names or logos.
  • close Shipping JSON with syntax errors, since a single trailing comma can invalidate a whole block.
  • close Treating a long entity list as a quality signal when the properties inside are thin or wrong.
  • close Assuming schema added by JavaScript is always read, when this and many other tools see only the served HTML.
lightbulb

Common use cases

task_alt

Auditing what an SEO plugin actually outputs on a live page.

task_alt

Checking a competitor's structured data to see which types they use.

task_alt

Confirming a template or theme update did not remove existing markup.

task_alt

Finding duplicate or conflicting entities before a rich results review.

task_alt

Documenting a page's entities for a developer or client handoff.

groups

Who should use this

person Technical SEOs auditing schema output. person Developers building or maintaining templates. person Content teams checking what a page exposes to machines. person Agencies comparing client and competitor markup. person Ecommerce managers verifying product and organization entities.
dictionary

Glossary

schema.org
A shared vocabulary of types and properties, such as Organization or Product, used to describe web content in a way search engines understand.
JSON-LD
JavaScript Object Notation for Linked Data: structured data written as JSON inside a script tag, separate from visible HTML.
Microdata
A format that embeds schema.org data in visible HTML using attributes like itemscope, itemtype, and itemprop.
RDFa
A format that embeds structured data in HTML attributes such as typeof and property, used less often than JSON-LD.
@graph
A JSON-LD container that holds several entities in one block, letting a page describe related things together.
@id
A unique identifier for an entity, usually a URL with a fragment, used to reference the same entity from other markup.
sameAs
A property listing URLs of official profiles for an entity, such as social accounts, helping machines confirm identity.
Rich result
An enhanced search listing, such as review stars or product prices, that some structured data can make a page eligible for.
quiz

Frequently asked questions

Ready for a deeper audit?

HeyLead reviews your site, competitors, and growth opportunities with no sales pressure.

Get a Free Audit arrow_forward