Chapter 26: How to Do SEO for Multiple Countries

Last updated: November 1, 2026.

Translating a site into English, German or Arabic is not international SEO.

The real issue in international SEO is this:

Sending the right user to the right URL, with the right language and regional version.

That’s why the job isn’t just translation. Technical structure, hreflang, URL architecture, country targeting, content localization and keyword research all have to be thought through together.

1. A multilingual site and a multi-regional site are not the same thing

Google treats these two structures separately.

A multilingual site offers content in more than one language. For example:

• Turkish
• English
• German

A multi-regional site offers content tailored to users in different countries or regions. For example, your content may all be in English, but you can offer:

• Different prices for the US
• A different currency for the UK
• Different shipping for Canada
• A different product range for Australia

A site can be both multilingual and multi-regional at the same time. In Google’s own example, there can be English and French versions for Canada and a separate English version for the US. Google for Developers

2. Don’t mix up language and country targeting

This is where mistakes often happen on the coding side.

For example, we can use tr for Turkish. For Turkish content aimed at Turkey, we can use tr-TR. The first part is the language, and the second, optional part is the region.

Google states clearly that in hreflang values the first code must be an ISO 639-1 language code and the second, optional code must be an ISO 3166-1 Alpha 2 region code. Google for Developers

So tr-TR is correct. But by the same logic we can’t write en-EN, because there is no country code EN.

For English content, you could use, for example:

• en: English, regardless of region
• en-US: English-speaking users in the US
• en-GB: English-speaking users in the United Kingdom
• en-AU: English-speaking users in Australia

Google’s own hreflang examples use values like en-US, en-GB and de. Google for Developers

I think this is a detail that looks small but matters. During development, a developer may think, “We have tr-TR, so English should be en-EN.” That’s wrong.

Language codes and country codes should follow the standards, not be guessed from memory.

3. We don’t have to specify a country for every language

This is important too.

If your English content serves all English speakers in the same way, hreflang="en" may be enough. But if the content differs for the US and the UK, it makes sense to separate them as en-US and en-GB.

For example, both pages may be in English, but the US page may use:

• Dollars
• US shipping
• US terminology

And the UK page:

• Pounds
• UK shipping
• British terminology

Google also recommends using hreflang for pages in the same language with different regional variations. Google for Developers

4. What is hreflang?

Hreflang is an annotation that lets us tell Google about the other language or regional versions of a page.

For example, the same page might have these versions:

• Turkish
• English, US
• English, UK
• German

In the HTML, it might look roughly like this:

<link rel="alternate" hreflang="tr-TR" href="https://site.com/tr/urun" />
<link rel="alternate" hreflang="en-US" href="https://site.com/us/product" />
<link rel="alternate" hreflang="en-GB" href="https://site.com/uk/product" />
<link rel="alternate" hreflang="de-DE" href="https://site.com/de/produkt" />

This way we tell Google that these URLs are language or regional variations of each other.

5. Is hreflang a ranking factor?

I think this is the right way to look at hreflang:

We use it not to push rankings up, but to show the right version to the right user.

For example, we may not want to show the UK page to a user in the US. Even if the English is the same, these can differ:

• Currency
• Shipping
• Tax
• Phone number
• Address
• Product stock
• Promotions

Hreflang helps Google understand these variations. Google recommends hreflang to help show users the right language or regional version. Google for Developers

6. Hreflang has to be reciprocal

This is one of the most common mistakes.

If page A lists page B as an alternate, page B also has to list page A.

For example, the Turkish page has hreflang="en-GB". But the English page has no return link to the Turkish page. In that case, the hreflang set is incomplete.

Google explicitly lists missing return links as one of the common hreflang errors and says these annotations may be ignored. Google for Developers

In short:

If TR → EN exists, EN → TR must exist too.

7. A page should also list itself in hreflang

In an hreflang set, you need to list not only the other languages but also the current page itself. Google requires this.

For example, the Turkish page might include:

• tr-TR: itself
• en-US: the US version
• en-GB: the UK version
• de-DE: the German version

That way all the variations form a single set.

8. What is x-default?

Sometimes we don’t have a specific page that matches the user’s language or region. In that case we can use hreflang="x-default".

Google uses it to indicate the default version for users who don’t match any language or region. It can be especially useful on country or language selector pages. Google for Developers

For example:

<link rel="alternate" hreflang="en-US" href="https://site.com/us/" />
<link rel="alternate" hreflang="en-GB" href="https://site.com/uk/" />
<link rel="alternate" hreflang="x-default" href="https://site.com/" />

Here the homepage could be a general page that directs the user to choose a country or language.

9. Don’t confuse hreflang with canonical

This is important.

A canonical says:

“Among these similar URLs, this is the main URL I prefer.”

Hreflang says:

“These are the different language or regional versions of this page.”

