How to fix inconsistent language in Google Merchant Center for WooCommerce

How to fix inconsistent language in Google Merchant Center for WooCommerce

An inconsistent language issue occurs when the language assigned to product data does not accurately match the language customers encounter on the associated WooCommerce product page and throughout the purchasing process.

The submitted product title may be in English while the landing page opens in German. The product description may be translated correctly, but variation names, stock messages or the Add to cart button may remain in another language. A customer may reach an English product page and then be redirected to a Turkish shopping cart or checkout.

These differences can limit product performance or result in disapproval when Google cannot connect the submitted offer with a coherent customer experience.

The solution is not simply to change the WordPress site language.

Merchants must identify the language assigned to the product data source, inspect the actual values submitted for each offer, open the exact landing-page URL Google receives and follow the complete purchase path through the cart, checkout, policy pages and payment-selection stage.

The objective is to provide one understandable and operationally complete language experience for each submitted offer.

The short answer

To fix inconsistent language in Google Merchant Center for WooCommerce:

• Open the affected product in Merchant Center.
• Record the affected offer ID.
• Record the product’s content language.
• Record the feed label and data source.
• Inspect the submitted title and description.
• Open the exact submitted product URL.
• Confirm that the page opens in the intended language while logged out.
• Check the product title and description.
• Check attribute and variation names.
• Check colour, size, material and pattern values.
• Check price, availability and condition messages.
• Check the Add to cart button and quantity controls.
• Select every relevant variation.
• Add the product to the cart.
• Check the shopping-cart language.
• Continue to checkout.
• Check field labels, validation messages and shipping methods.
• Check payment instructions and required customer notices.
• Open the terms and conditions.
• Open the refund and return policy.
• Open the shipping policy.
• Open the contact and business-information pages.
• Confirm that navigation required to purchase is understandable in the same language.
• Disable unintended browser-language or IP-based redirections.
• Review multilingual and translation-plugin settings.
• Review page-cache and CDN variations.
• Confirm that translated products link to translated landing pages.
• Submit each language version with the correct content language.
• Use separate product data for each language where necessary.
• Update the affected products through the authoritative data source.
• Remove obsolete or competing product sources.
• Allow Google to process the corrected information.
• Monitor Merchant Center for updated product status.

Do not change the declared content language merely to match whichever untranslated text happens to appear on the website.

Correct the entire language path.

What inconsistent language means

Google evaluates the relationship between:

• The language selected for the product data
• The language used in submitted product attributes
• The language displayed on the landing page
• The language of product-selection controls
• The language used in the cart
• The language used during checkout
• The language of customer policies and business information required to make a purchasing decision

Suppose a product is submitted with English as its content language.

The following experience is generally consistent:

• English product title
• English description
• English variation names
• English stock status
• English purchase button
• English cart
• English checkout
• English shipping information
• English terms and return policy

The following experience is inconsistent:

• English submitted title
• English submitted description
• French product page
• German variation labels
• Turkish cart
• English checkout
• Untranslated validation messages
• Return policy available only in another language

The issue is not limited to one heading.

Google considers whether a customer can understand the product and complete the purchase using the language represented by the product data.

Google’s current language policy

Google updated its inconsistent-language policy in December 2024.

Some differences between product data and website language may now be allowed. For example, individual titles, descriptions or variation information in another language may not automatically produce immediate disapproval when the majority of the product data matches the declared language.

However, Google warns that these offers may have limited performance because the information may not match the customer’s search terms and expectations. If most product data does not match the selected product-data language, products may still be disapproved.

Google also continues to require the elements that allow a customer to navigate, understand the offer and complete the purchase to use the same language as the product data.

The change therefore does not mean that multilingual inconsistency can be ignored.

It means that minor or isolated language differences are treated differently from a catalogue or purchase journey that fundamentally uses the wrong language.

Google explains the update in its Merchant Center announcements change log.

Why language consistency matters

A product listing sets an expectation before the customer visits the store.

If a customer searches in English and sees an English product listing, the linked page should allow that customer to understand:

• Which product is being sold
• Which variation is selected
• Whether the product is available
• What the product costs
• How it will be delivered
• What information is required during checkout
• Which payment methods are available
• What the return conditions are
• How to contact the business

A sudden language change can interrupt that process.

The customer may not understand a mandatory option, validation message, shipping restriction or payment instruction. Even if the product itself is clear, an untranslated checkout can prevent the order from being completed.

Language consistency therefore supports both Merchant Center compliance and a usable purchasing experience.

Correct language information does not guarantee approval, impressions, ranking, clicks or sales. Google independently processes the submitted product data and determines product eligibility and presentation.

The three language layers

Most inconsistent-language investigations involve three different layers.

1. Product data language

This is the language associated with the submitted product data.

It affects how Google interprets values such as:

