Store operations

Localization: translation, multilingual SEO and local pricing

Translating stores, multilingual SEO and checking prices, currency and VAT per country.

3 guides3 in-depth42 min of reading

Selling in another language changes more than the words on the page. Each language needs its own crawlable URL with a complete, reciprocal hreflang set. The cart and checkout have to stay in the shopper's language even where WooCommerce renders them in the browser. Prices must show the right currency and tax treatment for the country. And the translation tool you pick decides where translations are stored, which on a large catalog shows up directly in the size of your database.

Internationalizing WooCommerce at scale measures that cost. On WooCommerce 11.2.1, one variable product with 12 variations took 13 posts, about 270 postmeta rows and 24 attribute-lookup rows, and WPML adds the same again for every language: a 10,000-product catalog in 4 languages grows from about 2.7 million to about 10.8 million postmeta rows. Weglot keeps translations in its cloud and translates the rendered HTML, so MySQL stays the size of one language, but every uncached page view depends on an external API. Optimizing multilingual SEO on WooCommerce covers the search side: translated URLs, hreflang and self-referencing canonicals, translating the Store API's cart and checkout JSON, and fitting the translation word budget to the catalog.

Geo-targeted price checks handles what shoppers in each country actually see. It sends requests from a residential IP in that country, held for the whole redirect chain, with a cookie jar and a matching Accept-Language header. It then reads price and currency from the page's schema.org data and strips VAT before comparing, since EU and UK prices include VAT and US prices exclude sales tax. Most failed checks turn out to be redirect loops caused by a rotating IP, a missing cookie or a language header that contradicts the IP.

Start here

Localization12 min read

Internationalizing WooCommerce at scale: SaaS (Weglot) vs database-heavy (WPML)

WPML (and Polylang) store every translation as its own WordPress post, so each translated variable product copies the product, all of its variations and their meta. In our measurement on WooCommerce 11.2.1, one variable product with 12 variations took 13 posts, about 270 postmeta rows and 24 attribute-lookup rows, and every extra language added the same again: a 10,000-product catalog in 4 languages grows from about 2.7 million to about 10.8 million postmeta rows. Weglot keeps translations in its cloud: WordPress renders the original page, Weglot's plugin catches the HTML in an output buffer and translates it through cdn-api-weglot.com, so MySQL stays the size of one language. The price is a network call on every uncached translated page view, which makes a full-page cache in front of the translated URLs mandatory, and a word quota: Weglot counts unique words across all languages, so a large catalog can outgrow its 5-million-word top plan. Pick Weglot for performance and a lean database; pick WPML when translations must live on your server, when you need per-language prices or stock rules, or when the word count makes SaaS too expensive. Polylang is the open-source version of WPML's model.

Localization18 min read

Optimizing multilingual SEO on WooCommerce: Linguise vs manual translation

Multilingual SEO on a big WooCommerce store comes down to three jobs. First, every language version of a product needs its own crawlable URL with a complete, reciprocal hreflang set and a self-referencing canonical. Second, text that WooCommerce renders in the browser (block cart and checkout, Ajax fragments, React catalogs reading the Store API) must be translated too, or shoppers switch language halfway through checkout. Third, the word budget must fit the catalog. Linguise covers the first two server-side: it translates URLs, prints hreflang, and translates the Store API's cart and checkout JSON. Reading its 2.2.70 source shows that it skips the /wc/store/v1/products route unless you add it with two filters, which our tested mu-plugin does. Its Large plan has no word cap (fair use applies) for $45 a month, which is why it's our pick past 10,000 products; Weglot is the strong alternative, priced by unique words. Translate by hand where words sell: top products, categories and legal pages. Exclude SKUs, prices and account pages, and audit hreflang clusters with the script below.

Localization12 min read

Geo-targeted price checks: currency, VAT and geo-redirect pitfalls with residential proxies

To see the price a shopper in another country sees, send the request from a residential IP in that country, keep the same IP for the whole redirect chain with a sticky session, keep the cookies the store sets on the way, and send a matching Accept-Language header. Then read the price and currency from the page's schema.org Product data, convert it with a daily reference rate such as the ECB's, and strip VAT before you compare, because EU and UK prices include VAT and US prices don't include sales tax. Most failed geo checks are redirect loops caused by a rotating IP, a missing cookie jar or a language header that contradicts the IP.