A customer usually needs only a few seconds to find the information that matters to them on a product page. It quickly becomes clear what the product is, how much it costs, whether it's available, who makes it, and in many cases even when it might arrive. But what's obvious to a human is much harder for a search engine to identify with certainty.
A product page can display a list price, a sale price, shipping costs, an SKU, stock information, a brand name and plenty of other data all at once; Google's job is to work out which piece of information means what and how it relates to the product. This is where structured data helps. Its brilliance lies in the fact that it doesn't add new content to the page — it makes the information that's already there unambiguous, in a standardised format.
For webshops this is especially significant. With Product and Offer markup you can precisely specify, among other things, the product's name, price, currency, availability, SKU or GTIN. Google can use this data in various product displays, so with a proper implementation a product page can appear with richer information than a traditional search result.
That's why structured data shouldn't be treated as a standalone technical SEO task. In a modern webshop it's part of the same product data system as the product name, the price or the stock status — and it can directly help search engines understand your catalogue more accurately and present it better.
Product and Offer: they describe two different things
At first glance the two concepts may seem identical or similar in purpose, yet they play quite different roles in describing product data.
Product identifies the product itself; this can include its name, description, image, brand, SKU, manufacturer part number or GTIN — in other words, all the data that makes it unambiguous exactly which product we're talking about.
Offer, by contrast, describes the merchant's specific offer. This is where the price, the currency, the stock status, the product's condition and the page where it can actually be purchased appear.
The distinction matters because the same product can be sold by many webshops under different conditions. A Bosch drill is the same product at every retailer, yet at one store it's available immediately for HUF 42,990, while elsewhere it costs HUF 39,990 but ships only in two weeks. Product tells you what the product is; Offer tells you on what terms it can be bought in a given webshop.
It may sound like a technical detail, but it's precisely this separation that makes structured data truly useful in a commerce environment.
Merchant listing is not yet another schema type
Alongside Product and Offer, the term merchant listing comes up frequently, so it's easy to assume it's a third type of structured data. That's a common misconception — it's not another schema type, but one of Google's commerce-oriented display formats.
The data for these results can come from, among other sources, your Product and Offer markup. Google treats the requirements for traditional product snippets and merchant listings separately, because the latter applies specifically to pages where the visitor can actually buy the product. That's why, alongside price and stock, even shipping or return information may be displayed.
The difference is worth dwelling on for a moment, because it's a frequent source of confusion. Let's look at an example... A trade magazine can publish a detailed review of a phone and use Product structured data for it — that doesn't turn it into a webshop. A webshop's product page, however, carries an actual commercial offer, so the Offer data plays an important role too. With merchant listings, then, it's not enough to tell Google what the product is. The search engine also needs to understand the terms on which that particular merchant is offering it.
In search results, even the price can influence the click
Classic SEO was for a long time about the title and meta description a page appears with in the results list. For webshops, far more information can now reach the customer before they ever visit the site.
If Google knows the exact price, stock status or other product data, it can use them in certain search displays. Merchant listing features can appear in Google Search, in Google Images, in product results and in Shopping-style environments, among others.
When someone sees several similar products side by side, price and availability status can influence which store they click on right there among the search results. It's by no means certain that the result with the prettiest meta description attracts the visitor. It's entirely plausible that the one showing, at a glance, that the product is in stock and available at a reasonable price gets the advantage.
That said, it's important to understand that structured data guarantees nothing automatically. Proper markup can make a page eligible to display certain information, but Google doesn't promise to show it for every search. Even so, in the era of AI-powered search, we wholeheartedly recommend the consistent use of structured data to every webshop.
A wrong price is worse than missing data
There's a basic principle with structured data that you should never lose sight of: what you tell the search engine must match what the customer actually sees on the page.
If the product costs HUF 49,990, no other amount may appear in the markup. The same goes for stock: a sold-out product can't remain marked InStock just because the structured data wasn't updated in time. Google's expectation is clear — the data in the markup must be consistent with the content of the product page, which is exactly why a webshop should never hand-craft a JSON-LD block and then abandon it for months. Product data changes constantly: prices shift, products sell out or come back into stock, promotions launch, sales conditions change.
If the structured data has no direct connection to the webshop's actual product data, a discrepancy will develop sooner or later — we'd bet big money on it, if anyone were willing to take the bet. At that point you're no longer dealing with technical optimisation but with a data quality problem. This is where it becomes especially important how the webshop engine itself manages and refreshes this information.
Structured data and the Merchant Center feed are not the same thing
In webshop circles the question often comes up: if you have a Merchant Center feed, do you need structured data at all — or the other way round, if Google can read the information straight off the product page, why send a separate feed?
We often point out that in practice you shouldn't have to choose between the two. Structured data lives directly on the product page, so Google can interpret the current price, stock and other product information from there. Merchant Center, on the other hand, receives the commercial data as a separate data source, which it can use for Shopping ads and free product listings, among other things.
What's more, the two sources can complement each other. In certain cases, Merchant Center's automatic updates can use the structured data found on your website to detect changes in price, stock or sale price. This doesn't replace regular feed updates, but it can reduce the chance of outdated information lingering in the system.
If a product's price changes in the evening, for instance, Merchant Center may still carry the old value while the product page and the structured data already show the new one. In such cases Google can sometimes recognise the discrepancy and take the fresher data into account.
This illustrates well that the role of structured data now goes far beyond how a page appears among organic results — it is increasingly becoming an integral part of the webshop's product data ecosystem.
Product identifiers aren't administrative busywork either
In a webshop managing thousands of products, it's easy to regard the EAN, GTIN, SKU or manufacturer part number as just another mandatory field to fill in. In reality, these identifiers ensure that your webshop, Google and other commerce systems are all certain they're talking about the same product.
With a unique, in-house product, the name alone may well distinguish the item, but with a Samsung television or a Bosch power tool there can be a multitude of near-identical models, so an exact GTIN or MPN is a far more reliable anchor than the product name by itself. It's no coincidence that Google Merchant Center uses several of these identifiers directly when interpreting product data. A well-ordered product catalogue is therefore not merely an administrative matter — it's an asset from both a technical and an SEO standpoint. If the underlying data is wrong or incomplete, no schema generator can conjure up the real information afterwards.
And what happens with all those sizes, colours and pack sizes?
With a simple product, life is easy: one product, one price, one stock status. In many webshops, however, a product comes in multiple sizes, colours, pack sizes or technical variants, so how these variations relate to one another becomes important too.
Alongside Product, Google also offers structured data solutions for handling product variants and ProductGroup. The goal here, once again, isn't to cram as much markup onto the page as possible, but to make the technical description accurately mirror the webshop's real product structure.
This is the point where the difference becomes obvious between a webshop built on a well-ordered data structure from the start and a system patched together afterwards with bolt-on solutions.
Structured data should come from the system itself
It's very important to state and understand that in Sellvio, structured data handling isn't built on a separately installed SEO add-on — it's an integral, built-in part of the platform's technical SEO/GEO/AEO system. It slots into the same backend as indexability, the XML sitemap, canonical URLs and hreflang handling.
Why does this matter so much? Because it means the webshop operator doesn't have to create structured data for every product by hand — which, to put it mildly, would be an impossible task with a larger catalogue. Instead, the system can rely on the very product data that forms the foundation of the webshop's operation anyway. If the price or the stock changes, there's no need to enter the same information again. With a larger product catalogue this is no longer a mere convenience feature — it's the precondition for keeping the data consistently manageable over the long term.
At the same time, the technical system can only work with what it receives from the product catalogue. If the manufacturer is missing, the EAN isn't filled in, the product name is imprecise or the stock information is wrong, the structured data can't be perfect either. Quality is, in truth, decided back when the product data is uploaded and maintained.
Sellvio's product channels are part of the same data system
Through Sellvio's product channels, your webshop's catalogue data can also be passed on to external systems. The platform can provide data feeds for Google Shopping and other external catalogues, among others, with information such as the EAN, the manufacturer part number, the brand, the price, the category and the stock status. The Google Merchant Center feed is built on the same foundation: it transmits the data of your webshop's product catalogue to Google. The goal, then, is not to maintain the same information in several separate systems, but precisely the opposite — for every surface to work from the same reliable data source.
Ideally, a product has one correct price, a real stock status, an accurate identifier and a tidy data sheet. From that same data come the product page shown to customers, the structured data Google can interpret, and the feed sent to Merchant Center. The more these pieces of information originate from a single system, the less you have to worry about discrepancies — and the errors they cause — disrupting your operation.
Price and stock make the technical solution especially important
A product name rarely changes from one hour to the next, but price and stock can shift several times a day. That's why it matters a great deal how the structured data gets into the page and how quickly it follows changes in the webshop. According to Google's merchant listing recommendations, commerce pages should make the Product structured data available in the initial HTML. Markup generated solely with JavaScript is less reliably processed when the data changes rapidly.
With a few dozen products this may have no visible effect, but with a catalogue of several thousand it carries real weight. If prices or stock change for hundreds of products a day, the way that data gets refreshed is no longer an SEO question — it's part of the webshop's technical infrastructure.
Structured data needs to be checked from time to time
Just because a markup works flawlessly today doesn't mean it still will in six months. A template update, a new product type, a change in price handling or a mishandled product variant can easily introduce an error the customer never notices — while the search engine is already receiving incomplete or inaccurate data.
Google Search Console provides dedicated reports for checking merchant listing and product snippet structured data, and individual URLs can also be examined with the Rich Results Test. Search Console shows not only the errors, but also lets you track how the number of valid items changes after, say, a development or a template modification. For webshops, checking structured data should be built into the regular technical routine just like reviewing indexing errors or Core Web Vitals metrics.
It's not only Google that makes tidy product data worthwhile
For a long time, the importance of structured data was explained mainly through Google's rich results, but the picture is broader today. More and more systems process the content of the web not by simply searching pages, but by trying to interpret the relationships between pieces of information.
It helps enormously if a webshop can state unambiguously that one number is a price, another is a GTIN, a given string is a brand name and a given status is stock information. That alone doesn't automatically put every product in every AI-based search engine, of course, but an accurate and consistent data structure leaves far less guesswork for the systems that want to process your catalogue.
In fact, this is one of structured data's most important roles: describing, as unambiguously as possible, exactly what each piece of information in a webshop means.
Behind a good webshop today there's also a good data structure
The customer doesn't really care how tidy your webshop's data structure is. They open the shop, find the product, see its price and place the order. Behind the scenes, though, that same product has to appear consistently in the product database, on the page, in the structured data and in the feed sent to Google.
Product describes what the item is, and Offer describes the terms on which it can be bought. A merchant listing can draw on this very data when Google builds a commerce-style product display.
In a modern webshop, then, structured data isn't an SEO add-on bolted on after the fact — it's part of the technical infrastructure just like inventory management or the product feed. This is one of the key elements of Sellvio's approach too: technical SEO, structured data and the external product channels are all built on the same product catalogue.
The merchant's job, as a result, is not to write separate code for Google, but to work with accurate and consistent product data. Once that's in order, it's the technical backend's job to deliver that information, in the right format, to wherever it's needed.