For example, the US and UK pages may be very similar. But if each one serves a separate audience, each page’s canonical should usually point to itself. Then they should be connected to each other with hreflang.

Google recommends using canonical and hreflang signals correctly together when multi-regional sites have similar content. Google for Developers

A setup like this is usually wrong: the US page says canonical → UK but also says hreflang en-US → US.

On one hand we’re saying, “The main page is the UK one.” On the other, we’re saying, “Show the US page to US users.”

Technical signals should not contradict each other.

10. Is translation alone enough?

I think this is one of the biggest mistakes in international SEO.

We take the Turkish page and translate it into English. Then we say, “English SEO is done.”

But as we said earlier about keyword research:

Translating is one thing; keyword research is another.

A product may be searched for with one word in Turkey, another in the US and yet another in the UK. Terminology can even change within the same language.

For example, English has regional usage differences like these:

• vacation / holiday
• apartment / flat
• truck / lorry

The same applies to products. Translating a Turkish keyword into English doesn’t tell us how people actually search.

That’s why, whenever possible, we need to do these again for each country:

• Keyword research
• SERP analysis
• Competitor analysis
• Search intent analysis

11. Localization and translation are not the same thing

Translation answers the question, “What is this text in another language?” Localization answers, “Is this content really right for the user in that market?”

For example, these may also need to change in the content:

• Currency
• Date format
• Units of measurement
• Phone number
• Address
• Delivery information
• Tax
• Return policy
• Legal texts
• Images
• Product variants
• Promotions
• The examples used

If the page you prepared for the US shows prices in euros, sizes in centimeters, a Turkish phone number and delivery information only for Turkey, the fact that you translated the text into English doesn’t mean much.

12. Is a Turkish user in Turkey the same as a Turkish user in Germany?

Not always.

For example, tr-TR can target Turkish-speaking users in Turkey. Turkish users living in Germany, depending on the business model, may need a separate experience.

The page may still be in Turkish, but it might have:

• Prices in euros
• Delivery to Germany
• German regulations
• A local phone number
• Local stores
• Germany-specific promotions

In this case, technically, you can use a Turkish + Germany combination like tr-DE. Google allows these language + region combinations. By the same logic, de-ES can be used for German speakers in Spain. Google for Developers

But I’m not saying “let’s open a separate page for every country no matter what.” It makes sense when there’s a real content or commercial difference.

13. How do we set up the site structure?

There are three structures that come up most often for international sites.

Country domain (ccTLD)

For example site.de, site.fr, site.co.uk.

Its biggest advantage is that the country target is very clear to both users and search engines. Google treats ccTLDs as one of the strong country signals. Google for Developers

But these can make things harder:

• Domain costs
• Separate technical management
• The need to build SEO authority separately
• Domain registration requirements in some countries

Subdomain

For example de.site.com, fr.site.com, uk.site.com.

It can be easy to keep separate from a management point of view. You can use different applications, teams or infrastructure.

Subdirectory

For example site.com/de/, site.com/fr/, site.com/uk/.

Because you work under a single domain, it can be easier to manage.

Google states clearly that both subdomain and subdirectory structures can be used; it lists both as valid URL architectures for multi-regional sites. Google for Developers

14. Subdirectory or subdomain?

My practical approach here is a little different.

Technically, Google supports both subdirectories and subdomains and presents both as valid options for international targeting. Google for Developers

But from a project management perspective, I usually think of it like this:

A subdirectory is more like a continuation of the existing site.

site.com/de/ feels like the German section of the same site.

A subdomain can be managed operationally more like an independent site.

de.site.com can run on a separate application, a separate server, with a separate team or a separate technical setup.

Saying “Google definitely treats a subdomain as a separate site” would be too absolute. But in practice, since you can set up a subdomain’s technical and content management more independently, thinking of it as a separate site sometimes makes things easier to understand.

In most projects, unless there’s a technical or organizational requirement, I find the subdirectory structure simpler. For example, site.com/tr/, site.com/en/, site.com/de/ are easier to manage for both the team and the user.

But there’s no single correct architecture for every project.

15. Does having /en/ in the URL tell Google the page is in English?

Not on its own. This is another important detail.

Google says clearly that it doesn’t use strings like en, de or en-gb in the URL or subdomain to automatically determine a page’s target audience. You need to state the target language and region explicitly through the content, hreflang and other signals. Google for Developers

So using en.site.com or site.com/en/ can make sense architecturally. But you shouldn’t say, “The URL says en, Google will figure it out.”

16. Is it right to automatically redirect users based on IP?

You need to be careful here.

For example, seeing a Turkish IP and forcing the user to the Turkish site can cause problems. The user may be in Turkey but want to see the English version. They may be using a VPN. Googlebot can also come from different locations.

Google recommends avoiding automatic redirects based on IP or the user’s perceived language and offering users links to switch between language or regional versions. Google for Developers

