What Is Product Schema Markup?
The type with the sharpest commercial consequence. Price and availability can appear in a result, which means a wrong assertion is discovered by a customer before they reach your site rather than by anybody looking at a report.
This One Is Visible To Customers
Price, availability and ratings can all be shown in a search result. That makes this the only type where a wrong statement is seen by somebody deciding whether to visit, rather than found later by whoever audits the site.
What appears where. Before the click.
A result can carry the price, whether the item is in stock and a star rating, all drawn from what the page asserts. Somebody reads those and decides on that basis.
Why that changes the stakes. Two failures at once.
A wrong price loses the sale twice: once when somebody arrives expecting the figure they saw, then again when they conclude the store is unreliable. Neither shows up as an error anywhere.
What it asserts overall. The commercial facts.
Name, description, identifiers, price, currency, availability and any ratings. Almost all of it is information a customer uses to decide, which is why almost all of it has to be current.
Why the reporting will not catch it. It is valid.
A price that is wrong is still a properly formed price. Nothing about the markup fails, so no check reports anything and the first signal is a complaint or a lost order.
Price And Availability Go Stale Instantly
These two properties change more often than anything else asserted anywhere in this subject. A result showing a price you no longer charge is a complaint waiting to happen.
How quickly they move. Continuously.
Stock changes with every order. Prices change with promotions, supplier costs and seasonal adjustment. Neither is a value you set once, which makes both unlike almost every other property in this section.
What that requires. Automatic updating.
Anything maintained by hand will be wrong. These properties only work where the markup is generated from the same records the shop uses, so that changing the record changes the assertion.
The lag nobody accounts for. Between change and result.
Updating the record updates the page immediately and does not update what a search result shows. That gap is real and outside your control, which is worth knowing before promising a customer anything.
What to do about the lag. Honour what was shown.
Where somebody arrives quoting a price from a result, the practical answer is usually to accept it. Arguing that the result was out of date is technically correct and commercially poor.
The version that is not a lag. A record nobody updated.
Where the underlying data is simply wrong, the assertion is wrong indefinitely rather than briefly. That is block three.
Generated From The Feed, Which Nobody Reads
On most stores this markup is produced automatically from the product records. It therefore asserts whatever those records say, including everything wrong with them, on every product at once.
Where the records come from. Several places.
Typed at upload, imported in bulk from a supplier, else synchronised from another system. Each route introduces its own errors and none of them involves anybody reading the result.
Why nobody reads them. Volume.
A store with a few thousand products has a few thousand descriptions nobody has checked. Reading them is not a task anybody has time for, so the errors sit there being asserted.
What that produces. False statements at scale.
A supplier feed with wrong specifications, a bulk import with a mispositioned column, a category filled in by default. Each becomes an assertion repeated across every affected product.
Why this is worse than a manual error. Nobody chose it.
A hand-written mistake was made by somebody who might notice. An inherited one was never seen by anybody in the business at all, which is a different kind of exposure.
What to check instead of pages. The source.
Since the markup inherits, checking a sample of records catches more than reading pages. The platform page covers the same argument for other generated markup.
Discontinued And Out Of Stock
Availability has values for out of stock and discontinued. Using them is the correct answer. Marking something available because the page still exists is exactly the assertion this section refuses.
The difference between the two. Temporary and permanent.
Out of stock means coming back. Discontinued means gone. Those are different statements and the vocabulary distinguishes them, which is useful to somebody deciding whether to wait.
Why stores get this wrong. Inertia.
A product sells out and the page remains, still asserting availability because nobody changed the record. The store is now stating that something can be bought when it cannot.
What that costs. A wasted visit and worse.
Somebody clicks a result showing an item as available, arrives and cannot buy it. That is the same failure the local business page describes about opening hours, applied to money.
What to do with a discontinued page. Not simply delete it.
Removing the page leaves links pointing nowhere. Marking it discontinued while pointing people at what replaced it serves everybody better. Our ecommerce material covers the options.
The test that settles it. Could a customer buy it today.
If not, the markup should not say otherwise. That is the whole rule and it takes no interpretation.
Variants
Products with options need describing as one product with variations rather than as several unrelated products or as one product with a single arbitrary price. Getting it wrong produces either duplication or missing items.
What a variant is. A version, not a product.
The same item in a different size, colour or specification. Each may have its own identifier, its own price and its own stock position, while all of them are the same thing.
The first way it goes wrong. Treating each as separate.
Describing every variation as its own product produces a store apparently selling many near-identical things. That is duplication. It makes the range harder to understand rather than easier.
The second way. Describing only one.
Asserting a single price and availability for a product with a range of both. Somebody sees the cheapest option in a result, arrives, then finds their size costs more.
What the correct shape looks like. One product, many offers.
A single product carrying several priced options, each with its own availability. That describes the situation accurately and handles a price range without misleading anybody.
Why this is worth getting right. It affects what a customer sees.
Variants done badly are visible in results as wrong prices or absent items, which returns to block one.
Ratings On Products
Only real reviews from real customers about the product on that page. Never aggregated from elsewhere, never written by the business, never applied to a product nobody has reviewed.
Why it is stated here as well. Products are where it happens.
A star rating beside a product in a result is visibly valuable. A store with thousands of products has thousands of opportunities to invent one. That combination is why this rule gets restated.
What the markup claims. That people rated it.
A rating asserts that real customers gave real scores averaging that figure for that product. It is a factual claim about the world rather than a presentational choice.
The specific error stores make. Site-wide ratings on products.
Applying an overall store rating to every individual product. Those customers rated the store rather than that item, so the assertion is false even where every review is genuine.
The other one. Ratings from a platform.
Scores collected on a third-party marketplace generally belong there. Restating them as the site's own is a common misunderstanding rather than deliberate deception. It is still wrong.
Where the full argument sits. Its own page.
Review markup argues this in full. How to get star ratings covers what we will and will not implement.
Do Not Mark Up What Is Not On The Page
Every property should correspond to something a customer can see. Asserting details the page does not display is the usual way this type becomes untrue without anybody intending it.
Why it matters even when true. Nobody can check.
A property stated in markup and absent from the page cannot be verified by a reader. The markup and the page should describe the same thing, so a customer can confirm it.
The usual instance. Hidden properties.
Specifications held in the product record but not shown, asserted because the field existed. Frequently accurate and still a claim nobody can confirm from the page.
The deliberate version. Enriching the markup.
Adding properties specifically to qualify for an appearance while leaving the page unchanged. That is describing a page that does not exist. It is the same error as inventing a rating.
What to do instead. Show it.
Where a property is worth asserting, put it on the page. That resolves the problem correctly and improves the page for the customer at the same time.
How we apply this to ourselves. On this page.
This guide describes the product type and is not a product, so it carries no product, price or rating markup at all. The full series is on the schema and structured data guide.
Could a customer
buy it today?
If not, the markup should not say otherwise. We generate product descriptions from the same records your shop uses, so changing a record changes the assertion. We check a sample of the records rather than reading pages nobody has time to read.
On every page we build:
We will not apply a store rating to individual products. Those customers rated the store.
Every guide.
One practice.
What structured data is, which types apply to your business, how to test it, where the results features come from and what to do when nothing appears.
