WooCommerce Feed Labels, Target Countries and Languages in Google Merchant Center

WooCommerce feed labels, target countries and languages in Google Merchant Center

WooCommerce merchants selling internationally must manage three different Merchant Center concepts correctly:

• Feed label
• Content language
• Target country

These values are related, but they do not mean the same thing.

A feed label categorises product data and can be used to select product sources for supported advertising campaigns.

The content language identifies the language used in the submitted product information.

A target country identifies a country in which the product is intended to become eligible.

One value cannot automatically replace another.

A feed label named US does not, by itself, target the United States.

An English content language does not mean that the product can automatically be shown in every English-speaking country.

Adding a target country does not prove that the WooCommerce store can deliver there, display an appropriate currency or complete checkout in the submitted language.

The complete product journey must remain consistent.

This includes:

• WooCommerce product information
• Product URL
• Product language
• Price and currency
• Shipping availability
• Return information
• Checkout language
• Merchant data source
• Feed label
• Target-country configuration
• Merchant API product identity

Incorrect combinations can create duplicate products, data-source mismatch errors, inconsistent-language issues, unexpected campaign targeting or products that remain ineligible for the intended market.

The short answer

To manage WooCommerce feed labels, target countries and languages correctly:

1. Identify every country in which the store genuinely sells and delivers.
2. Identify the language customers use on each country-specific product page.
3. Confirm the currency shown on the landing page and throughout checkout.
4. Decide whether one product data source can support the required markets.
5. Create a feed-label strategy based on operational or campaign requirements.
6. Do not assume that the feed label controls country targeting.
7. Configure the actual target countries on the product data source.
8. Configure accurate shipping for every targeted country.
9. Submit the correct content language for each product.
10. Keep the language consistent across product data, landing pages, policies and checkout.
11. Maintain a stable WooCommerce offer ID for the same product identity.
12. Record the data source used for each submitted product.
13. Check the processed product in Merchant Center.
14. Review country-specific and marketing-method-specific issues.
15. Prevent another integration or data source from restoring an old combination.

A technically accepted Merchant API request does not confirm that a product is eligible in every intended country.

The processed Merchant product, target-country status and complete WooCommerce purchasing journey must also be reviewed.

Feed label, content language and target country are different

The following comparison explains the role of each value:

Value	What it identifies	What it does not prove
Feed label	A product-data grouping used for organisation and supported campaign selection	It does not automatically target a country
Content language	The language of submitted product information	It does not prove that the complete website uses that language
Target country	A country in which the product data is intended to be used	It does not prove that shipping, currency, policies or checkout support that country
Offer ID	The merchant’s stable identifier for a specific offer	It does not identify the language or feed label by itself
Data source	The source supplying product information to Merchant Center	It does not guarantee that every submitted product matches its configuration
Shipping country	A country to which the product can be delivered under the submitted shipping information	It does not replace the data source’s complete country and marketing configuration

These values should be planned together, but they should remain conceptually separate.

A common mistake is to use a two-letter country code as the feed label and then assume the products target that country.

For example:

Feed label: US

This is only a label unless the target-country and shipping configurations also support the United States.

Google’s current Merchant API data-source guidance explicitly states that a data source label has no effect on the targeted country. Targeting is controlled through the countries configured for the primary product data source and applicable shipping information.

What is a feed label?

A feed label is a value used to categorise and identify product data.

Feed labels can help merchants separate products according to:

• Market
• Language
• Currency
• Business division
• Catalogue group
• Campaign structure
• Regional availability
• Product category
• Operational source
• Storefront

Possible examples include:

TR
GB
EU
EN-GB
DE-DE
RETAIL
OUTLET
WHOLESALE
SUMMER

The value should have a clear purpose that the merchant can document and maintain.

A feed label is not customer-facing product content. Customers normally do not see it on the WooCommerce product page.

Google’s feed-label documentation explains that products sharing a feed label can be selected for supported Shopping, Demand Gen or Performance Max campaign structures.

The campaign use of feed labels does not turn the label into a geographical setting.

A merchant can use GB as a convenient feed label for products managed for the United Kingdom, but actual country targeting still requires the relevant country configuration.

