Product schema for Nepali stores: NPR, stock and variants

Product schema helps Google understand a product page's offer, but the markup has to match what shoppers can actually buy. A Nepali store should declare NPR when the displayed price is in rupees, update availability with stock, and avoid inventing ratings or reviews.

Here is a minimal single-product example and a variant checklist. Google has separate guidance for product snippets and merchant listings; structured data can make a page eligible for certain appearances but does not guarantee them.

Add a single visible product and offer

Put one JSON-LD block in the HTML of a specific, crawlable product page. The name, image, description, price, currency, stock status and destination should agree with the page. This is an illustrative scarf on example.com; replace every field with your real product data before publishing it:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Himalayan Wool Scarf — Blue",
  "image": [
    "https://example.com/images/blue-scarf.jpg"
  ],
  "description": "Blue wool scarf, 180 cm by 30 cm.",
  "sku": "SCARF-BLUE-01",
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/products/blue-scarf/",
    "priceCurrency": "NPR",
    "price": "2490.00",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition"
  }
}

The price value uses digits and a decimal point; priceCurrency is the three-letter ISO currency code. If an item is out of stock, update the visible page and use the matching schema availability URL. Do not keep InStock in the markup after your store says unavailable.

Decide whether variants need separate URLs

Size and colour choices can be represented as a family of products using Google's ProductGroup guidance. Think through the URL structure before writing markup. Can a shopper open the blue medium scarf directly, or do they have to choose options after loading the parent page? Your schema and canonical URLs should reflect the actual shopping experience.

Do not create many near-identical, thin variant pages solely for markup. Give shoppers a usable selection interface and search engines consistent identifiers.

Validate the page and keep the feed in sync

1. Paste the live URL into Google's Rich Results Test. Check detected product items and errors.
2. Inspect the rendered page to confirm that shoppers see the same product, currency, price and stock state.
3. Test an out-of-stock and a variant URL, not just your best-selling product.
4. After deployment, watch the Search Console product enhancement reports if they are available for your property.

Google may apply additional rules for merchant listings, and account or regional eligibility can vary. Check the current official requirements rather than assuming that adding JSON-LD creates a shopping listing. The broader ecommerce SEO guide covers category pages, product content and internal links.

Avoid three common implementation errors

First, do not put one generic Product object on every category page. Use product markup on pages where a shopper can understand and buy the item. Second, do not copy a five-star aggregateRating value from a template when no real, visible review data exists. Third, do not let stale schema prices survive a sale, currency switch or stock change. Server-rendering the current offer from the same product source used by the page reduces drift.

If you have many products, test a small set of representative page templates, then monitor the output after every catalogue change. Schema is one part of store SEO; accurate products and a trustworthy checkout remain essential.

Make the markup part of the product workflow

For a small store, the safest implementation is to populate structured data from the same product record that renders the visible price, SKU and stock status. If staff update inventory in a CMS, the schema output should change automatically. In a template review, inspect the page source for one in-stock item, one sold-out item and one item with colour or size choices. A single successful test page cannot prove every template state works.

For each variant, keep a simple worksheet with its displayed name, SKU, selectable attributes, public URL, price and availability. If two variants share a URL, document how the selected option is expressed to users and to Google's variant model. Avoid adding optional claims such as ratings, shipping prices or return policies until the site can keep them accurate. Test after a sale or stock update, when stale values are most likely to appear.

Sources and further reading

• Google Product structured data
• Google Product variant structured data
• Google Rich Results Test