Product Schema Markup for Online Stores in Uzbekistan

Product schema markup is a block of structured data in a product page's code. Shoppers never see it, but search engines read it: name, price in sums, availability, rating. Here is which fields matter, where stores usually go wrong, and how to test the result.

Why product schema markup matters for a store

A search engine reads a page as text, and it cannot always tell whether the number next to the Buy button is a price, an article code or a sales phone line. Schema.org markup removes the guesswork: the Product type describes the item itself, and a nested Offer describes the terms of purchase.

In practice, this can make price, availability and ratings eligible to appear in search results, helps product listings pick up your pages, and lets your catalog be understood as a whole. Nothing is guaranteed, because Google decides what to show. Without correct markup, though, you have no chance at all. For a shop competing with Uzum and OLX listings, a richer result in Google is one of the few ways to stand out without an ad budget.

Which Product properties to fill in

Start with data that already sits in your product database. You do not invent anything. Every field must match what a visitor can see on the page.

  • name: the same title the product page shows;
  • image: links to real product photos, ideally from several angles;
  • description: a short, unique text rather than a supplier copy-paste;
  • brand: the brand or manufacturer;
  • sku for your internal code, gtin for the barcode when one exists;
  • offers: the offer with price and availability;
  • aggregateRating and review: only when reviews are genuinely published on that page.

Offer: UZS prices and availability

Offer is where most mistakes happen. Write the price as a plain number with no spaces, no thousands separators and no word for the currency. The currency goes in as an ISO 4217 code, which for the Uzbek sum is UZS, not “sum” or “so‘m”.

Availability uses the standard Schema.org values such as InStock, OutOfStock and PreOrder. Add the page url, and if a sale price ends on a certain date, include priceValidUntil. If you sell anything other than new items, itemCondition is worth adding.

The golden rule: markup must match the visible page

The price and availability in the code must equal what the shopper sees on screen. If the markup says one price and the page shows another, Google may switch off rich results for the whole site, not just one product.

The usual culprit is caching. A page rebuilds once a day, while a manager changed the price at noon. Another case: an item sells out, the page says “out of stock”, and the markup still says InStock. The fix is technical: generate the markup from a template, using the same data and at the same moment as the visible price. Pasting JSON by hand into product pages should not happen.

Variants, “price on request” and category pages

When a product has colors or sizes with different prices, the approach depends on how your page works. One page with a variant switcher can use several Offer entries or an AggregateOffer with a low and high price. If every variant has its own URL, each gets its own Product, and Google also supports product groups for linking variants together.

If your site hides the price and tells customers to “ask in Telegram”, you cannot honestly fill in price. You can leave Product without an offer: no price snippet will appear, but you also will not be breaking the rules. Entering a fake price for a nicer snippet is a direct route to penalties.

Category pages do not need full Product markup for every listed item. Detailed markup belongs on the page where one specific product is presented.

Testing, feeds and common mistakes

Spot-check several different product pages with Google's Rich Results Test. Then watch the product reports in Search Console, which gather errors and warnings across the whole site. Fix errors first and recommended fields second. For Yandex, the markup validator in Webmaster is available.

If you send products to Google Merchant Center or a Yandex feed, keep a single data source for the site, the markup and the feeds. When feed prices and site prices disagree, products can be rejected. Before you hand a template to your developer, compare it against these common mistakes:

  • prices with spaces or a currency symbol;
  • the currency written as a word instead of UZS;
  • availability that never changes after a sell-out;
  • ratings on products that have no reviews;
  • Product markup output on category pages;
  • image links that point to deleted or private files.

Where to start

The easiest path is to take one product template, connect the markup to your database fields, test it, and only then roll it out across the catalog. If you want help with the template or an audit of markup you already have, markdev works on SEO optimisation in Uzbekistan. Tell us about your store and platform, and we will talk through where to begin.

FAQ

What is product schema markup in simple terms?

It is structured data in a page's code that tells search engines a product's name, price, currency, availability and rating in a machine-readable form. Visitors do not see it.

Which currency code should I use for the Uzbek sum?

UZS. Write the price as a number only, with no spaces, no word “sum” and no currency symbol.

What if we do not show prices on the website?

Do not enter a placeholder value. You can mark up Product without an offer, but no price-based rich result will appear.

Does markup guarantee a rich result?

No. It makes your page eligible, but the search engine makes the final call. Markup that does not match the page can even cause harm.

How can I test my markup?

Use Google's Rich Results Test, the product reports in Search Console, and the validator in Yandex Webmaster.

Let’s look at your task for free

Leave your contact — in a 15-minute call we’ll show where leads get lost and what to fix first.