• Title
• Description
• Product type
• Colour
• Material
• Pattern
• Size type
• Size system
• Age group
• Gender
• Custom labels containing meaningful text
• Variant-related information

Attribute names used by Google are submitted according to the technical product-data specification. The customer-facing values must represent the intended content language.

For example, the technical attribute remains color, but its submitted value may be:

• Red for English
• Rot for German
• Rouge for French
• Kırmızı for Turkish

Do not translate Google’s technical attribute names in an API request.

Translate the customer-facing product values.

2. Landing-page language

This is the language shown when Google or a customer opens the submitted product URL.

The page should provide a coherent version of:

• Product title
• Description
• Variation selectors
• Attribute names
• Attribute values
• Availability
• Condition
• Price information
• Purchase controls
• Delivery information
• Important product restrictions

Google’s landing-page requirements state that the landing page should use the same language as the product data.

Google also explains that the experience should remain stable regardless of the user’s device, browser, cookies, location or other contextual factors.

3. Purchase-process language

The language must remain usable after the customer leaves the product page.

Relevant areas include:

• Mini cart
• Shopping cart
• Checkout
• Account-registration form
• Shipping-address form
• Billing-address form
• Form validation
• Shipping-method selection
• Payment-method selection
• Mandatory notices
• Terms and conditions
• Refund and return policy
• Contact information
• Order-review section

Google’s checkout requirements specifically identify the shopping cart, checkout, terms and conditions, return policy and business information as relevant parts of the language review.

A translated product page does not solve the issue when the customer reaches an untranslated checkout.

Content language is not the same as target country

A target country identifies where products are intended to be shown and sold.

Content language identifies the language of the submitted product information and associated customer experience.

One target country can support more than one language.

For example, a merchant targeting Canada may prepare:

• English product data linked to English pages
• French product data linked to French pages

The country can remain the same while the language changes.

Do not assume that the target country automatically determines the correct language.

Review Google’s current supported languages and currencies before creating a country-and-language combination.

The WordPress site language does not prove compliance

WordPress includes a Site Language setting under Settings → General.

This setting can control:

• WordPress administration translations
• Theme translation files
• Plugin translation files
• Some front-end interface text
• Date and number formatting
• Core-generated messages

It does not prove that the entire WooCommerce store uses that language.

A WordPress installation set to English can still contain:

• German product descriptions
• Turkish variation names
• French checkout fields
• Untranslated theme buttons
• Browser-generated validation messages
• Payment-gateway instructions in another language
• Policy pages copied from an older store
• Cached pages from another locale

Conversely, the WordPress administration can use Turkish while the customer-facing store is correctly presented in English.

The administration language and customer-facing product language are separate matters.

How Google identifies a Merchant API product

Merchant API identifies a product using a combination of:

• Content language
• Feed label
• Offer ID

The resulting identifier follows a structure similar to:

en~US~sku12345

Google’s Merchant API product-management documentation explains that language, feed label and offer ID form the product identity.

This distinction matters when correcting language.

Changing an existing product from en to de is not necessarily a simple textual update to the same Google product identity. It may create or address a different language-and-label combination.

An integration should therefore know:

• Which source owns the existing product
• Which content language was used
• Which feed label was used
• Which offer ID was used
• Whether a replacement or a new language-specific product is intended
• Whether the obsolete language version should be removed

Do not repeatedly resend a product under different language combinations without controlling the resulting product records.

How Merchant API data sources handle language

Merchant API supports different data-source strategies.

A primary API data source can be created without restricting it to one feed label and content language. Such a source can accept multiple language-and-label combinations.

Alternatively, a source can be restricted to a specific content language and feed label when separate rules or configurations are required.

Google’s current API data-source guidance describes both models.

A flexible data source does not remove the merchant’s responsibility to submit the correct language for each product.

It only changes how the data source accepts product combinations.

Google’s data-source migration documentation also explains that Merchant API can use:

• A single source accepting multiple labels and languages
• Separate sources for each language-and-label combination
• Compatible legacy sources during a controlled migration

Choose a strategy based on catalogue management, target markets and the need for language-specific rules.

Do not create unnecessary duplicate sources for the same products.

How to diagnose an incorrect language issue

1. Open the affected product

In Merchant Center, open the product issue or affected item.

The exact menu wording can vary, but language-related problems normally appear within product status, diagnostics or needs-attention information.

Record:

• Product title
• Offer ID
• Product status
• Affected countries
• Affected destinations
• Issue name
• Data source
• Last update time
• Submitted language
• Submitted link

Do not diagnose the problem from a screenshot of the issue name alone.

The affected product details show which offer and source must be corrected.

2. Identify the authoritative product source

Determine which system currently controls the product.

Possible sources include:

