Use the destination’s specification
Google’s Merchant Center specification calls for unique, stable product IDs and accurate product information, including titles that identify the item and distinguish relevant variants. It also sets requirements for attributes used by the destination. That official reference establishes a data contract; the release workflow below is independent editorial guidance, not a guarantee of approval or search visibility.
Begin with the actual destination and product type. Record the required attributes and the person responsible for each input. A feed accepted by one channel should not be assumed to satisfy another channel’s rules.
Choose an identifier owner
Decide which catalog reference represents the sellable item and which system maintains it. Preserve a mapping between that reference, the storefront variant and the destination record. Keep product families and individual variations distinct in the release sheet.
When a product is renamed or repackaged, review whether it is still the same sellable item before changing its identity. Document the decision. Changing identifiers merely to tidy a catalog can make investigation harder because historical records no longer connect cleanly with the current item.
Build a revealing release sample
Select an ordinary product, a multi-variant product, an unavailable item and a product with a recent price or description change. Add a special product type only when it is relevant to the store. For each, record the expected destination values and the matching landing page.
Include the exact variant a buyer should reach. A feed title describing one color while the page defaults to another deserves review even when both belong to the same product family. The release sample should expose relationships and exceptions, not simply demonstrate that several rows can be generated.
Compare the buyer-facing promise
Open the destination link and inspect the visible product, variation, availability and purchasing information. Compare these with the approved catalog record and generated feed. Make a note of caching or scheduled synchronization that could explain a temporary difference.
If the systems update at different times, plan the release order and review window. Assign someone to confirm that they converge. Avoid treating a mismatch as harmless merely because one team knows a background job will run later; another team still needs a clear way to verify that it did.
Give exceptions a working queue
Create a queue for rejected records, warnings and manual findings. Include the item reference, observed problem, responsible person and next review date. Separate a malformed value from a disagreement about the underlying product information because those require different owners.
Keep correction evidence with the case. After a fix, inspect the regenerated record and the relevant destination result instead of closing the task when the source field changes. Repeatedly editing the catalog without checking the output can conceal a transformation rule that continues to produce the wrong value.
Make releases reviewable
Save the specification reference, approved change set, sample results and unresolved exceptions together. Record the release time and the versions or jobs involved where the team can reasonably identify them. A future reviewer should understand which information was intended to change.
Reuse the checklist for supplier imports and promotional updates, adjusting the sample to the risk. Feed quality is an ongoing coordination task among catalog, engineering and merchandising. The objective is an accurate and explainable product promise across systems, with someone accountable when those systems disagree.
Official reference: Google Merchant Center: product data specification. Source checked on 29 October 2026. AMZ12 analysis and suggested checks are independent editorial guidance.