Feed label format requirements

For Merchant API product inputs, the feed label is part of the product identity.

Google’s current ProductInput reference states that the feed label:

• Is required for a product input
• Is immutable for that product input
• Can contain up to 20 supported characters
• Can use uppercase letters
• Can use numbers
• Can use hyphens
• Can use underscores
• Must not contain spaces

Examples of structurally suitable labels include:

TR
GB
EN-GB
EU_2026
OUTLET

Examples that should not be used include:

United Kingdom
english store
uk products
Türkiye Mağazası

A technically valid label can still be operationally confusing.

For example:

USA

may be valid as a label, but it remains only a label. It should not be treated as proof that the data source targets the United States or that the store can deliver there.

Choose a naming convention that remains understandable when viewed months later by another administrator.

What is content language?

Content language describes the language used in the submitted product information.

For Merchant API product inputs, it is represented through the contentLanguage field.

Examples include:

en
tr
de
fr
it
es

The value uses a supported two-letter language code.

The content language should describe the actual language of:

• Product title
• Product description
• Product type
• Product highlights
• Colour values where language-dependent
• Size terminology where applicable
• Material descriptions
• Condition disclosures
• Bundle descriptions
• Included accessory information
• Other customer-facing product attributes

It should also match the language customers encounter after opening the submitted product URL.

Declaring:

"contentLanguage": "en"

does not translate a Turkish WooCommerce product page into English.

It only declares that the submitted product content is English.

If the product title is English but the description, cart, checkout, policies and payment instructions remain Turkish, the complete purchasing journey can still be inconsistent.

Google’s official inconsistent-language guidance instructs merchants to use a supported language consistently across product data and the website, including checkout and important policy information.

The website language must match the submitted language

For an English Merchant product, review:

• Product title
• Short description
• Long description
• Variation names
• Attribute labels
• Stock messages
• Add-to-cart button
• Basket
• Checkout
• Payment instructions
• Shipping information
• Return policy
• Terms and conditions
• Privacy information
• Error messages
• Required-field validation
• Order confirmation process

A single untranslated phrase does not necessarily describe the complete page, but large or important sections in another language can create a poor and inconsistent experience.

Browser language, customer IP address or saved cookies should not unexpectedly redirect Google or the customer to a different language.

Automatic language redirection can cause the submitted URL to expose different content depending on who opens it.

A stable language-specific URL is generally easier to verify.

Examples can include:

https://example.com/en/product/product-name/
https://example.com/de/produkt/produktname/
https://example.com/tr/urun/urun-adi/

The actual URL architecture depends on the WooCommerce multilingual system, but each submitted URL should reliably expose the intended language.

What is a target country?

A target country is a country in which a product is intended to become eligible for applicable Google product experiences.

Targeting a country requires more than adding its country code.

The merchant should genuinely support:

• Delivery to that country
• Appropriate shipping costs
• Realistic delivery times
• A supported language
• A supported currency or an applicable currency-conversion arrangement
• Checkout access
• Payment methods available to customers
• Returns from that country
• Required business and policy information
• Applicable legal and tax responsibilities

Google’s multi-country product guidance explains that products can target combinations of countries within a data source. Countries can be added through data-source configuration and, where applicable, product shipping information.

This does not mean that every WooCommerce store should target every available country.

Only select countries that the store can serve accurately and consistently.

Feed label does not equal target country

This is the most important distinction in the workflow.

Consider the following configuration:

Feed label: EU
Content language: en
Target countries: Germany, France, Netherlands

The label EU is an organisational choice.

It does not create those three target countries.

The content language en describes the language of the product data.

It does not prove that English is the best or supported customer experience for every selected country and marketing method.

The countries configuration defines the intended countries.

Shipping settings then help establish whether the product can actually be delivered to those countries.

All three layers need separate verification.

Another example is:

Feed label: GB
Content language: en
Target country: Ireland

This can be technically possible as a naming arrangement because the feed label is not inherently the target country.

However, it is operationally confusing.

An administrator may later assume that the products target the United Kingdom.

Campaigns may also use the label in ways the merchant did not intend.

