Sell internationally without breaking the market you already have

Most stores do not need a market-sizing report to choose the next country. The evidence is already in the account. Analytics shows which countries send sessions that browse deeply and then stop at the shipping step. The order table shows foreign billing addresses on payments that failed or were abandoned. Search Console shows impressions from outside the home market on queries you never targeted. Support shows the emails asking whether you ship there, and in what language they were written. That is unassisted demand: people who found you despite the store making no effort to be found by them. It beats a forecast, because it has already survived contact with reality. If your analytics are wired to the funnel rather than to pageviews, this is an afternoon of work, not a research project.

• Sessions by country that reach the cart but never reach checkout
• Abandoned or declined orders carrying a foreign billing address
• Search Console impressions and queries from outside your home market
• Support messages asking whether you ship there — and in which language

Translation is the visible part and the smallest part. The real job is to stop asking a foreign buyer to do conversion arithmetic in their head or fight a form built for someone else's country. Sizes in the system they use, not a footnote table. Weights and dimensions in their units. Dates in the order they read them. An address form with the fields their country actually has — a state selector that exists or does not, a postcode that may be alphanumeric, a house number that goes before or after the street. Phone input that accepts a local format without throwing a validation error. Baymard Institute's checkout usability research devotes a striking share of its length to address fields, which tells you how often this is where motivated buyers quit. Translate the pages where money is decided first; the blog can wait.

• Sizes, weights and dimensions in local units, not a conversion footnote
• Address forms with the right fields, order and postcode rules
• Phone and date inputs that accept local formats without errors
• Translate the product, delivery, returns and checkout copy before anything else

Showing a price in your home currency and letting the card issuer convert it is a quiet tax on trust. A shopper who cannot tell what will land on their statement behaves like a shopper who has been quoted a bad price. Charge in the local currency, with price points that look deliberate rather than like an exchange-rate remainder. The bigger variable is method. Card dominance is not universal: iDEAL carries an enormous share of Dutch online payments, BLIK is normal in Poland, invoice and bank transfer habits persist in German-speaking markets, wallets dominate much of Asia. If your gateway cannot present the local method, that part of the market cannot buy from you at all, no matter how good the translation is. This is one reason to keep the native WooCommerce checkout through a hybrid handoff — the payment plugin ecosystem is already there.

The number that closes or kills an international sale is what the customer pays in total, at the door, in their currency. Shipping is the obvious half. Duties and import taxes are the half that arrives later and does the damage. Two models exist and you must choose one on purpose. Under DDP — delivered duty paid — you collect duties and import tax at checkout and the parcel arrives with nothing left to pay. Under DDU or DAP, the carrier collects from the customer on delivery, usually adding a handling fee and a delay. DDU looks cheaper until you count refused parcels, chargebacks and the support hours spent explaining a bill you did not mention. Returns are the same trap: a customer who has to ship an item back across a border at their own cost is a customer who leaves a public complaint instead.

• Quote the delivered total, duties included, before the payment step
• Choose DDP or DDU deliberately and state which one on the product page
• Publish realistic delivery windows that account for customs clearance
• Name a returns address and say plainly who pays return shipping

This is the part where honest scope ends. Registration thresholds, EU VAT and OSS handling, US economic nexus rules that differ state by state, commodity codes for customs declarations, invoice requirements that vary by country — none of that is a development decision. A developer can implement any rule you are given, wire it into WooCommerce tax classes and shipping zones, and make the storefront display it correctly. A developer cannot tell you what you owe, where you must register, or when crossing a threshold changes your obligations. Get an accountant familiar with the target country before the first order, not after the first audit letter. Tax errors are not bugs you patch in a release; they accrue quietly and are settled with interest.

Search is where a second market most often damages the first. Pick one URL strategy — subdirectories, subdomains, or country domains — and keep it. All three are defensible; mixing them is not. Then implement hreflang properly: every alternate listed on every version, reciprocal, including a self-reference, with an x-default for the fallback. Google treats hreflang as a signal rather than a command, so the annotation only helps if the pages genuinely differ. That is why machine-translating a catalogue and publishing it is the expensive mistake: you create pages that read as low quality in the target language and compete with your originals for the same intent. Localized metadata means titles and descriptions written by someone who knows how that market searches, because the German query is not the English query translated. A multilingual storefront renders those signals server-side, which is where they need to be.

The boundary is worth stating concretely, because expansion is where teams start believing they need a new platform. WordPress and WooCommerce keep everything operational: products and variations, stock, orders, refunds, coupons, tax classes, shipping zones and rates, payment gateways, order emails, and whatever multi-currency or translation plugin you already use as the source of that data. Your team adds a German shipping zone on the same admin screen they use today. What changes is the customer-facing layer. The Next.js storefront resolves locale and currency before the first paint, renders the localized route with the right metadata and hreflang server-side, formats units and addresses per market, and hands the shopper to the native checkout with the cart intact. Nothing about opening a second country requires replatforming the business behind it.

The honest recommendation is often to wait. Localization is a standing cost — every product, policy and campaign now exists twice — and it is a poor way to discover whether anyone abroad wants your product. The cheaper test comes first: switch on international shipping, quote an accurate delivered price in English, and see whether orders appear. If nobody buys, language was not the constraint, and translating the catalogue would have bought you a second silent store. Do not start if your home market still has an unsolved problem: a slow storefront, a leaking checkout, or margins that only survive domestic shipping. Fix the paying market before diluting attention. When you do move, move once. One country, launched completely, measured across a full purchase and returns cycle, before the second. Our pricing is structured around that sequencing rather than a big-bang multi-market launch.