What structured data do Spanish online stores publish on their product pages?

An online store that sells in Spain has two readers on every product page: the shopper, who looks at the photo, the price and the reviews, and the program that reads the page to work out what it sells, at what price and whether it's in stock. The second reader is the one structured data speaks to: a block that describes the product in a fixed format, almost always JSON-LD with the Schema.org vocabulary. The question this study asks is simple, and the public figures don't answer it with Spanish data: what structured data do the product pages of stores selling in Spain actually publish, and how much of it is correct?

Correct means four things at once: the markup is there, it says what it needs to say, it reaches whoever reads the page even if they don't run JavaScript, and it matches what the shopper sees. We measure all four, page by page. We also publish what went right, because a study that only counts failures overstates the problem.

Why it matters to a store selling in Spain

Buying online is already the norm in Spain: 59.6% of people aged 16 to 74 bought something online in the last three months, according to the 2025 survey by INE, Spain's National Statistics Institute, and 37.9% used a generative AI tool over the same period.⁠^{[1]National Statistics Institute (INE). Survey on Equipment and Use of Information and Communication Technologies in Households. Year 2025}

On Google, what a machine can read from a product page follows written rules. For a page to appear in merchant listings, Google's experiences for pages that sell a product, the Product markup needs three required properties (the name, the image and an offer), and the offer needs a price and its currency.⁠^{[2]Google Search Central. Merchant listing (Product, Offer) structured data} Only pages where the shopper can buy the product are eligible, not pages that link to another store that sells it.⁠^{[2]Google Search Central. Merchant listing (Product, Offer) structured data} A page that talks about a product without selling it, a review for example, can qualify for a product snippet, and all it needs is the name plus a review, an aggregate rating or an offer.⁠^{[3]Google Search Central. Product snippet (Product, Review, Offer) structured data}

The rest is recommended: the GTIN and the other global identifiers, the MPN, the brand and the aggregate rating (AggregateRating).⁠^{[2]Google Search Central. Merchant listing (Product, Offer) structured data} Recommended doesn't mean decorative. According to GS1 Spain, the 13-digit GTIN identifies units meant for the point of sale, and it can only be generated from a GS1 company prefix:⁠^{[4]GS1 Spain. GTIN} it's the shortest way to say, without ambiguity, which exact product this is.

And one rule weighs more than all the others: structured data has to be a true representation of the page's content, and you don't mark up content that the page's readers can't see.⁠^{[5]Google Search Central. General structured data guidelines} A price in the markup that doesn't match the one on the page isn't a technical detail. It's the page contradicting itself.

What's already known, and why it isn't enough

There are public figures on structured data, and they're good ones. HTTP Archive's Web Almanac analyzes millions of websites worldwide every year: the 2025 edition starts from 16,213,084 sites, taken from the Chrome UX Report and crawled in July 2025.⁠^{[6]HTTP Archive. Web Almanac 2025: Methodology} Its SEO chapter reports that 50% of home pages carried structured data in 2025, on desktop and on mobile, and that 43% carried JSON-LD; among inner pages, 39% carried JSON-LD on desktop and 37% on mobile.⁠^{[7]HTTP Archive. Web Almanac 2025: SEO} The same chapter says most sites deliver their structured data in the initial HTML, and that JavaScript added it in only 2% of crawls.⁠^{[7]HTTP Archive. Web Almanac 2025: SEO}

The 2024 structured data chapter gives the figure for one specific type: Product appeared in JSON-LD on 0.77% of the pages analyzed.⁠^{[8]HTTP Archive. Web Almanac 2024: Structured Data} The base is the whole web, with its blogs, its newspapers and its company pages, so the figure doesn't say what share of product pages carry Product.

Nor can the worldwide picture of ecommerce platforms be carried over to Spain. The Web Almanac itself explains that the leading platform changes from one region to another, because of language, local payment methods, the agency ecosystem and each vendor's history.⁠^{[9]HTTP Archive. Web Almanac 2025: Ecommerce} And the platform and its theme can decide much of a product page's markup, as the study From stored data to published data shows on Shopify and BigCommerce. That's why this study reads Spanish stores and records each one's platform.

