Product feed QA is not filling out a spreadsheet. It is confirming that Shopify admin, product page, structured data, Merchant Center, ad systems, and inventory systems all describe the same product truth. Google Merchant Center product data specification says accurate and correctly formatted product data is essential for ads and free listings, and that incorrect, missing, or conflicting product information can cause disapprovals, limited eligibility, or display issues.
The common small-team problem is not knowing that fields exist. It is not knowing who owns the source of truth. Where does title come from? Is GTIN a barcode or a store SKU? Does price come from Shopify, landing page, or feed? Does availability match checkout? This article uses title, GTIN, price, and availability to build a practical feed QA workflow.
Feed QA starts with product truth
Create a product truth table before editing Merchant Center. Every SKU or variant needs stable ID, title, brand, GTIN or identifier status, price, sale price, availability, link, image, shipping, and return information. The table should also assign owners: product owns title and attributes, operations owns price and stock, data owns feed and structured data, support owns policy promises.
Without source of truth, feed fixes become platform-error cleanup. Merchant Center flags title today, so someone edits the feed. The Shopify page remains unchanged, and structured data still carries the old version tomorrow. Real QA repairs the source, not only downstream symptoms.
What to check for title, price, availability, and GTIN
Title should accurately describe the product and match the landing page. Google product data specification says title should clearly identify the product and should not include promotional text, all caps, or gimmicky characters. Price and availability are even more sensitive: availability should match landing page, checkout, and structured data. If the item is out of stock, the landing page should still show price clearly.
GTIN is a global trade item number such as UPC, EAN, JAN, or ISBN. It is not the internal SKU you invent in Shopify. Google unique product identifier guidance explains that GTIN, MPN, and brand help distinguish products when real identifiers exist. Do not invent GTINs to silence warnings, and do not use store SKUs as GTINs.
When not to invent identifiers
Some products truly do not have GTINs: custom goods, handmade products, some accessories, or private-label products in specific circumstances. In those cases, express identifier status according to platform requirements instead of entering a random barcode-like number. A wrong GTIN can be worse than a missing GTIN because it may connect your product to the wrong real-world item.
Internal SKU helps you manage inventory and fulfillment. GTIN helps external systems identify global product identity. Both are important, but they are not interchangeable. A feed QA table should include SKU, variant ID, brand, GTIN or MPN, identifier source, and who confirmed it.
Product page, structured data, and feed consistency
Google Search Central product structured data and merchant listing guidance point to one principle: structured data should match visible page content, and product information should be understandable to systems and users. Do not show $49 on the page, submit $39 in the feed, and leave old availability in structured data. Search and shopping systems may read any of those versions, and conflict reduces trust.
Consistency does not mean every text field must be identical. Product page title can be more user-friendly, while feed title can be more structured. Core facts cannot conflict: what the product is, which variant it is, price, availability, whether it can be purchased, and what shipping or return promises apply. QA aims for fact consistency, not mechanical copy-paste.
QA workflow before Shopping or PMax traffic
Start with key SKUs, not a full rewrite. Select the 20 products with the most ad spend, highest profit, tightest inventory, or most diagnostics. For each, check Shopify, product page, structured data, feed, Merchant Center diagnostics, and checkout. Every mismatch needs an owner and fix location: source data, feed, page, structured data, inventory sync, or pricing rule.
After repair, do not scale immediately. Wait for feed processing and Merchant Center status updates, then validate with controlled budget. Product-data changes also need a change log: which field changed, which systems are affected, and when to review. Feed QA is ongoing governance, not a one-time cleanup.
Product feed field QA matrix
| Field | Source of truth | Mismatch symptom | Fix owner |
|---|---|---|---|
| title | Shopify product facts and landing page | Feed title differs from page or includes promotional text | Product owner |
| GTIN | Brand or supplier barcode records | SKU used as GTIN or invented identifier | Product data owner |
| price | Shopify price and checkout price | Feed, page, and checkout price differ | Operations owner |
| availability | Inventory system and purchasable checkout state | Feed says in stock while page is unavailable | Inventory owner |
| structured data | Visible product facts on page | Product/Offer data conflicts with page or feed | SEO/data owner |
Turn this into a repeatable operating loop
Do not treat this article as a one-time reading task. Turn the decisions around Feed QA starts with product truth / What to check for title, price, availability, and GTIN / When not to invent identifiers into a small operating loop that your team can run before a launch, after a platform change, or when performance data starts to look inconsistent. The practical output should be a dated note, a checklist status, and a short owner comment, not a vague memory that someone "looked at it." That habit gives future reviews something concrete to compare against.
The table on Product feed field QA matrix starts with title / GTIN / price. Use those rows as the minimum evidence set. If one row cannot be verified, mark the page, campaign, feed, event, or policy as not ready and write down the exact missing proof. This protects the team from a common ecommerce failure mode: a visible metric moves, everyone reacts, but no one knows whether the store, tracking, content, or offer was actually in a valid state.
After you apply the checklist, connect the result to the linked Ecomwith tool, tutorial, or answer page. The blog should help you make the first decision; the next route should help you calculate, audit, document, or repair the issue. That is also what makes the page useful for search and AI discovery: it states the operating question, shows the evidence, and then points to the next page where the reader can act with more context.