Are you targeting a language or a market?
Language and market are not the same thing. English-speaking visitors may come from several countries with different offers, while a single country may need pages in more than one language. Start by listing what genuinely changes between your audiences: whether the service is available, terminology, currency, delivery terms, support hours.
That list tells you which versions need pages of their own. If only the language differs, one version per language is usually enough. If the offer, the terms or the legal conditions differ, a separate country version may be justified. Choosing between these options is part of international SEO.
Then choose a URL structure the team can maintain, whether subfolders, subdomains or separate domains, and document how equivalent pages map to one another. Remember, too, that a translated page still has to answer the local visitor’s actual question. A literal translation of a page written for another market rarely does.
How will visitors find their language version?
Give each maintained language version its own URL and a visible switch that leads to the equivalent page, not to the home page of the other version. Within each version, internal links should stay in the same language.
Check that hreflang annotations are reciprocal: if page A points to page B, page B must point back to page A, otherwise Google ignores the pair. Each page should also reference itself, and canonical tags should point to the same language version, never across languages.
Avoid redirecting visitors automatically based on their assumed language or location. They may have chosen the page on purpose, and Google’s crawlers could miss the versions they are redirected away from. If an offer is not available in a market, say so honestly on the page; do not let the visitor discover it at the last step of an order.
Who looks after each version?
Assign a person responsible for each market’s terminology, commercial facts and update cycle. Without that, the main version moves ahead while the others quietly fall out of date.
Keep a record of which changes to the source page need only translation and which need a local decision, such as new terms or a service that is not offered in one country. Test navigation, forms, emails and downloadable files in the same language as the page: a Russian page with an English-only form breaks the journey just as surely as a broken link.
Evaluate search performance by market and page type over comparable periods. A global total can look stable while one country is steadily losing visibility.
Language-version acceptance sheet
A template to adapt to your own project.
| Check | Acceptance evidence |
|---|---|
| Equivalent-page switch | Both versions open the intended counterpart. |
| Language annotations | Reciprocal, self-referencing hreflang points to the maintained URLs. |
| Local offer | Availability and terminology are approved for the market. |
| Complete journey | Navigation, forms and materials match the chosen language. |
Checklist: international structure
- Document language and country requirements separately.
- Check that each language switch opens the equivalent page.
- Verify reciprocal, self-referencing hreflang annotations.
- Review local offers and terminology with a responsible person.
- Measure each market with the same definitions.
Example: an English and a Russian version
An English service page and its Russian counterpart cover the same task and scope and are linked by a direct language switch. Their hreflang annotations point to each other, and each page references itself.
A possible future offer for a specific country would get its own page only if availability or delivery there differed in a meaningful way. Meanwhile, the team keeps a translation matrix so that any change in scope reaches both maintained versions.
