Product markup that matches what shoppers can see.
We review and update your online store’s structured data, including product details, offers, variants, ratings, shipping, and returns. All updates reflect the information already visible on your site, ensuring search engines and shopping platforms see exactly what your customers see.
What structured data does an online store need?
Each product page should include Product markup with the name, image, description, and brand, as well as an Offer showing price, currency, and availability. For product variants, describe them as a product group. If your page displays genuine reviews, add rating data. Include shipping and return details if they appear on the page. Ensure all values match what shoppers see, as inaccurate or fabricated markup may result in loss of eligibility for rich results.
Google lists the required and recommended properties in its Product structured data documentation.
Stores that should look at this first.
Not every shop needs a full project. These are the situations where a structured data review usually pays for itself.
Stores losing rich results
Price and stock details used to appear beside your listings and then stopped, or Search Console now shows warnings you cannot trace.
Shops that changed platform
After moving to a new theme, plugin set or platform, markup is often doubled up, missing or pointing at old values.
Catalogues with many variants
Clothing, footwear, furniture and food stores have options for size, colour or weight that need careful modelling.
Sellers using Merchant Center
Disapproved products and feed mismatches frequently trace back to page data that disagrees with the feed.
Six areas of a store that carry markup.
A store is more than a product page. We map markup to every template that has facts worth describing.
What we review and build
- Product pages. Name, images, description, SKU, brand and identifiers such as GTIN where you hold them.
- Offers. Price, currency, availability, sale dates and condition, always read from the same data that prints on the page.
- Variants. Sizes, colours and bundles described so each option has its own price and stock, not one blended figure.
- Category and brand pages. Collection and breadcrumb data that explains where each product sits in the catalogue.
- Store identity. Organization details, logo and contact points that tie the shop to one clear entity.
Wider markup planning for non-store pages is handled in schema engineering.
What may be marked up, and what may not.
Search engines compare markup against the visible page. The line between safe and risky is easier to hold than many people think.
| Criteria | Safe to mark up | Do not mark up |
|---|---|---|
| Reviews | Ratings customers can read on the page | Reviews copied from other sites or written by staff |
| Price | The price a shopper pays now | A price visible only in the feed |
| Stock | Availability shown on the page | Always showing in stock |
| Discounts | Sale prices with real end dates | Permanent fake discounts |
| Awards or badges | Ones you can document | Invented trust claims |
Getting variants and prices right.
Variant pages are where most store markup breaks. A shoe in six sizes is one product with several offers, not six unrelated pages.
How we handle them
- One product, many options. Variants are linked to a parent product so Google can group them and show the right price for each.
- Price ranges. When a listing shows a range, the markup reflects the lowest and highest price instead of one random figure.
- Stock by variant. Availability follows the selected option, so an out-of-stock size never advertises as available.
- Currency and region. Multi-currency stores output the right currency for the page being viewed.
Matching Merchant Center data is covered by Merchant Center feeds, since page markup and feed must agree.
Six steps from first crawl to a monitored fix.
Duration depends on catalogue size and platform. The order of work does not change.
- 01
Crawl the store
We sample every template type and collect all structured data currently output, from plugins, themes and apps.
- 02
Validate and compare
Output is tested with Google's tools and compared with the visible page and your product feed.
- 03
Rank the faults
Issues are sorted by effect: missing required fields, wrong prices, duplicates, then optional improvements.
- 04
Implement the fixes
We correct the source, whether a plugin setting, a theme template or a small custom function.
- 05
Test with real products
Simple products, variants, sale items and out-of-stock items are checked one by one.
- 06
Monitor in Search Console
Enhancement and merchant listing reports are watched so new errors are caught early.
Faults that show up on almost every audit.
Most stores carry markup from more than one source. The result is often noisy, contradictory or simply wrong.
Duplicate Product blocks
A theme, an SEO plugin and a reviews app each output their own product data, and they disagree about price.
Missing availability
The Offer has no availability field, or says in stock for items that cannot be bought.
Review markup without reviews
Rating stars appear in code for pages that show no ratings, which risks a manual action.
Wrong currency or sale price
Cached pages show an old price in markup after a promotion ends.
Variants flattened
Every size shares the first variant's price and image.
Broken identifiers
Brand, GTIN or SKU fields hold placeholders such as 'N/A'.
Telling search engines your store policies.
Shoppers decide on delivery cost and returns before buying. Where your pages state these clearly, structured data can carry them too.
What we add where the page supports it
- Shipping details. Cost, destination and handling and delivery time are described for the regions you actually serve.
- Return policy. Return window, method and fees are marked up so they match your returns page word for word.
- Policy pages. Shipping and returns pages are written plainly, since markup can only describe what the pages say.
- Merchant account settings. The same rules are set in Merchant Center so listings and pages tell one story.
Clean policy data is also useful for AI shopping answers that quote delivery terms. Vague wording such as 'fast delivery' gives them nothing to quote, so we help you state real timeframes in plain language, and then reflect them in the code.
What markup cannot do for you.
We are direct about this, because inflated promises about schema are common in the market.
It does not set rankings
Structured data helps systems understand a page. It does not push it above better competitors by itself.
It cannot repair weak pages
Thin descriptions, poor photos and missing prices still hold a product back, whatever the code says.
It does not guarantee stars
Search engines choose when to show enhancements, and they can stop showing them at any time.
Doing it on your own store platform.
The right fix depends on where the markup comes from. We work inside the platform you already use.
Platforms we work with
- WooCommerce. We configure or extend the SEO plugin output and remove duplicates from themes, or write a small plugin if needed.
- Shopify. Theme Liquid templates are corrected and conflicting apps are identified, then removed or configured.
- Next.js and headless stores. JSON-LD is generated server-side from the same product data that renders the page.
- Ongoing checks. After each theme or plugin update, a short test confirms the markup has not changed.
Our SadaPure store and Gifts for Harmain projects both required careful product data.
Store schema, answered.
Straight answers to what clients ask before they start.
Does product schema improve my rankings?
Structured data is not a direct ranking factor. It helps search engines understand the page and can make it eligible for richer results such as price and availability, which may attract more clicks.
Will I get review stars if I add rating markup?
Not automatically. Google decides when to show them, and rating markup must reflect genuine reviews shown on the page. We never add ratings that customers cannot see.
Is the plugin's default schema good enough?
It is often a good start for simple products, though many stores need fixes for variants, sale prices, shipping data or duplicate output from other plugins. An audit tells you which case yours is.
How does this relate to Google Merchant Center?
Merchant Center uses your feed, while search crawls your page markup. When the two disagree, products can be disapproved or lose eligibility, so we align them.
Can you fix errors Search Console is reporting?
Yes. We trace each error to the template or plugin that creates it, fix the source, and ask Search Console to validate the fix.
What affects the cost?
The number of distinct page templates, the platform, how many apps output markup, and whether feed alignment is included. Catalogue size matters less, since templates generate the pages.
How do you test the result?
We run each template type through Google's Rich Results Test and the Schema Markup Validator, compare the output with the visible page and the feed, and then watch the Search Console reports after release.
Will this change how my store looks?
No. Structured data is invisible code. The only visible changes might come from search results, where richer listings can appear over time.
Make your product pages easy to trust.
Send us the link to one product page and one category page. We will return a short report on the markup they output today and what should be fixed first.