How we measure it

The data comes from the Corpus, the crawl of online stores run by the team that publishes this library. That same team builds a tool that reads stores' structured data, so the method is written for anyone to repeat with public tools: an HTTP request, a headless browser and a JSON parser.

The sample

A store enters the sample if it sells to shoppers in Spain: prices in euros, shipping to Spain and a Spanish-language version of the product page. Within that frame, the sample is spread across sectors and platforms, so that no single sector or platform decides the result. Each store's platform is recorded as its HTML and headers give it away, and one that can't be identified is recorded as unknown, not guessed.

On each store we read a fixed number of product pages, picked at random from the product URLs in its XML sitemap. A store with fewer product pages than that number goes in with all it has. Product pages only: category pages and home pages are left out, because they're a different question.

Two reads of every page

1. The HTML without JavaScript. A GET request that runs nothing: what a crawler that doesn't render receives. We keep the status code, the final URL, the headers and the body.
2. The rendered DOM. The same URL in a headless Chromium, which loads the page and runs its JavaScript, as Google does in its rendering phase.⁠^{[10]Google Search Central. Understand JavaScript SEO basics} We keep the DOM, the visible text and every application/ld+json block.

Comparing the two reads tells you where the markup comes from: whether it was already in the HTML the server sends, through server-side rendering, or whether it only appears after JavaScript rendering. The difference matters because Google can read JSON-LD that a script injects,⁠^{[11]Google Search Central. Introduction to structured data markup in Google Search} but warns that dynamically generated product markup can make Shopping crawls less frequent and less reliable, a problem for price and availability,⁠^{[12]Google Search Central. Generate structured data with JavaScript} and because not every bot can run JavaScript.⁠^{[10]Google Search Central. Understand JavaScript SEO basics} What each AI crawler does with JavaScript is covered in the guide What an AI crawler sees in your store.

What we measure on each page

• Format. Whether there's JSON-LD, microdata or RDFa, and how many blocks of each. Google supports all three and recommends JSON-LD, the easiest to maintain at scale.⁠^{[11]Google Search Central. Introduction to structured data markup in Google Search}
• Product. Whether there's a Product node, and with which properties: name, image, description, brand and offer. Schema.org defines Product as any product or service on offer.⁠^{[13]Schema.org. Product}
• Offer. Whether the offer gives a price, a currency and availability, the three properties Schema.org uses to describe it.⁠^{[14]Schema.org. Offer} On a Spanish store, the expected currency is the euro.
• AggregateRating. Whether the product declares an aggregate rating, with its value and the number of ratings or reviews behind it.⁠^{[15]Schema.org. AggregateRating}
• Identifiers. Whether there's a GTIN in any of its forms, and an MPN.⁠^{[13]Schema.org. Product} A GTIN also gets checked from the inside: its last digit is a check digit, calculated from the digits before it, and it's there to catch errors.⁠^{[16]GS1 Spain. Cálculo de dígito de control GTIN} A GTIN with the wrong check digit isn't a valid GTIN.
• Validity. Whether each block can be parsed: a JSON-LD document is always a valid JSON document,⁠^{[17]W3C. JSON-LD 1.1} and a block with a syntax error tells nobody anything. And whether the Product has the properties Google requires for a merchant listing.⁠^{[2]Google Search Central. Merchant listing (Product, Offer) structured data}
• Consistency with the page. Whether the price, availability, name and rating in the markup are the ones the shopper sees in the page's text.⁠^{[5]Google Search Central. General structured data guidelines} And whether there are two or more Product nodes for the same product and, if so, whether they agree or contradict each other.

Before comparing, each value is normalized the same way in the markup and on the page: whitespace collapsed, HTML entities decoded and the price as a number plus a currency. That way a price written on the page with a decimal comma and the euro sign, and the same number written in the markup with a decimal point and EUR, count as the same price.

