Structured data and JSON-LD for business websites: formats, types, testing and the Schema Ladder
Google's rules for markup explained plainly, with the AH SEO Agency Schema Ladder, a clean JSON-LD example and a one-hour starter kit.

Structured data is code that tells Google what a page is about, such as a business, product, article or event. Google prefers JSON-LD. Add it only for content visitors can see, include every required property, test with the Rich Results Test and monitor Search Console. Markup can make a page eligible for rich results, but it never guarantees them.
- Google supports JSON-LD, Microdata and RDFa, and prefers JSON-LD because it stays separate from visible text and scales better.
- Markup must describe content that users can see, and it belongs on the page it describes.
- A type must include all its required properties to be eligible, and complete, accurate recommended properties beat many half-filled ones.
- Test with the Rich Results Test before launch and use the Rich result status reports after, because templates and servers can break markup.
- AH SEO Agency's Schema Ladder below shows which markup to add first for a typical business site.
What is structured data, and what does it do for your website?
Structured data is a standardized way of labelling the facts on a page so that search engines can understand them without guessing. A page might say "Dr. Amira Khan, dentist, open nine to five", and markup tells Google that the first part is a person, the second is an occupation and the third is opening hours.
How does Google describe its purpose?
Google's introduction to structured data, last updated December 10, 2025, explains that markup gives Google explicit clues about the meaning of a page and that it can lead to richer search displays called rich results. The page includes case studies of publishers reporting gains, such as a 25 per cent higher click-through rate for pages with structured data at Rotten Tomatoes. Treat such figures as examples from Google's own page, not as a promise for your site.
What are rich results?
Enhanced search listings that show extra information, such as star ratings, prices, availability, images, breadcrumbs or event details, beside the usual title and snippet. They depend on eligible markup and on Google choosing to show them.
Does structured data improve rankings?
Google does not describe structured data as a general ranking factor. It helps Google understand content and can make pages eligible for enhanced displays that may improve click-through. Think of it as clarity, not a ranking lever. The broader picture appears in the guide to GEO versus SEO, where clear, structured facts help both search results and AI answers.
Is structured data only for big sites?
No. A local business with correct markup for its name, address and hours gives search systems the same clarity as a retailer with product markup. The value lies in accuracy, not scale.
What does structured data not do?
It does not replace good content, fix crawling or indexing problems, or guarantee rich results. If a page is not crawlable and indexable, its markup is never read, as the checks in the guide to Googlebot, rendering and the DOM explain.
Can markup hurt you?
Misleading or invisible markup can break Google's guidelines and lead to manual actions or lost rich results. Accuracy and visibility are the rules.
Which structured data formats does Google support?
Google supports JSON-LD, Microdata and RDFa. All three are acceptable if the markup is valid and follows the documentation for each feature, but Google prefers JSON-LD for practical reasons.
How do the three formats compare?
| Format | How it works | Strengths | Drawbacks |
|---|---|---|---|
| JSON-LD | A script block of JSON, separate from visible HTML | Easy to add, edit and generate from data; Google's preferred format | Can drift from visible content if it is hand-maintained |
| Microdata | Attributes added to visible HTML elements | Tied directly to what users see | Hard to maintain across templates |
| RDFa | Attributes in HTML tags, similar to Microdata | Rich linked-data model | Verbose and rarely used on business sites |
Which format should most sites use?
JSON-LD. It is simpler to generate from the same data that fills your pages, easier to validate and recommended by Google.
Where should the markup go?
On the page it describes. JSON-LD usually sits in a script tag of type application/ld+json in the head or the body. Do not create empty pages just to hold markup, and do not describe content that is not visible. Google states plainly not to add structured data about information that is not visible to the user.
Can you add markup with a tag manager?
You can, but server-rendered markup is safer, because it does not depend on a container being published or scripts executing. If you inject it with JavaScript, test the rendered output, as described in Googlebot and the DOM.
Which vocabulary should you use?
Most Search markup uses schema.org types and properties, but Google's own documentation governs what Search supports. Markup using the older data-vocabulary.org vocabulary is no longer eligible for rich results. Always check the Google page for the feature you want and follow its required and recommended properties.
Are all schema.org types supported by Google?
No. Schema.org has hundreds of types, and Google supports a subset for specific features. Use unsupported types only for clarity, knowing they will not produce rich results.

