The international SEO guide

London businesses go international earlier than most. A Mayfair jeweller ships to the Gulf and the United States; a Shoreditch software company has more customers in Berlin than in Birmingham; a Soho language school recruits in Madrid, Milan and São Paulo. The website usually follows the sales, and that is when the search problems start: the wrong country’s page ranking in the wrong country, translated pages that read like translations, and a single analytics view where every market’s numbers are mixed together.

This guide is the order of decisions we work through with a client expanding abroad. Each is explained in plain terms, with Google’s own documentation linked where the behaviour is Google’s. It assumes you already know there is demand in the market; the first section is a short check that you do.

Before the technical work: is there demand you can serve?

International SEO is expensive to do well and cheap to do badly. Before building anything, answer four questions per market. Do people there search for what you sell, in which language, and what do the current results look like? Can you deliver: shipping, returns, local payment methods, VAT and duties, customer service in the right language and time zone? Who already ranks, and are they local companies with local trust signals you would need years to match? And what is the realistic revenue if you win a reasonable share, against the cost of content, localisation and support?

Search a dozen of your core phrases in the target language from the target country (a VPN or a rank tracker with location settings) and read the results as a customer would. If every result is a domestic retailer with local reviews and next-day delivery, you are not competing on SEO; you are competing on being local, and the website is the smallest part of that.

Across the group behind this agency, teams work in ten countries, which is useful for exactly this stage: a colleague who searches from the market, reads the language and knows which local platforms matter. It does not change the arithmetic. If the arithmetic does not work, the honest advice is not to build the site.

Choosing the URL structure

Google’s documentation on managing multi-regional and multilingual sites sets out the options and their trade-offs. The table below is Google’s comparison with our commentary on cost for a UK business adding markets.

A note on language versus country folders. /de/ can mean German-language or Germany. If you sell to Germany, Austria and Switzerland in German with different prices and delivery terms, you need /de-de/, /de-at/ and /de-ch/ (or equivalent), each with its own hreflang. If you sell one German-language offer to all three, one /de/ folder with hreflang for the language alone is simpler and avoids near-duplicate pages. Decide this from the commercial reality, not the other way round.

Language and region codes

Hreflang values are a language code, optionally followed by a region code. Google’s localised versions documentation specifies ISO 639-1 for languages and ISO 3166-1 Alpha 2 for regions. A language code may stand alone; a region code may not. The documentation calls out the common mistakes: using a region alone (be is the Belarusian language, not Belgium) and using reserved codes such as EU, UN or UK, which have no effect. The United Kingdom is GB, so the value for English pages aimed at the UK is en-GB, which is Google’s own example.

Hreflang done right

Hreflang tells Google which version of a page is intended for which language and region, so that a searcher in Munich sees the German page and a searcher in Manchester sees the UK one. Google’s documentation gives three methods, treats them as equivalent, and says using more than one gives no benefit in Search:

1. HTML link elements in the head of each page: one link rel="alternate" hreflang="..." element per version, including the page itself.
2. HTTP headers, for non-HTML files such as PDFs.
3. XML sitemap entries, listing every version under each URL. Easiest to maintain at scale, because one file holds the whole map.

Whichever method you use, three rules decide whether it works at all.

• Every version lists every version, including itself. The self-reference is required.
• Annotations are bidirectional. If page X points to page Y, page Y must point back to X. Google states that "if two pages don’t both point to each other, the tags will be ignored". This is the mistake behind most broken implementations: a new market is added to the new pages but not to the existing ones.
• Use x-default for the fallback. It sets the page for users whose language matches none of your versions, typically a country selector or the auto-redirecting home page, and needs no language code.

Hreflang does not transfer ranking strength and does not replace localisation. It resolves which of your own pages Google shows where. If the German page is a thin translation, hreflang will faithfully serve the thin translation to Germany.

Two things not to do

Google’s multi-regional documentation advises against automatically redirecting users to a language version based on a guess about their language, because it can stop users and search engines seeing all versions. It also advises against adapting content from the visitor’s IP address: IP location is unreliable, and Googlebot crawls mostly from the United States without varying its location, so versions served only to other IPs may never be crawled. Offer visible links to switch region and language instead, and let hreflang do the routing in search.

Where the same language appears for different regions on different URLs, Google asks you to choose a preferred version and use rel="canonical" together with hreflang. Its canonicalisation documentation sets out the methods. The usual pattern is that each regional page canonicalises to itself and hreflang links them; cross-canonicalising regional pages to one "master" removes the regional versions from search, which is the opposite of what you built them for.