Labels should therefore be meaningful without being mistaken for actual eligibility settings.

One language can support more than one country

A WooCommerce store may use one language for several countries.

For example, an English product-data source may be prepared for supported English-language markets.

The merchant still needs to verify every market separately.

Check:

• Whether the language is supported for each target country
• Whether the submitted currency is supported
• Whether the website shows the correct price
• Whether shipping reaches the country
• Whether delivery times are accurate
• Whether returns can be handled
• Whether checkout accepts valid addresses
• Whether taxes are represented properly
• Whether required customer information is available
• Whether products are legally sellable there

The current supported languages and currencies reference should be checked before expanding into a new market because supported combinations and country requirements can change.

Do not assume that a shared language produces identical commercial requirements.

The United Kingdom, Ireland, the United States, Canada and Australia may all use English, but they can require different currencies, shipping services, delivery times, tax handling and policy information.

One country can use more than one language

A store may also serve one country through multiple languages.

For example, a country-specific catalogue may have:

• English product pages
• French product pages
• German product pages
• Another supported local-language version

Each submitted product should lead to the corresponding language version.

A multilingual WooCommerce product may therefore create more than one Merchant product identity.

For example:

en~CA~SKU-100
fr~CA~SKU-100

These are not the same Merchant product identity, even though they can originate from the same physical WooCommerce product and share the same internal SKU.

The language component is different.

Each version should maintain its own:

• Product title
• Description
• URL
• Image where localised
• Price
• Availability
• Product attributes
• Policy consistency
• Checkout experience
• Processing status

Do not submit two language identities that both lead to the same single-language landing page.

Merchant API product identity

Merchant API identifies products through a combination of:

contentLanguage~feedLabel~offerId

Google’s add and manage products guide provides an example such as:

en~US~sku12345

This means that the following values can identify different Merchant products:

en~US~SKU-100
en~GB~SKU-100
de~DE~SKU-100
tr~TR~SKU-100

The offer ID is the same, but the content language or feed label differs.

This has several operational consequences.

Changing the content language is not the same as editing a product title.

Changing the feed label is not the same as changing a custom category.

Because these values participate in identity, a new combination can create another Merchant product rather than update the existing one.

The previous identity can remain active unless it is properly managed.

Do not create duplicate products accidentally

Suppose a product was originally submitted as:

en~UK~SKU-100

The merchant later decides to use:

en~GB~SKU-100

Submitting the new combination does not necessarily rename the old product.

It can produce a second identity.

The merchant should verify:

• Whether the old product input remains active
• Which data source owns each identity
• Whether both products use the same landing page
• Whether both can enter the same campaign
• Whether product history is affected
• Whether the old identity should be removed
• Whether scheduled synchronisation can restore the old identity

Do not delete a product based only on its WooCommerce SKU.

The complete Merchant identity and owning data source must be confirmed first.

Changing language requires more than changing a code

A merchant should not change:

"contentLanguage": "tr"

to:

"contentLanguage": "en"

while leaving the Turkish title, description, landing page and checkout unchanged.

A real language migration includes:

1. Creating or verifying the translated WooCommerce product.
2. Confirming the translated URL.
3. Translating the title.
4. Translating the short description.
5. Translating the long description.
6. Translating relevant attributes.
7. Translating cart and checkout interfaces.
8. Translating policies and customer instructions.
9. Checking the currency.
10. Checking shipping and returns.
11. Preparing the correct Merchant identity.
12. Submitting through the appropriate data source.
13. Verifying the processed product.
14. Managing the previous identity where necessary.

The language code should describe completed customer-facing content, not an intended future translation.

Changing the feed label requires migration planning

A feed label should not be changed casually after products are active.

Review:

• Existing Merchant product identities
• Existing data sources
• Campaign selection
• Supplemental-source rules
• Country configuration
• Content language
• Product history
• Offer IDs
• Scheduled product updates
• Previous integrations
• Deletion procedures
• Reporting
• Local inventory relationships
• Promotion relationships

Google’s Merchant API migration guidance warns about “offer stealing,” which can occur when a product identified by language, feed label and offer ID is inserted into a different primary data source.

The official guidance recommends identifying the exact owning data source before write operations.