• PW Merchant API
• Another Merchant API integration
• XML data source
• Scheduled file
• CSV upload
• Google Sheets
• WooCommerce Google extension
• ERP platform
• Supplier integration
• Automated website product data
• Manual product entry
• Supplemental source

A manual correction in Merchant Center may be overwritten when the authoritative source updates the product again.

Correct the origin of the wrong language.

3. Record the language and feed label

Inspect the product or source configuration and record:

• Content language
• Feed label
• Target country
• Source name
• Offer ID

Do not confuse the feed label with the customer-facing language.

A feed label such as US, GB, DE or a custom value helps organise targeting. It does not translate the product.

4. Inspect the submitted title and description

Compare the submitted title and description with the intended language.

Look for:

• Entirely wrong-language content
• Partially translated sentences
• Supplier text in another language
• Automatically translated brand names
• Untranslated product specifications
• Mixed-language promotional wording
• HTML fragments from an old description
• Shortcodes that expose another language
• Broken character encoding
• Machine-translated text that changes meaning

Brand names and internationally recognised technical values do not always need translation.

The objective is not to translate every proper noun. It is to ensure the product information is understandable and correctly assigned to its declared language.

5. Open the exact submitted URL

Copy the product link from the submitted data.

Open it:

• While logged out of WordPress
• In a private browsing window
• Without previously selected language cookies
• On a desktop viewport
• On a mobile viewport
• From the intended target location where possible
• With and without common tracking parameters

Do not open the product through the WordPress preview button.

The preview may use administrator cookies, unpublished translations or permissions that Google does not have.

6. Check the initial page response

Review the language shown when the page first loads.

Google warns merchants not to rely on product information that changes after initial loading. A crawler may process what appears in the first response or initial rendered state.

Check whether:

• The page initially loads in one language and switches later
• JavaScript replaces translated content after a delay
• A currency or language selector appears only after interaction
• Cached HTML contains another language
• The selected variation changes after scripts load
• A consent tool blocks or replaces important product information
• A translation service requires browser-side rendering

The correct language should be available reliably without requiring an undocumented customer action.

7. Inspect every customer-facing product element

Check:

• Product name
• Short description
• Long description
• Category breadcrumbs
• Attribute labels
• Attribute values
• Variation names
• Stock status
• Backorder message
• Pre-order message
• Product condition
• Quantity label
• Add to cart button
• Buy now button
• Delivery information
• Tax information
• Subscription information
• Required product options
• Error notices
• Review headings
• Product tabs
• Accessibility labels required for navigation

A title and description can be translated while the variation interface remains unusable.

8. Test every relevant variation

Variable products require special attention.

A parent product may appear in English while individual variation data remains in another language.

Test:

• Every colour
• Every size
• Every material
• Every pattern
• Every configuration
• Every variation-specific description
• Variation availability
• Variation price
• Variation image
• Variation URL
• Variation-specific purchase controls

If variations are submitted as separate offers, each submitted variation must link to an appropriate page state in the correct language.

Google recommends preselecting the corresponding variation on the landing page where possible.

9. Add the product to the cart

Do not stop at the product page.

Add the affected product to the shopping cart and inspect:

• Product name
• Variation description
• Quantity controls
• Coupon text
• Remove-product link
• Cart totals
• Shipping calculator
• Tax notices
• Empty-cart message
• Error messages
• Continue-shopping link
• Proceed-to-checkout button

A language switch between the product page and cart is a common source of inconsistency.

10. Complete the checkout journey

Continue until the final order-submission stage without placing an unnecessary live order.

Review:

• Checkout heading
• Billing fields
• Shipping fields
• Country and region selectors
• Required-field messages
• Invalid-address messages
• Shipping methods
• Delivery estimates
• Payment methods
• Payment instructions
• Order summary
• Tax information
• Consent checkboxes
• Terms link
• Privacy notice
• Place order button

Google’s concern is whether customers can understand and complete the purchase.

An untranslated optional footer element is less significant than an untranslated mandatory address field or payment instruction.

11. Review customer-policy pages

Open all pages a customer may need before purchase:

• Shipping policy
• Refund and return policy
• Terms and conditions
• Privacy policy
• Payment information
• Contact page
• About page
• Warranty information
• Cancellation policy

These pages should be accessible in the intended language and should describe the same business and commercial conditions shown elsewhere.

Do not link an English checkout to a mandatory return policy available only in another language.

WooCommerce causes of language inconsistency

Incomplete product translations

A translated product can be missing:

• Long description
• Short description
• Categories
• Tags
• Attributes
• Variation values
• Custom fields
• SEO title
• Meta description
• Shipping-class name
• Product add-on text
• Brand information

Review the actual product object used by the product-data integration.

A visually translated page does not prove that the integration reads the translated product record.

Untranslated global attributes

WooCommerce global attributes may be created once and reused across many products.

