WooCommerce Google Merchant integration troubleshooting

WooCommerce Google Merchant integration troubleshooting: Keep products, prices and stock consistent

A WooCommerce Google Merchant integration should keep the commercial information in WooCommerce aligned with the products processed in Google Merchant Center.

When the integration works correctly, a genuine change to a WooCommerce product reaches the same Merchant product without creating an unnecessary duplicate. The submitted price matches the public product page, the availability reflects the actual purchasing experience, each variation retains its own identity and discontinued products do not return through an old data source.

The direct answer is:

A reliable WooCommerce Google Merchant integration needs more than successful API requests. It requires defined data ownership, stable product identities, deliberate data-source management, controlled background processing and regular reconciliation among WooCommerce, the public product page, structured data and Google’s processed product.

The correct diagnostic route is:

WooCommerce value → integration input → Merchant data source → processed Google product → public landing page → cart and checkout.

If these layers disagree, repeatedly pressing a synchronisation button rarely solves the underlying problem.

What does a healthy WooCommerce Google Merchant integration look like?

A healthy integration creates a traceable relationship between each WooCommerce product and its corresponding Google Merchant product.

An administrator should be able to answer:

Which WooCommerce product created this Merchant product?
Which variation does it represent?
Which Merchant Center account received it?
Which data source controls it?
Which product identity was used?
What price and currency were submitted?
What availability was submitted?
When was the latest operation completed?
Has Google processed the submitted information?
Did Google return a warning, limitation or disapproval?
Can the product be updated or removed through the same source?

The integration is not healthy merely because its Google connection shows a green status.

A valid OAuth connection confirms that the application can access authorised resources. It does not confirm that products are accurate, background workers are running or Google has approved the submitted items.

A complete health assessment therefore covers four areas:

Connection health
Product-data accuracy
Processing health
Merchant Center results

These areas should be reviewed separately.

Understand the difference between submitted and processed products

Google Merchant API distinguishes between the product information submitted by an application and the final product processed by Google.

A ProductInput represents information supplied by a data source. The processed Product represents the result after Google applies applicable rules and combines the primary input with eligible supplemental information.

Google’s official Merchant API product migration guide explains this separation between product input and processed product.

This distinction is important during troubleshooting.

A successful insert or update can mean:

The request was authenticated
The request format was acceptable
The product input was received
The technical operation completed

It does not necessarily mean:

The product has been processed
The latest value is already visible
The product is approved
Every destination is eligible
The price matches the landing page
The product has no warnings
Google Shopping will display the product

Google also notes that processing a changed product input can take several minutes before the updated processed product becomes available.

The WordPress interface should therefore distinguish statuses such as:

Waiting
Queued
Submitted
API operation successful
Processing
Processed
Warning
Limited
Disapproved
Temporary operation failure
Permanent data error

Displaying every HTTP success as “Approved” creates an inaccurate picture of the integration.

Define the source of truth for every product field

Troubleshooting becomes difficult when several systems can change the same value.

A WooCommerce store may receive product information from:

Manual WordPress administration
An ERP system
Warehouse software
Supplier imports
Currency converters
Dynamic-pricing extensions
Stock-management services
Marketplace integrations
Scheduled CSV imports
Custom WordPress functions
WooCommerce webhooks

Before investigating Merchant Center, document which system controls each important field.

A basic ownership record should identify:

Product title owner
Description owner
SKU owner
GTIN owner
Brand owner
Regular-price owner
Sale-price owner
Currency owner
Stock owner
Backorder owner
Image owner
Variation owner
Product-publication owner
Product-deletion owner

WooCommerce can remain the immediate source used by the Merchant integration even when an ERP is the original business source.

For example:

Warehouse system → WooCommerce stock → PW Merchant API → Google Merchant API → Merchant Center.

If the warehouse sends an incorrect quantity, the integration may accurately transmit an inaccurate WooCommerce value.

The correction must be made at the authoritative source. Otherwise, the next warehouse update can overwrite a manual WooCommerce correction.

Create a product-level reconciliation record

A reconciliation record compares the same commercial offer across every relevant layer.

For each product, record:

WooCommerce product ID
WooCommerce variation ID
SKU
Merchant offer ID
Content language
Feed label
Merchant account
Data source
WooCommerce price
Public-page price
Structured-data price
Cart price
Checkout price
Submitted price
Processed price
WooCommerce availability
Public-page availability
Structured-data availability
Submitted availability
Processed availability
Latest operation time
Latest Google processing time
Current product status

This record turns a general complaint such as “Merchant Center displays the wrong price” into a specific comparison.

The administrator can identify the first layer where the value changes.

For example:

WooCommerce: EUR 49.00
Public page: EUR 49.00
Structured data: EUR 59.00
Merchant input: EUR 49.00
Processed product: EUR 59.00

This pattern suggests that the integration submitted the expected value, but Google found a different value in the landing-page structured data or another eligible input affected the processed result.

Another example:

WooCommerce: In stock
Selected variation: Out of stock
Merchant input: In stock
Processed product: In stock
Checkout: Cannot purchase

This pattern suggests that the integration may be reading the parent product’s stock condition instead of the selected variation.

Diagnose price mismatches systematically

Price mismatch is one of the most common WooCommerce Google Merchant integration problems.

The submitted price must represent the amount an ordinary customer is expected to pay under the stated conditions.

Check the following values in order:

WooCommerce regular price
WooCommerce active sale price
Selected variation price
Public product-page price
Structured-data price
Cart price
Checkout price
Submitted Merchant price
Processed Merchant price

A mismatch can be caused by:

Cached product pages
Cached structured data
Scheduled sales using different time zones
Incorrect variation selection
Tax-inclusive and tax-exclusive calculations
Customer-group pricing
Dynamic-pricing rules
Currency conversion
Minimum-order pricing
Product add-ons
Membership discounts
Coupon-dependent prices
Another active Merchant data source
Delayed Google processing
An outdated background job

Do not assume that the WooCommerce administration value is the only price visible to Google.

The theme, structured-data plugin, caching layer or currency extension may publish another value.

Google can use structured data and page extraction to update price, sale price, availability and condition. Its automatic product update documentation also states that these automations are intended to correct temporary discrepancies, not replace regular accurate product updates.

If automatic updates repeatedly change submitted prices, treat that as evidence of an unresolved store-data inconsistency.

The durable correction is to align:

WooCommerce
Product-page HTML
Structured data
Cart
Checkout
Merchant input

Disabling automatic updates without correcting the underlying mismatch can convert an automatic correction into a product disapproval.

Check sale-price timing

Sale-price problems deserve a separate review.

Confirm:

The sale has started in the WordPress time zone
The sale has not expired
The visible customer price is the sale price
Structured data contains the active price
The regular price remains accurate
The integration sends the expected sale information
The selected variation has its own valid sale schedule
Page cache was cleared after the price changed
Google has processed the most recent input

A sale may begin correctly in WooCommerce while the cached landing page continues to show the regular price.

The opposite can also occur: WooCommerce may consider the sale finished while an old cached page or structured-data block continues to display the lower price.

Record the time zone and exact activation time when testing scheduled sales.

Diagnose stock and availability mismatches

Availability should represent whether the customer can purchase the submitted product under the represented conditions.

Review:

WooCommerce stock status
Managed stock quantity
Backorder setting
Parent product condition
Individual variation condition
Product publication status
Add to cart behaviour
Target-country delivery availability
Structured-data availability
Submitted Merchant availability
Processed Merchant availability

Possible causes of availability mismatches include:

Parent stock used for all variations
Backorders mapped as ordinary in-stock products
Stock updated after order placement but not synchronised
Cancelled orders restoring stock incorrectly
Warehouse imports overwriting WooCommerce
Object-cache delays
WP-Cron failures
Queue congestion
Another data source submitting older availability
Structured data publishing a different condition
Product page allowing purchase despite an out-of-stock database value

A positive stock quantity does not prove that the customer can purchase the product.

A required variation may be unavailable. Shipping may not be available for the target country. A product add-on may prevent checkout. The Add to cart action may fail because of a JavaScript or theme error.

The complete purchasing experience must match the submitted condition.

Separate backorder, preorder and in-stock behaviour

WooCommerce supports several stock behaviours that require deliberate mapping.

A product allowing backorders is not operationally identical to a product ready for immediate dispatch.

Review:

Whether backorders are allowed
Whether the customer is informed
Whether an availability date is required
Whether the public page explains the condition
Whether the selected Merchant value represents the offer accurately
Whether the delivery promise remains realistic

Google’s automatic update system may treat certain availability values as compatible during its matching process. That does not remove the merchant’s responsibility to submit an accurate commercial condition.

The integration should use a documented mapping rule rather than converting every purchasable WooCommerce product into a generic in-stock value.

Troubleshoot variable products individually

Variable products should be investigated at variation level.

A parent product can contain combinations with different:

Prices
Sale prices
SKUs
GTINs
Stock quantities
Availability
Images
Colours
Sizes
Materials
URLs

A variation error may remain hidden when the administrator reviews only the parent product.

For each affected variation, compare:

Parent product ID
Variation ID
Variation SKU
Variation attributes
Variation-specific price
Variation-specific stock
Variation image
Merchant offer ID
Item group ID
Landing-page selection
Processed Merchant result

Common variation failures include:

All variations receiving the parent’s lowest price
Every variation using the same SKU
One GTIN copied to multiple different variations
Parent availability applied to unavailable options
Variation images replaced with the parent image
Colour and size attributes omitted
Two variations generating the same Merchant identity
Deleted variations remaining active
Product links opening the wrong default selection

Every submitted variation should have a stable identity while related variations share an appropriate grouping value.

Changing a variation’s price should update the same Merchant offer. It should not create a new offer merely because the price changed.

Investigate duplicate products by source and identity

Duplicate Merchant products are usually an ownership or identity problem.

Possible causes include:

An active XML product source
A scheduled file
Another WooCommerce plugin
An ERP integration
Manual Merchant Center products
A previous API connection
Automatically found products
A changed offer ID
A changed content language
A changed feed label
Parent and variation records using overlapping identities
Reinstalling an integration without preserving mappings

Merchant API requires explicit data-source management and supports multiple API data sources. Google’s data-source migration documentation warns that integrations should identify the product’s specific data source before performing write operations when source rules are involved.

For every apparent duplicate, compare:

Merchant offer ID
Product title
Product URL
Data source
Content language
Feed label
Target country
Update time
Responsible application

Two products with similar titles are not necessarily duplicates.

They may represent:

Different variations
Different languages
Different countries
Different currencies
Different sellers
Different landing pages

Conversely, two records with slightly different titles may represent the same commercial offer submitted by competing sources.

Do not delete products until the controlling source has been identified.

Use a controlled duplicate-cleanup sequence

Use the following order:

List every active data source.
Identify the source responsible for each duplicate.
Confirm the desired authoritative source.
Stop the unwanted plugin, schedule or external import.
Preserve the desired product identity.
Remove the unwanted input through its controlling source.
Wait for Google processing.
Monitor the next scheduled cycle.
Confirm that the unwanted product does not return.

Deleting the visible Merchant product before stopping its source is usually temporary.

The next scheduled XML fetch, API job or ERP operation may recreate it.

Diagnose products that return after deletion

A product that returns is evidence that at least one creation route remains active.

Review:

Scheduled product files
Old WordPress plugins
WooCommerce action queues
Server cron jobs
ERP connections
Supplier import jobs
Old API credentials
Automatically found products
Manual data-source rules
Retry queues containing old operations

Google provides controls for products added through its Found by Google data source. This source should be reviewed when products reappear even though the expected plugin route has been stopped.

Also confirm whether the deletion affected:

The submitted product input
The processed product
Only one country
Only one language
Only one data source
Only the parent product
Only one variation

A product can appear to return when another source-specific version was never deleted.

Preserve stable product identities

Merchant API product identities use content language, feed label and offer ID as important identifying components.

Google’s product lifecycle documentation explains the product-name structure and notes that API products should be updated or refreshed regularly to prevent expiration.

A stable offer ID should not be based mainly on information that changes frequently.

Avoid using:

Product title
Current price
Category name
Stock quantity
Image filename
Product-list position
Temporary query parameters

More suitable internal identity components can include:

WooCommerce product ID
WooCommerce variation ID
Stable SKU
Store-defined immutable identifier

The integration should retain a mapping among:

WooCommerce object
Merchant account
Data source
Content language
Feed label
Offer ID
Processed product name

Without this record, a product title change may accidentally create a second Merchant product instead of updating the existing one.