A label migration should therefore be treated as a controlled product-data migration, not a cosmetic text edit.

Merchant API data-source strategies

Merchant API supports more than one valid data-source strategy.

According to Google’s current data-source migration documentation, merchants can use:

• A primary API data source that accepts different feed-label and language combinations
• Separate data sources for specific feed-label and language combinations
• Compatible existing Content API data sources during migration

A flexible API data source can simplify management for integrations that do not require strict separation.

Separate data sources can be useful when the merchant needs:

• Different rules
• Distinct languages
• Regional catalogue control
• Separate campaign structures
• Different operational teams
• Clear market isolation
• A controlled migration from an older system

Neither strategy is automatically correct for every WooCommerce store.

The chosen model should match the store’s actual markets, languages, rules and maintenance capacity.

Restricted and unrestricted API data sources

For applicable API-based primary product data sources, Merchant API can allow the data source to be created without a fixed feed-label and content-language pair.

Such a source can accept products using different combinations.

This can reduce the number of data sources an integration needs to manage.

However, it does not remove the required product-level identity values.

Each product input still has a content language, feed label and offer ID.

A flexible source also does not remove the need to manage:

• Country targeting
• Shipping
• Product-language consistency
• Campaign labels
• Duplicate identities
• Offer ownership
• Product issues

For a data source restricted to a particular feed-label and language combination, submitted products must match that combination.

Otherwise, the operation can fail with a mismatch.

Google’s Merchant API error reference includes errors for invalid content language and mismatches between the data source’s feed label or language and the submitted item.

Common mismatch errors

Relevant Merchant API errors can include:

INVALID_CONTENT_LANGUAGE
INVALID_CONTENT_LANGUAGE_NOT_SUPPORTED
INVALID_DATA_SOURCE_DOES_NOT_MATCH_ITEM
INVALID_DATA_SOURCE_FEED_LABEL_OR_LANGUAGE_MISMATCH_ITEM
INVALID_DATA_SOURCE_MUST_HAVE_API_INPUT_TYPE
INVALID_DATA_SOURCE_NOT_PART_OF_ACCOUNT

The exact message should be recorded before making changes.

Do not respond to every mismatch by creating another data source.

First determine:

• Which Merchant account received the request
• Which data source was supplied
• Whether the data source belongs to that account
• Whether it accepts API product operations
• Which feed label the product uses
• Which content language the product uses
• Whether the source is restricted
• Whether the product already belongs to another source
• Whether the offer ID already exists under another identity
• Whether a previous plugin created the product

Creating additional sources without understanding the existing structure can increase duplication.

WooCommerce multilingual stores

WooCommerce multilingual stores commonly use:

• Separate language URLs
• Translation plugins
• Currency switchers
• Country selectors
• Geolocation
• Translated variations
• Shared or separate SKUs
• Regional price tables
• Country-specific stock
• Multiple warehouses
• Localised tax settings
• Localised shipping zones

The Merchant integration must identify which record is authoritative for each product identity.

Questions to answer include:

• Is each translation a separate WooCommerce product record?
• Do translations share one parent product?
• Do variations have language-specific records?
• Is the SKU shared across languages?
• Does the translated URL remain stable?
• Is the product price converted automatically?
• Is the conversion visible consistently to Google?
• Does the language change based on IP address?
• Does the currency change without changing the URL?
• Does checkout preserve the selected language?
• Are policy pages translated?
• Are structured data values translated?
• Can scheduled imports overwrite translations?

A translation plugin’s existence does not prove that Merchant-ready translated product pages are complete.

Every submitted language version must be reviewed as an independent customer journey.

Currency is separate from content language

Language and currency are related to market preparation, but one does not determine the other.

An English page can display:

• GBP
• USD
• CAD
• AUD
• EUR
• Another supported currency

A German-language page can display EUR or another currency supported for the intended country and configuration.

The currency should match:

• Submitted product price
• Landing-page price
• Structured data
• Cart
• Checkout
• Target-market configuration
• Shipping charges where applicable

Do not assume:

contentLanguage: en

means:

currency: USD

Similarly, a feed label of GB does not automatically convert a WooCommerce price into GBP.

