International SEO Technical Specs (+ Business Decision Insights)

Updated on: 
January 13, 2022
Tory Gray
Tory Gray

High-quality technical documentation is critical to ensuring solid web software.

With that in mind, we’d like to share our documentation for requirements for SEO Internationalization, so you can get a taste of what that looks like. Learn more about our recommendations for SEO Internationalization Best Practices - plus a QA checklist.

We’ve also included those critical decision points your brand should carefully consider - they impact SEO + Internationalization, as well as your development teams, marketing budget (etc.), and the potential efficacy of your efforts. 

Make these decisions carefully, weighing the costs and benefits to your own business as a whole - with full knowledge of the SEO implications.

International SEO Business Decision Insights

Language-Only, or Country + Language-Specific Considerations

It’s important to decide if you need country-specific targeting, or just language targeting, both in terms of the Domain Structure you choose and the page-level technical implementation.

Language-only targeting is simpler and easier. Can you add Spanish to your website, or do you need to differentiate between Spanish for users in Spain, the US, Mexico, etc?

Global brands, or brands subject to local rules and regulations, may prefer (or require) country and language targeting. 

Country-Specific Considerations


If you are targeting specific countries, be sure to do your research on those countries to determine: 

  • Any local rules and regulations you are legally required to follow for that area.
  • The major and minor search engines to target for that region.
  • Google isn’t the major search engine everywhere in the world. For example, if you want to break into the Chinese market, Baidu will be critical. Similarly, you may need to consider Yandex if you are targeting Russia. 
  • Don’t assume that the UX of your site in your core market applies to your international markets (applies especially to Asian and Middle-Eastern countries).

Region-Specific Considerations

For international SEO purposes (and Google purposes!), there is no such thing as “regional targeting.” Only the different combinations of languages and countries. 

This is especially important when implementing hreflang on your site (the key method for specifying language and country targeting to Google). Don’t attempt to target “eu” for the European Union, or “uk” for the United Kingdom (it should be “gb”, for Great Britain, when used in this context).

Same-Language Targeting in Different Countries

The more similar the languages are, the more complications arise. 

If you need to follow different rules and regulations (say, you offer different products or product variations in some places but not others, based on what’s legally allowable in those countries) you may have to have variations in the same (or very similar) languages.

But don’t expect to copy your American English product pages, set up a UK variation with some “u”s added here and there (e.g. color vs. colour), add hreflang to specify which is which and expect it to magically work out. 

This is still duplicate content, which generally results in a common problem: the .com variation outranks the variation - where the power of the .com is outweighing the geolocation signals. Learn more about the international SEO + duplicate content issue, and how to over come it.

For this reason, we strongly urge: 

  • Don’t do it if you don’t have to. 
  • If you do have to, ensure your localization work is top-notch. The more localization you do (and the less duplicate content you have), the better it will work. 

Localization work examples: 

  • Local currency 
  • Local address
  • Making the copy more localized and more unique - common phrases and terminology vary from country to country
  • Local imagery
  • Local experts as authors of strategic content
  • Local link building
  • Local time/weather (as appropriate) 
  • Local seasonality and holidays

Structural Considerations

There are 3 major architecture setup options for adding internationalization to your website. They include: 

ccTLD (country code top-level domains)

Examples: (UK), (Germany), (Mexico)

Recommended for: 

  • Brands where country-specific targeting (e.g. not just language targeting) is desirable, and/or a legal requirement (e.g. to meet local rules & regulations.)
  • Brands with the time, budget, and technical capabilities to maintain entirely different websites.
  • Brands with the marketing, SEO, and link building budget to support multiple websites.
  • Brands who want maximum SEO return and are willing to pay the associated costs (as outlined above).


  • Country-specific hosting is an option, which can improve site performance locally.
  • Maximizes country-specific ranking potential (assuming you are willing to pay the marketing costs to achieve that).


  • Tech complexity. 
  • Extra cost (tech and marketing setup and maintenance).


  • Depending on the country/language you are targeting, this could be a requirement or a strong recommendation. Alternatively, you may need a representative of your company living in the country to qualify to use the ccTLD. Learn more about ccTLD restrictions.
  • If you aren’t targeting specific countries, it’s simply unhelpful and unnecessary. 
  • Some ccTLDs are used so often as to become generic (gccTLDs,) e.g, .tv (Tuvalu). These are no longer useful for country-specific targeting.

Bottom line: If you have to, or can afford to, this can be a great option. 



