Product schema: the properties that decide eligibility

availability expects one of the ItemAvailability enumeration members, written as a schema.org URL: https://schema.org/InStock, https://schema.org/OutOfStock, https://schema.org/PreOrder, https://schema.org/BackOrder, https://schema.org/Discontinued, https://schema.org/LimitedAvailability, https://schema.org/SoldOut, https://schema.org/InStoreOnly and https://schema.org/OnlineOnly.

What turns up in real markup instead is true, Available, in stock, Yes or the label printed on the button. None of those is a member of the enumeration, so none of them says anything. Consumers are known to accept the bare member name without the URL prefix, and you may well get away with InStock, but the documented form is the full URL and it costs you nine characters to be certain. Use it.

Then there is the property that quietly expires. priceValidUntil is a date, and a date in the past says this offer is no longer current. Hardcode it once, or generate it as launch day plus a year, and the block goes from correct to self-cancelling on a morning nobody is watching. Either emit it from something real, a promotion end or a contract date, or leave it out. A stale priceValidUntil is the only property here that can break a page you have not touched in two years.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Fielding 20cm carbon steel chef knife",
  "description": "Forged carbon steel, full bolster, 20cm blade.",
  "sku": "KN-2000-CS",
  "gtin13": "5012345678900",
  "image": ["https://example.com/img/kn-2000-cs-16x9.jpg"],
  "brand": { "@type": "Brand", "name": "Fielding Cutlery" },
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/knives/kn-2000-cs",
    "price": "89.00",
    "priceCurrency": "EUR",
    "priceValidUntil": "2026-11-30",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition",
    "seller": { "@id": "https://example.com/#organization" }
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.4",
    "bestRating": "5",
    "ratingCount": "112"
  },
  "review": [
    {
      "@type": "Review",
      "author": { "@type": "Person", "name": "Marta Iversen" },
      "datePublished": "2026-05-02",
      "reviewRating": {
        "@type": "Rating",
        "ratingValue": "4",
        "bestRating": "5"
      },
      "reviewBody": "Holds an edge far longer than my old stainless one, but it will rust if you leave it wet."
    }
  ]
}

itemCondition is an enumeration too, and it matters more than it looks on any site selling refurbished or used stock, because the default assumption is new. seller references an entity rather than repeating your company name, the same move the Organization guide argues for everywhere else.

aggregateRating is two facts, not one. A ratingValue on its own is a score with no sample behind it, so it needs a ratingCount or a reviewCount alongside it. The two counts are not synonyms and the distinction is worth getting right: ratingCount is how many people scored the product, reviewCount is how many wrote something. A shop with four hundred stars and eleven written reviews has both numbers and they are different.

Declare bestRating if your scale is not out of five. Leave it off and the value is read against the default, so an eight out of ten arrives as an eight out of five, which is the one arithmetic error in this type that a validator will not query.

Then the trap in the title of this page. review needs an author, and the author cannot be you. Google's policy is that ratings come from real customers, and a review of your own product, written by your own staff, marked up as a Review on your own page, is the case it exists to exclude. This is not a technical error and no tool will report it. It is a policy problem, and the remedy is to remove the markup rather than to reword it.

Because nothing on the page stops working. A product page with no markup is crawled, indexed, ranked and bought from. Critical on the severity scale is reserved for failures that take a page out of the running altogether, and this is not one of them. It is also, on most sites, a finding scoped to a minority of URLs: the catalogue, and nothing else.

What lifts it clear of Refinement is that the loss is visible to the person deciding. On a shopping query your result is drawn next to results carrying a price, a stock line and a star rating, and the searcher can see which listing tells them what they wanted to know before they click. Most audit findings cost you something only you can measure. This one costs you a side-by-side comparison in front of the customer, on the exact pages where a click has a transaction behind it, which is why it belongs in a plan rather than in the polish list.

The rating also reflects a fix that is a template change rather than a data project. Price, stock and currency already exist in your system, because the storefront could not function without them. Getting them into the markup is plumbing, and it is the reason this sits below the schema failures whose remedy is somebody starting to record a value nobody records.

Two passes. First the feature question, then the drift question, and the second is the one that matters six months later.

• Read which feature you qualified for. The Rich Results Test names the feature it detected, not just an error count. If it reports a product snippet and you were building for the shopping surfaces, the block is valid and you have cleared the wrong bar.
• Treat the two Search Console reports as separate. Merchant listings and product snippets are reported apart, so a clean row in one and four hundred errors in the other is a real state and not a glitch.
• Compare the block against the page, on a product whose price changed this month. Pick the item most recently repriced rather than a random URL. That is where an export lag shows up.

# the offer, as the page actually serves it
curl -s https://example.com/knives/kn-2000-cs \
  | grep -o '"\(price\|priceCurrency\|availability\)": *"[^"]*"'

# any offer that stopped being valid before today
curl -s https://example.com/knives/kn-2000-cs \
  | grep -o '"priceValidUntil": *"[0-9-]*"' \
  | grep -o '[0-9-]\{10\}' \
  | awk -v today="$(date +%F)" '$1 < today { print "expired: " $1 }'

Run the second command across your sitemap once and you will find out whether anything on the site is emitting a validity date from a previous financial year. It is the cheapest audit in this guide and the one nobody thinks to run, because the block it breaks was correct on the day it shipped.

Last, the sanity check no script does. Say the price out loud with its currency, and say the availability member as a sentence about your warehouse. If either sounds wrong, the markup is describing a different shop.