Brand promotion: this article introduces Guangsuan's Shopify technical maintenance and SEO services.
Editing a Shopify product page looks like a two-field job: change the SEO title, rewrite the meta description, save. On the live site it behaves like a four-part job, because four different pieces of output have to agree — the title a search result shows, the wording a buyer reads on the page, the Product and Offer markup in the page source, and the numbers Google reports afterwards. When they disagree, the symptom usually gets described as a rich result problem or a Search Console problem, when it is really a data-matching problem.
This article is a field-level check for merchants who run their own Shopify store and read their own reports. It covers what each field is, what Google actually takes from the page, which values in structured data must match what a buyer sees, and how to work through a disagreement between a test tool and a report. It closes with where that work sits inside Guangsuan's Shopify technical maintenance service.
The fields on a product page, and what each one costs to change
A Shopify product page carries a small set of editable text fields, and they are not equally cheap to change. Ordering them by the cost of a mistake is more useful than working down the admin screen from top to bottom.
- Handle (the URL). The expensive one. Old addresses are held in bookmarks, forum posts and affiliate links, and in references hard-coded inside the theme, so a change has to be followed by redirects and a pass over internal links.
- Page title (the SEO title). Low cost, though it is a different field from the product title, which also drives the page, on-site search and report groupings.
- Meta description. Low cost, but time-limited: a description that carries a promotion has to be revisited when the promotion ends.
- Product description. Medium cost, because rewriting it to say something the supplier's copy does not takes real work.
- Image file name and alt text. Low cost; whether the theme even prints the alt attribute is a theme-output question, so the check happens in the page source rather than in an admin field.
Two of these sit close to the search result itself. Shopify's own documentation says the title in a search result is taken from the page title and the description from page content, such as the product description, and that both can be set in the SEO settings at the bottom of a product, collection, blog post or page — with the caveat that the description set there is not guaranteed to be the one used.
What Google takes from the page, and what you only influence
The title link is generated automatically from a number of sources, so the title element is a preference rather than an instruction, and the page has to be recrawled before a change is visible. The snippet behaves the same way: it is created primarily from page content, and the meta description is used when it describes the page better than the on-page text does. That is why a title that did not update is a recrawl question first and a metadata question second, and why a strong description is closer to a readable summary of the page than to a ranking switch.
Structured data: two kinds, and what a Shopify theme already prints
For product pages, structured data comes in two shapes. Product snippets suit pages that cannot be bought from directly; merchant listings suit pages that can, and support more detail, including apparel sizing, shipping and return policy. Marking up the full set required for a merchant listing also makes a page eligible for the product snippet type.
Two practical consequences follow. First, Shopify's help documentation states that officially supported themes and themes from its theme store already include structured data for price, inventory and reviews, so on many stores the starting problem is not missing markup but values inside markup that no longer describe the page. Second, the output arrives in two forms: microdata attributes and JSON-LD script blocks. The platform's default output is the microdata form; apps and custom code typically inject JSON-LD. Both can be present on the same URL, so the source check looks for both.
The five fields that must match the visible page
The comparison that matters is not whether the markup is valid, but whether the markup says what the page says. Five fields carry most of the risk.
| Field | What the page should show | A mismatch looks like |
|---|---|---|
| Price and currency | The price a buyer sees in their current context | Markup carries the base currency while the page shows a local currency |
| Availability | The purchasable state on the page | Sold out but still marked in stock, or variants contradicting each other |
| Rating and reviews | Reviews a visitor can actually read on the page | A value pulled from a review source that never renders on the page |
| Shipping and delivery | A policy that can be confirmed before checkout | Markup claiming something the store never promised |
| Image | The main image actually displayed | Pointing at a file that has since been replaced or deleted |
Price, availability and reviews are the three a theme prints by default; shipping and returns normally have to be added. Start with the default output and fix what is wrong before adding anything, because default fields are maintained with the theme while added fields are extra code that is harder to trace when something breaks.
Price is the field most likely to drift. A store that switches currency can show different prices at the same address while the markup carries a single value. If the page's structured data has no price at all, the product snippet may fall back to a price from a Merchant Center feed, and when both exist but disagree the contradiction is left for the search engine to resolve. The rule to hold on to: the price in the markup is the price on the page right now, not the base price in the admin and not an original figure stacked onto a discount.
Reviews carry the same rule in a stricter form. The rating and review count should correspond to reviews that are visible on the page. Reviews that exist only inside a review app's dashboard are not visible content, and inventing a set of numbers is not a grey area. Where markup and page disagree, the markup may simply be ignored or handled under Google's structured data policy, with the determination following the official policy — which is why this article is about matching data rather than about working around a rule.
When the rich results test and the report seem to disagree
Structured data lives in three layers at once: what the code marks up, what the report accepts, and what a person actually sees. A clean report only tells you the first two are aligned; it cannot tell you that a buyer is seeing a price, a rating or a shipping promise. Differences between the layers tend to come from conditional template output, duplicate injection by apps, or variant prices that changed after the markup was written.
Two expectations are worth setting correctly. Google states that result enhancements are decided by each display surface and may change over time, which is why its guidance is to supply rich product information without tying the work to one specific treatment; a computed signal such as a price drop is produced by Google from observed price changes and is not guaranteed to appear. And a status such as crawled, currently not indexed or discovered, currently not indexed is a starting point for inspection, not a root cause: it does not by itself prove weak content, and it does not by itself prove that a paid indexing service is needed.
A check you can repeat on one product page
- Pick the most complex product page you have — variants, a promotional price, reviews — and open its source. Search for microdata attributes and JSON-LD script blocks and copy the price, currency, availability, rating, review count and shipping fields into a table.
- Open the same page as a buyer and copy the same values: displayed price, availability, review count, shipping wording.
- Compare the two columns line by line.
- Run the rich results test and deal with the errors it flags first, then rank the rest by impact.
- Use URL inspection to confirm the rendered version Google fetched contains the markup — especially for anything injected by script.
- In the Search Console structured data report, record the valid and error counts, and when a new error appears, trace whether it came from the theme or from an app.
Then set a cadence rather than a heroic first pass. A shop with many fields, many apps and layered price rules can review monthly; a small catalogue with few changes can review once a quarter. A frequency you cannot keep produces a table that stops after month one.
Two working rules make the changes reversible. Edit a copy theme or a single template and confirm the output before publishing, instead of editing the live theme during trading hours, and change one class of field at a time so a problem can be attributed. The riskiest moment for this markup is not the initial setup but a theme update: structured data is often printed by a conditional block in the template, and that is the code most easily lost when a theme is refreshed.
Where Guangsuan fits
Guangsuan provides Shopify technical maintenance and custom development, and the work described in this article sits in two of its published areas. Under speed optimization and technical SEO it lists canonical links, redirects, structured data and multilingual checks, alongside checking important URLs, content, tracking and conversion paths before and after a change. Product listing and multilingual maintenance is listed separately: bulk import, variants, categories and metafields, image matching, specification and FAQ content, with product facts and translations confirmed on the merchant side rather than by the provider. The technical service can be bought on its own, without a promotion package attached.
If a duplicate path or a theme-level output is what is confusing the picture, the diagnosis order for one product answering at two addresses is set out in this site's note on collection and product pages that compete for one query. The Chinese-language walk-through behind the field comparisons above is the product structured data consistency check.
FAQ
Does my theme already print Product structured data?
Shopify's help documentation states that officially supported themes and themes from its theme store already include structured data for price, inventory and reviews. The check is therefore whether those values still match the page after prices, stock rules or review apps have changed.
Should I rewrite the markup to be more complete?
Not by default. When the default output is already correct, rewriting it adds a small upside and a real risk of losing the block. Add fields the theme does not print, such as shipping and return details, only where the page genuinely states them.
Why does the rich results test pass while the report shows an error, or the other way round?
They answer different questions. The test reads the markup it is given; the report reads what Google crawled and accepted. Check the rendered version Google fetched, and check whether a script-injected block is present in it, before assuming either tool is wrong.
Will matching these fields improve rankings?
No such promise is made here. Matching data keeps a page eligible for the treatments that surface price, availability and ratings, and it keeps the page honest for the people reading it. Ranking depends on competition, content and links, and crawling and indexing take time without a guaranteed schedule.