The Schema Ladder
AH SEO Agency adds structured data in five rungs, in this order, because each rung rests on the one below:
- Identity: Organization (or LocalBusiness) and WebSite markup on the home page, so that your name, logo, address and contact details are unambiguous.
- Page type: the main type for each template: Article for posts, Product for product pages, LocalBusiness for location pages, Service where it fits.
- Navigation: BreadcrumbList on every page below the home page.
- Extras that earn displays: only types whose current Google documentation you qualify for, such as Product offers, Review snippets on eligible pages or VideoObject.
- Maintenance: validation in the build, Search Console monitoring and a monthly check that markup still matches the page.
How do required and recommended properties work?
Each rich result type has required properties and recommended ones. A page must include every required property to be eligible. Recommended properties add detail, and Google says complete, accurate recommended properties matter more than filling in many incomplete ones.
What does that mean in practice?
Open the Google documentation for the type you want, list the required properties and make sure your template can supply each one from real data. Then add recommended properties you can fill accurately, such as images, dates and ratings from real reviews. Leave out any property you cannot support honestly.
What happens if a required property is missing?
The page is not eligible for that rich result, and Search Console's reports list an error. Fix the template so that the property is always present.
Which guidelines apply to all markup?
- Mark up only content visible to users on the page.
- Mark up the main content of the page, not a different page.
- Do not use markup to hide or misrepresent information.
- Follow any guidelines specific to the type, such as the rules on self-serving reviews.
- Keep prices, dates, ratings and names identical to the visible text.
What if you break a guideline?
Your markup may be ineligible for rich results, and serious or repeated violations can lead to a manual action reported in Search Console.
How does this apply to product data?
Product markup must match what shoppers see: the same price, currency and availability. Mismatches between markup, feed and page cause lost eligibility, as explained in the comparison of Merchant Center feeds and structured data and the guide to AI shopping and structured data.
Should every product property be filled?
Fill those you can support: identifiers, brand, images, price and availability. Skip anything you would have to guess.
Which structured data types matter for a typical business website?
Choose types by page, not by wish list. A small business usually needs a handful of types, applied consistently across templates, rather than dozens of experimental ones.
Which types suit which pages?
| Page or business | Typical types | Notes |
|---|---|---|
| Home page | Organization, WebSite | Name, logo, contacts, site name |
| Local business or location page | LocalBusiness or a specific subtype | Name, address, hours, telephone, geo |
| Blog post or guide | Article, BreadcrumbList, Person for the author | Headline, dates, author, image |
| Product page | Product with Offer, BreadcrumbList | Price, availability, identifiers, images |
| Category page | BreadcrumbList, optionally ItemList where documented | Check current guidance before using |
| Video page | VideoObject | Thumbnail, upload date, description |
| Event page | Event | Dates, location, status |
| Team or about page | Organization, Person | Real people and verifiable details |
What about FAQ markup?
Google has restricted how often FAQ rich results appear, so check the current documentation before relying on them. You can still write FAQ sections for readers, since clear questions and answers help users and AI summaries regardless of markup.
How do local businesses use markup?
Use LocalBusiness or a more specific subtype on the home or location page, keep name, address and phone identical to the Business Profile and avoid marking up your own reviews as if they were reviews of another business. The full walkthrough is in the LocalBusiness schema guide.
Do service pages need their own type?
Schema.org has a Service type, which can clarify what you offer, but Google does not document a specific rich result for it. Use it for clarity if you can keep it accurate and consistent.
How do blogs and publishers use markup?
Mark up articles with headline, image, dates and author, link the author to a real profile page and keep the markup in line with the visible byline and dates. Honest authorship matters, as explained in the guide to E-E-A-T for YMYL businesses.
Should dates in markup match visible dates?
Yes. A modified date in markup should reflect a real revision visible or documented on the page.
How do you write and place JSON-LD correctly?
Write valid JSON, use the right type and property names, use absolute URLs and keep values identical to the visible page. Place the script on the page it describes, and generate it from the same data as the page content.
What does a clean Article and Organization example look like?
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://www.example.com/#organization",
"name": "Example Agency",
"url": "https://www.example.com/",
"logo": "https://www.example.com/assets/logo.png"
},
{
"@type": "Article",
"headline": "Structured data basics for business websites",
"image": "https://www.example.com/assets/img/structured-data.jpg",
"datePublished": "2026-10-25",
"dateModified": "2026-10-25",
"author": { "@type": "Person", "name": "Alex Example", "url": "https://www.example.com/author/alex/" },
"publisher": { "@id": "https://www.example.com/#organization" },
"mainEntityOfPage": "https://www.example.com/blog/structured-data-basics/"
}
]
}
</script>
The names, URLs and dates are placeholders. Replace them with your own, and check Google's Article documentation for current required and recommended properties.
Why use @graph and @id?
They let you describe several entities in one block and refer to them by identifier, so the Article can point to the same Organization defined elsewhere. This keeps entity information consistent across pages.
Which syntax mistakes break markup?
Trailing commas, unescaped quotation marks, curly quotes pasted from word processors, missing closing braces, wrong type names, dates in the wrong format and relative URLs. A validator catches most of these in seconds.
How do you avoid copy-paste errors?
Generate JSON-LD from a template that reads fields from your content database, not from hand-edited snippets. Hand-edited copies decay as pages change.
How should markup connect to page content?
Every value in the markup should appear on the page in some form: the headline, the author, the date, the price, the address. If something is in the markup but not visible, either show it or remove it. The same rule applies to titles and headings, so that the page tells one consistent story, as in the guide to title links and rewrites.
Can the same fact appear in several types?
Yes. A business name can appear in Organization, LocalBusiness and Article publisher markup, as long as all values are identical.
How do you test structured data and monitor it after launch?
Test with the Rich Results Test during development, deploy, then watch the Rich result status reports in Search Console. Google recommends both, because templating and serving issues can break markup after launch.
What does the testing workflow look like?
- Write or generate the markup for one template.
- Run the live URL, or the code snippet, through the Rich Results Test and fix errors and warnings.
- Check the rendered HTML in the URL Inspection tool to confirm that Google sees the markup.
- Deploy to all pages of the template and spot-check ten URLs.
- Watch the relevant enhancement report in Search Console for valid, warning and error counts.
- Repeat after every template or platform change.
What is the difference between an error and a warning?
Errors mean required properties are missing or invalid, which makes the item ineligible. Warnings flag recommended properties that are missing, and the item may still qualify. Fix errors first, then improve warnings where you can supply accurate data.
What breaks markup after launch?
Theme updates, plugin conflicts that add duplicate blocks, CMS fields that become empty, redesigns that remove visible elements the markup describes, caching that serves stale templates and scripts that fail to run. Monthly checks catch these early.
How do you catch duplicates?
View the rendered source and count the JSON-LD blocks. Two plugins describing the same Organization with different details create conflicts, so keep one source.
How do you measure whether markup helps?
Track impressions, clicks and click-through rate for the pages with markup in Search Console, compare against similar pages without it and use the Search appearance dimension where rich results are reported. Keep a change log, and avoid attributing every change to markup. The measurement approach in measuring SEO in the AI era applies.
How long until rich results appear?
Google needs to recrawl and reprocess pages, which can take days to weeks, and display is never guaranteed. Set expectations accordingly.
The one-hour structured data starter kit
- Add Organization and WebSite JSON-LD to your home page with your real name, logo and contact details.
- Add BreadcrumbList to every page below the home page.
- Add Article markup to blog posts, with a real author page.
- For local firms, add LocalBusiness markup to the home page or location pages.
- Run each template through the Rich Results Test and fix every error.
- Open the relevant Search Console reports and note the valid counts as your baseline.

