Multilingual SEO : A Primer

Note: this article focuses on long-form web content : marketing site, help center, and landing pages. In-product localization and UI strings are covered in the engineering articles.

How Do You Surface Languages To Users? URL Architectures To Consider.

You will generally have three choices in how you surface language to users: subdirectories, subdomain or TLD (top level domain), Each option has tradeoffs.

Subdirectory (The Best Option For Startups)

This is a widely used pattern where a URL is suffixed with a locale code in a subdirectory, such as {yourdomain}/en-GB/Hello-World

This is easy to parse, supported by multiple CMS platforms, and is easy to share. This approach consolidates domain authority because subdirectories identify assets as children of parent assets.

Subdomain (OK, But Comes With A Rank Authority Hint)

Another option is to use subdomains to signal language intent, for example en-GB.{yourdomain}/Hello-World

This approach is less widely used because search engines treat each subdomain as a new site, with an associated hit to rank authority. Translation proxy services such as Motion Point and Smartling’s GDN prefer this approach for technical reasons.

Country Specific TLD (Good For Scaling Companies)

This option is good for scaling companies that have in country sales and marketing staff who want to deliver locally relevant content to visitors, not just a translation of the English website. This is where choosing the right CMS is so important.

A CMS that has a modular information architecture makes it possible to create pages from “LEGO blocks”, so of which might be used globally, and some of which might be used in local markets.

This is one of the reasons choosing a global-ready CMS matters; we discuss what to look for in our CMS selection article.

I like to use the example of customer brands. If you are operating in Japan, you probably want to display brands and customer stories that are relevant to your market, along with a few brands that are globally known. This landing page might look like the following:

			
[Home Page]
  [Welcome To ABC Company]
  [What We Do]
  [Local Brands]
  [Global Brands]
  [Sign Up]

		

The [Local Brands] block contains customer stories and logos relevant to Japan, which might not even have translations in other languages, while everything else on the page is translated or transcreated from the source language.

You can also do this with the other language signalling methods. The main reason for going with country TLDs is to give local teams more control over what is presented to users, especially if the company’s brand, design or product offering is significantly different.

Hreflang : A Common Source Of Errors

Hreflang is a HTML tag that tells search engines “this page is the French version of that English page.” It is widely misimplemented. Common mistakes include:

Forgetting the x-default tag
Not making hreflang bidirectional (both pages should reference each other)
Using the wrong locale codes (e.g. fr-CA instead of fr-FR)
Not updating it when URLs change

Examples are shown below:

			
<!-- German for Germany -->
<link rel="alternate" hreflang="de-de" href="https://example.com/de/" />
<!-- German for Austria -->
<link rel="alternate" hreflang="de-at" href="https://example.com/at/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />

		

A good CMS will handle a lot of this for you.

Localized Keyword Search Versus Translated Keywords

Another thing to consider is how to adapt metadata that is used for SEO (title, description and keywords). These affect how a page is displayed in search results and keyword matching.

One mistake companies make is to translate these fields literally, without considering local search patterns. For example, the term people use when searching for “project management software” may be different than a literal translation.

These fields are usually short, so it makes sense to have people with local knowledge handle these. I like to route them to a transcreation agency since they have high awareness of these issues.

With a good CMS and TMS combo, you can easily set up automation to route all content tagged as metadata to that workflow.

Localized URLs and Slugs

Some CMS platforms will allow you to localize URLs and slugs. I generally advise against this because it can break automated QA testing and can also be a curation nightmare.

For example, when a QA agent runs a test suite against a URL to verify it is working, with untranslated URLs it can loop through the supported locales, simply by adding the locale subdirectory to the URL. With translated URLs and slugs, the QA agent needs to know each language variant. While this is possible to automate, it’s easy to break. Unless there is a compelling reason to translate URLs, just use translated link text in <a> tags.

Content Quality Signals By Language

Search engines also consider language quality when ranking pages. They can detect machine translation which often has unnatural phrasing and minor grammar errors. Here it is important that high visibility, high impact assets like landing pages go through human review. It’s ok to automatically translate low visibility assets, but landing pages, sign up funnel and other assets like testimonials should be reviewed.

Local Link Building

Inbound links are an important factor in search ranking in other languages. The page rank algorithm that was the basis for Google search was based on how many sites linked to a page. People figured out how to game this, but it is still a core factor that modern search tools consider.

This is where active user communities can really help you out. At Notion, we had a small army of brand ambassadors and consultants who were happy to link to us, which was a good way to boost search visibility in many markets. Local PR and marketing are also a key part of this.

Implementation Checklist

You’ll need to do the following to implement a good multilingual SEO strategy:

URL structure decision (in most cases subdirectory based is best)
Hreflang implementation with x-default and bidirectional references (ideally auto-generated by the CMS)
Sitemap localization (either with a separate sitemap for each language or a master sitemap that references translated sitemaps)
Make sure metadata is transcreated and not literally translated
Ensure language-specific pages have self-referencing canonical tags, not the English version.
Consider page speed. CDN coverage matters. A page that loads quickly in the US may be slow in Japan.
Google Search Console (verify each language property separately)

What NOT To Do

Don’t use a single page with Javascript language switching (search engines typically only crawl and index a single version)
Don’t automatically redirect users based on language preference without presenting an override (this breaks sharing)
Don’t use AI or machine translation on pages you want to rank. Search engines can detect this, and it is a quality signal.
Don’t treat international SEO as a one time setup. It requires ongoing maintenance like other content.