I think the healthiest approach is to show a suggestion like “Would you like to go to the Turkey site?” without forcing the user.

17. Each page should be entirely in one language

This is another point Google specifically draws attention to.

For example, a page like this is not a good user experience:

• Menus in German
• Content in English
• Footer in Turkish

Google also recommends using mostly one language in each page’s content and navigation. Translating only template areas like the menu and footer while leaving the main content unchanged can cause problems. Google for Developers

18. What if you don’t sell the same products in every country?

At this point international SEO turns into e-commerce SEO.

For example, you have 500 products in Turkey. Only 300 of them are sold in Germany. In the US, there are 200 additional products.

Trying to use the same sitemap and the same category structure in every country may not be right. For each market, these should match the real setup:

• Product stock
• Categories
• Prices
• Currency
• Delivery
• Tax
• Promotions

Just because we point Google to alternate pages with hreflang doesn’t mean we have to copy a product that doesn’t exist into another country.

19. International backlinks and authority

A site may be very strong in Turkey but completely unknown in Germany.

In the local market, these may be different:

• Local publications
• Industry sites
• Local business partners
• News sites
• Associations
• User reviews

Google also says that when determining country targeting, it may use additional signals like a local address, phone number, currency and links from other local sites. Google for Developers

So international SEO isn’t just preparing an hreflang file. It’s about having a real presence in each market.

20. How should you use Search Console and Analytics for international SEO?

Tracking all traffic as one total number doesn’t tell you much.

For example, we can look separately at:

• Organic traffic from Turkey
• Organic traffic from Germany
• Organic traffic from the US
• Organic traffic from the UK

Then we can ask questions like:

• Which queries are coming in?
• Which landing pages are getting traffic?
• Is the wrong country URL ranking?
• Is the Turkey page showing up for queries in Germany?
• Which country has the highest conversion rate?
• Which country has impressions but no clicks?

The wrong local URL ranking, in particular, can help us spot hreflang or site structure problems.

21. How do we check for hreflang errors?

I would specifically look at these:

• Are the language codes correct?
• Are the region codes correct?
• Are there invalid combinations like en-EN?
• Are return links missing?
• Do pages list themselves?
• Do canonical and hreflang contradict each other?
• Are there URLs returning 404s or redirects in the hreflang?
• Are noindex pages being used?
• Are HTTP and HTTPS mixed?
• Is x-default in the right place?
• Does every variation list the alternates in the same set?

On large sites especially, a small template error can affect tens of thousands of pages. So checking a few URLs manually may not be enough. You may need to use a crawler.

22. A common hreflang mistake: guessing the code

I want to come back to this because, in practice, it’s a very easy place to make a mistake.

Because Turkey is tr-TR, a developer may naturally write en-EN for the UK. But since the first code is the language and the second is the region, the correct UK example is en-GB. Other examples:

• US: en-US
• Australia: en-AU
• Canadian French: fr-CA
• Brazilian Portuguese: pt-BR
• European Portuguese: pt-PT

That’s why I think a good check for international sites is to map out the country and language pairs in a table before coding them.

23. How do I get started with international SEO?

I would go roughly in this order:

• Which countries are we targeting?
• Which languages will we use?
• Is the product/service the same in every country?
• Do we need different regional versions of the same language?
• Has separate keyword research been done for each country?
• Who are the competitors?
• What will the URL architecture be?
• ccTLD, subdomain or subdirectory?
• What’s the hreflang plan?
• Is the canonical structure correct?
• Are the currency and local details correct?
• Is the content just translated, or localized?
• Are there local backlinks and brand signals?
• Can countries be tracked separately in Analytics and Search Console?

After that, implementing hreflang is much easier. Because the code isn’t the hard part.

The hard part is deciding which page is right for which user.

In short

You shouldn’t treat international SEO as “Let’s translate the site into English.” Even in the same language, the user experience can change from country to country.

English can be en. But when needed, it can be split into en-US and en-GB. Turkish can be tr. For a Turkey target, tr-TR can be used. So deriving hreflang codes from memory can lead to errors.

There’s no single correct method for site architecture either. Google supports both subdirectories and subdomains. Still, in most projects I find it useful to think of a subdirectory as a natural continuation of the existing site and a subdomain as a more independent structure from a management point of view.

And maybe the most important sentence in this chapter is this:

International SEO is not translation work; it’s market work.

It starts to mean something when the right language, the right country, the right search behavior, the right price, the right product, the right URL and the right technical signal all come together.

Translating a page into another language may take a few minutes. But being genuinely findable in another market takes much more comprehensive work.

Previous: Chapter 25: How Can Google Understand Your Page Better? · Contents · Next: Chapter 27: Why Does Google Trust Some Sites More?

This chapter was first published in Turkish on X (September 30, 2026).