Stable identity is also essential for controlled deletion.

Troubleshoot stale prices and stock

A correct WooCommerce value may remain stale in Merchant Center because the change never completed its operational route.

Check:

Was the WooCommerce change detected?
Was an update job created?
Was the job placed in the queue?
Did a worker claim the job?
Did the worker complete?
Did the API request succeed?
Was the correct data source used?
Was the correct product identity used?
Did Google process the updated input?
Did another source overwrite the value?

The integration should record each stage.

A stopped progress bar does not reveal whether the failure occurred before or after the API request.

Useful product-level operation statuses include:

Change detected
Job created
Waiting for worker
Worker started
API request sent
API operation succeeded
Temporary failure
Retry scheduled
Permanent failure
Processing result retrieved
Reconciliation completed

This information allows the administrator to distinguish a WordPress queue failure from a Google processing delay.

Review WordPress background processing

WooCommerce Google Merchant integration jobs may depend on:

WP-Cron
Action Scheduler
A server cron job
WordPress REST requests
Loopback requests
Database locks
PHP workers
Memory limits
Execution-time limits

Check:

Last successful cron event
Last queue-worker activity
Oldest pending job
Failed WooCommerce scheduled actions
Duplicate running jobs
PHP error logs
Database table size
Loopback-request health
Authentication failures
Time-zone configuration

Large catalogue operations should be divided into manageable batches.

A worker should not repeatedly process the same invalid product without a limit. It should also prevent two workers from operating on the same job concurrently.

Safe background processing needs:

Batch limits
Progress records
Job locking
Resume behaviour
Cancellation controls
Retry limits
Failure classification
Log cleanup
Visible last activity

Use different update strategies for different fields

Price and availability can change frequently. Titles, descriptions and images usually change less often.

Merchant API supports partial product-input updates for frequently changing attributes. Google’s frequent product updates guide describes updating selected fields while leaving other product information unchanged.

A balanced integration can use:

Targeted price updates
Targeted availability updates
Full updates after meaningful catalogue changes
Periodic product reconciliation
Scheduled refresh operations
Controlled product removal

Partial updates reduce unnecessary data transmission, but they require accurate product identity and field-selection logic.

An incorrect update mask can remove or preserve the wrong information.

The integration should also perform periodic complete reconciliation so that rarely changed fields do not remain stale indefinitely.

Control quotas and retry behaviour

Uncontrolled retry loops can turn a temporary problem into a larger operational failure.

Google applies Merchant API quotas at method and account levels. Current usage and limits should be reviewed through the appropriate quota tools because limits can change.

When a temporary rate or internal error occurs, retrying may be appropriate.

When a product contains permanently invalid information, repeating the same request without changing the product is not appropriate.

Google’s Merchant API error-handling guide recommends exponential backoff for suitable rate-related and transient internal errors.

The integration should distinguish:

Temporary failures

Short-lived connectivity problem
Temporary Google service error
Suitable rate-limit response
Temporary DNS or transport problem
Brief server interruption

Permanent or corrective failures

Missing required value
Invalid product identifier
Unsupported attribute
Unauthorised Merchant account
Wrong data-source relationship
Invalid currency
Inaccessible product URL
Incorrect field format

A controlled retry system should:

Preserve the original error
Classify the error
Delay appropriate retries
Increase the delay between repeated attempts
Limit retry counts
Stop repeating permanent errors
Respect current quotas
Display permanently unsuccessful products

Google’s Merchant API quota guide identifies separate per-minute and daily quota errors and recommends periodically reviewing current usage.

Protect logs without losing diagnostic value

Troubleshooting requires operational records, but those records must not expose credentials.

Useful records include:

WooCommerce product ID
Variation ID
SKU
Merchant offer ID
Masked account reference
Data-source reference
Operation type
Request time
Completion time
Result category
Retry count
Google error code
Product-processing status

Logs should not contain:

Google passwords
OAuth client secrets
Access tokens
Refresh tokens
Complete authorisation headers
Licence secrets
Unmasked callback values
WordPress administrator passwords

Logs should have:

Administrator-only access
Retention limits
Scheduled cleanup
Sensitive-value masking
Product search
Status filtering
Date filtering
Controlled export where necessary

Unlimited logging can enlarge the WordPress database and slow administrative operations.

