Schema Markup Statistics (2026): We Audited 222 Business Websites

Each finding has its own link and a copy button that includes the source.

The study in four minutes. Watch on YouTube

87% of the pages we checked had structured data, and 85% had JSON-LD, the format Google recommends. 6 pages used only the older Microdata format and 31 had nothing at all. But only 23% of pages passed all four of our quality checks.

Adoption is high because most website builders add a basic block on their own. Local businesses (90% of pages) and online stores (88%) were close. SaaS websites trailed: 15 of 23 pages had any structured data. Custom-built sites (13 of 38 without markup) and Webflow (7 of 15), where nothing is added unless someone writes it, had the most pages with nothing at all.

On 10 of the 205 JSON-LD pages where we also saved the server HTML (5%), the markup was missing from the HTML the server sent and appeared only after JavaScript ran, usually from an app or a tag manager. Google can still read it after rendering, but many other crawlers and AI tools read the raw HTML only.

Only 57 of 243 pages (23%) passed all four checks. Most pages had markup, and most of that markup fell short.

We held every page to the same bar, using only what the page already shows a visitor:

1. It has JSON-LD, the format Google recommends.
2. The type fits the page. The most specific type or a broader one from the same family: Dentist and LocalBusiness both pass on a dental practice. Organization or WebSite alone does not.
3. No errors. No missing field that Google requires for rich results, no broken JSON, and nothing that breaks schema.org's rules, such as a made-up type or plain text where an object belongs. Format warnings, such as an image URL without https:, don't count against the page.
4. The key facts are there and match. On pages about a business, the phone number, street address and opening hours, if the page shows them. On product pages, the price, stock status, rating and review count, if the page shows them. Nothing in the markup contradicts the page.

Pages fell short at every step: 37 had no JSON-LD, 55 stopped at the type, 58 at errors and 36 at the facts on the page. Where a call was close, the page got the benefit of the doubt. One matching value was enough when a page listed several phone numbers, a page that showed no phone, address or hours wasn't marked down for leaving them out, and only contradictions we confirmed by hand counted.

The gaps were usually small. Of the 136 pages with JSON-LD that showed key facts, 81 left at least one out, and 71 of those 81 were missing just one or two. For most businesses, the work left is finishing the markup they already have: 149 pages had JSON-LD that didn't pass. The 6 pages with Microdata only weren't checked field by field and aren't among the 57; even if all of them passed, the share would be 26%.

Mostly not as precisely as they could. 31% of all pages described their main subject with the most specific schema.org type. Among local businesses it was 23%: the rest used a broader type such as LocalBusiness or Organization, described only the website, or had no markup.

For each page, two independent AI readers recorded what the page is about and which schema.org type fits it best: a Dentist, a RoofingContractor, a Product, a SoftwareApplication. We then checked the page's markup for that type or one of its subtypes. Online stores scored best (69%) because shop themes write Product blocks. Local businesses (23%) and SaaS (3 of 23) mostly used broader types or described only the company.

The type is the first thing a search engine or an AI assistant learns about a page. Organization says "a company"; Dentist says what the company does and which fields to expect, such as opening hours, accepted insurance and medical specialty.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "WebSite",
      "@id": "https://example-dental.com/#website",
      "url": "https://example-dental.com/",
      "name": "Example Dental"
    },
    {
      "@type": "Organization",
      "@id": "https://example-dental.com/#organization",
      "name": "Example Dental",
      "logo": "https://example-dental.com/logo.png",
      "sameAs": [
        "https://www.facebook.com/exampledental"
      ]
    }
  ]
}

{
  "@context": "https://schema.org",
  "@type": "Dentist",
  "@id": "https://example-dental.com/#dentist",
  "parentOrganization": {
    "@id": "https://example-dental.com/#organization"
  },
  "name": "Example Dental",
  "telephone": "+1-555-0100",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "200 Example Ave, Suite 4",
    "addressLocality": "Springfield",
    "addressRegion": "IL",
    "postalCode": "62701",
    "addressCountry": "US"
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": [
        "Monday",
        "Tuesday",
        "Wednesday",
        "Thursday"
      ],
      "opens": "08:00",
      "closes": "17:00"
    }
  ]
}

On local business pages with JSON-LD, the markup left out the street address shown on the page 55% of the time, the phone number 42% of the time and the opening hours 43% of the time.

This is the measure we think matters most, and the one most audits skip. A validator only checks the block that exists; it can't tell you that the page shows a phone number, an address and opening hours that the markup never mentions. We compared every fact the page visibly states with the markup on the same page.

A likely reason: many of these blocks come from a theme or plugin that fills them from a few site settings, not from what the page says. A fact that lives only in the page's text never reaches the markup.

On 9 pages from 8 websites, the markup stated something the page itself contradicted. Phone numbers were the most common case: 6 of the 70 pages where both the page and the markup had a phone number.

We flagged every page where the markup and the page disagreed on a phone number, price, rating or stock status, then checked each one by hand. We kept only clear cases:

• A climbing gym listed two phone numbers. The markup had one of them with a single digit wrong.
• An Australian fitness club's markup wrote its number without the area code, so it no longer dials.
• Three websites, four pages: the markup carried a phone number that appears nowhere on the page.
• A clothing store's markup used a trade price list, about 17% below the price visitors saw.
• A food brand's page showed 4.6 stars from 638 reviews. The markup said 4.9 from 120.
• A parts store's page said the item was backordered. The markup said InStock.