How does structured data support entity clarity and AI search?
Structured data states who you are, what you offer and how pages relate, in a form that machines can read directly. That clarity helps classic search features and also helps AI systems that summarize businesses, although no markup can guarantee a mention in a generated answer.
What does entity consistency involve?
Use the same business name, address, phone number, logo and descriptions in your markup, your visible pages, your Business Profile and your main directory listings. Link people, organizations and pages with identifiers, so that a single description of your company is reused everywhere. When the facts agree across sources, systems have less to reconcile.
Which entities should you define explicitly?
Your organization, your locations, your key people with real profile pages, your main services and your products. Define each once and refer to it elsewhere.
Does Google use markup for AI features?
Google's guidance on AI features says there is no special markup needed, and that pages need to be indexed and eligible to appear with a snippet. Structured data remains useful for understanding and for rich results, but do not expect it to switch on AI visibility. The practical context is in the guide to AI Overviews and AI Mode.
Should you add markup only for AI?
No. Add markup because it describes your content accurately and supports documented features. Any benefit for AI summaries is a side effect.
How does markup interact with your measurement?
Track structured data validity, rich result impressions where reported and the pages' overall impressions and clicks. When a template changes, compare before and after. The approach for mixing these signals appears in measuring SEO in the AI era.
What if markup validates but nothing changes?
That is normal. Eligibility is not display. Keep the markup accurate and invest in the content and signals that drive visibility.
What governance template keeps markup accurate as your site changes?
Treat structured data as a product with an owner, a specification and a test plan. A one-page governance template turns that into routine work.
What does the governance sheet record?
| Field | Example entry |
|---|---|
| Template | Blog post, product page, location page |
| Markup type | Article, Product, LocalBusiness |
| Data source | CMS fields, product database, location table |
| Required properties and where they come from | Headline from title field, dates from publish record |
| Google documentation link | The exact Google page for the type |
| Owner | Named developer and named SEO |
| Last validated | Date and tool used |
| Known limitations | Properties intentionally omitted and why |
How often should you review the sheet?
Quarterly, and whenever Google updates the documentation for a type you use. Google's pages carry update dates that make changes easy to spot.
What release rules prevent breakage?
Run the template through a validator in your build, fail the release on errors, compare the count of JSON-LD blocks per page type against a baseline and spot-check live pages within a day of release. These steps take minutes and protect against theme updates and plugin changes.
Who is accountable when markup breaks?
The named owner on the sheet. Without a name, markup problems linger until a drop in rich results reveals them.
How do you handle content changes by editors?
Make sure the fields that feed markup are required in the CMS, so that an editor cannot publish a post without a headline, an author or an image. If an editor changes a price or address, markup updates automatically because it reads the same field. That is the whole point of generating markup from data.
What if editors paste markup by hand?
Discourage it. Hand-pasted blocks drift, duplicate and conflict with template markup. Provide fields, not code boxes.
How do you add structured data on WordPress, Shopify and custom sites?
Most platforms either output some markup themselves or offer plugins and apps. Check what is already there before adding more, and make sure there is a single source of truth for each type.
What should you check on a CMS or plugin?
View the rendered source of a typical page and note every JSON-LD block. Identify which plugin or theme produces each, whether the values are correct and whether blocks conflict. Disable duplicate sources and fill every field in the plugin's settings, such as the organization name, logo and social profiles.
Which fields do plugins often leave empty?
Logo, organization type, publisher details, author profile URLs and local business details. Empty fields lead to incomplete or inconsistent markup.
What should you check on ecommerce platforms?
Confirm that product markup uses the correct price, currency, availability and identifiers for each variant, that review markup reflects real, visible reviews and that apps do not add a second, conflicting Product block. The impact of heavy apps on speed is covered in how Shopify apps affect Core Web Vitals.
Can you edit theme templates safely?
Yes, with version control and a staging copy. Make small changes, validate and compare before and after.
What should you do on custom and static sites?
Generate JSON-LD at build time from your content data, validate in the build and fail on errors. This site generates its markup from the same data as its pages, which keeps structured data and visible content aligned automatically.
How does mobile affect markup?
The mobile version must carry the same markup as desktop, because Google uses the mobile page for indexing, as described in mobile-first indexing best practices.
How do you read the structured data reports in Search Console?
Search Console groups detected markup by type and shows valid items, items with warnings and items with errors. Use the reports to find template-level problems, not to chase individual URLs.
Which numbers should you watch?
The count of valid items per type, the count of errors and the trend over time. A sudden drop in valid items after a release almost always means a template change broke the markup. A sudden rise in errors often points to a plugin update.
How do you act on an error group?
Open the error, view the example URLs, identify the shared template and fix the cause once. Then use the validate fix option to ask Google to recheck, and monitor until the count recovers.
What if a type appears that you did not add?
A plugin or theme probably outputs it. Decide whether it is accurate and wanted, then keep one source and disable the others. Unplanned markup is a common source of conflicts, so inventory your pages regularly.
Does a green report mean success?
It means the markup is valid and eligible, not that Google shows rich results. Judge success by the combination of validity, impressions and clicks over time.
What does a structured data project look like in practice?
This is a fictional example that illustrates the method. The outcomes are invented.
What was the situation?
A fictional two-location dental practice had a WordPress site with no deliberate markup. An SEO plugin and the theme each output Organization blocks with different names, and the contact page listed an old phone number in markup.
What did the audit find?
Two conflicting Organization blocks, no LocalBusiness markup for either location, no breadcrumb markup, blog posts without author information and a Rich Results Test showing errors on several templates.
What did AH SEO Agency recommend?
Climbing the Schema Ladder: remove the theme's Organization block, configure the plugin with the correct name and logo, add Dentist markup with address, hours and telephone to each location page, add BreadcrumbList sitewide, add Article markup with real author profiles to blog posts and validate every template. They kept a baseline of Search Console report counts, monitored monthly and recorded that any change in appearance or click-through could not be attributed to markup alone.
What did they learn?
Consistency mattered more than quantity. One clean Organization block and accurate location data replaced a pile of conflicting markup.
Which structured data mistakes should you avoid?
Most issues come from marking up what users cannot see, copying someone else's markup and neglecting maintenance.
What do sites get wrong most often?
Marking up invisible content, using self-serving review markup, copying competitor code without changing values, leaving required properties empty, using the wrong type for the page, duplicating blocks from plugins and themes, letting prices and dates drift from the visible page, creating pages only for markup and never revalidating after releases.
Which mistake is the most common?
Drift. The markup was correct at launch, then a price, an address or a name changed on the page and nobody updated the code. Generating markup from live data prevents it.
How do you keep markup healthy?
Add validation to your release process, review Search Console reports monthly, keep one owner for markup and review Google's documentation when it updates. The checks fit within the technical SEO audit checklist.
Who owns structured data?
SEO defines what is needed, developers implement it in templates and content owners keep the underlying facts accurate.
How does AH SEO Agency help with structured data?
AH SEO Agency audits your existing markup, removes conflicts, builds clean JSON-LD from your own data using the Schema Ladder and sets up validation and monitoring so that it stays accurate. We follow Google's documentation and tell you plainly which rich results you can realistically expect and which you cannot.
Where do you start?
Book a technical SEO review, strengthen page-level signals with on-page SEO or request a free SEO audit that includes a structured data check.
Summary: how do you use structured data well?
Use JSON-LD, mark up only visible content, fill every required property, validate with the Rich Results Test, monitor Search Console and keep the markup tied to live data.
- Google supports JSON-LD, Microdata and RDFa, and prefers JSON-LD.
- Required properties decide eligibility, and rich results are never guaranteed.
- Markup must describe visible content on the page it belongs to.
- Test before launch and monitor after, since templates break markup.
- Follow the AH SEO Agency Schema Ladder from identity to maintenance.
Related guides
Local SEOLocalBusiness schema markup: a JSON-LD guide for local SEO, hours, geo and multi-location pages
Write LocalBusiness JSON-LD that follows Google's guidance: required and recommended properties, opening hours, geo, departments and validation.
Read the guide
Ecommerce SEOProduct feed vs structured data: how Merchant Center and your pages work together
How product feeds and Product structured data differ, which attributes must match, how return and shipping policies fit in and how to diagnose disapprovals.
Read the guide
SEO fundamentalsWhy Google rewrites your title links and how to write titles that Google keeps
Why Google rewrites title links, which signals it uses, how to write unique descriptive titles and how to measure click-through changes in Search Console.
Read the guideTechnical SEOTechnical SEO audit checklist: 27 checks, step by step
A step-by-step technical SEO audit checklist: crawling, indexing, canonicals, redirects, Core Web Vitals, structured data and how to prioritize and fix findings.
Read the guideFrequently asked questions
Which structured data format does Google prefer?
Google supports JSON-LD, Microdata and RDFa, and prefers JSON-LD because it is separate from visible text and easier to maintain at scale. All three are acceptable if the markup is valid and follows the feature's documentation.
Does structured data guarantee rich results?
No. Valid markup can make a page eligible, but Google decides whether to show a rich result. Pages must also meet the feature's requirements and guidelines.
Can I mark up information that is not visible on the page?
No. Google says not to add structured data about information that is not visible to the user, and not to create empty pages to hold markup. Violations can make markup ineligible or lead to manual actions.
How do I test my structured data?
Use the Rich Results Test while developing, and the Rich result status reports in Search Console after deployment. Also inspect the rendered HTML with the URL Inspection tool to confirm Google sees the markup.
Do I need every recommended property?
No, but required properties must be present. Google says complete, accurate recommended properties matter more than filling in many incomplete ones. Leave out anything you cannot support honestly.
Is structured data a ranking factor?
Google does not describe it as a general ranking factor. It helps Google understand your content and can make pages eligible for enhanced displays that may improve click-through.
Not sure where your site stands?
Send us your website and we will tell you what we would fix first, including if SEO is not your best next step.