Recommended for: 

  • Brands where language-targeting, not country-targeting, is the goal.
  • Brands who want less technical complexity, maintenance, and ongoing costs.
  • Brands who would prefer to leverage the power/equity of their existing domain internationally vs. maintaining multiple websites. 
  • Brands with smaller marketing, SEO, and link building budgets.


  • Simple and easy.
  • Cheaper.


  • Can create UX concerns, but they are surmountable with a good designer. 

Bottom line: 

  • The best solution for language-only targeting.
  • Good and workable solution for all use cases, making it (often) the default choice for SEO - especially when considering the costs of other solutions.



Recommended for: 

  • Brands where this setup is the only technically feasible option… it is what it is, and you can work around it. 
  • Just keep in mind that you’ll want a bigger marketing, SEO, and link building budget to support what are essentially multiple websites in the eyes of search engines. If you don’t have this budget, expect more middling results. 


  • (Often) less technically complex than setting up and maintaining ccTLDs and hosting. 


  • You’ll want a bigger marketing, SEO, and link building budget to support what are essentially multiple websites in the eyes of search engines.

Bottom line: The “good enough” solution.

URL Parameters:

Whatever your decision is, make sure that you align your international expansion with overall business strategies. A well thought-out digital strategy can make your business grow even more than you think!

International SEO Technical Specs

Site-wide Conventions and Configurations

The following are technical SEO specifications we recommend which affect the site at the root level or affect content across the site. 

Human-translate your content: 

All content must be translated into the language (or country-specific language) you are targeting. That includes: 

  • URL paths, where possible
  • ASCII characters, historically, were the only option for URLs. In other words, you couldn’t include Japanese characters in URLs.
  • Non-Latin alpha-numerical characters are technically possible in URLs, but this is much less common. Plus, special characters may not be easy to c+p, or share on social media.
  • We recommend ASCII characters for URLs at this time (eg use Roman characters to spell out words in that language.)
  • Metadata (the copy specified in page titles and meta descriptions)
  • Navigation headers, footers & all links
  • Text in images
  • Alt tags on images
  • Image file names
  • Header tags
  • Page copy
  • Anchor text for links
  • *** Note that this doesn’t mean all URLs on your site must be translated, rather, all pages that are translated should be fully-translated for all fields on those pages. We do recommend translating as much of your site as you can afford to. Not translating strategic content, or customer service answers, can create challenges for SEO and the users. 
  • Automated translations are specifically not recommended - for your international users, and for SEO.
  • Simply translating content is a (low) minimum bar. Transcreation is highly recommended, especially because the content users want at different locations may vary across the globe.

Not a “tech spec” but important: Ensure you understand what keywords you are targeting for each language/region. Translating the term alone may not be enough, as slang and terminology can vary greatly.

Specify what & where you are targeting explicitly for search engines & web browsers. 

That includes the following, in priority order:

Build internal linking pathways to international pages

  • Don’t: silo international pages in their own bubble, expecting hreflang to notify search engines about all your new page variations.
  • Instead, ensure you explicitly hyperlink the “international homepages” from your primary homepage.
  • Much like your primary homepage & navigation links to sub-pages, build crawl paths from the international homepage to international sub-pages.
  • Interlink between language variation pages as appropriate.
  • Don’t depend on “links” from a language dropdown that requires user interaction - that Googlebot can’t mimic

Hosting & Servers

  • International CDN servers (e.g. local to the target area) should be considered, where possible, to improve site performance for the user, and establish local context. 
  • If possible, host your site via a local IP address.
  • Never use IP sniffing to auto-redirect users to the “right” location. It’s a frustrating user experience (especially for people traveling, or near large borders), and Googlebot is “from” the US. Don’t accidentally bar them from accessing your foreign-language content. 

All valid language and country-targeted URL variations should self-canonicalize.

  • Google Search Console should be verified on each site (if there are multiple), or on each sub-folder (if you choose the 1 site solution.)
  • Create & submit XML sitemaps of international URLs via GSC.
  • If you are targeting specific countries, specify those countries in GSC (geotargeting) and look out for errors to be fixed, especially in your hreflang.

Maintain normal SEO tech requirements and best practices. 

(Not a “tech spec” but important): Build local external links to international variations. 

  • If you want to rank well in Germany, build links from the German community to your German pages.


Hreflang and Language Targeting Implementation Details

All 3 language specifications can be QA’d with Merkle’s international SEO testing tool

