International Ecommerce SEO: Catalogs, Currencies, and Country Pricing

International ecommerce SEO is mostly a data problem, not a URL problem. Once your country folders or domains exist, the hard part is what sits inside them: thousands of product pages that must be translated well enough to rank, priced in the right currency, marked up so the price Google reads matches the price a shopper sees, and honest about what can actually be shipped to that market.

This article covers that catalog layer. It assumes you already have, or are separately planning, a URL structure and hreflang annotations for your markets. Here the questions are different. Which parts of a catalog deserve real translation and which do not? How do you express two prices for one product without confusing crawlers? What should a product page say when an item is sold in Germany but not in Norway? Most international catalog failures come from treating those questions as an afterthought.

Why Catalogs Break Differently Than Content Sites

A blog post translated badly is one weak page. A catalog translated badly is tens of thousands of weak pages that all share a template, and search engines evaluate templates at scale. If every product page in a new market is an unedited machine output wrapped in the same boilerplate, the market folder as a whole looks thin, and the good pages inside it inherit that reputation.

Catalogs also carry a second layer that articles do not: transactional data. Price, currency, stock, shipping cost, delivery time, and tax treatment are all facts that differ per country, and they appear in three places at once: the visible page, the structured data, and any product feed. Search engines compare these. When they disagree, you can lose rich results, get products disapproved in shopping surfaces, or simply train users to distrust the listing.

So the working model is this. Every market folder has to answer three questions independently: is the text good enough to rank, is the commercial data correct for this country, and is the product actually available here? The rest of this article takes those in order.

Deciding What to Translate, and How Well

You rarely need to translate everything to the same standard. A sensible approach is to tier the catalog by commercial value and search demand in the target market, then apply a different level of effort to each tier.

The top tier is the small set of products, categories, and brands that drive most revenue or that have real local search demand. These deserve human-edited copy and local keyword research, because the words people use for a product in Mexico are not always the words used in Spain, and the same holds for Brazilian versus European Portuguese or German versus Austrian retail vocabulary. The middle tier can be machine translated and then reviewed on a sample basis, focusing on titles, category names, and the first paragraph of each description. The long tail can be machine translated with light checks, or left untranslated and kept out of the index until it earns attention.

That last option is underused. A product page in the new language that is half English, with a translated title but an untranslated description and reviews, is a weaker page than no page at all. If you cannot translate a product properly, consider serving it without an indexable local version rather than letting a hollow one into the index.

• Titles and category names first. They carry the most ranking weight and the most click-through influence, so errors here cost the most.
• Attributes and filters. Size, color, material, and unit labels are catalog data, not prose. Translate them from a controlled glossary so the same term is never rendered two ways across the store.
• Units and sizing. Centimeters versus inches, EU versus US shoe sizes, and kilograms versus pounds are part of localization. A correct translation with the wrong measurement system still loses the sale.
• User reviews. Reviews in another language can stay in their original language if labeled, but do not machine translate them into thousands of near-duplicate fragments.

Terminology Glossaries and the Duplicate Trap

Large catalogs usually reuse manufacturer descriptions. In the source language that is already a duplicate-content risk across retailers. Translation does not fix it; it multiplies it, because many competitors in the target market are translating the same manufacturer text with the same tools and often arriving at nearly identical output.

The practical defense is to add something the feed supplier's text does not contain. That can be local sizing advice, a comparison table, compatibility notes for local standards such as plug types and voltages, country-specific care or legal information, and real answers to questions local customers ask. You do not need long text. You need a few sentences per product that could only have been written for that market.

A translation glossary belongs at the center of this work. Define preferred terms for brand names that should never be translated, product type nouns, and recurring phrases such as shipping and returns language. Store it as data and feed it to whoever or whatever does the translating. The benefit is consistency across thousands of pages, which affects both user trust and the way search engines associate your pages with a coherent topic.

Pricing and Currency in Structured Data

Each country version of a product page should carry Product structured data whose Offer reflects that country's price. The fields that matter are price, priceCurrency, availability, and url. The price must be a plain number with a period as the decimal separator and no currency symbol or thousands separator, and the currency must be an ISO 4217 code such as EUR, GBP, MXN, or CAD. The visible page can format the amount however the local convention demands, with a comma decimal in Germany or a space grouping in France. The markup should not.

The most common mistake is emitting the same JSON-LD on every country page, typically the default-market price, while the visible price is converted. Google's guidance is that structured data must describe content visible on the page, so a mismatch is a quality problem and can make the page ineligible for product rich results. Generate the markup from the same variable that renders the visible price, never from a separate field.

Watch tax treatment as well. Consumer prices in many markets are expected to include VAT or sales tax, while in others, such as the United States, the displayed price usually excludes sales tax. Merchant Center has market-specific requirements here, so the price you mark up and feed should follow the convention of the country it serves. If you sell to businesses, you may show ex-VAT prices deliberately, but then say so on the page, since the markup cannot express the nuance alone.