Currency conversion, store pricing and Merchant data are separate responsibilities.

Shipping determines whether the market can be served

Adding a country to a data source is not enough when the store cannot fulfil orders there.

Review WooCommerce shipping zones and Merchant Center shipping settings together.

For every target country, confirm:

• Eligible products
• Shipping service
• Shipping cost
• Handling time
• Transit time
• Delivery regions
• Postal-code limitations
• Free-shipping thresholds
• Oversized-product exceptions
• Remote-area restrictions
• Carrier availability
• Currency
• Minimum order rules
• Return route

Google’s official shipping attribute documentation explains that product shipping data can specify the country to which a product can be delivered and can provide or override applicable shipping information.

A product should not target a country merely because the merchant hopes to add international shipping later.

The operational shipping route should exist before the product is submitted for that market.

Country-specific eligibility must be reviewed separately

One product can have different outcomes in different countries.

For example, the same WooCommerce product may be:

• Eligible in one target country
• Limited in another
• Disapproved in another
• Missing shipping information in another
• Affected by currency inconsistency in another
• Restricted by policy in another
• Unavailable for one marketing method
• Approved for free listings but not Shopping ads

Do not treat one green product status as proof of universal eligibility.

Open the processed product and review:

• Country
• Marketing method
• Issue severity
• Issue code
• Affected attribute
• Effective date
• Suggested action
• Data source
• Last update time

Correct the issue in the authoritative source whenever possible.

Campaign targeting and feed labels

Feed labels can help select which data sources participate in supported advertising campaigns.

For example, a merchant may use:

TR
GB
DE

or:

RETAIL
OUTLET
SEASONAL

The correct structure depends on how products need to be organised.

Before changing a feed label used by campaigns, review:

• Active Shopping campaigns
• Performance Max campaigns
• Demand Gen campaigns
• Campaign filters
• Product groups
• Asset groups
• Country targeting
• Reporting continuity
• Budget allocation
• Promotion sources

A feed-label change can alter which products a campaign can select.

It should not be used as a casual WooCommerce tag.

WooCommerce tags and Merchant feed labels solve different problems.

A WooCommerce tag can describe or organise products inside WordPress.

A Merchant feed label participates in Merchant product identity and supported campaign organisation.

Example market structures

One country and one language

A Turkish WooCommerce store selling only in Türkiye may use:

Content language: tr
Feed label: TR
Target country: Türkiye
Currency: TRY

This is easy to understand, but each value still performs a different function.

The feed label does not create the country targeting.

The content language does not configure the currency.

The target country does not configure shipping automatically.

One language and multiple countries

An English store may use:

Content language: en
Feed label: EN
Target countries: United Kingdom and Ireland

The merchant must separately verify GBP or EUR pricing, shipping, returns, taxes and checkout behaviour for each country.

Using one English source does not remove country-specific commercial responsibilities.

One country and multiple languages

A Canadian store may prepare:

en~CA~SKU-100
fr~CA~SKU-100

Each product identity should lead to the matching English or French landing page.

Both versions need accurate prices, stock, shipping and checkout.

Separate commercial groups

A merchant may use:

Feed label: RETAIL
Feed label: OUTLET

These labels can separate catalogue groups, while target countries are configured independently.

An outlet label should not be confused with product condition. Products still require accurate supported condition values.

WooCommerce workflow before submission

Before creating or updating market-specific Merchant products:

1. Open the WooCommerce product.
2. Record the product ID.
3. Record the variation ID where applicable.
4. Record the SKU.
5. Record the GTIN where applicable.
6. Open the public product URL.
7. Confirm the visible language.
8. Confirm the selected variation.
9. Confirm the price and currency.
10. Confirm stock.
11. Add the product to the cart.
12. Confirm the cart language.
13. Continue to checkout.
14. Confirm the checkout language.
15. Enter an address from the target country.
16. Confirm shipping availability.
17. Confirm shipping cost and delivery time.
18. Open the return policy.
19. Confirm that the policy applies to the target country.
20. Record the intended feed label.
21. Record the content language.
22. Record every target country.
23. Record the owning Merchant data source.
24. Check whether the same offer ID already exists.
25. Submit only after the complete combination is verified.

