Editorial guide

In brief

A multilingual site plan brings together the audience, accessible URLs for each language, correct page relationships and sustainable content management. Translating the text is one part of that plan.

In this article

Separate language from country targeting

Publishing in English and serving a particular country are different decisions. First establish which audience you want to reach and with which product or service. Even when two markets share a language, service scope, units, communication expectations and examples may differ.

Google defines a multilingual website as one that provides content in more than one language, and a multi-regional website as one that explicitly targets different countries. A site can do both. Multilingual and multi-regional websites

Prepare a content inventory for each language. Which pages have direct equivalents, which only make sense for one market, and which are not ready yet? Keeping these situations separate reduces incorrect assumptions when pairing pages.

Plan an understandable address for every language

Google recommends using different URLs for language versions instead of changing the language only through cookies or browser settings. Readers should be able to switch languages using links. Automatic redirects can make some versions harder to access. Managing language versions

For a small website, a pattern such as /tr/hakkinda/ and /en/about/ could be understandable. This example is not a universal recommendation: existing domains, team capacity and market plans should be considered together.

Include navigation and internal links in the plan. A link from an English service page that unexpectedly leads to Turkish content may work technically while creating an incomplete user experience.

Match hreflang relationships correctly

Hreflang describes language or regional versions of the same content. Google’s guidance says that each version should list itself and the other versions, with reciprocal relationships. Addresses must be fully qualified, including the protocol. These relationships can be declared in HTML, HTTP headers or a sitemap. Localised versions guidance

If an article has no equivalent in another language, pairing it with that language’s home page does not establish the correct content relationship. Identify the matching content first, then produce the technical declarations.

A tracking table can hold the source URL, equivalent URL, language code and publication status together. This is especially useful when different languages follow different publishing schedules.

Follow the experience after launch

The work continues after a language version launches. Content updates, navigation changes and removed pages can affect its relationships with other languages. It helps to assign someone to review the mapping after important changes.

  • Can visitors choose their language?
  • Are the title, main content and navigation in a consistent language?
  • Does switching languages lead to the equivalent content?
  • Are there links to translations that are not published?
  • Are contact and service details appropriate for the market?

This checklist is an implementation suggestion. A sound multilingual structure combines technical relationships with a complete, understandable journey in each language.

Sources

Sources checked on 24 September 2026. This is an editorial guide based on official documentation.