Sale prices deserve care. If a discount is real and time-limited, express it with the current price in the Offer and an expiry through priceValidUntil, and make sure the expired price is not left in markup after the sale ends. A stale price in structured data is one of the easiest ways to create the mismatch described above.

Feeds, Merchant Center, and One Product in Many Markets

If you use product listings on Google, the feed is a second source of truth that has to line up with the page. A feed is scoped to a target country and language, and the price, availability, shipping, and tax data in it apply to that country. Publishing one global feed with a single price and hoping it sorts itself out is how merchants end up with disapprovals for price mismatch.

The clean pattern is one product identity with country-specific attributes. Keep the same item ID or GTIN across markets so the product is recognized as one thing, but supply a separate price, currency, link, and availability per country, either through separate feeds or through country-specific feed rules. Each link should point to the local page, and that page should show the same price the feed claims. Google's crawler will compare them.

A few details trip people up repeatedly. The landing page must be reachable and priced for the country in the feed, including when the shopper arrives with a foreign browser locale. Shipping costs and delivery estimates should exist for each target country, or the product may not display there. And when a market uses different product identifiers or brand naming, the feed needs to reflect the local reality rather than a translated guess.

Showing the Right Price Without Geo-Redirecting Crawlers

A tempting shortcut is one URL per product that detects the visitor's country by IP address and swaps the currency and language. Search engines crawl from a limited set of locations, and Google has documented that its crawlers may not see locale-adaptive content the way a local visitor does. The result is that only one version of the page, usually the one served to a US address, is reliably seen and indexed. Your French, Japanese, and Brazilian prices effectively do not exist for search purposes.

The safer structure is that each market has its own stable URL whose price and currency are fixed by the URL itself, not by the visitor. If you want to help shoppers, offer a visible suggestion banner, for example noting that a local version is available, rather than forcing a redirect. Let the shopper choose and remember that choice with a cookie, but never gate the content of a crawlable URL behind a cookie or location check.

For markets where you only change the currency and not the language, such as an English store serving the UK, Ireland, and Australia, the pages will be near duplicates. That is acceptable when prices, shipping, and availability genuinely differ, but it is worth adding local substance, such as local delivery terms and returns information, so the pages are not interchangeable. Shipping and return details can also be marked up per country, which is covered in a separate article on return policy schema.

Availability That Changes by Market

Availability is the dimension most stores forget. A product may be in stock in one warehouse, restricted by regulation in another country, licensed only for certain regions, or simply not shipped to a market. Each of those needs a deliberate decision rather than a default.

If a product cannot be sold in a country at all, the best answer is usually not to create a page for it in that market. A page that exists only to say the item is unavailable adds nothing for searchers. If you already have one, choose between removing it with a proper status code and keeping it with a useful alternative, such as a compatible local product or a link to the category.

If a product is temporarily out of stock, keep the page, set the Offer availability to OutOfStock or BackOrder as appropriate, and keep the status consistent with the feed. Removing a page on every stock-out throws away its accumulated links and history. For discontinued items, redirecting to the closest equivalent in the same country works, but redirect within the market folder, not into another country's catalog.

Pay attention to the mismatch between the market and the warehouse. If stock is held in one country but sold in several, the availability and delivery time shown in each market should reflect real lead times. Shoppers and shopping surfaces both penalize items that advertise next-day delivery but take two weeks.

A Worked Example: One Product, Three Markets

Take a hypothetical backpack sold in Germany, Mexico, and Canada. The German page lives in a German-language folder and lists the price in EUR, VAT included, with metric dimensions and German terminology from the glossary. The markup gives a numeric price, priceCurrency EUR, and InStock availability. The German feed points to that URL and carries the same values, plus German shipping and the VAT setting.

The Mexican page is in Spanish, priced in MXN, and references local shipping and delivery times. Because the warehouse is abroad, the lead time is longer, and the page says so. The markup reflects MXN and the feed is scoped to Mexico. Nothing on this page is computed from the German one.

The Canadian store serves both English and French. That means two language versions, both priced in CAD, each with its own URL, both fed to the Canada target. One model is shared product identity and separate local attributes everywhere. If the backpack cannot be shipped to Canada because of a supplier restriction, no Canadian page exists, and the German and Mexican pages are unaffected.

Mistakes That Quietly Cost Rankings

Most problems in international catalogs are silent. Nothing breaks visibly; the pages simply underperform. A short audit list catches the majority.

• Structured data price differs from the visible price on country pages, usually because the markup is hard-coded to the default currency.
• Feed prices drift from page prices after a currency refresh or promotion, because the two are updated by different processes.
• Live exchange rates change the displayed price constantly, so crawled snapshots disagree with each other. Prefer fixed prices per market that you review on a schedule.
• Thin pages with translated titles and untranslated descriptions are left indexable across the whole long tail.
• Out-of-stock and unavailable products are handled with soft 404s, redirects to the homepage, or cross-market redirects.
• Country selection is cookie or IP based, so only one version of each product is crawlable.
• Measurements, sizes, and terms are translated but not localized, which raises returns and lowers conversion even when rankings hold.