Examples include:

• Colour
• Size
• Material
• Pattern
• Age
• Capacity
• Length
• Compatibility

The attribute heading may be translated while its terms remain in the original language.

Review both:

• Attribute taxonomy name
• Individual attribute terms

For example, translating “Colour” but leaving “Kırmızı, Mavi, Siyah” on an English product page still creates mixed-language product data.

Variation inheritance problems

Multilingual plugins may connect translated parent products but fail to synchronise every variation correctly.

Possible symptoms include:

• Translated parent title with original variation titles
• Missing variation in one language
• Wrong-language default variation
• Shared SKU mapped to an unintended product
• Original-language variation description
• Incorrect translated permalink
• Different stock status between translations

Test the exact offer submitted to Google, not only the WooCommerce parent product.

Theme text that bypasses translations

Themes can contain hard-coded text such as:

• Add to cart
• Select options
• In stock
• Out of stock
• Product details
• Delivery information
• Related products
• Previous and next product
• Secure checkout

If these phrases are written directly into template files without translation functions, changing WordPress or the page language may not translate them.

Review custom templates and child-theme overrides.

Plugin-generated interface text

Language can also come from:

• Product-add-on plugins
• Booking plugins
• Subscription plugins
• Size-guide plugins
• Delivery-estimate plugins
• Payment gateways
• Shipping integrations
• Cookie tools
• Age-verification tools
• Address-validation services
• Currency switchers
• Checkout-field editors

Each plugin may use its own translation files or configuration.

Test the complete page after all active extensions load.

Untranslated WooCommerce system pages

WooCommerce assigns pages for:

• Cart
• Checkout
• My account
• Terms and conditions
• Shop

A multilingual configuration may require a corresponding page in each language.

Common errors include:

• English product links to Turkish cart
• French cart links to English checkout
• German checkout opens an untranslated terms page
• Language switcher returns users to the default-language shop
• Endpoint content uses the default language

Confirm that every language version has correctly connected system pages.

Automatic browser-language detection

Some multilingual tools redirect visitors based on:

• Browser language
• IP address
• Country
• Cookie history
• Logged-in preference
• Device
• Referrer

This can produce unstable landing pages.

Google may receive an English URL but be redirected to another language because the crawler’s location or headers differ from those used during merchant testing.

Use explicit, stable language URLs when possible.

Examples include:

• example.com/en/product/example-product/
• example.com/de/produkt/beispielprodukt/
• en.example.com/product/example-product/
• de.example.com/produkt/beispielprodukt/

Do not rely solely on a language cookie when the submitted URL itself does not identify the intended version.

Cache contamination

Multilingual stores require careful caching.

A cache that does not vary by language may serve:

• English HTML at a German URL
• German buttons within an English product page
• Default-language cart fragments
• Wrong-language navigation
• Wrong-language structured data
• Translated content from a previous visitor session

Review:

• WordPress page cache
• Object cache
• Server cache
• Reverse proxy
• CDN cache
• Edge cache
• Browser cache
• WooCommerce cart fragments
• Translation-plugin cache

After correcting translations:

• Clear WordPress caches.
• Clear server caches.
• Clear CDN caches.
• Purge affected product URLs.
• Test while logged out.
• Test a new browser session.
• Reopen the page using the submitted URL.

Geolocation and language are different

A customer’s location does not always determine the language they prefer.

Automatically showing German to every visitor in Germany or French to every visitor in France can conflict with the language of the submitted product offer.

Geolocation may be used for legitimate currency, tax, availability or shipping purposes, but it should not unexpectedly replace the language represented by the product data.

If multiple languages target the same country, create controlled product experiences for each supported language rather than forcing one version based only on IP location.

Language and currency are separate

An inconsistent-language issue and an inconsistent-currency issue can occur at the same time, but they require separate checks.

A valid combination might be:

• English language
• EUR currency
• Germany as the target country

Another valid combination might be:

• German language
• EUR currency
• Germany as the target country

The currency does not determine the language.

Do not change the product language merely because the store uses a particular currency.

Similarly, translating the page does not correct an incorrect currency.

Single-language WooCommerce setup

A store using one language should maintain one clear source of truth.

Review:

• WordPress front-end language
• WooCommerce system-page language
• Product catalogue language
• Product-data language
• Merchant Center source language
• Policy-page language
• Checkout language

Remove obsolete multilingual settings and old translated URLs if they are no longer used.

A one-language store can still produce inconsistent data when supplier descriptions, imported attributes or payment instructions use another language.

Multiple languages in one country

Some countries support several relevant languages.

A multilingual WooCommerce store may submit separate offers for each language.

For each language version, maintain:

• Correct translated product data
• Language-specific landing-page URL
• Correct cart route
• Correct checkout route
• Translated policies
• Stable content language
• Controlled product identity
• Appropriate targeting