How we classify each page

• No markup: no structured data at all.
• Markup without Product: there's structured data, but none of it describes the product.
• Incomplete Product: a property required for a merchant listing is missing.
• Complete Product: it has a name, an image and an offer with a price and a currency.
• JavaScript only: the Product is missing from the HTML and present in the rendered DOM.
• Invalid: the block can't be parsed as JSON.
• Inconsistent: the markup gives a price, availability or rating that differs from the visible one.
• Conflicting duplicate: two Product nodes give different values for the same property.

A page can fall into more than one class: a complete Product can also be JavaScript only and inconsistent.

Results

What didn't fail, and what went unmeasured

Some things this method doesn't measure from the start:

• Whether Google shows the page with rich results. Reading the markup tells you whether the page is eligible, not whether Google will show it that way: structured data doesn't guarantee it.⁠^{[11]Google Search Central. Introduction to structured data markup in Google Search}
• Whether an AI cites the store. Google says structured data isn't a requirement for its generative AI features, and that there's no special markup to add for them.⁠^{[18]Google Search Central. Optimizing your website for generative AI features on Google Search} This study measures what the page publishes, not what an assistant does with it.
• What each bot reads. We read the HTML with the crawl's user agent, not with each company's, and a store can serve something else under another name.
• The rest of the store. Category pages, home pages and content pages are left out.

What it means

Until there are results, this is the frame for reading them, rule by rule, with what each rule's source says:

• A page without Product, or without an offer with a price and a currency, isn't eligible for Google's merchant listings. Those are the required properties.⁠^{[2]Google Search Central. Merchant listing (Product, Offer) structured data}
• A page without a GTIN is still eligible. The GTIN is recommended, not required,⁠^{[2]Google Search Central. Merchant listing (Product, Offer) structured data} and what the page loses is the unambiguous way to say which product it sells.
• A Product that only exists with JavaScript reaches Google with more risk, and doesn't reach some bots at all. Google warns of less frequent and less reliable Shopping crawls,⁠^{[12]Google Search Central. Generate structured data with JavaScript} and a bot that doesn't run JavaScript doesn't see it.⁠^{[10]Google Search Central. Understand JavaScript SEO basics}
• Markup that contradicts the page is the most serious defect on the list. It breaks the rule of faithfully representing the content,⁠^{[5]Google Search Central. General structured data guidelines} and it's the only one on the list that hands whoever reads the markup false data.

To check all this on your own product page, the comparison Validating structured data vs verifying it's published explains the difference between markup that's valid and markup that's published. Google's tool for the job is the Rich Results Test, run on the URL rather than the code, as Google recommends for markup that JavaScript generates.⁠^{[12]Google Search Central. Generate structured data with JavaScript}

Limits

• A sample, not a census. The percentages hold for the pages and stores measured, with their split by sector and platform, not for all of Spanish ecommerce.
• One crawl, one moment. A page that's fine today can change tomorrow with a new theme, an app or a sync: that's data drift.
• The starting list decides. Stores that aren't on the candidate list can't enter the sample, and that list has its own biases.
• Consistency is measured by automatic extraction. Reading a page's visible price by machine can go wrong, for example with discounts or variants, so a subsample is checked by hand.
• Reading isn't testing. The study changes nothing on any store, so it can't show why a page is the way it is; it can only describe it.

The data

Each page read is one row of the dataset, with these columns: run_id, datetime_utc, store_id, platform, sector, url, http_status, formats, jsonld_blocks, has_product, product_props, has_offer, price, price_currency, availability, has_aggregaterating, rating_value, rating_count, gtin, gtin_check_ok, mpn, brand, in_raw_html, in_rendered_dom, parse_errors, visible_price, visible_availability, visible_rating, consistent, product_nodes, conflict, classes and notes. Stores are published with a code, not their name.

The rest of the concepts for describing your catalog to a machine are laid out in order in the structured data reading path.