Google product feed for WooCommerce: How to choose, configure and test the right solution
A Google product feed for WooCommerce connects the commercial information stored in a WooCommerce catalogue with Google Merchant Center.
The most important decision is not whether a solution can generate an XML file.
The important decision is whether the selected method can keep product identity, price, availability, variations, images and deletion operations accurate as the store changes.
The direct answer is:
Choose a file-based product feed when the catalogue changes at a predictable rate and scheduled full-catalogue processing is sufficient. Choose a controlled Merchant API integration when individual products change frequently, faster updates are required or the administrator needs product-level operation records.
A dependable solution should provide a complete operational route:
WooCommerce product → validation and mapping → selected Merchant Center data source → Google processing → product-level result review.
This guide explains how to choose, configure and test the right method without repeating a general product-data optimisation guide.
Its focus is practical decision-making:
- What type of connection should be used?
- Which plugin capabilities actually matter?
- What should be tested before processing the complete catalogue?
- How can duplicate data sources be prevented?
- When does a file feed remain sufficient?
- When does Merchant API become the stronger operational choice?
- How can an existing XML feed be replaced without creating duplicate products?
What is a Google product feed for WooCommerce?
A Google product feed for WooCommerce is a structured transfer of WooCommerce product information to a data source in Google Merchant Center.
The information can include:
- Stable product ID
- Title
- Description
- Product URL
- Main image URL
- Additional images
- Price
- Sale price
- Availability
- Brand
- GTIN
- MPN
- Condition
- Product category
- Product type
- Colour
- Size
- Material
- Pattern
- Item group ID
- Shipping information
- Custom labels
The word “feed” is often associated with an XML, TXT or TSV file. However, Merchant Center can receive product information through several types of data sources, including files, ecommerce-platform connections and programmatic integrations.
Google’s product data specification describes an item as a product added through a text feed, XML feed or API. It also emphasises that inaccurate, incomplete or conflicting information can cause limited eligibility, disapprovals or incorrect product presentation. Google product data specification
A modern product-feed decision should therefore consider both file and API methods.
The transfer format is only one part of the system.
The complete system must also determine:
- Which WooCommerce values are authoritative
- How variations are separated
- How product identities remain stable
- How frequently changes are delivered
- Which source owns each Merchant product
- How unsuccessful operations are reviewed
- How products are deleted
- How Google’s processed results are retrieved
- How another feed is prevented from overwriting the same products
A feed URL without this operational structure can become an outdated catalogue copy.
The main product-transfer methods
There are several ways to transfer WooCommerce products to Merchant Center.
Each method has a different level of automation and control.
Manual product file
A WooCommerce extension or export tool generates a file that an administrator downloads and manually uploads to Merchant Center.
This method may be suitable for:
- Small catalogues
- Infrequent product changes
- Initial testing
- Temporary migrations
- Stores without automated server access
Its limitations include:
- Manual work
- Delayed price changes
- Delayed availability changes
- Risk of forgetting the next upload
- Limited operation history
- Difficulty managing urgent deletions
A manual file should not be selected for a catalogue whose stock changes after every order unless another reliable update method is also in place.
Scheduled file retrieval
A WooCommerce feed plugin generates a file and makes it available through a URL. Merchant Center retrieves that file according to a schedule.
This approach can reduce manual work and is often suitable when:
- The entire catalogue can be generated efficiently
- Price and stock changes are not extremely frequent
- The server can create the feed reliably
- The retrieval schedule matches the store’s operational needs
- Product-level immediate updates are unnecessary
The complete delay includes more than the scheduled retrieval interval.
A change must pass through:
- The WooCommerce update
- Feed-file regeneration
- Merchant Center retrieval
- Google validation
- Google product processing
A feed retrieved once per day can therefore remain outdated for a meaningful period after a product changes.
Direct platform connection
Some ecommerce platforms or extensions provide an integrated connection that manages the product transfer without requiring the merchant to handle the file manually.
This can simplify initial setup, but the administrator should still determine:
- Which Merchant Center account is connected
- Which data source is created
- Which products are included
- Which IDs are submitted
- How variations are handled
- How errors are displayed
- Whether another active feed overlaps
- What happens after the extension is removed
Convenience should not remove visibility.
The merchant still needs to know which system owns the submitted products.
Merchant API integration
A Merchant API integration performs programmatic product operations.
Depending on the implementation, it can provide:
- Individual product submission
- Variation-level submission
- Targeted product updates
- Controlled deletion
- Background processing
- Scheduled operations
- Product-level results
- Error classification
- Limited retries
- Processed-product retrieval
- WooCommerce-to-Merchant reconciliation
Merchant API still requires an identified data source. Google’s official quick-start documentation states that a primary product data source must exist before a product can be inserted. The returned data-source name is then used for later product operations. Insert your first product with Merchant API
API use therefore does not mean that data-source ownership disappears.
It makes that ownership more explicit.
Choose the method according to operational requirements
Do not choose a product-feed solution only by comparing feature lists or yearly prices.
Begin with the behaviour of the store.
Record:
- Number of simple products
- Number of variations
- Daily order volume
- Frequency of stock changes
- Frequency of price changes
- Frequency of new products
- Frequency of product deletion
- ERP or supplier imports
- Number of target countries
- Number of currencies
- Number of Merchant accounts
- Need for product-level records
- Need for rapid correction
- Available server capacity
- Available technical support
A catalogue with 100 stable handmade products has different requirements from a store containing 30,000 frequently changing electronic components.
The first store may operate successfully with a scheduled file.
The second may need:
- Controlled queues
- Incremental processing
- Variation-level mapping
- Frequent price and availability operations
- Retry limits
- Reconciliation
- Product-level diagnostics
The correct solution is the one that matches the store’s change pattern.
A practical method-selection test
A file-based solution may be sufficient when most of the following are true:
- Product information changes slowly
- Stock is not highly volatile
- Full-catalogue generation finishes reliably
- A scheduled delay is acceptable
- The catalogue is manageable
- Individual operation records are unnecessary
- Product deletion is infrequent
- One primary source controls the catalogue
- The server can generate the file without timeout or memory problems
An API-based solution becomes more valuable when most of the following are true:
- Stock changes frequently
- Prices change several times a day
- The store contains many variations
- ERP imports create frequent events
- Products must be removed quickly
- Individual changes need to be traceable
- Unsuccessful operations require controlled retries
- The catalogue is too large for frequent complete regeneration
- Administrators need Google results inside WordPress
- WooCommerce and Merchant products must be reconciled
The decision is not based only on catalogue size.
A small catalogue with rapidly changing stock may benefit from API operations.
A large but stable catalogue may continue to use a scheduled file effectively.
Evaluate product identity before evaluating design
A visually attractive WordPress interface does not compensate for unstable product identities.
Ask every prospective solution:
- How is the offer ID generated?
- Is the ID stable after a title change?
- Is every variation assigned a separate ID?
- Can an existing ID strategy be preserved?
- Is the Merchant product identity stored locally?
- Can a deleted WooCommerce product still be identified?
- Does changing the feed method create new IDs?
- Are language and feed-label values recorded?
Google’s current Merchant API product-management guide identifies a product through a combination of content language, feed label and offer ID. It also explains that API products should be refreshed regularly and that product-management operations apply to API-type data sources. Google Merchant API product management
A product title should not be used as the primary ID.
Titles change for:
- Search optimisation
- Seasonal campaigns
- Spelling corrections
- Brand-standard updates
- Variation clarification
- Product relaunches
If the ID changes with the title, Google may treat an ordinary product update as a new product.
The previous product can remain in Merchant Center while the new identity creates another entry.
Inspect variation support carefully
The statement “supports variable products” is not sufficient.
The integration should determine, for every sellable variation:
- Variation ID
- SKU
- Offer ID
- Price
- Sale price
- Availability
- Stock quantity
- GTIN
- MPN
- Colour
- Size
- Material
- Pattern
- Variation image
- Landing-page selection
- Item group relationship
A weak implementation may technically export variations while still using the parent product’s:
- Price
- Stock status
- Image
- GTIN
- Product URL
- SKU
This can create a valid-looking feed that represents the wrong commercial offer.
Before purchasing or activating a solution, ask to test at least one variable product containing:
- Different prices
- Different stock conditions
- Different images
- Different identifiers
- Different attribute combinations
The test should confirm that every variation remains separately identifiable after a price or stock change.
Review price and availability freshness
Price and availability usually change more frequently than titles, descriptions or images.
A suitable solution should explain:
- When it detects a WooCommerce change
- Whether the complete catalogue is regenerated
- Whether only the affected product is processed
- How quickly the operation begins
- What happens if the operation fails
- Whether a newer change replaces an older pending operation
- How the final Merchant result is checked
Merchant API provides mechanisms for updating selected product information, including price and availability, where the relevant method and account environment support them. Google’s frequent-update guidance explains that partial operations can avoid resubmitting an entire product for a small change, while regular complete reinsertion remains important for synchronisation. Google’s frequent product update guide
Partial updates require precise control.
An integration must know:
- Which WooCommerce field changed
- Which Merchant attribute is affected
- Which data source owns the product
- Which product identity must be updated
- Whether a partial operation is sufficient
- Whether a complete product operation is required
An incorrect partial operation can leave an old field unchanged.
Examine background-processing behaviour
Large catalogue operations should not depend on one browser page remaining open.
A dependable Google product feed for WooCommerce should use controlled background work for long-running operations.
Review whether the solution supports:
- Batch processing
- Queue persistence
- Duplicate-job prevention
- Worker locking
- Recorded progress
- Safe resumption
- Maximum retry limits
- Temporary-error delay
- Permanent-error stopping
- Manual retry after correction
- Old-record cleanup
- Last worker activity
- Oldest pending operation
- Product-level status
A simple “processing” indicator does not prove that background operations are healthy.
The administration interface should show:
- How many operations are pending
- Which product is currently being processed
- When the last successful operation occurred
- Whether the worker has stopped
- Which products failed permanently
- Which products are waiting for retry
Without this information, an administrator may repeatedly start another full-catalogue operation.
This can create:
- Duplicate jobs
- Repeated API calls
- Conflicting operation order
- Database growth
- Server load
- Quota pressure
Require useful error reporting
A feed solution should translate technical failures into corrective actions.
Compare these two messages:
Request failed: HTTP 400.
and:
The selected variation has no price. Add a valid WooCommerce price before retrying this product.
The second message helps the administrator correct the source problem.
Useful error records can include:
- WooCommerce product ID
- Variation ID
- SKU
- Operation type
- Error category
- Google reason
- Date and time
- Retry number
- Corrective recommendation
- Data-source reference
- Masked account reference
Errors should also be classified.
Temporary conditions may include:
- Short network interruption
- Temporary Google service failure
- Suitable quota-related response
- Brief server timeout
Corrective conditions may include:
- Missing price
- Invalid currency
- Unsupported identifier
- Inaccessible product URL
- Wrong account
- Invalid data-source relationship
- Missing required variation information
Repeating a permanent data error does not correct the product.
It only creates more failed operations.
Check processed results, not only submission results
A successful request does not necessarily mean that a product is approved or eligible.
It means that the technical operation was accepted.
Google still processes the product information and may apply:
- Data-source rules
- Supplemental values
- Automatic improvements
- Policy evaluation
- Destination requirements
- Product-data validation
Google’s Merchant API documentation distinguishes submitted product input from the final processed product. It also explains that processed products and associated issues can be retrieved after products have been added. List processed products and product issues
A suitable integration should distinguish among:
- WooCommerce product prepared
- Operation queued
- Request sent
- Request accepted
- Product awaiting processing
- Processed product retrieved
- Warning detected
- Product limited
- Product disapproved
- Product eligible
The WordPress interface should not label a product “approved” merely because an API request returned successfully.
Inspect data-source ownership
A Merchant Center account may contain several product sources:
- An old XML feed
- A new WooCommerce feed plugin
- An API source
- An ERP connection
- A manual file
- Google Sheets
- Automatically found website products
- Another ecommerce integration
Multiple sources can coexist when their responsibilities are deliberately separated.
They become risky when they control the same products without a documented plan.
Before configuring a new solution, record every active source:
- Source name
- Source type
- Product count
- Language
- Feed label
- Country
- Update schedule
- Product ID pattern
- Responsible plugin or service
- Last update
- Whether the source should remain active
Do not assume that deleting duplicated products will solve the cause.
If the old plugin or scheduled file remains active, the next operation may add them again.
First stop the unwanted creation route.
Then confirm which products it owns and remove obsolete entries through a controlled process.
Review the security model
A Merchant API connection can handle sensitive authorisation information.
The solution should protect:
- OAuth client secret
- Access token
- Refresh token
- Authorisation code
- Callback state
- Internal service credentials
- Licence secrets
Sensitive values should not appear in:
- WordPress notices
- Browser addresses after callback processing
- Public REST responses
- Front-end JavaScript
- Diagnostics exported for support
- Unmasked application logs
- Screenshots
Administrator actions should require appropriate permissions and nonce protection.
Important actions include:
- Connecting Google
- Disconnecting Google
- Changing the Merchant account
- Changing the data source
- Resetting local mappings
- Retrying products
- Cancelling queued operations
- Deleting Merchant products
- Clearing logs
A single ambiguous “Reset everything” button is risky.
The interface should explain what each action changes and what remains intact.
Assess compatibility with the complete WooCommerce environment
A product-feed plugin does not operate in isolation.
It may be affected by:
- Currency extensions
- Dynamic-pricing plugins
- Wholesale-price plugins
- Multilingual extensions
- ERP integrations
- Inventory systems
- Product-bundle plugins
- Subscription products
- Custom product fields
- Page builders
- Schema extensions
- Security plugins
- Cache systems
Test the actual store configuration.
A demonstration on a basic WooCommerce installation does not prove compatibility with:
- Customer-specific pricing
- Multiple currencies
- Imported supplier stock
- Custom variations
- Country-based restrictions
- Complex tax rules
The integration should use the price and availability that apply to the intended customer and destination.
If the store presents different commercial values to different customer groups, the Merchant strategy must define which public offer is submitted.
Calculate total operating cost
The least expensive plugin is not necessarily the least expensive solution.
Calculate the total cost of:
- Licence
- Initial configuration
- Attribute mapping
- Product-data correction
- Server resources
- Support
- Troubleshooting
- Manual feed monitoring
- Duplicate cleanup
- Failed-operation review
- Migration
- Staff time
- Downtime caused by incorrect data
A low-cost feed generator may be appropriate for a stable catalogue.
It may become expensive if an administrator must repeatedly:
- Regenerate files
- Investigate mismatches
- Remove duplicates
- Resubmit products
- Correct variation errors
- Compare several data sources manually
An advanced integration is valuable only if its control and visibility address real operating requirements.
Complexity without a genuine need is not an advantage.
Prepare WooCommerce before installation
A new integration cannot correct unreliable source information automatically.
Before configuration, review:
- Product publication status
- Product and variation prices
- Sale dates
- Currency
- Stock status
- Backorder settings
- Product URLs
- Variation selection
- Image accessibility
- Brand
- GTIN
- MPN
- Product attributes
- Shipping information
- Store policy pages
- Business information
Select a representative test group rather than beginning with the complete catalogue.
Include:
- One simple in-stock product
- One simple out-of-stock product
- One product with an active sale
- One variable product
- One product without a GTIN
- One recently changed product
- One discontinued product
This group reveals different mapping and operational behaviours.
Configure the Google product feed for WooCommerce
Use a controlled sequence.
1. Confirm the intended Merchant Center account
Do not automatically select the first accessible account.
Record:
- Merchant account name
- Account ID
- Verified website
- Administrator access
- Target country
- Business identity
2. Review existing data sources
Identify every file, API, platform and automatically created source.
Determine which sources will remain active.
3. Select the intended source
For an API integration, confirm that the selected source is suitable for API product operations.
Google’s documentation states that API insertion, update and deletion operations apply to products belonging to API-type data sources, rather than products inside file-upload sources. Google Merchant API product management
4. Define product identity
Choose stable IDs for:
- Simple products
- Parent products where required
- Individual variations
Do not change the strategy after processing the complete catalogue unless a controlled migration is planned.
5. Define language and feed label
These values participate in Merchant product identity and destination organisation.
They should not be selected casually.
6. Configure attribute mappings
Map:
- Title
- Description
- Link
- Image
- Price
- Sale price
- Availability
- Brand
- GTIN
- MPN
- Condition
- Category
- Variation attributes
- Item group relationship
7. Configure exclusions
Define whether to exclude:
- Draft products
- Private products
- Non-purchasable products
- Unsupported product types
- Products without prices
- Selected categories
- Selected tags
- Products restricted to another market
8. Configure processing limits
Choose conservative initial batch sizes.
Confirm queue and retry behaviour before increasing throughput.
9. Submit the representative test group
Do not begin with every product.
10. Retrieve processed results
Wait for Google processing and inspect each test product.
11. Test changes
Change:
- One price
- One sale price
- One stock status
- One variation image
- One title
Confirm that the same Merchant products are updated.
12. Test deletion
Delete or discontinue one test product through a controlled route.
Confirm that it does not return through another source.
13. Expand gradually
Process larger product groups only after the first tests succeed.
Test what happens after ordinary WooCommerce events
A reliable solution should continue working after initial submission.
Test:
- Product creation
- Product editing
- Price reduction
- Price increase
- Sale start
- Sale end
- Stock reduction
- Product becoming unavailable
- Variation creation
- Variation deletion
- Product deletion
- Scheduled import
- Plugin update
- Temporary network failure
- Worker interruption
For every test, record:
- WooCommerce value before change
- WooCommerce value after change
- Operation created
- Operation time
- Submitted identity
- Google response
- Processed Merchant value
- Final issue status
This evidence is more useful than relying on a general “connection successful” message.
When a file-based feed is the right choice
A file-based Google product feed for WooCommerce remains a valid option.
It can provide a simpler system when:
- The catalogue is stable
- Full-feed generation is fast
- Scheduled retrieval is dependable
- Product changes are infrequent
- A delay is acceptable
- The store does not need product-level operation records
- One feed controls the catalogue
The goal is not to use the most technically advanced method.
The goal is to use the least complex method that reliably meets the store’s requirements.
Continue monitoring:
- Feed-generation time
- Latest successful retrieval
- File accessibility
- Product count
- Rejected rows
- Price freshness
- Availability freshness
- Deleted products
- Competing sources
When Merchant API is the stronger option
Merchant API becomes a stronger choice when the store needs more direct operational control.
Google describes Merchant API as a way to automate product, account, inventory and reporting workflows. Its current migration guidance also documents structural differences from the older Content API, including resource names, sub-APIs and request behaviour. Google Merchant API migration overview
An API-based integration can be useful for:
- Frequently changing stock
- Frequently changing prices
- Large variation catalogues
- Targeted product operations
- Controlled deletions
- Background queues
- Product-level histories
- Processed-result retrieval
- Error classification
- Reconciliation
The API does not correct inaccurate WooCommerce information.
It provides a more direct and traceable route for managing that information.
How PW Merchant API supports this route
PW Merchant API is developed for WooCommerce stores that want to manage product operations through Google Merchant API from the WordPress administration environment.
Depending on the installed version, licence and configured environment, its workflow can include:
- Authorised Google connection
- Accessible Merchant Center account selection
- WooCommerce product review
- Simple-product operations
- Variation-level operations
- Product submissions
- Price and availability operations
- Background processing
- Scheduled work
- Product-level records
- Unsuccessful-operation review
- Controlled retries
- Google result visibility
- WooCommerce and Merchant product matching
The intended route is:
WooCommerce information → PW Merchant API validation and processing → Google Merchant API → processed Merchant product → WordPress result review.
Compared with a complete XML file, this structure can provide more control over individual changes.
For example, one stock change can be associated with one product operation instead of requiring the entire catalogue to be regenerated.
PW Merchant API does not:
- Invent GTINs
- Determine the genuine selling price
- Correct warehouse information independently
- Guarantee Google approval
- Guarantee product visibility
- Guarantee traffic or sales
- Replace Merchant Center policies
- Replace accurate public product pages
Its role is to create a controlled and visible technical route.
Current information is available on the PW Merchant API page.
Migrate from XML without creating duplicates
Do not remove an existing feed immediately after installing a new integration.
Use this transition:
- Record the old source name.
- Export or document its product IDs.
- Record the language and feed label.
- Identify the plugin or service updating it.
- Confirm the current product count.
- Configure the new integration.
- Preserve stable identities where appropriate.
- Select a small product group.
- Submit the test products through the new route.
- Retrieve their processed results.
- Compare old and new identities.
- Test price and availability changes.
- Test one deletion.
- Stop overlapping operations for the selected group.
- Expand the new route gradually.
- Disable the obsolete generation schedule.
- Confirm that old products do not return.
- Remove the obsolete source only after verification.
Changing every offer ID can create a second catalogue rather than transfer ownership.
The migration should preserve product identity where the existing identity is stable, appropriate and compatible with the new structure.
Google product feed for WooCommerce checklist
Before choosing a solution
- Record catalogue size
- Count sellable variations
- Measure price-change frequency
- Measure stock-change frequency
- Identify ERP imports
- Define acceptable update delay
- Determine the need for product-level records
- Review server capacity
- List active Merchant data sources
- Define the available budget
Before configuration
- Confirm the Merchant account
- Confirm the verified website
- Review account access
- Identify the intended data source
- Define language
- Define feed label
- Establish stable IDs
- Review variation data
- Correct missing prices
- Review stock conditions
- Validate images and links
Before complete processing
- Test a simple product
- Test a variable product
- Test an active sale
- Test different stock conditions
- Test a price change
- Test an availability change
- Retrieve processed results
- Review warnings and disapprovals
- Test one deletion
- Check for duplicate products
For ongoing operation
- Monitor latest worker activity
- Monitor latest file retrieval
- Review unsuccessful products
- Review retry records
- Check queue age
- Check price freshness
- Check availability freshness
- Review processed product issues
- Identify obsolete mappings
- Reconcile WooCommerce and Merchant products
- Review competing data sources
- Clean old operational records safely
Frequently asked questions
What is the best Google product feed for WooCommerce?
The best solution is the one that matches the catalogue’s size, change frequency, variation structure and monitoring requirements. A scheduled file can be suitable for a stable catalogue, while Merchant API may be better for frequent individual changes and product-level control.
Do I always need an XML feed?
No. Merchant Center can receive product information through different data-source methods. A file is one method; a compatible Merchant API integration is another programmatic method.
Is a free WooCommerce product feed plugin sufficient?
It can be sufficient when it generates accurate information, handles variations correctly and matches the store’s update requirements. The licence price alone does not determine data quality or operational suitability.
How often should a WooCommerce feed update?
The frequency should reflect how often important commercial values change. A stable catalogue may use scheduled full updates, while fast-changing price and availability information may require a more frequent or targeted route.
Can I use the product title as the feed ID?
This is not recommended. Titles change, while product identities should remain stable. Use a stable product, variation, SKU or store-defined identifier strategy.
Should every variation have a separate entry?
Each sellable variation should normally have its own identity and applicable price, stock, identifiers, attributes, link state and image.
Why did a new feed create duplicate products?
Possible causes include changed offer IDs, different language or feed-label values, an old source remaining active or more than one plugin managing the same catalogue.
Can two WooCommerce feed plugins remain active?
They can technically remain active, but they should not manage the same product identities without a clearly separated responsibility. Overlapping sources can create duplicates and conflicting updates.
Does Merchant API remove the need for data sources?
No. Merchant API product operations also belong to an identified data source.
Does an API request update products inside my old XML source?
Google’s current guidance states that API product-management operations apply to API-type data sources. A file-upload source and API source should be treated as separate ownership routes.
Does a successful request mean the product is approved?
No. It confirms a technical operation. Google still processes the product and may return warnings, limitations or disapprovals.
Can Merchant API update only price or availability?
Merchant API provides partial-update mechanisms for suitable product attributes and environments. The integration must use the correct product identity, data source and update mask.
Should I delete the old feed as soon as API connection succeeds?
No. First test product creation, updates, processed-result retrieval and deletion. Stop overlapping operations before removing the obsolete source.
Can a feed plugin generate missing GTINs?
It should not invent GTINs. Genuine product identifiers must come from the manufacturer, supplier or reliable product records.
Does PW Merchant API guarantee Merchant Center approval?
No. Google independently evaluates accounts, products, destinations and policies. PW Merchant API is intended to manage and trace product operations.
Conclusion
Choosing a Google product feed for WooCommerce is an operational decision, not merely a file-format decision.
Begin with the store’s real behaviour:
- How frequently do prices change?
- How frequently does stock change?
- How many variations are sold?
- How quickly must deletions reach Merchant Center?
- Does the administrator need product-level records?
- Can the server regenerate the complete catalogue reliably?
- Which existing data source currently owns the products?
A scheduled file may be the most practical solution for a stable catalogue.
A controlled Merchant API integration may be the stronger choice for a frequently changing catalogue that requires individual operations, background processing, error classification and processed-result visibility.
Whichever method is selected, it must preserve a dependable relationship:
WooCommerce product → stable product identity → selected data source → submitted information → processed Merchant product.
Test that relationship with a small representative group before processing the entire catalogue.
Confirm product creation, variation mapping, price changes, availability changes, processed results and deletion.
Document every existing data source and stop overlapping creation routes before removing duplicates.
PW Merchant API is designed to support stores that need a more controlled WooCommerce-to-Google Merchant API route.
Its value is not limited to transmitting a large number of products.
Its value depends on whether the administrator can determine which product was processed, which operation occurred, whether Google received it, whether the final product was processed and what action is required when an operation does not succeed.
The right Google product feed for WooCommerce should therefore keep product ownership clear, commercial information current and every important result traceable to its WooCommerce origin.