Do not send two language versions to the same default-language URL.

The English product data should link to the English page. The French product data should link to the French page.

One language targeting multiple countries

A store may use one language across several target countries.

For example, English product data may target multiple supported countries.

The language may remain consistent while other settings differ, including:

• Currency
• Shipping
• Tax
• Availability
• Return policy
• Legal disclosures

Language consistency does not remove the need to configure these country-specific commercial conditions accurately.

Multiple languages and multiple countries

A complex international store should document its combinations before submission.

A useful internal table can contain:

Content language	Feed label	Target country	Currency	Landing-page pattern	Checkout language
English	GB	United Kingdom	GBP	/en-gb/	English
English	US	United States	USD	/en-us/	English
German	DE	Germany	EUR	/de/	German
French	FR	France	EUR	/fr/	French

These are illustrations.

Use only combinations supported by the store and Google’s current requirements.

Each combination should be tested independently.

Do not translate technical identifiers unnecessarily

Some values should remain stable across languages.

Examples can include:

• SKU
• Offer ID
• GTIN
• MPN
• Brand
• Merchant product identifiers
• Internal source names
• Technical feed labels
• API resource names

A brand such as “PW Merchant API” should not be translated into unrelated wording.

Likewise, changing the offer ID for every textual correction can create duplicate products or break update continuity.

Translate customer-facing commercial information while preserving stable identifiers according to the integration’s product-identity rules.

Product titles and descriptions

Product titles and descriptions should be written naturally in the intended language.

Avoid:

• Combining several language versions in one title
• Appending machine translations to the same description
• Filling untranslated sections with keyword lists
• Translating brand names inaccurately
• Mixing supplier and retailer terminology
• Copying original-language HTML into translated products
• Using language-specific promotional claims that do not appear on the landing page

A title such as:

Men’s Blue Running Shoes – Herren Laufschuhe Blau

does not create two controlled language offers.

It creates one mixed-language title.

Prepare separate English and German product versions when both languages are required.

Categories and product types

Google product category values follow Google’s supported category system and technical requirements.

The merchant’s own product_type values can reflect the store’s categorisation and may be localised for the intended product-data language.

Do not assume that translating the visible WooCommerce category automatically updates the submitted product_type.

Inspect the final value received by Merchant Center.

Colour, size and material values

Variant values are especially visible in Shopping results and landing-page comparisons.

Review:

• color
• size
• material
• pattern
• size_type
• size_system

Use values understandable in the intended language and compliant with Google’s attribute requirements.

Do not submit Blue while the linked variation opens as Mavi unless the complete offer is intentionally handled under Google’s currently permitted language differences and the experience remains understandable.

For the most reliable setup, use matching language values.

Structured data

WooCommerce, themes and SEO plugins may generate product structured data.

Review the rendered markup for:

• Product name
• Description
• Variant information
• Price
• Availability
• URL
• Brand
• SKU

Structured data should match the visible product version.

A German page should not contain an English product name from a cached or default-language schema source when that difference misrepresents the actual page.

Check for duplicate product schema created by:

• WooCommerce
• The active theme
• SEO plugin
• Schema plugin
• Custom PHP
• JavaScript
• Tag Manager

Structured data can help Google understand the page, but it does not replace correct product data, visible content or checkout language.

Competing product sources

A corrected language can be overwritten by another source.

Review:

• PW Merchant API
• Other Merchant API integrations
• Legacy Content API sources
• XML sources
• CSV files
• Google Sheets
• Scheduled imports
• Supplier feeds
• ERP systems
• Automated website data
• Supplemental sources
• Manual Merchant Center changes

For each source, identify whether it controls:

• Content language
• Title
• Description
• Link
• Mobile link
• Product type
• Variant attributes
• Custom labels

Remove or disable obsolete sources only after confirming that they are no longer required and that the authoritative source contains the complete product catalogue.

How PW Merchant API fits into language management

PW Merchant API is designed to support controlled product communication between WooCommerce and Google Merchant Center.

Depending on the installed version and supported mappings, it can help users:

• Read supported WooCommerce product information.
• Prepare supported Merchant product attributes.
• Submit new products through Merchant API.
• Update existing products.
• Manage simple and variable product operations.
• Run controlled scheduled processes.
• Review successful and unsuccessful operations.
• Identify products requiring attention.
• Maintain a more structured product-management workflow.

As a WooCommerce Google Merchant Center plugin, PW Merchant API can communicate the supported product values selected from WooCommerce.

However, it cannot create accurate translations that do not exist.

PW Merchant API cannot:

