One global site or separate country domains?

Draw the system boundary before choosing URLs

Start with a diagram of the real service. A retailer using one catalogue of 800 products, one warehouse, one checkout and one support team has one operational core even if it publishes in English, German and Polish. Stable paths such as example.com/en-gb/, example.com/de-de/ and example.com/pl-pl/ expose regional versions without pretending they are independent businesses.

Now change the case: the German subsidiary sells only 220 products, sets its own euro prices, uses a German returns address and releases promotions on a different calendar. example.de can then represent a genuine product boundary. The URL architecture follows responsibility that already exists.

One global domain still needs explicit regional architecture

Do not mix languages by session, cookie or browser setting under one URL. Every version needs a crawlable address, its own page title and regional content. Connect equivalent pages with reciprocal hreflang annotations; use x-default for a neutral selector or fallback where appropriate. Keep navigation available so a traveller can choose another market.

A shared domain concentrates deployment, analytics and link authority, but it also concentrates failure. A bad routing rule at example.com can affect every country. Assign owners for locale routing, translation releases and the default-market page, and test all regional paths in the same release checklist.

Country domains are a production portfolio

Launching example.de, example.fr and example.pl creates three registration lifecycles and three DNS zones, even when one registrar and one hosting platform are used. Inventory the registrant, registrar, registry, renewal date, recovery method, nameservers, DNSSEC state and certificate coverage for each name. A spreadsheet without an accountable owner is not a control.

Separate properties also need coordinated releases, monitoring and measurement. Define who can change DNS, who receives expiry alerts and who acts during an outage. Use organisation-controlled accounts, two-factor authentication and at least two trained people for recovery; a country manager’s personal mailbox must not be the only route back into a business-critical domain.

Set a market-autonomy threshold

Open a country site only when local differences justify another production property. Score the proposed market against concrete triggers:

One translation alone does not cross that threshold. With four country domains, even a quarterly access review produces 16 domain reviews per year, before releases or incidents are counted. Reserve strategically important names if necessary, but redirect unused ones to the live regional path instead of maintaining thin duplicate sites.

• its own legal seller, terms or privacy obligations;
• a different catalogue, currency, tax display or checkout;
• local fulfilment, returns and customer support;
• a team and budget able to publish, monitor and renew the site.

Design the exit before launch

Document how a market can move between models. When a regional path graduates to a ccTLD, map every old URL to its closest new page, use permanent redirects, update internal links, sitemaps and hreflang, and monitor both properties through the transition. Do not redirect an entire section to the new homepage.

The reverse must also be possible. If a local operation closes, preserve the country domain, redirect valuable URLs into the global structure and keep renewal ownership clear. Architecture is sound when adding or retiring one market is a controlled migration rather than an emergency.