Get your free SEO auditIf you already have international pages, the review checks the hreflang map, the canonicals and which country is actually seeing which page. Two working days, written by a person.

Localisation, not translation

A translated page tells a German customer what a British company says. A localised page tells them what they want to know, the way a German company would say it. The difference shows in search results because local competitors have written localised pages and Google’s systems are good at telling which page serves the searcher.

There is also a policy edge to this. Google’s spam policies list, among the examples of scaled content abuse, generating many pages through "automated transformations like synonymizing, translating, or other obfuscation techniques" where little value is provided to users. Machine translation as a drafting tool, reviewed and rewritten by a native speaker who knows the market, is fine. Machine-translating a thousand product pages and publishing them unread is the example in the policy.

• Search terms are not translations. The phrase German customers use for your product may not be the dictionary translation of the English one. Research the terms in the target language from the target country before writing the page, and name the pages accordingly.
• Prices, currency, units and formats. Local currency, local tax treatment stated plainly, metric where metric is used, dates and numbers in the local format.
• Delivery, returns and legal. Delivery time to that country, the returns process from it, the consumer rights that apply there, and any mandatory legal information for the market.
• Local proof. Reviews from customers in that country, local press, local partners and stockists. A UK review wall on a German page is proof of something, but not of being a safe choice in Germany.
• Local contact. A way to reach you in the language, with hours in the time zone. It does not need to be an office; it needs to be answered.
• Spelling and register. en-US pages in US spelling and idiom; formal or informal address chosen deliberately in languages where it matters.

Local search in each market

If you have a physical presence in the market (a showroom, a clinic, a partner-run office), it needs its own Google Business Profile, following Google’s guidelines for representing your business, which also set out how service-area businesses should be represented. If you have no presence, do not invent one: a virtual office address on a Business Profile is a policy problem and, in most markets, an obvious one to local customers.

Links and mentions are local too. The link building guide applies market by market: a German page with no German links is a page with no local reputation. Local directories, trade bodies, press and partners in each country are the starting point, and a digital PR story with a local angle lands better than a translated UK press release.

Some markets have search engines other than Google that matter. Where that is true, the local research in the first section will have shown it, and the technical and content work should account for that engine’s requirements rather than assuming Google’s documentation covers everything.

Tracking by market

Mixed international data hides everything. The UK may be growing while Germany falls, and the total looks flat. Set up measurement so each market is visible on its own.

• Search Console. The performance report groups data by country as one of its dimensions, with clicks, impressions, click-through rate and average position. For folders, add a property per folder (example.co.uk/de/) as well as the domain property; for ccTLDs, each domain is its own property.
• Analytics. In GA4, report by country and by landing-page folder, and set key events (purchase, enquiry) so each market’s traffic is judged by what it produces.
• Rank tracking. Track each market’s phrases from a location in that market, in that language. A UK-located check of a German phrase is meaningless.
• Hreflang monitoring. Re-crawl the hreflang map after every release. The commonest regression is a template change that drops the return links on one market’s pages.
• Indexing by market. Check that each market’s pages are indexed and that Google is showing the right version in each country, by searching from the market or checking the country filter against the landing page.

A launch sequence

1. Research the market: demand, language, local competitors, delivery feasibility, local engines. Decide go or no-go.
2. Choose the structure from the table above and decide language-only versus language-plus-region folders from the commercial reality.
3. Research local search terms in the language, from the country, and build the intent map for the market, one page per intent, as in the content guide.
4. Localise the content with a native speaker who knows the sector. Prices, delivery, legal, proof, contact.
5. Implement hreflang in the sitemap or the head, with self-references, return links and x-default. Self-canonical on each regional page.
6. Test before launch on a staging site that is blocked from indexing: crawl the hreflang map, check canonicals, check every page returns 200, check no IP-based redirects exist.
7. Launch and verify: Search Console property per market, sitemaps submitted, first crawl checked, the technical checklist run against the new sections.
8. Measure monthly per market and treat each as its own campaign, with its own links, content and reporting.

If you are moving an existing site to a new structure to accommodate international pages, that is a migration, with all its risks; the migration checklist should be run alongside this guide. Our international SEO service covers market research, structure, hreflang, localisation with native speakers and per-market reporting, and the review will tell you honestly if a market is not worth the build.