This process should be repeated for every materially different market or language version.

Merchant API product-input example

A simplified Merchant API product input can include:

{
  "offerId": "SKU-100",
  "contentLanguage": "en",
  "feedLabel": "GB",
  "productAttributes": {
    "title": "Example product",
    "link": "https://example.com/en-gb/product/example-product",
    "availability": "IN_STOCK"
  }
}

The exact request also requires the correct account, data source and supported product attributes.

The example does not prove that the product targets the United Kingdom.

Country eligibility depends on the associated data-source and shipping configuration.

The label GB is still a label.

Technical acceptance does not confirm market eligibility

A successful Merchant API operation can confirm that a request was received or processed technically.

It does not prove that:

• The content language matches the website
• The feed label is strategically correct
• The target country is configured
• Shipping reaches the country
• The currency is suitable
• Checkout supports the country
• Policies are available in the correct language
• The product is approved
• The product is eligible for every marketing method
• The product will receive impressions
• A campaign selects the product
• Duplicate identities do not exist
• Another source will not overwrite the product

Wait for processing and review the resulting Merchant product.

Verifying the processed product

After submission:

1. Open the correct Merchant Center account.
2. Go to Products.
3. Search for the exact offer ID.
4. Check whether multiple language or label identities appear.
5. Open the intended product.
6. Confirm the product data source.
7. Confirm the content language.
8. Confirm the feed label.
9. Confirm the target countries.
10. Confirm the processed title.
11. Confirm the processed description.
12. Confirm the URL.
13. Confirm the price and currency.
14. Confirm availability.
15. Review shipping information.
16. Review country-specific status.
17. Review marketing-method status.
18. Review Needs attention issues.
19. Open the product URL while logged out.
20. Confirm the page language.
21. Add the product to the cart.
22. Confirm the currency.
23. Confirm delivery to the intended country.
24. Confirm checkout language.
25. Repeat the check after the next scheduled synchronisation.

If another language or label combination appears unexpectedly, identify the source that created it.

Check every active data source

A WooCommerce store can have products supplied through:

• Merchant API
• An old Content API integration
• Scheduled XML files
• Uploaded files
• Google Sheets
• Automatic website sources
• A previous WooCommerce plugin
• Manual Merchant Center records
• Supplemental data sources
• Local inventory sources
• ERP integrations
• Supplier imports

For each source, record:

• Data source ID
• Display name
• Input type
• Feed label
• Content language
• Target countries
• Marketing methods
• Product count
• Update schedule
• Rules
• Owning integration
• Active status

Do not assume that disabling one WooCommerce plugin removes products previously created through that source.

Do not delete a source before confirming which products, campaigns or rules depend on it.

What PW Merchant API can support

PW Merchant API provides an API-oriented workflow between WooCommerce and Google Merchant Center.

Depending on the installed version, supported product fields and configured workflow, it can help merchants:

• Connect the intended Google account
• Select the intended Merchant Center account
• Work with supported WooCommerce products and variations
• Maintain stable offer IDs
• Prepare supported Merchant product information
• Submit supported product operations
• Record operation results
• Review applicable product issues
• Synchronise supported product changes
• Compare WooCommerce records with processed Merchant information

Where the installed workflow supports the required market fields, it can communicate prepared content-language, feed-label and data-source information through Merchant API.

However, PW Merchant API cannot independently decide:

• Which countries the business can legally serve
• Which languages customers fully understand
• Whether translations are professionally accurate
• Whether a shipping carrier reaches an address
• Whether taxes are configured correctly
• Whether return operations are practical
• Whether a feed label suits a campaign strategy
• Whether the business has completed market-specific legal duties

It cannot:

• Translate an incomplete WooCommerce store automatically
• Turn a feed label into country targeting
• Guarantee Google approval
• Guarantee Shopping visibility
• Guarantee campaign inclusion
• Guarantee impressions, clicks or sales
• Invent a supported currency arrangement
• Correct inaccurate WooCommerce shipping zones without authoritative data
• Prevent another active source from overwriting information
• Replace professional legal, tax or localisation advice