Insufficient logging makes intermittent failures impossible to investigate.

The system needs a deliberate balance.

Build a daily operational dashboard

A practical dashboard should show current action items rather than only total product numbers.

Useful indicators include:

Selected Merchant Center account
Active data source
Last successful authorisation
Last successful worker activity
Oldest queued job
Active job count
Temporary failure count
Permanent failure count
Products awaiting Google processing
Products with price mismatches
Products with availability mismatches
Disapproved products
Limited products
Deleted WooCommerce products still found in Merchant Center
Merchant products without WooCommerce mappings
WooCommerce products not recently reconciled

The administrator should be able to move from a summary number to the affected products.

A counter showing “75 problems” is less useful when it does not reveal which products, variations, countries or destinations are affected.

Use a repeatable troubleshooting workflow

When a WooCommerce Google Merchant integration problem is reported, use this sequence:

Identify one affected product.
Record its WooCommerce ID, variation ID and SKU.
Record its Merchant offer ID and data source.
Confirm the authoritative source for the disputed field.
Compare WooCommerce, public page, structured data, cart and checkout.
Review the latest plugin operation.
Confirm that the correct Merchant account was used.
Confirm that the correct data source was used.
Confirm that the stable product identity was preserved.
Separate API success from processed product status.
Review other active sources.
Correct the earliest inaccurate layer.
Send a controlled update.
Wait for Google processing.
Compare the processed product again.
Monitor the next scheduled cycle.

Do not begin by resending the complete catalogue.

A single affected product usually provides enough evidence to locate the failing layer without generating thousands of additional requests.

How PW Merchant API supports controlled integration management

PW Merchant API is developed to help WooCommerce stores manage product operations through Google Merchant API from the WordPress administration environment.

Depending on the installed version and configured environment, its workflow can include:

Authorised Google connection
Accessible Merchant Center account selection
WooCommerce product review
Simple-product processing
Individual variation processing
Product submission
Price and availability updates
Scheduled background processing
Product-level operation records
Google-side result visibility
Unsuccessful-operation review
Controlled retries
WooCommerce and Merchant product matching

The intended operational route is:

WooCommerce product → PW Merchant API operation → Google Merchant API → processed Merchant product → issue review and correction.

This structure helps administrators determine:

Which WooCommerce product was processed
Which operation occurred
Whether the request succeeded technically
Whether Google processed the product
Whether corrective action is required

PW Merchant API does not invent product identifiers, determine the genuine selling price, repair incorrect warehouse information or guarantee Google approval.

Its purpose is to make WooCommerce-to-Merchant operations more controlled, visible and manageable.

Merchants can review current product and licence information on the PW Merchant API page.

WooCommerce Google Merchant integration audit checklist

Product identity

Every simple product has a stable identity
Every variation has a separate stable identity
Product titles are not used as the primary identity
Price changes do not create new products
Stock changes update the same products
Merchant mappings survive ordinary plugin updates
Deleted products retain enough information for cleanup

Price accuracy

WooCommerce price is correct
Active sale price is correct
Variation price is correct
Public-page price matches
Structured-data price matches
Cart price matches
Checkout price matches
Currency is consistent
Cached pages are current
Submitted and processed prices are distinguished

Availability accuracy

WooCommerce stock status is correct
Variation stock is checked individually
Backorders are mapped deliberately
Add to cart works
Target-country delivery is available
Structured-data availability matches
Submitted availability matches the purchasing experience

Data sources

Every active source is documented
The intended API source is identified
Old XML sources are reviewed
Old plugins are disabled when no longer needed
Scheduled files are reviewed
Automatically found products are reviewed
Data-source ownership is clear
Duplicate products are investigated before deletion

Background processing

WP-Cron or server cron is working
Latest worker activity is visible
Batch sizes are controlled
Duplicate workers are prevented
Progress is recorded
Jobs can resume safely
Temporary failures use limited retries
Permanent failures stop repeating
Failed products are searchable

Security and logs

OAuth is used appropriately
Google passwords are not stored
Tokens are protected
Sensitive values are masked
Logs have retention limits
Log access is restricted
Database cleanup is scheduled
Disconnect and reset actions are controlled

Google results

