Launching a website in another country used to sound relatively straightforward: translate the copy, point a new domain at it and start targeting some new keywords.
Modern applications make that considerably more complicated.
A website might now be server-rendered, client-rendered, distributed through a CDN, backed by multiple APIs and responsible for everything from authentication to payments. Add multiple countries, languages and currencies and international SEO stops being something that can be handled entirely by the marketing team.
It becomes an architectural decision.
Start with the URL architecture
One of the first decisions is how different markets will be represented.
Common approaches include country-specific domains, subdomains and subdirectories.
For example:
example.co.uk
de.example.com
example.com/de/
There is no universally correct answer.
Separate domains can create a very clear geographical distinction but increase operational overhead. Subdomains provide separation while retaining the primary domain, although they can complicate deployment and infrastructure. Subdirectories often provide the simplest architecture when markets share the same underlying platform.
The decision shouldn’t just belong to SEO.
Engineering needs to consider deployments, authentication, cookies, caching, routing, analytics, content management and how much of the application is genuinely shared between markets.
Changing the structure later can mean a sizeable migration, so it is worth getting right early.
The original Jublo article already considered the trade-offs between subdomains, country-code domains and subdirectories.
Language and country are not the same thing
One of the most common internationalisation mistakes is assuming that language identifies a market.
It doesn’t.
English spoken in Britain, the United States and Australia is still English, but each market has different spelling, terminology, currency, date formats, addresses and expectations.
This means a locale such as en-GB conveys considerably more information than simply en.
That distinction should flow through the application.
URLs, metadata, content, pricing, emails, generated documents and API responses may all need to understand which locale the user belongs to.
The same applies when two countries nominally speak the same language.
Localise the application, not just the words
Translation is only one part of localisation.
An application launching internationally may also need to account for:
- currency and number formatting;
- dates and time zones;
- address and telephone formats;
- units of measurement;
- images and other media;
- payment methods;
- form validation;
- transactional emails;
- PDFs and generated documents;
- legal or regulatory information;
- search behaviour and terminology.
If these decisions are scattered around the codebase as exceptions, supporting the next country becomes increasingly expensive.
Internationalisation works best when it is part of the application’s architecture.
Even the original version of this article recognised that localisation needs to extend to currencies, time zones, checkout journeys and culturally appropriate content rather than simply translating page copy.
Make every version discoverable
A beautifully localised page is of little use if a search engine cannot reliably discover or render it.
Modern JavaScript applications therefore need particular attention.
Ask some basic questions:
Can the important content be returned in the initial HTML?
Does each localised page have a stable URL?
Does it output the correct title and metadata?
Are canonical URLs correct?
Can search engines identify the relationship between regional versions?
Are localised URLs represented in your sitemap?
Can a crawler reach them without having to select a country from a JavaScript dropdown first?
The application should make the market structure explicit rather than expecting a crawler to infer it.
Use hreflang correctly
When equivalent pages exist for different languages or regions, hreflang can help search engines understand the relationship between them.
For example, you may have:
en-GB
en-US
es-ES
es-MX
These are not duplicates in the traditional sense. They are variants intended for different audiences.
The implementation needs to be consistent. Regional pages should reference the appropriate alternatives, including themselves where required, and URLs should be canonical and indexable.
A malformed international configuration can be worse than no configuration at all, so this is something worth testing rather than simply generating and assuming is correct.
Don’t automatically redirect everyone
Automatically forcing a visitor onto a particular region based solely on their IP address often creates more problems than it solves.
People travel. They use VPNs. They may live in one country while buying for another. Search crawlers may access your application from infrastructure nowhere near your customer.
Geo-detection can be useful for suggesting a region, but the user should generally retain control.
And once they make a choice, remember it.
Performance becomes international too
A site that performs brilliantly from a UK datacentre might feel considerably less impressive several thousand miles away.
International expansion therefore needs infrastructure consideration as well as content changes.
Static assets can often move closer to users through a CDN. Dynamic application traffic may require regional infrastructure, edge caching or different API strategies depending on the workload.
Measure the experience from the places your customers actually are, not simply from the office where the development team sits.
Test with people in the market
Automated testing will find broken routes, missing strings and layout problems.
It won’t always tell you that something simply feels wrong.
Someone familiar with the target market will notice terminology, expectations and assumptions that a technical test suite won’t.
The original Jublo article recommended testing an international site with people familiar with the target market before rolling it out. That principle remains useful today.
International SEO is really systems thinking
The strongest international websites aren’t ones where localisation was added just before launch.
They are platforms designed to understand that users live in different places, speak differently, pay differently and expect different things.
That requires content, commercial teams and engineering to work on the same problem.
At Jublo, that’s the bit we find interesting: making sure the technology underneath an international digital product is as considered as what appears on the screen.