The product page as Google sees it: what we found in 30 stores

On 8 August 2026 we opened the product pages of thirty live online stores. Stationery, optics, household chemicals, textiles, footwear, jewellery, power tools. We do not name the stores; we do name the niches.

We were not looking with a shopper's eyes. A shopper sees a photo, a price and a button. What interested us was the other reading of the same page: what a search crawler and a marketplace parser get out of it. In other words, structured data — product markup, price and availability markup, machine-readable specifications.

Three numbers from that measurement:

For a machine, two thirds of those pages are plain text. Good text, with photographs and a manufacturer's description. But with no hint at all about which part is the product name, which is the price and which is the availability.

Why this is not cosmetic

Google reads a product page the way it reads any other: it tries to guess. Sometimes the guess is right. JSON-LD markup removes the guessing — it states outright that 1,890 ₴ is a price in hryvnia, not an article number, not a weight and not a model code.

The consequence shows up in the results page. Without an Offer block there is no price and no availability label under your result's heading. The page still ranks, but in a list of ten it looks like a paragraph of text next to results where the price is visible at a glance. That is a question of screen area and of what the eye catches, not of position.

The second consequence, often the weightier one for Ukrainian e-commerce, is the feed. Rozetka, Prom and Google Merchant Center all want machine fields: name, price, currency, availability, specifications. When the page carries no markup, the feed is assembled separately — a database export, or a script that has to be patched every time something changes in the catalogue. A store with a marked-up page hands over the same fields almost for free. How much work the field mapping alone takes is spelled out in our breakdown of the Rozetka integration.

Broken down by niche

The sample is small, and every individual figure in it should be read as an observation rather than as market statistics. The spread is still visible.

Six niches account for exactly the ten we counted in total. So among the three power-tool pages there was no product markup at all. And that is the niche with the largest catalogues in the whole sample: the median is 19,962 URLs in the sitemap, the largest catalogue 32,623. Twenty thousand pages, every one of them a wall of text as far as search is concerned.

One more observation from the same table: within every niche the Product and Offer counts matched exactly. Markup appears to be either fully in place or entirely absent. That is rather good news — the problem is not a small oversight during implementation, it is that nobody got round to the task.

The deepest hole is the specifications

Four of thirty. Both niches where they turned up are textiles (2 of 5) and footwear (2 of 5). In the remaining stores the specifications are on the page, they simply sit in a form only a human can use: a table saved as an image, a paragraph inside the description, a PDF datasheet.

For a machine that is zero. Size, material, wattage, compatibility — precisely the things a shopper filters by and a marketplace uses to file the product into a category.

Syntactically, specifications live in the additionalProperty field inside Product:

"additionalProperty": [
  { "@type": "PropertyValue", "name": "Material", "value": "100% cotton" },
  { "@type": "PropertyValue", "name": "Size", "value": "200×220 cm" }
]

There is a precondition here that cannot be skipped: to hand specifications to a machine, they have to exist in the database as separate fields, not as a chunk of HTML inside the description. Stores where specifications were typed in as text for years go through normalisation first, and that is longer work than the markup itself. What a healthy page looks like is described in our product page quality scoring.

What follows the specifications

During the same sweep we also looked at features that cannot be built without structured specifications. Filtering by specification worked on 9 sites of 30, product comparison on 9 of 30 as well. The numbers are suspiciously close, and the reason is the same one: a filter cannot be built over a field that does not exist in the database, and a comparison without a shared set of fields turns into two columns of solid prose.

Rating markup stands apart: we found it on 3 sites of 30. This is the item where haste does not pay. A marked-up rating with no real reviews on the page is exactly the kind of discrepancy that earns a manual action. Reviews first, markup second, never the other way round.

Now with a shopper's eyes

The same sweep, the same thirty pages, but this time we looked at the buttons.

One-click purchase — a third of the sample. We will not claim it lifts anything: we did not measure that, and somebody else's percentages are worth nothing here. We will describe the mechanism instead. A two-field form in place of full checkout removes one specific barrier — having to invent a password and fill in ten lines for a two-hundred-hryvnia item. For expensive equipment with a long decision it barely matters; for cheap repeat purchases it does. How it works technically is covered in one-click purchase.

Instalment payment — seven of thirty, and the most expensive item on the list. It needs a bank agreement, a separate integration and ongoing support. Adding it for the sake of having it makes no sense; it is justified where the average order value genuinely makes people do arithmetic.

Free delivery above a threshold — three of thirty, and this is where the gap between implementation cost and adoption is widest. It is a rule in the cart plus a line on the product page, roughly a day of work. It guarantees nothing, but it gives the shopper a reason to add one more item instead of leaving. The mechanics and the limits are in free delivery above a threshold.

Checking your own page takes five minutes

Open any product page of your own store and take three steps.

Start with Google's rich results test. You paste the URL and it shows which markup types it can see and which of their fields are empty. If the answer is empty, press Ctrl+U and search the page source for application/ld+json — that confirms there is no markup at all.

Next you have to assemble a correct block. We have a Schema.org builder for that: fill in the fields, get ready JSON-LD without typing quotes and commas by hand. A general walkthrough of the formats and types sits in the article on JSON-LD structured data, and the page as a whole — photos, description, price and availability included — is checked by our product page audit.

And the rule to keep in mind throughout: you may only mark up what is genuinely on the page. The price in the markup matches the price a human sees. Availability matches real stock. Ratings match real reviews that are visible on the page. Google treats a discrepancy as an attempt to deceive, and the penalty here is a manual action, after which rich results disappear for a long while. We drew the same line in our technical checklist for online stores, which also carries the basic Product block for a page.

The order of work barely depends on the platform. Product with a name, photo and SKU comes first — the cheapest step, and it closes half of what a parser complains about. Then Offer with price, currency and availability, because that is the block responsible for what appears in search results and what the feed takes. Then additionalProperty, but only once the specifications have become database fields rather than a paragraph of description. Breadcrumbs and ratings come last, each with its own precondition.

What this will not give you

Markup does not lift positions. Google says so plainly, and we will repeat it in our own words: none of the ten stores where Product and Offer are in place gained any ranking advantage from them.

Two other things change. The first is how your result looks once it is already shown: price, availability, breadcrumbs instead of a bare URL. That is not a guarantee either — Google decides on rich results itself and can change its mind.

The second, usually more important for a store, is that a marked-up page feeds a product feed. Data that already sits in a machine format does not have to be scraped out of HTML every time you open a new sales channel.

Twenty stores in our slice are still paying for this with manual work. And judging by the fact that markup is either fully present or entirely missing, most of them do not even know the bill exists.