• Translate the entire WooCommerce store automatically.
• Determine the intended commercial language without configuration.
• Repair incomplete multilingual product relationships automatically.
• Translate theme template text.
• Translate third-party checkout extensions.
• Guarantee that payment-gateway instructions are localised.
• Prevent a CDN from serving the wrong cached language.
• Decide which countries the business should target.
• Guarantee Google approval.
• Guarantee that products will appear.
• Guarantee rankings, impressions, clicks or sales.
• Override another source without an applicable product operation.
• Replace the merchant’s responsibility to test the complete purchase journey.

WooCommerce remains the commercial source of product information, PW Merchant API supports the applicable communication process, and Google Merchant Center independently processes and evaluates the submitted data.

A controlled correction workflow

Step 1: Choose the intended language

Decide which language the affected product should genuinely use.

Base the decision on:

• Available product translations
• Customer support capability
• Checkout language
• Policy-page language
• Target market
• Supported shipping locations
• Legal information
• Payment instructions

Do not choose a language that exists only in the product title.

The complete customer journey must support it.

Step 2: Complete the WooCommerce translation

Update:

• Product title
• Short description
• Long description
• Categories
• Attributes
• Attribute terms
• Variations
• Product add-ons
• Stock messages
• Delivery notices
• Custom fields
• SEO fields
• Product URL
• Structured data source

Save the product and test the public page.

Step 3: Complete the purchase-path translation

Update:

• Cart
• Checkout
• Account registration
• Form fields
• Validation messages
• Shipping methods
• Payment methods
• Terms and conditions
• Return policy
• Shipping policy
• Privacy information
• Contact page
• Business-information pages

Do not submit the language version until customers can understand the required purchasing steps.

Step 4: stabilise the landing-page URL

Ensure that the submitted URL:

• Opens the intended language directly
• Does not depend exclusively on cookies
• Does not redirect unexpectedly by IP
• Works while logged out
• Works on mobile
• Selects the correct variation
• Uses the claimed Merchant Center domain
• Returns a successful response
• Remains accessible to Google

Test the URL several times in clean sessions.

Step 5: verify the Merchant data-source strategy

Confirm whether the store uses:

• One unrestricted API data source
• Separate sources for each language and label
• A file-based source
• A legacy source
• Multiple competing sources

Check that the intended source accepts the language-and-label combination.

Step 6: submit the correct content language

Send the product using the intended:

• Content language
• Feed label
• Offer ID
• Landing-page URL
• Product values

Do not submit German product content using English as the content language merely because English is the store’s default administration language.

Step 7: handle obsolete products

If the previous product used the wrong language identity, determine whether it should be:

• Updated
• Replaced
• Removed
• Preserved as a separate valid language version

Avoid leaving an obsolete English offer and a corrected German offer active when both link to the same German page unintentionally.

Step 8: inspect the processed product

After submission, allow Merchant Center to process the update.

Then inspect:

• Processed title
• Processed description
• Content language
• Feed label
• Landing-page link
• Product status
• Remaining issues
• Update timestamp

A successful API operation means that Google accepted the request technically. It does not prove that the resulting product is policy-compliant.

Step 9: test again as a customer

Open the processed product link from Merchant Center and repeat the customer journey.

Verify that the exact version Google holds leads to:

• Correct product
• Correct language
• Correct variation
• Correct cart
• Correct checkout
• Correct policies

Step 10: monitor the result

Allow Google time to crawl and process the corrected website and product data.

Review:

• Product status
• Needs-attention information
• Issue count
• Affected countries
• Affected destinations
• Last crawl or update information where available

Do not repeatedly change correct language settings merely because processing is not immediate.

Common mistakes

Changing only the WordPress site language

This may translate core interface text but does not repair product descriptions, variations, policies or submitted product data.

Changing only the Merchant Center language

This can make the declaration match neither the submitted content nor the website.

Translating only the product title

The description, variation values, checkout and policy pages may remain inconsistent.

Using one URL for every language

The page may open according to cookies or browser settings, producing an unstable result.

Using automatic IP redirects

Google and customers may receive a different language from the one represented by the product data.

Ignoring variation values

Colour and size values can remain untranslated even when the parent product is correct.

Ignoring checkout validation messages

Customers may be unable to understand why a required field or payment step failed.

Using one mixed-language description

Combining several translations in one field is not a controlled multilingual strategy.

Assuming the target country defines the language

Many countries support more than one language, and one language can target several countries.

Confusing currency with language

EUR does not automatically mean German or French. USD does not automatically mean English.

Creating duplicate sources unnecessarily

Several sources can overwrite one another or create duplicate product identities.

Changing offer IDs during every correction

Unnecessary identifier changes can create duplicates and break product continuity.

Correcting Merchant Center manually

The next API or file update may restore the wrong language.

Forgetting caches

A corrected WordPress page may continue to serve old-language HTML through server or CDN caches.

Testing while logged in

Administrator cookies and translation preferences may hide what Google and new customers receive.