We left out cases we couldn't settle from the saved page, such as stock that differs by size or prices that change with the visitor's country. The real number is probably higher.

22% of pages with JSON-LD had at least one error on a field Google requires. 69% had no Google error and no schema.org vocabulary error.

We split problems into three groups and only call the first one an error. Required fields come from Google's structured data documentation. Vocabulary problems break schema.org rules; search engines may ignore the affected part. Format issues are things we avoid in our own output, but we have not confirmed that Google rejects them, so we report them without calling them errors.

Every Squarespace and Wix page in the sample had structured data, but what it said varied widely. Among the larger groups, WordPress pages were the most likely to be free of Google and vocabulary errors (83%) and Squarespace pages the least (54%), mostly because of blank LocalBusiness blocks. Complete and correct markup was rare on every platform: 20% on Squarespace, 25% on WordPress and 18% on Shopify.

Squarespace

Squarespace's help center says it generates structured data on its own (Website, Organization, Local business, Product, Event and Blog post) and that site owners can't edit or remove it. In our sample, 60 of 70 Squarespace pages carried a LocalBusiness block. 21 of those blocks were blank: no name, an empty address, empty opening hours and an image. On 13 of those 21 pages, the street address was right there on the page.

{
  "address": "",
  "image": "https://static1.squarespace.com/static/…/",
  "openingHours": "",
  "@context": "http://schema.org",
  "@type": "LocalBusiness"
}

{
  "@context": "https://schema.org",
  "@type": "RoofingContractor",
  "name": "Example Roofing Co.",
  "url": "https://example-roofing.com/",
  "telephone": "+1-404-555-0137",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "100 Example Drive SE",
    "addressLocality": "Atlanta",
    "addressRegion": "GA",
    "postalCode": "30316",
    "addressCountry": "US"
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": [
        "Monday",
        "Tuesday",
        "Wednesday",
        "Thursday",
        "Friday"
      ],
      "opens": "08:00",
      "closes": "17:00"
    }
  ]
}

WordPress

97% of WordPress pages had structured data, most of it from an SEO plugin: Yoast on 32 pages, Rank Math on 7, All in One SEO on 6. These plugins write a tidy site graph, which helps explain the low error rate. What the graph doesn't say is what the page is about: 33% of WordPress pages used the most specific type, and on local business pages the address made it into the markup on 38% of them.

Shopify

Shopify themes write a Product block on product pages, so 14 of 22 Shopify pages used the right type. The gaps are in the details Google's shopping results use: shipping costs and return policies were almost never in the markup (see Online stores).

Webflow and Wix

The two builders behave in opposite ways. Webflow adds nothing by default: 7 of 15 Webflow pages had no structured data, and the 8 that did had no Google or vocabulary errors. All 6 Wix pages had markup, but 0 of the 3 Wix business pages that showed an address had it in the markup. Both groups are small, so treat these as observations, not rates.

Home services were the most likely to name their exact business type (38%); fitness studios (1 of 15), restaurants (1 of 13) and real estate offices (0 of 7) the least. Health practices had the best phone coverage, with the number in the markup on 82% of pages that showed one. Hotels had the phone in the markup on 6 of 14 pages and the address on 5 of 15.

33 of 41 product pages had a Product block and 31 had an offer with a price. Only 5 carried shipping details and 3 a return policy, two fields Google uses in shopping results.

{
  "@context": "http://schema.org/",
  "@type": "Product",
  "name": "Example Avocado Oil, 375ml",
  "brand": {
    "@type": "Thing",
    "name": "Example Brand"
  },
  "offers": [
    {
      "@type": "Offer",
      "sku": "EX-375",
      "availability": "http://schema.org/InStock",
      "price": "34.0",
      "priceCurrency": "USD"
    }
  ]
}

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Example Avocado Oil, 375ml",
  "brand": {
    "@type": "Brand",
    "name": "Example Brand"
  },
  "offers": {
    "@type": "Offer",
    "sku": "EX-375",
    "price": 34,
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock",
    "shippingDetails": {
      "@type": "OfferShippingDetails",
      "shippingRate": {
        "@type": "MonetaryAmount",
        "value": 6.95,
        "currency": "USD"
      },
      "shippingDestination": {
        "@type": "DefinedRegion",
        "addressCountry": "US"
      }
    },
    "hasMerchantReturnPolicy": {
      "@type": "MerchantReturnPolicy",
      "applicableCountry": "US",
      "returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
      "merchantReturnDays": 30
    }
  }
}

15 of 23 SaaS pages had structured data, and 5 described the product as a SoftwareApplication. 10 showed pricing plans; 5 had any plan price in the markup.

Most SaaS markup described the company (Organization) and the website (WebSite), which tells a search engine who you are but not what you sell. A SoftwareApplication block with the category, operating system and plan prices answers the questions people ask before signing up.

WebSite and Organization topped the list, on 141 and 127 of the 206 pages with JSON-LD. Both describe the website and the company behind it, not the page.

Everything below should come from what the page already shows. If the page doesn't say it, leave it out.

You're welcome to use the numbers and charts with a link to this page. The data is under CC BY 4.0.

Last updated October 4, 2026. We plan to repeat the study every year at this address.