API success is not shown as approval
Processed products are retrieved
Product issues are visible
Account issues are reviewed
Countries and destinations are identified
Disapproved products are traceable to WooCommerce
Corrections are made at the authoritative source
Products are checked again after Google processing

Frequently asked questions

Why is my WooCommerce price different in Merchant Center?

The cause may be an outdated background operation, another active data source, a scheduled sale, caching, currency conversion, variation mapping, structured data or a difference between the product page and checkout. Compare every price layer before resubmitting the product.

Why does Merchant Center show an old stock status?

The WooCommerce change may not have created a job, the worker may have stopped, the request may still be queued, Google may still be processing the input or another source may have overwritten the new availability.

Why are WooCommerce products duplicated in Merchant Center?

Common causes include multiple data sources, an old XML feed, another plugin, automatically found products or a changed product identity. Compare the data source, offer ID, language and feed label of every apparent duplicate.

Should I delete my old XML source immediately?

No. First identify the products it controls, test the new API source and stop the old update schedule. Remove the obsolete source only after confirming that the new integration manages the intended products accurately.

Why does a deleted product return?

An old plugin, scheduled file, ERP connection, retry queue or automatically found product source may be creating it again. Stop the active creation route before repeating the deletion.

Does an API success mean that Google approved the product?

No. It means the technical operation succeeded. Google must still process the product and can return warnings, limitations or disapprovals.

Can Google automatically correct a wrong WooCommerce price?

Google may use landing-page information for automatic product updates, but this is not a replacement for accurate regular submissions. Repeated automatic corrections indicate that WooCommerce, the product page, structured data or the submitted information remains inconsistent.

How should variable products be synchronised?

Each variation should preserve its own stable identity, SKU, price, availability, identifiers, attributes and suitable image. Related variations should use an appropriate grouping relationship.

Can the integration create missing GTINs?

No. GTINs must come from a genuine manufacturer, supplier or product record. An integration should not invent them.

How often should WooCommerce products be updated?

Price and stock changes may require timely targeted updates. Full reconciliation should also occur periodically so that titles, descriptions, images, identifiers and other less frequently changed fields remain accurate.

Should every failed request be retried automatically?

No. Suitable temporary failures can use limited retries with exponential backoff. Permanent product-data errors should stop and wait for correction.

Can two Merchant data sources remain active?

Yes, when their responsibilities are deliberately separated. They should not compete for the same product identity without a documented ownership strategy.

What should I check when the queue stops?

Review WP-Cron, WooCommerce scheduled actions, last worker activity, failed actions, loopback requests, PHP errors, database locks, memory limits and whether another worker already holds the job.

Does PW Merchant API guarantee product approval?

No. Google independently evaluates products, destinations and accounts. PW Merchant API is intended to provide a controlled product-processing route and make results easier to trace back to WooCommerce.

Conclusion

A WooCommerce Google Merchant integration should be evaluated by data consistency and operational traceability, not only by the number of products it can send.

A healthy integration preserves a stable relationship among:

WooCommerce products
Individual variations
Merchant product identities
Merchant Center accounts
Data sources
Public landing pages
Structured data
Google’s processed products

When a problem occurs, begin with one affected product.

Compare its WooCommerce value, public product page, structured data, cart, checkout, submitted input and processed Google product.

Identify the first layer where the value becomes inaccurate.

Price and stock problems are not always caused by the Merchant integration. They can originate in an ERP system, a currency extension, scheduled sales, cache, structured data, variation logic or another active data source.

Duplicate products and returning deleted products usually indicate unresolved source ownership.

The correct sequence is to identify the controlling source, stop the unwanted update process, remove the unwanted product through that source and monitor the next scheduled cycle.

Background operations also require active control. Workers should use manageable batches, preserve progress, prevent duplication, classify failures and apply limited retries only when appropriate.

PW Merchant API is designed to support this controlled WooCommerce Google Merchant integration workflow through authorised account access, product-level processing, scheduled operations and result visibility.

Its purpose is not to guarantee Google approval or replace accurate store information.

Its purpose is to help administrators identify which product was processed, which operation occurred, whether Google received it and what action is required next.

The strongest integration is not the one that repeatedly sends the complete catalogue whenever a problem appears.

It is the one that maintains stable identities, protects data-source ownership, keeps prices and availability accurate, controls background work and makes every important result traceable to the correct WooCommerce product.