Assuming a successful API response means the issue is fixed

Google still needs to process the product and evaluate the associated customer experience.

Frequently asked questions

What does incorrect language mean in Google Merchant Center?

It means the language assigned to the product data does not adequately match the submitted product information, landing page or customer purchase journey.

Must every word on the website use the product-data language?

Google’s current policy permits some differences in product information when most data matches the declared language. However, the elements required to navigate, understand the offer and complete the purchase must remain usable in the product-data language.

Can a product be disapproved for mixed-language data?

Yes. Google states that products may be disapproved when most product data does not match the selected data-source language. Other differences may limit performance.

Did Google relax its inconsistent-language policy?

Yes. Google announced a relaxation in December 2024, but this does not remove the requirement for a coherent customer and checkout experience.

Is the WordPress Site Language setting enough?

No. It does not prove that products, variations, theme text, cart, checkout, payment instructions and policies use the same language.

Can I target one country in two languages?

Yes, where those languages and the country are supported. Prepare separate product data and matching landing pages for each language.

Can one language target several countries?

Yes, where supported. Country-specific currency, shipping, tax and legal requirements must still be configured accurately.

Does the feed label set the language?

No. Feed label and content language are separate product-data concepts.

Does Merchant API include language in the product ID?

Yes. Merchant API identifies products using the combination of content language, feed label and offer ID.

Can changing content language create another product identity?

Yes. Because language forms part of the product identity, changing it can address a different language-and-label combination.

Should I translate the offer ID or SKU?

Normally, no. These are stable technical identifiers. Translate customer-facing product information unless the integration has a specific documented identifier strategy requiring otherwise.

Should brand names be translated?

Normally, established brand names should remain accurate and unchanged. Do not transform a brand into unrelated localised wording.

Do WooCommerce attributes need translation?

Customer-facing attribute names and values should be understandable in the intended language. Review global attribute taxonomies and variation terms.

Do cart and checkout pages need the same language?

Yes. Google identifies cart, checkout and related decision-making pages as important parts of language consistency.

Do policy pages need translation?

Relevant customer policies should be available and understandable in the intended purchasing language, particularly when linked during checkout.

Can I use automatic browser translation?

Browser translation is not a substitute for a controlled product-data and website-language configuration. Google and customers should receive a stable intended language version.

Can I use IP-based language redirection?

Use caution. It can cause Google to receive a different page from the submitted language version. Explicit and stable language URLs are generally easier to control.

Why does the page look correct to me but wrong to Google?

Your account, cookies, browser language, IP location or cache may produce a different version. Test the submitted URL while logged out and in a clean browser session.

Can a cache cause inconsistent language?

Yes. A cache that does not vary correctly by language can serve the wrong HTML, navigation, schema, cart fragments or checkout text.

Does structured data need to match the visible language?

Structured product information should describe the visible product accurately. Review duplicate or default-language schema sources.

Can PW Merchant API translate products automatically?

No. It can communicate supported WooCommerce product information, but accurate translations and a consistent customer journey must exist in the store.

Can PW Merchant API guarantee that Google removes the issue?

No. Google independently crawls, processes and evaluates the submitted information.

Should I request a review immediately?

First correct the authoritative product source and complete customer journey. Allow Google to process the changes and follow the review option shown for the specific issue, if one is provided.

How long does correction processing take?

Processing time varies. Avoid guaranteeing a fixed period. Monitor the product status and update information in Merchant Center.

What should I do with the old wrong-language product?

Determine whether it should be updated, removed or retained as a separate valid language version. Do not leave obsolete duplicate offers active without a purpose.

Can English product data use EUR?

Yes, where the language, currency and target-country combination is supported and the landing page and checkout display the correct information.

Final checklist

Before considering the inconsistent-language correction complete, confirm that:

