How to choose a Google Merchant API plugin for WooCommerce
Choosing a Google Merchant API plugin for WooCommerce requires more than comparing feature lists or selecting the plugin that promises the fastest product upload.
The plugin becomes a connection between three systems:
- WooCommerce, where the store’s product information is maintained
- Google Merchant API, which receives and processes product operations
- Google Merchant Center, where products, destinations and account issues are evaluated
A suitable plugin should manage this connection securely, preserve stable product identities, process simple and variable products correctly, record operational results and distinguish successful submission from final Google approval.
The direct answer is:
A suitable Google Merchant API plugin for WooCommerce should provide current Merchant API support, secure OAuth authorisation, deliberate Merchant Center account selection, reliable variation mapping, controlled background processing, product-level error records, appropriate retry behaviour and clear visibility into Google’s processed results.
It should not:
- Describe API submission as guaranteed product approval
- Invent GTINs or other product identifiers
- hide Google errors behind a generic failure message
- Send the complete catalogue repeatedly without a reason
- Treat every variation as an identical parent product
- Publish OAuth secrets or tokens in ordinary logs
- Allow an old product source to compete silently with the new connection
- Depend on the discontinued Content API for Shopping as its long-term product route
PW Merchant API is designed to provide an API-based WooCommerce product-management workflow within WordPress. However, merchants should still understand the requirements of the connection before installing or purchasing any integration.
What is a Google Merchant API plugin for WooCommerce?
A Google Merchant API plugin for WooCommerce connects product information stored in WooCommerce with an authorised Google Merchant Center account.
Depending on the plugin’s design, the connection may perform operations such as:
- Connecting a Google account
- Retrieving accessible Merchant Center accounts
- Selecting the intended merchant account
- Creating or selecting an API data source
- Preparing WooCommerce product information
- Sending simple products
- Processing product variations
- Updating price and availability
- Removing discontinued products
- Retrieving processed product information
- Displaying account or product issues
- Scheduling product operations
- Recording successful and unsuccessful requests
Merchant API is not a WordPress feature. It is Google’s programmatic interface for managing Merchant Center resources.
A WordPress plugin provides the application layer that translates WooCommerce information into suitable Merchant API requests and presents the resulting information to the store administrator.
Google describes Merchant API as the simplified interface for programmatically managing Merchant Center accounts and products. Merchant API v1 became generally available in July 2025 and is the official successor to Content API for Shopping. Google Merchant API’s latest updates confirm the general availability of v1.
This means the quality of the WooCommerce integration depends on both sides:
- The accuracy of the store’s WooCommerce data
- The reliability of the plugin’s Merchant API implementation
The API cannot correct information that is already inaccurate in WooCommerce.
Why current Merchant API support matters
One of the first questions to ask is whether the plugin genuinely uses the current Google Merchant API.
Some older integrations use Content API for Shopping. Google has deprecated that interface and states that it will be shut down in August 2026. Store owners relying on an older API integration therefore need to confirm whether its developer has completed the Merchant API migration. Google’s Content API release notes document this deprecation and shutdown schedule.
This is not simply a change to an endpoint address.
Merchant API introduces differences involving:
- Resource names
- Product identities
- Price representation
- Data-source creation
- Account resources
- Product operations
- Error information
- Supported methods
- Request structures
- Batch-processing strategies
- Issue retrieval
Google’s official migration overview explains that Merchant API uses modular sub-APIs and full resource names. It also notes that complete backwards compatibility with Content API features is not guaranteed.
Before choosing a plugin, ask:
- Does the current released version use Merchant API v1?
- Is Content API still used for essential product operations?
- Has the plugin completed its data-source migration?
- Does it support Merchant API product identities?
- Is the developer actively following Merchant API release changes?
- Is there a documented update path for API changes?
- Will the existing connection continue working after the Content API shutdown?
The phrase “Google API integration” is not specific enough. The product documentation should identify the API generation being used.
Start with the store’s actual requirements
The most feature-rich plugin is not automatically the correct choice.
Begin by evaluating the store.
Record:
- Total number of simple products
- Total number of variable products
- Total number of individual variations
- Average number of daily price changes
- Average number of daily stock changes
- Number of target countries
- Number of product languages
- Number of Merchant Center accounts
- Existing product sources
- Current scheduled tasks
- Server limits
- External ERP or warehouse integrations
A store with 100 stable products has different requirements from a store with 50,000 products whose prices and stock change throughout the day.
A small store may prioritise:
- Simple setup
- Clear product validation
- Manual product selection
- Understandable error messages
- Scheduled daily processing
A larger store may require:
- Incremental product updates
- Controlled background queues
- Product-level operation records
- Reliable variation processing
- Quota-aware scheduling
- Suitable retry controls
- Periodic catalogue reconciliation
- Detailed failed-operation reporting
Choose the plugin according to the workload it must manage, not according to the total number of features printed on its sales page.
Check the Google authorisation method
A third-party Google Merchant API plugin for WooCommerce should use an appropriate OAuth 2.0 authorisation flow.
The merchant should connect a Google account and deliberately grant the application access required for its Merchant Center functions.
Google states that third-party providers accessing their clients’ Merchant Center accounts should use OAuth 2.0. Applications accessing Merchant API must also complete applicable OAuth verification to avoid warnings and limitations. The requirements are described in Google’s third-party authorisation guide.
A suitable connection should not require the merchant to enter a Google password directly into WordPress.
Review whether the plugin:
- Opens Google’s real account-selection page
- Shows Google’s permission screen
- Returns through a registered callback address
- Verifies the callback state
- Stores tokens securely
- Refreshes access appropriately
- Allows the connection to be revoked
- Prevents unauthorised WordPress users from changing the connection
- Avoids exposing tokens in logs or page source
- Explains what Google access is requested and why
OAuth authorisation does not make every integration automatically secure. The plugin must still protect the complete connection lifecycle.
A plugin should also provide a clear method for disconnecting Google without deleting unrelated WooCommerce information.
Confirm Merchant Center account selection
A Google user may have access to more than one Merchant Center account.
The first account returned by Google is not necessarily the account intended for the WooCommerce store.
A reliable plugin should:
- Retrieve the accounts accessible to the authorised Google user.
- Display enough information to distinguish those accounts.
- Require the administrator to select the intended account.
- Store the selected account relationship.
- Show the active account in the plugin.
- Warn before changing to a different account.
- Prevent scheduled processes from using an incomplete account configuration.
This is particularly important for:
- Agencies
- Developers
- Store owners with several brands
- Businesses operating in multiple countries
- Advanced Merchant Center account structures
- WordPress administrators who manage several stores
Sending products to the wrong account can create confusion, duplicate data and unnecessary cleanup work.
Account selection should therefore be a deliberate configuration step, not an invisible default.
Review existing Merchant Center data sources
Before the plugin sends its first product, it should help the merchant understand the active data-source environment.
Merchant Center products may already be supplied through:
- An XML file
- A scheduled URL
- Google Sheets
- Manual product entry
- Another WordPress plugin
- An ecommerce-platform connection
- An ERP system
- Automatically found website products
- Another API application
Merchant API uses explicit data-source management. Google’s Data Sources sub-API guide explains that data sources can include primary, supplemental, local inventory, regional inventory, promotion and review sources.
A plugin should not assume that it is the only product source in the account.
Before synchronisation, determine:
- Which sources are active
- Which products they manage
- Which countries and languages they target
- Which product identities they use
- Whether their update schedules remain active
- Whether they overlap with the intended API products
- Which source should remain authoritative
Installing a new plugin does not automatically disable an old XML generator or scheduled import.
If an old process remains active, it may overwrite current information or recreate deleted products during its next update.
Evaluate WooCommerce product mapping
The plugin must understand how WooCommerce represents products.
For simple products, it should process information including:
- Product ID
- SKU
- Title
- Description
- Price
- Sale price
- Currency
- Availability
- Product URL
- Main image
- Additional images
- Brand
- GTIN
- MPN
- Condition
- Product category
- Shipping-related information
The plugin should not send the same default value blindly for every store.
It should recognise whether the product is published, visible and purchasable.
The submitted price should match:
- The visible product page
- WooCommerce
- Product structured data
- Cart
- Checkout
- Merchant Center
Availability should describe the genuine purchasing condition.
A product may have a stock quantity of zero while WooCommerce allows backorders. This requires more careful interpretation than simply converting every zero value to out_of_stock.
The plugin should also provide a way to review the source information before large-scale submission.
Require accurate variation support
Variation support is one of the most important selection criteria for many WooCommerce stores.
A variable product can contain options with different:
- Prices
- Sale prices
- Stock quantities
- Availability values
- SKUs
- GTINs
- Images
- Colours
- Sizes
- Materials
- URLs
A plugin that advertises “variable product support” should explain how individual variations are represented.
Check whether it:
- Gives every submitted variation a stable offer identity
- Uses a shared item group ID where appropriate
- Preserves individual variation prices
- Sends individual variation availability
- Uses variation-specific SKUs and GTINs
- Sends variation attributes such as colour and size
- Uses the correct variation image
- Removes deleted variations
- Associates Google issues with the correct WooCommerce variation
The parent product’s lowest price should not be submitted for every variation unless every variation can genuinely be purchased at that price.
A listing for a blue medium product should not present the image, stock or price belonging to a red large variation.
Variation support must be evaluated using real store products, not only a checkbox on the plugin’s feature page.
Look for stable product identities
Every Merchant product needs a stable identity.
The identifier should not change unnecessarily when:
- The title is edited
- The description is improved
- The price changes
- Stock changes
- An image is replaced
- A category changes
- A sale begins or ends
A stable identity may incorporate:
- WooCommerce product ID
- Variation ID
- SKU
- Content language
- Feed label
- Country or data-source context
Product titles should not be used as primary identities. Titles can change, may contain special characters and may not be unique.
Stable identities help with:
- Updating the intended product
- Matching Google issues
- Removing discontinued products
- Preserving variation relationships
- Avoiding duplicates
- Investigating processing results
- Maintaining performance continuity
Ask whether the plugin documents its product ID strategy and whether changing configuration can create new product identities.
An administrator should not discover the identity model only after thousands of duplicate products have appeared.
Distinguish submitted data from processed products
A strong Google Merchant API plugin for WooCommerce should distinguish between data sent by the plugin and the product processed by Google.
Merchant API uses separate concepts for submitted product input and processed product information.
This difference means that a successful request can confirm that Google received an operation without confirming that the product is:
- Approved
- Eligible for Shopping ads
- Eligible for free listings
- Available in every country
- Free from warnings
- Fully processed
- Compliant with every policy
A product may be accepted technically and later receive an issue such as:
- Missing required attribute
- Invalid attribute
- Price mismatch
- Availability mismatch
- Image problem
- Identifier problem
- Landing-page problem
- Policy limitation
The plugin interface should use accurate status language.
“Submitted successfully” is different from “approved by Google.”
Any plugin that promises automatic or guaranteed Google Shopping approval should be treated cautiously. Product and account eligibility remain Google’s decision.
Check product and account issue visibility
A useful integration should not stop after uploading products.
It should help the administrator understand what Google returned.
Merchant API provides dedicated account-issue resources with severity and impacted-destination information. Google’s account issue guide explains that issues can identify affected destinations such as Shopping ads or free listings.
When evaluating a plugin, ask whether it can display:
- Product-level problems
- Account-level problems
- Issue severity
- Affected country or region
- Affected destination
- Google’s issue description
- Documentation links
- The related WooCommerce product
- The latest retrieval time
- Whether the issue remains current
Generic messages such as “Google error” or “synchronisation failed” are not sufficient for practical catalogue management.
The administrator needs to understand:
- Which product failed
- Which operation failed
- When it failed
- Why it failed
- Whether another attempt is appropriate
- Which WooCommerce information must be corrected
The plugin should help locate the source of the problem without falsely claiming that it can resolve every Google policy issue automatically.
Review price and availability update behaviour
Price and availability often change more frequently than titles, descriptions or images.
Merchant API supports partial updates for frequently changing product information. Google identifies price and availability as suitable examples but also recommends periodically reinserting complete product information to keep the full state synchronised. This approach is documented in Google’s frequent product-update guide.
A suitable plugin should therefore provide a balance between:
- Targeted updates
- Full product operations
- Change detection
- Scheduled reconciliation
- Complete catalogue reviews
Sending every product whenever one stock value changes wastes server resources and API quota.
Sending only event-based updates without periodic reconciliation may miss changes made by:
- ERP imports
- Direct database operations
- Bulk product tools
- Warehouse systems
- Custom integrations
- Failed WordPress cron events
Ask how the plugin detects changes and whether it provides a controlled method for reconciling WooCommerce with Merchant Center.
Examine background processing
Large product catalogues should not depend on one browser request remaining open.
A reliable plugin should divide work into manageable background operations.
Background processing can reduce the risk of:
- Browser timeouts
- PHP execution limits
- Memory exhaustion
- Interrupted catalogue runs
- Duplicate submissions
- Incomplete batches
- Lost progress
However, the presence of a queue does not automatically make processing reliable.
Check whether the plugin:
- Limits batch size
- Records progress
- Prevents the same job from running twice
- Resumes safely after interruption
- Identifies permanently failed products
- Stops repeated invalid requests
- Separates manual and scheduled operations
- Shows the latest worker activity
- Provides a safe cancellation or reset method
- Avoids filling the database with unlimited logs
A failed background worker should be visible to the administrator.
A progress bar that stops silently at 42% is not a complete operational system.
Inspect quota and retry management
Merchant API requests are subject to quotas and limits.
Google documents per-minute and daily quota behaviour and identifies errors such as quota/request_rate_too_high and quota/daily_limit_exceeded. Google’s Merchant API quota guide explains the applicable quota structure.
A plugin should not respond to every error by immediately repeating the same request.
Temporary failures may justify another attempt.
Examples can include:
- Temporary connectivity problems
- Certain server-side failures
- Rate-related responses
- Short-lived service interruptions
Permanent data problems generally require correction.
Examples can include:
- Missing required values
- Invalid identifiers
- Unsupported attribute values
- Incorrect product data
- Unauthorised account access
- Invalid resource relationships
Google’s error-handling guidance recommends exponential backoff for appropriate transient internal errors.
A suitable plugin should:
- Classify errors
- Delay suitable retries
- Limit retry counts
- Stop repeating invalid data
- Preserve the original error
- Avoid exceeding quota through uncontrolled loops
- Let the administrator review permanently unsuccessful products
“Automatic retry” is useful only when the plugin understands what should and should not be retried.
Check deletion and discontinued-product handling
Product deletion is often overlooked during plugin selection.
Ask what happens when:
- A WooCommerce product is moved to trash
- A product is permanently deleted
- A variation is removed
- A product becomes private
- A product is unpublished
- A country is removed
- A language configuration changes
- The Merchant account connection changes
The plugin should retain enough identity information to remove the corresponding Merchant product through the intended source.
A deleted WooCommerce product may no longer contain all the information that originally created its Merchant identity. The integration therefore needs a controlled identity record or cleanup strategy.
Also remember that another active data source can recreate the product.
The correct order is:
- Identify the source that controls the product.
- Stop the unwanted update process.
- Remove the product through the authoritative connection.
- Monitor the next scheduled cycle.
- Confirm that the product does not return.
Deletion should not be treated as an isolated API call without reviewing source ownership.
Evaluate logs and operational records
A useful plugin should maintain enough information for troubleshooting without exposing sensitive credentials.
Operational records may include:
- WooCommerce product or variation ID
- SKU
- Operation type
- Merchant account reference
- Data-source reference
- Start time
- Completion time
- Submission result
- Error category
- Retry count
- Processed-product status
Logs should not expose:
- OAuth client secrets
- Access tokens
- Refresh tokens
- WordPress passwords
- Licence secrets
- Complete authorisation headers
- Sensitive callback values
Check whether logs have:
- Retention limits
- Cleanup controls
- Access permissions
- Masking of sensitive values
- Search or filtering
- Export functions where appropriate
Unlimited logging can enlarge the WordPress database. Insufficient logging can make failures impossible to diagnose.
The integration needs a controlled balance.
Check WordPress and WooCommerce compatibility
The plugin should state its supported environment clearly.
Review:
- Minimum WordPress version
- Tested WordPress version
- Minimum PHP version
- Supported WooCommerce versions
- PHP 8.2 compatibility
- WordPress multisite behaviour
- WP-Cron requirements
- Server extension requirements
- REST API requirements
- Compatibility with object caching
- Translation support
- Database table cleanup behaviour
Also test compatibility with systems that affect product information, including:
- Multilingual plugins
- Multi-currency plugins
- Dynamic-pricing extensions
- Stock-management integrations
- Product add-ons
- ERP connections
- Custom checkout rules
- SEO and structured-data plugins
A plugin cannot guarantee compatibility with every WooCommerce extension. Its documentation should explain important requirements and known limitations.
Review support, updates and licensing
Merchant API is an external platform that continues to change.
The plugin therefore needs ongoing maintenance.
Before purchasing, check:
- Current release date
- Changelog quality
- Merchant API version
- Support channel
- Documentation
- Licence duration
- Update entitlement
- Number of authorised sites
- Renewal terms
- Requirements after the licence expires
- Availability of original packages
- Compatibility testing
- Security-update process
A licence should be understood as more than permission to activate a feature.
It may also provide:
- Controlled software updates
- Current Google API compatibility
- Security improvements
- Technical support
- Access to corrected packages
- Compatibility fixes
PW Merchant API uses a controlled licensing and update structure intended to provide original packages and supported updates without exposing the technical details of the security infrastructure.
Merchants can review the current product and licence information on the PW Merchant API page.
Warning signs when evaluating a plugin
Treat the following claims or behaviours cautiously:
- “Guaranteed Merchant Center approval”
- “Guaranteed Google Shopping sales”
- “No Google account authorisation required”
- “Works with every WooCommerce extension”
- “Automatically creates valid GTINs”
- “Instantly fixes all policy violations”
- “Unlimited retries for every error”
- “No need to review existing product sources”
- “Every API success means product approval”
- “All variable products use the parent price”
- “API version does not matter”
- “Content API will continue indefinitely”
- “Server requirements are irrelevant”
- “Deleting the plugin automatically cleans every Merchant product”
- “All logs must contain complete tokens for support”
A credible plugin describes its limitations.
It should explain that product accuracy, store transparency, checkout functionality and Google eligibility remain the merchant’s responsibility.
How PW Merchant API supports WooCommerce stores
PW Merchant API is developed for WooCommerce stores that want to manage Google Merchant Center product operations through an API-based WordPress workflow.
Depending on the installed version and configured environment, its workflow can include:
- Authorised Google connection
- Accessible Merchant Center account selection
- WooCommerce product review
- Simple and variable product processing
- Merchant API product submission
- Price and availability updates
- Background operations
- Scheduled processing
- Product-level result records
- Google-side status visibility
- Review of unsuccessful operations
- Controlled retries
- WooCommerce and Merchant product matching
The intended route is:
WooCommerce product → PW Merchant API operation → Google Merchant API → Merchant Center processing result → corrective action in WooCommerce.
PW Merchant API does not:
- Guarantee product approval
- Guarantee account approval
- Invent genuine identifiers
- Repair an inaccessible product page
- Correct inaccurate warehouse data
- Decide the genuine selling price
- Replace store policy pages
- Override Google policies
- Guarantee traffic or sales
Its role is to make WooCommerce product submission and follow-up more controlled, traceable and manageable.
A practical pre-purchase test
Before using any plugin for the complete catalogue, test it with a representative product group.
Include:
- One simple product
- One variable product
- One sale product
- One out-of-stock product
- One backorder product
- One product with a GTIN
- One product without a GTIN
- One product with several images
For every product:
- Record its WooCommerce ID and SKU.
- Open the public product page.
- Confirm price and currency.
- Confirm availability.
- Check its structured data.
- Review the intended Merchant identity.
- Submit the product.
- Record the operational response.
- Wait for Google processing.
- Match the processed product.
- Review warnings and disapprovals.
- Change the price.
- Change the stock condition.
- Confirm that both changes reach the same product.
- Remove one test product.
- Confirm that it does not return.
This controlled test reveals more than a long feature list.
Frequently asked questions
What is the best Google Merchant API plugin for WooCommerce?
The best option is the plugin that matches the store’s catalogue size, variation structure, update frequency, server environment and monitoring requirements. Current Merchant API support, secure OAuth, stable identities, background processing and issue visibility are more important than an unusually long feature list.
Does a Merchant API plugin replace Google Merchant Center?
No. The plugin connects WooCommerce with Merchant Center. Merchant Center remains the Google platform where products, destinations and account conditions are processed and evaluated.
Does the plugin guarantee Google Shopping approval?
No. Google determines product and account eligibility. A plugin can submit information, retrieve results and help administrators find issues, but it cannot guarantee approval.
Should a new plugin still use Content API for Shopping?
A long-term integration should use the current Merchant API. Google has deprecated Content API for Shopping and states that it will be shut down in August 2026.
Is OAuth required?
Third-party applications managing client Merchant Center accounts should use OAuth 2.0. The merchant authorises access through Google rather than entering a Google password into WordPress.
Can one Google account access several Merchant Center accounts?
Yes. The plugin should list accessible accounts and allow the administrator to choose the intended account deliberately.
Can a Merchant API plugin process WooCommerce variations?
Yes, if it implements variation mapping correctly. Each submitted variation should retain its own stable identity, price, availability, SKU, attributes and suitable image.
Can the plugin invent a missing GTIN?
No. A valid GTIN must come from the manufacturer, supplier or genuine product record. Automatically inventing an identifier can create inaccurate product information.
Does successful API submission mean approval?
No. It confirms a technical operation. Google must still process the product and may return warnings, limitations or disapprovals.
How often should products be synchronised?
Synchronisation should reflect genuine product changes and the store’s operational needs. Price and stock may need timely updates, while unchanged products should not be submitted repeatedly without purpose.
Should the complete catalogue be sent during the first test?
No. Begin with a small representative group and confirm product identities, variations, prices, availability, processing results and deletion behaviour.
Can the old XML feed remain active?
It can remain active only when its responsibilities do not conflict with the API source. Overlapping sources require deliberate product identity and ownership planning.
Why does a deleted product return?
Another active source, scheduled file, old plugin or ERP integration may be creating it again. Stop the unwanted update process before removing its products.
Can a plugin fix a price mismatch automatically?
It can submit a corrected WooCommerce value, but the real cause may be the product page, structured data, variation selection, tax configuration, currency conversion or another data source. The source of the mismatch must be corrected.
Does Merchant API work with large WooCommerce catalogues?
It can, provided the integration uses controlled batching, background processing, stable product identities, quota-aware scheduling and suitable error handling.
Final plugin selection checklist
Before choosing a Google Merchant API plugin for WooCommerce, confirm that:
- It uses the current Merchant API
- Its Merchant API version is documented
- It has a maintained update path
- It uses appropriate OAuth authorisation
- Tokens and secrets are protected
- Google passwords are not stored in WordPress
- Accessible Merchant Center accounts can be listed
- The intended account can be selected deliberately
- Existing data sources can be reviewed
- Simple products are mapped correctly
- Variations are processed individually
- Product identities remain stable
- Prices match the public store
- Availability matches the purchasing experience
- Images are publicly accessible
- GTINs and MPNs are not invented
- Submitted and processed products are distinguished
- Product issues can be reviewed
- Account issues can be reviewed
- Background jobs are controlled
- Queue progress is visible
- Duplicate jobs are prevented
- API quotas are respected
- Temporary errors use limited retries
- Permanent errors require correction
- Logs mask sensitive values
- Log retention is controlled
- Deleted products can be removed correctly
- Obsolete sources do not recreate products
- WordPress and WooCommerce requirements are documented
- PHP 8.2 compatibility is available
- Scheduled processing requirements are explained
- Support and update terms are clear
- The plugin does not promise guaranteed Google approval
- A limited product test can be completed before full synchronisation
Conclusion
Choosing a Google Merchant API plugin for WooCommerce is a product-data management decision, not merely a WordPress installation decision.
The plugin will be responsible for translating WooCommerce products into Merchant API operations, protecting the Google connection, maintaining stable identities, managing background work and presenting Google’s results to the administrator.
Start by confirming current Merchant API support. Google has deprecated Content API for Shopping, so an older integration without a migration path presents a serious continuity risk.
Next, evaluate OAuth security, Merchant Center account selection, existing data sources, product mapping and variation handling.
Then review operational behaviour:
- How are changes detected?
- How are background jobs processed?
- How are quotas respected?
- Which errors are retried?
- How are unsuccessful products identified?
- How are discontinued products removed?
- How are sensitive logs protected?
A suitable integration should make each product operation traceable without suggesting that submission equals approval.
PW Merchant API is designed to connect WooCommerce products with Google Merchant API through a controlled WordPress workflow. It supports product processing, account selection, background operations and result visibility while keeping WooCommerce as the primary source of product information.
Its purpose is not to guarantee approval or create missing commercial information. Its purpose is to help merchants manage the connection more accurately and understand what happened to each submitted product.
Before processing the complete catalogue, test simple products, variations, price changes, stock changes and deletions. Confirm that Google processes the intended products and that old sources do not overwrite the new information.
The correct Google Merchant API plugin for WooCommerce should provide security, current API compatibility, operational visibility and controlled product management—not merely an upload button.