Specify Hreflang

  • Specify language-only, or language and country combinations. 
  • “en” or “es-es”
  • Ensure you specify the correct, indexable, full-path URL (e.g. the canonical URL)
  • Specify all variations - each language you are targeting
  • If you are targeting 10+ languages, we should talk about alternatives.
  • Ensure you are utilizing the correct country & language codes (e.g. “gb” not “uk” for targeting the United Kingdom.)
  • Ensure each page with hreflang refers to the other variations, and they, in return, refer to the starting tag (e.g. ensure correct cross-references. Avoid Return Tag errors.)


  • Implement hreflang via the HTML *and* the sitemap. It’s redundant, and Google recommends against it. 
  • Add hreflang to pages that are not indexed, or which canonicalize to other pages. Only valid, original pages should be indexed and optimized for internationalization.
  • Strong recommendation: include an x-default URL. The “default” URL is very likely the original URL variation, prior to you adding internationalization. 

Hreflang can be implemented via tags in the HTML (most common), http headers, or via your XML sitemap. Any of these versions works, however, the more countries/languages you target, the more you should lean towards a non-html solution (avoid code bloat and complexity.)

Hreflang via HTML

  • Add to the <head> section
  • List URL itself, and ideally all variations. If there are too many variations, list the most critical ones. 
  • Remember that any page you link to via hreflang should link back in turn. 

Example syntax for language only targeting: 

  • <link rel="canonical" href="">
  • <link rel="alternate" hreflang="es" href="">
  • <link rel="alternate" hreflang="de" href="">
  • <link rel="alternate" hreflang="en" href="">
  • <link rel="alternate" hreflang="x-default" href="">

Example syntax for language+country targeting: 

  • <link rel="canonical" href="”>
  • <link rel="alternate" hreflang="en-us" href="">
  • <link rel="alternate" hreflang="en-gb" href="">
  • <link rel="alternate" hreflang="es-es" href="">
  • <link rel="alternate" hreflang="x-default" href="">

Hreflang via Http Headers: 

  • Simply nest under existing <loc> tags for the URL in question. 
  • List any and all variations. If you have many variations, that’s a-okay - in this format, it’s easy to list them all.

Example Syntax:
<xhtml:link rel="alternate" hreflang="x-default" href="" />
<xhtml:link rel="alternate" hreflang="en" href="" />
<xhtml:link rel="alternate" hreflang="de" href="" />
<xhtml:link rel="alternate" hreflang="zh" href="" />

Hreflang via XML Sitemap

Serve the following syntax in the http header response for the page in question.

  • HTTP/1.1 200 OK
    Content-Type: application/pdf
    Link: <https://site/blog/name.pdf>; rel="alternate";hreflang="x-default",
    <https://site/blog/name.pdf>; rel="alternate";hreflang="en",
    <https://site/blog/de/name.pdf>; rel="alternate";hreflang="de",
    <https://site/blog/zh/name.pdf>; rel="alternate";hreflang="zh"

Specify HTML <lang> Attribute

Include the correct ISO language code in the <head> section via the following line of code. 

Example syntax variations:

  • <html lang=”en”>
  • <html lang=”es”>

Specify Content-Language

Choose whichever implementation method is the easiest to implement for you:

Http-equiv method (content-language meta tag)

Example syntax variations: 

  • <meta http-equiv="content-language” content=”en”>
  • <meta http-equiv="content-language” content=”en-us”>
  • <meta http-equiv="content-language” content=”es-es”>

HTTP header method

Example syntax variations: 

  • Content-Language: de-DE
  • Content-Language: en-CA

HTML <lang> Attribute

  • This one is super simple. Just specify the correct ISO language code in the <head> section via the following line of code: 
  • <html lang=”en”>, or <html lang=”es”>, etc. 

XML Sitemap Considerations


If you’ve chosen a ccTLD or Subdomain structure: 

  • Create a normal XML sitemap for all indexable pages for that domain. 
  • Once you’ve claimed GSC for the domain, submit the XML sitemap to it. 

If you’ve chosen a Subfolder structure: 

  • Create a dynamic XML sitemap file that lives in this folder of your site. 
  • Include all URLs specific to that language (and country, if applicable) in the sitemap
  • Ensure you follow XML sitemap best practices, including having it referenced in the robots.txt file or listed in your sitemap index file. 
  • Once you’ve claimed the GSC account for each folder, submit the XML sitemap to that property. 

Note: You can specify hreflang directly in your XML sitemap. 

We hope this technical documentation helps you with your own Internationalization roll out. If you need help with going international, please reach out!

Work With Us
We’ll help craft, teach, and carry out SEO roadmaps that check all the boxes.