Plan a multilingual website your team can maintain

Start with a visitor task, then choose the version

Suppose someone reaches a service page, reads the offer and tries to decide whether to inquire. Which part of that task is blocked by language, and which answer would change by region? Record the observed question, the existing page and the person who can check the answer. A search phrase or a list of countries is not evidence that every page needs another copy. If the need is unverified, mark it as such and investigate before committing to a publication schedule.

Google distinguishes a multilingual site, which offers more than one language, from a multi-regional site, which explicitly serves different countries or regions. A team may need both, one or neither. Translate selected pages when people need the same service explanation in another language. Add a regional version when a visitor needs materially different information, such as genuine availability, process, contact route or terms that the business can confirm and maintain. A regional label alone does not improve the answer. These are editorial decision tests, not thresholds prescribed by Google.

Give each published version a stable, reachable URL

Google recommends a distinct URL for each language version instead of serving different text at one address according to a cookie or browser setting. Its guidance compares country domains, subdomains and subdirectories; each has operational trade-offs, while URL parameters are not recommended for regional targeting. Choose a structure the team can deploy and maintain consistently. Keep useful existing addresses when their purpose stays the same, and map a changed address explicitly during a redesign.

Make every published version reachable through ordinary links, including a language or region switch that takes the visitor to the equivalent page when it exists. Do not force a visitor away from a page because an IP address or browser preference suggests another language. Google warns that automatic redirects and locale-adaptive content can hide variants from its crawler. A visitor may also be travelling, using a shared device or deliberately reading a different language. When no equivalent page exists, the switch should make the available destination clear instead of silently dropping the visitor on an unrelated homepage.

Copy this language-and-region decision worksheet

Use one row per proposed page and audience version. Copy the fields below into a shared document or spreadsheet; an honest “unknown” is useful because it exposes the next decision. Do not generate every country-by-language combination automatically. Publish a version only after its content, URL, review owner and release checks have an answer.

• Page and task: existing page URL; the visitor question and next action this page supports.
• Audience and evidence: language needed; country or region only if it changes the answer; actual inquiry, support or research evidence, or “unverified.”
• Difference and scope: same answer translated, materially adapted regional answer, or no separate version; which main content, navigation, form labels, validation messages and linked essentials need review.
• URL map: proposed stable URL; language or language-region code; existing equivalent URL; visible switch destination; sensible fallback if that page has no counterpart.
• Ownership: who owns shared facts, who writes or translates, who reviews the target language and region, who publishes, and who covers an absence.
• Change control: what source change triggers an update, where the translation request is recorded, how a correction is approved, and how long an inaccurate page may remain public.
• Decision and proof: keep current page, translate, regionalize or defer; direct URL and link checks, rendered language and accessibility check, alternate and canonical check, review date and named approver.

Hypothetical example: one service page in English and Hindi

Consider a hypothetical service business whose English page is https://example.com/services/. The team has verified a need for a Hindi explanation of the same service, and a named reviewer can maintain a complete Hindi page. It retains the English URL and proposes https://example.com/hi/services/. Both pages explain the actual service, form and next step in their respective languages. Nothing in this example establishes demand for Kinetivy or any real business; the audience evidence and URLs are invented for planning.

The URL map has an English row at https://example.com/services/ with language code en and a Hindi row at https://example.com/hi/services/ with code hi. On each page, the alternate links identify both fully qualified URLs, including that page itself: <link rel="alternate" hreflang="en" href="https://example.com/services/"> and <link rel="alternate" hreflang="hi" href="https://example.com/hi/services/">. The reciprocal set belongs on both pages. Each page also points its canonical link to its own stable URL. A visible switch links directly between the two service pages, and the document language is set to en or hi as appropriate.

The team does not add en-IN and hi-IN just because the business happens to operate in India: a country-specific label needs an intended regional audience and a reason to distinguish it. It does not add a UK page because no UK-specific service answer or owner has been established. If the Hindi reviewer becomes unavailable, the row changes to “defer” until a replacement can keep important corrections accurate. No translation is published merely to complete the URL map.

Use alternate links to describe real equivalents

For Google Search, hreflang describes language or region variations of the same page. It does not translate the page or guarantee indexing or a search position. Google accepts alternates in HTML, HTTP headers or a sitemap and says the methods are equivalent for Search; pick the one this site can maintain reliably. Every page in a set should identify itself and its equivalents with fully qualified URLs, and the versions must link back to one another. Link only pages that really answer the corresponding visitor task.

Use a language code such as hi for a language-wide page, or a language plus supported region code such as en-GB when that audience and version actually exist. A country code by itself is invalid for Google hreflang; en-UK and en-EU are not supported region labels. The optional x-default value can identify a fallback for an unmatched language, especially a language selector, but it is not a substitute for a useful page. Do not collapse fully translated pages onto the English URL with a cross-language canonical: Google advises a same-language canonical with hreflang where one exists, and recommends a self-referential canonical on the chosen page.

Keep facts and language access in sync

A translation is an ongoing publication, not a launch-day file. Choose one owner for each fact that can change across versions: service availability, eligibility, contact path, form instructions and policy or terms links. When that fact changes, the owner records which versions are affected, sends the change to each language reviewer and checks the published pages after approval. Give urgent corrections a route that works when the usual reviewer is away. If the team cannot maintain a version, defer it or clearly withdraw it rather than leaving a confident but stale answer.

The visible page language matters to both visitors and Google. Google says it determines language from visible content rather than the HTML lang attribute and warns against translating only navigation while leaving most main content in another language. HTML lang still matters for accessibility: WCAG 2.2 requires the default page language to be programmatically determinable at Level A and passages in another language at Level AA, with defined exceptions. Set the document language and mark meaningful language changes within the page; check form labels, errors, link text and the switch with a target-language reviewer and keyboard or screen-reader use.

Release a version only when the whole journey works

Before release, visit each proposed URL directly and through its switch link. Check that the main answer, navigation and form journey are genuinely usable in the promised language; the destination fits the same task; the page remains accessible without a forced locale redirect; and the canonical, hreflang and sitemap list only intended public versions. Inspect the rendered HTML, not just a configuration screen. Test narrow screens, keyboard operation, page language and any foreign-language passages. Record who approved the words and who will correct them later.

Defer a version when the need has not been established, the main answer is only partly translated, a regional distinction is merely a changed place name, the service facts cannot be verified, or there is no reviewer and correction process. The small-business website brief owns the overall audience and project scope; the service content map decides which services deserve distinct pages; the CMS decision guide chooses an editing method; and the handover checklist verifies account and asset control. This guide owns the narrower version-by-version language, URL and maintenance decision.