WooCommerce remains the commercial source, the integration manages supported communication and Google independently processes the submitted information.

Common mistakes

Treating the feed label as a country setting

A label named US does not automatically target the United States.

Using the country code as the content language

GB is a country-style code, while English content language is represented as en.

Submitting one language while showing another

An English product input should not lead to an untranslated Turkish product and checkout journey.

Targeting a country without shipping there

Products should not target a market that the WooCommerce store cannot serve.

Assuming English means USD

Content language does not select currency.

Changing the label without managing the old product

A new language-label-offer combination can create another Merchant identity.

Creating a new data source for every error

First inspect the existing source and exact mismatch.

Using WooCommerce tags as feed labels automatically

Internal store organisation does not necessarily match Merchant campaign strategy.

Ignoring campaign dependencies

Changing a feed label can affect product selection in supported campaigns.

Reusing one URL for every language

Each product identity should lead reliably to the matching language version.

Relying only on automatic IP redirection

Google and customers may receive an unexpected language or currency.

Checking only the API response

Technical receipt does not confirm country eligibility or website consistency.

Frequently asked questions

Is a feed label the same as a target country?

No. A feed label categorises product data and can support campaign selection. It does not automatically target a country.

Can I use a country code as a feed label?

Yes, a supported country-style code can be used as a convenient label, but actual country targeting must be configured separately.

Does the feed label have to be a country code?

No. It can represent another meaningful catalogue or campaign grouping when it follows the supported format.

Can one feed label cover several countries?

Yes. The label and country configuration are separate. Every targeted country still requires valid language, currency, shipping and store support.

Can one country have several content languages?

Yes, when the country and Merchant programme support them and each submitted product leads to a complete landing page and checkout journey in the declared language.

Can one language target several countries?

Yes. Each country must still be supported operationally and configured correctly.

Does contentLanguage translate my WooCommerce product?

No. It declares the language of the submitted content. The actual WooCommerce page must already use that language consistently.

Can I change a product’s feed label later?

Because the feed label participates in Merchant product identity, changing it should be treated as a controlled migration. Verify and manage the old identity and owning data source.

Can I change the content language without changing the URL?

Only when the URL reliably displays the complete intended language. A stable language-specific URL is generally easier to verify than automatic redirection.

Can the same SKU be used for several language versions?

The same internal offer ID can appear within different Merchant identities because language and feed label also participate in the identity. Each submitted version must remain distinct and accurate.

Does a successful API response mean the target country is active?

No. Review the processed product, country status, marketing-method status and shipping configuration.

Can a product be approved in one country and disapproved in another?

Yes. Product and policy outcomes can differ by country and marketing method.

Should every country have a separate data source?

Not always. Merchant API supports different strategies, including flexible API data sources and sources restricted to specific label-language combinations. The structure should match operational and rule requirements.

Can I use one English source for the United Kingdom and Ireland?

Potentially, but currency, shipping, returns, taxes, checkout and other country-specific requirements must be verified separately.

Does a GB feed label automatically use GBP?

No. Feed labels do not configure currency.

Can shipping data add another country?

Applicable data-source and product shipping configurations can participate in multi-country targeting. The store must genuinely deliver there and provide accurate shipping information.

Can automatic currency switching cause problems?

Yes. IP-based or cookie-based switching can cause Google and customers to see different prices or currencies. The submitted URL should expose a stable, consistent market experience.

Can PW Merchant API choose my target countries?

It can work with supported configuration supplied by the merchant, but it cannot decide which countries the business can genuinely serve.

Can PW Merchant API translate all product and policy pages?

No. Complete translation and localisation remain the merchant’s responsibility.

Will correct feed labels guarantee Shopping visibility?

No. Other product data, website, policy, account, campaign and eligibility factors still apply.

Final feed label, country and language checklist

Before submitting a WooCommerce product for a market, confirm that:

• The correct Merchant Center account was selected.
• The correct WooCommerce product was identified.
• The correct variation was identified.
• The WooCommerce product ID was recorded.
• The variation ID was recorded.
• The SKU was recorded.
• The Merchant offer ID was recorded.
• The intended product URL was recorded.
• The active data source was identified.
• The data source ID was recorded.
• The data source input type was checked.
• The data source accepted API operations where applicable.
• The data source’s language restriction was checked.
• The data source’s feed-label restriction was checked.
• The content language used a supported code.
• The submitted title used the declared language.
• The submitted description used the declared language.
• Customer-facing attributes used the declared language.
• The landing page used the declared language.
• The selected variation used the declared language.
• Cart messages used the declared language.
• Checkout used the declared language.
• Payment instructions used the declared language.
• Shipping information used the declared language.
• Return information used the declared language.
• Terms and conditions were understandable.
• Required customer notices were understandable.
• Automatic language redirection was checked.
• IP-based redirection was checked.
• Cookie-based language switching was checked.
• The language-specific URL remained stable.
• The feed label had a documented purpose.
• The feed label followed the supported format.
• The feed label contained no spaces.
• The feed label did not exceed the supported length.
• The feed label was not mistaken for a country setting.
• The feed label was not mistaken for a currency setting.
• The feed label was not mistaken for a WooCommerce tag.
• Campaign dependencies were reviewed.
• The target country was configured separately.
• The store genuinely delivered to the target country.
• WooCommerce shipping zones supported the country.
• Merchant shipping settings supported the country.
• Shipping prices were accurate.
• Handling times were accurate.
• Transit times were accurate.
• Remote-area restrictions were checked.
• Postal-code limitations were checked.
• The return process supported the country.
• The currency was supported for the intended configuration.
• The landing-page currency matched Merchant data.
• Cart currency matched Merchant data.
• Checkout currency matched Merchant data.
• Structured data currency matched Merchant data.
• Taxes were represented accurately.
• The complete checkout accepted an address from the target country.
• Payment methods were available to customers in that country.
• Restricted products were reviewed for the market.
• Legal and tax responsibilities were reviewed.
• Every language version had a distinct and accurate identity.
• Every market version had a stable URL.
• contentLanguage, feedLabel and offerId were recorded together.
• Existing identities using the same offer ID were searched.
• Old language identities were checked.
• Old feed labels were checked.
• Old product inputs were checked.
• Duplicate products were checked.
• The owning data source was confirmed before write operations.
• Accidental offer stealing was avoided.
• Previous Content API products were checked.
• Scheduled XML sources were checked.
• Automatic website sources were checked.
• Supplemental sources were checked.
• Previous WooCommerce integrations were checked.
• ERP and supplier imports were checked.
• No other source could restore an obsolete identity.
• The authoritative WooCommerce product was corrected.
• Upstream translations were corrected.
• Upstream currency mappings were corrected.
• Upstream shipping information was corrected.
• The product was saved.
• Applicable caches were refreshed.
• The public page was checked while logged out.
• The correct Merchant identity was submitted.
• The correct data source was supplied.
• The operation result was recorded.
• The processed Merchant product was opened.
• The processed content language was checked.
• The processed feed label was checked.
• Target-country status was reviewed.
• Marketing-method status was reviewed.
• Needs attention issues were reviewed.
• Shipping information was reviewed.
• The landing page was opened from Merchant Center.
• Cart and checkout were tested.
• Applicable processing time was allowed.
• The product remained correct after scheduled synchronisation.
• No approval or performance guarantee was assumed.

Feed labels, content languages and target countries must be managed as separate parts of one market strategy.

The feed label categorises product data and can support campaign selection.

The content language declares the language used by the submitted product.

The target-country configuration determines where the product data is intended to be used.

Shipping, currency, policies and checkout establish whether the WooCommerce store can genuinely support that market.

Merchant API then uses content language, feed label and offer ID as important parts of the product identity.

Changing one of these identity values can create a new product rather than simply update the old one.

For that reason, international WooCommerce expansion should be planned before large product operations begin.

PW Merchant API can support controlled product communication and applicable Merchant operations. It cannot turn an unsupported market, incomplete translation or inaccurate shipping configuration into an eligible product.

A clear data-source structure, stable identities, complete translations, accurate country settings and reliable WooCommerce checkout provide the strongest foundation for managing products across multiple Google Merchant Center markets.