Brand promotion: this article introduces Guangsuan's Shopify technical maintenance and custom development service. It is a vendor introduction, not an independent review or a commissioned evaluation.
A product that looks fine on the storefront can still be disapproved in Google Merchant Center. The cause is often not one broken field but a disagreement between records that are supposed to describe the same item: what the feed submits, what the product page shows, what the page's structured data says, and what a buyer in the target market can actually select and buy.
The short answer
Write down the exact record that failed first — the account, the data source, the product ID and variant, the target market and language, the date, and the full wording of the status. Then compare four things for that item against the live page a buyer sees in that market: the identifier, the price and currency, the availability, and the landing URL. Fix the place where the wrong value is produced, and resubmit only when the page and the feed agree.
Three conditions belong with that answer. Current requirements depend on the account, the country and the product category, so Merchant Center's own documentation decides what applies today. A disapproval status is a starting point for inspection, not a diagnosis: it does not by itself tell you whether the fault sits in a field, in the page, in a policy, or in how the data is synchronised. And an accepted feed is not the same result as a product that is displayed, clicked or sold.
1. Which record is failing
Merchant Center holds a different kind of object from your Shopify product. One product can produce several feed items across markets and languages, and a variant can fail while its parent passes. That is why the first step is identification rather than editing.
| Save this | Why it matters later |
|---|---|
| Account, data source, and whether a channel app or a manual feed supplies the data | Determines where a fix has to be made, and whether a sync will overwrite it |
| Product ID, variant, target market and language | The same SKU can be correct in one market and wrong in another |
| The raw status text and the date | Lets you compare the same item after a fix instead of guessing |
| The landing URL as submitted | Shows whether the record points at the variant a buyer can actually select |
If a connected channel app supplies the data, its settings may override values you edit elsewhere. Record the current configuration before changing it, so a later mismatch has a known starting point.
2. Identifiers: the value comes from the product, not from the form
Identifier fields are where well-intentioned fixes do the most damage. A GTIN belongs to a specific product from a specific manufacturer; an MPN identifies the manufacturer's part. Neither can be inferred from a photo, a similar item or an internal SKU. If a number exists but is not in your system, ask the manufacturer or supplier for it and keep the reply with the product record.
Products that genuinely have no assigned identifier are a separate case from products whose identifier is simply missing. The distinction is a data statement about the product, and the correct way to declare it depends on the current account documentation and the category rules in force — not on which option makes the error disappear. Declaring that no identifier exists for an item that does have a manufacturer number does not make the underlying mismatch go away; it hides it until the next review.
3. Price, currency and availability
These three fields fail in a predictable way: the feed carries a value that was true when the export ran, and the page carries a value that is true now.
- Price. Compare the price a buyer sees and can pay in that market with the submitted price and currency. A base price in the admin, an original price stacked next to a discount, and a market-specific price can all be different numbers. If a promotion has an end date, the page and the feed both need to change when it ends.
- Availability. In stock, out of stock, preorder and backorder communicate different promises. Check the specific variant: a shirt can be sold out in one size while the parent product still looks available.
- Shipping and conditions. Anything the checkout can confirm — delivery cost, delivery window, return terms — should match what the record promises for that market. A single free-shipping message does not cover every destination.
A currency or market switch is a common source of drift: the page shows a local price while the export still carries a single base-currency value. Read the page with the same market context the feed targets before deciding which side is wrong.
4. The landing page: one item, one address
The landing URL should open the exact item being submitted, with the right variant selectable, on a phone, without a login. Three checks cover most of the practical problems.
First, does the URL point to the variant rather than to a parent page where the buyer has to hunt? Second, does the page declare the address you submitted as the canonical version? Google's guidance on ecommerce URL structure recommends including the canonical product URL on all variant pages when variants have their own URLs, and using the same URL in internal links, sitemaps and canonical tags. Third, does the address still work after a product handle change or a discontinued item?
If the store answers one product at several addresses — the product path and a collection-prefixed path, for example — decide which one represents the item and make the others point to it. This is a duplicate-path question rather than a feed question, and it is worth settling before another resubmission, because it affects both the record and the page a shopper lands on.
5. Structured data is not a second feed
Product markup on the page and the Merchant Center record both describe the product, but they serve different systems and one does not repair the other. What the markup should do is describe the page honestly: the price shown, the availability a buyer can act on, reviews a visitor can actually read. If the markup says in stock while the page says sold out, correcting the feed leaves the page inconsistent for search.
Shopify themes commonly print some of this markup already, so the usual problem is not a missing block but a value that stopped matching the page after prices, stock rules or a review app changed. Check the source of the live page, not only the admin field. The field-by-field comparison used in this site's product page fields and schema check follows the same principle.
A repeatable check order
- Open the failed item in Merchant Center and copy the exact status and the submitted values.
- Open the submitted URL in a signed-out window using the target market, and record the displayed price, currency, availability and selectable variant.
- Compare identifier, brand, price, availability and URL line by line. Note every difference, including ones that look minor.
- Decide which side is correct from a product record — a supplier document, a price list, a stock figure — not from whichever value is easier to change.
- Fix the source: the product data, the market settings, the price rule, the page, or the feed mapping.
- Re-read the live page after the change, then let the item be reprocessed and record the new status with its date.
- Check whether other items share the same cause before treating the case as closed.
What not to do
- Do not resubmit repeatedly. Reprocessing does not correct a value that is still wrong; it only produces the same result later.
- Do not strip fields to make an error vanish. Removing a real identifier or a real shipping condition creates a different, quieter inaccuracy.
- Do not delete the product page to close a feed issue. A discontinued item needs its own decision about keeping, rewriting or redirecting the URL, because links and history may still point at it.
Where Guangsuan fits
Guangsuan provides a Shopify technical maintenance and custom development service, described on its site as monthly support plus theme optimisation, alongside single tasks and project work. Its published product data scope covers bulk import, variants, categories and metafields, image matching, specification and FAQ content, and multilingual handling, with product facts and translations confirmed on the merchant side rather than by the provider. On the technical side, its checklist starts from the actual URL and the page content before moving to crawl rules, index control, canonical addresses and the reporting that follows.
Two limits are worth knowing before a first conversation. What can be delivered depends on the Shopify plan, the theme structure, the installed apps and the available interfaces. And the service is described as a checkable work arrangement rather than a promise of rankings, rich results or feed approval. The technical service can be bought on its own, without a promotion package attached; the published scope, engagement types and delivery steps are on the Shopify service page.
FAQ
Does a disapproved product mean the page is broken?
Not necessarily. The page may be fine while the submitted record carries an old price, a different variant or an identifier that does not belong to it. Compare the two before changing either.
Should I switch the data source to fix this?
Only after you know which record is wrong. Changing the source first makes the original values harder to recover, and a channel app may overwrite fields you edited by hand.
Can better structured data get a product approved?
No such promise is made here. Markup helps search systems describe the page; the feed record and the page still have to satisfy the account's own requirements. Where the two disagree about price or availability, fix the disagreement rather than adding markup.
How long does reprocessing take?
It varies by account and item, and no schedule is guaranteed. Record the date of each submission so a later status change can be compared with a known attempt.