• The intended product language was defined.
• The target countries were reviewed.
• The language is supported for the selected countries.
• The currency was reviewed separately.
• The affected Merchant Center product was opened.
• The issue details were recorded.
• The offer ID was recorded.
• The content language was recorded.
• The feed label was recorded.
• The authoritative data source was identified.
• The submitted title uses the intended language.
• The submitted description uses the intended language.
• Supplier content was reviewed.
• Imported content was reviewed.
• Mixed-language promotional text was removed.
• Product-type values were reviewed.
• Colour values were reviewed.
• Size values were reviewed.
• Material values were reviewed.
• Pattern values were reviewed.
• Brand values remain accurate.
• SKU values remain stable.
• Offer IDs remain controlled.
• GTIN values were not translated.
• MPN values were not translated.
• The exact submitted URL was opened.
• The page works while logged out.
• The page works without a language cookie.
• The page works on mobile.
• The page uses HTTPS.
• The page returns a successful response.
• The page remains on the claimed domain.
• The page opens in the intended language.
• The initial HTML was reviewed.
• Delayed JavaScript language changes were reviewed.
• IP-based redirects were reviewed.
• Browser-language redirects were reviewed.
• Country redirects were reviewed.
• Cookie-based language selection was reviewed.
• Product headings were reviewed.
• Short descriptions were reviewed.
• Long descriptions were reviewed.
• Breadcrumbs were reviewed.
• Product categories were reviewed.
• Product tabs were reviewed.
• Global WooCommerce attributes were reviewed.
• Attribute terms were reviewed.
• Variation names were reviewed.
• Variation descriptions were reviewed.
• Every submitted variation was tested.
• The submitted variation opens correctly.
• The correct variation is preselected where appropriate.
• Availability messages were reviewed.
• Backorder messages were reviewed.
• Pre-order messages were reviewed.
• Condition information was reviewed.
• Price information was reviewed.
• Delivery information was reviewed.
• Product restrictions were reviewed.
• Add to cart text was reviewed.
• Required product options were reviewed.
• Error notices were reviewed.
• Theme-generated text was reviewed.
• Plugin-generated text was reviewed.
• Product-add-on text was reviewed.
• The mini cart was reviewed.
• The shopping cart was reviewed.
• Product names in the cart were reviewed.
• Variation values in the cart were reviewed.
• Coupon information was reviewed.
• Shipping-calculator text was reviewed.
• The checkout page was reviewed.
• Billing fields were reviewed.
• Shipping fields were reviewed.
• Country selectors were reviewed.
• Region selectors were reviewed.
• Required-field messages were reviewed.
• Address-validation messages were reviewed.
• Shipping-method names were reviewed.
• Delivery estimates were reviewed.
• Payment-method names were reviewed.
• Payment instructions were reviewed.
• Mandatory consent text was reviewed.
• The Place order button was reviewed.
• The terms and conditions were reviewed.
• The refund and return policy was reviewed.
• The shipping policy was reviewed.
• The privacy information was reviewed.
• The contact page was reviewed.
• The About page was reviewed.
• Business information was reviewed.
• Warranty information was reviewed where applicable.
• Cancellation information was reviewed where applicable.
• WooCommerce system pages are connected correctly.
• Language-specific cart pages are configured.
• Language-specific checkout pages are configured.
• Language-specific account pages are configured.
• Translated policy pages are connected.
• Multilingual-plugin relationships were reviewed.
• Translated parent products were reviewed.
• Translated variations were reviewed.
• Translation-plugin caches were cleared.
• WordPress page caches were cleared.
• Object caches were cleared.
• Server caches were cleared.
• CDN caches were cleared.
• A new browser session was tested.
• Structured product data was inspected.
• Product names in structured data match.
• Descriptions in structured data match.
• Variant information in structured data matches.
• Duplicate product schema was removed.
• PW Merchant API values were reviewed.
• Other Merchant API sources were reviewed.
• Legacy Content API sources were reviewed.
• XML sources were reviewed.
• CSV sources were reviewed.
• Google Sheets sources were reviewed.
• ERP sources were reviewed.
• Supplier sources were reviewed.
• Automated website product data was reviewed.
• Supplemental sources were reviewed.
• Manual Merchant Center changes were reviewed.
• Obsolete sources were removed where appropriate.
• The Merchant API data-source strategy was documented.
• Unrestricted language-and-label sources were reviewed.
• Restricted language sources were reviewed.
• Every valid language has matching product data.
• Every valid language has a matching landing page.
• Every valid language has a matching checkout.
• Obsolete language versions were removed.
• Duplicate offers were reviewed.
• Corrected products were submitted through the authoritative source.
• The API operation result was recorded.
• The processed product was inspected.
• The processed content language is correct.
• The processed feed label is correct.
• The processed landing-page link is correct.
• The customer journey was retested after submission.
• Merchant Center was allowed to process the correction.
• Product status was monitored.
• Remaining issues were reviewed.
• Future translations will be updated across every source.

An inconsistent-language issue is not solved by changing one setting or translating one product title.

The submitted language, product attributes, WooCommerce landing page, variation selection, cart, checkout and required customer policies should form one understandable purchasing journey.

Multilingual stores should prepare controlled product data and stable landing-page URLs for every supported language. Single-language stores should still inspect imported supplier content, global attributes, extension-generated text and policy pages for unexpected language differences.

Merchant API treats content language as part of product identity. Language corrections must therefore be managed carefully so that obsolete combinations, duplicate offers and competing data sources do not remain active unintentionally.

WooCommerce remains the customer-facing commercial source, PW Merchant API supports applicable product communication, and Google Merchant Center independently processes and evaluates the submitted information.

When the declared content language accurately represents the product data and the complete purchase path, Google can understand the offer more reliably and customers can make purchasing decisions without unexpected language changes.