The short answer
If you sell inside Estonia, English alone is not enough. You need Estonian as well, and you add a third language only when there is measurable demand behind it and the resources to run it properly.
The point most people miss: Estonia does not have one set of search results, it has three running in parallel. Estonian, Russian and English are different audiences, different phrasings and - most importantly for a budget - different levels of competition. The same service can be crowded in Estonian and nearly empty in Russian.
So "which language should I target" is really the question "what does a visitor cost me in each of these three markets".
How Estonia's language audience is split
According to the 2021 census, about two thirds of residents name Estonian as their native language and roughly 30% name Russian. That is not abstract statistics but a direct consequence for search: a significant share of the country's population looks for goods and services in a language other than the state language. English speakers are a real audience too, but a much smaller and more specific one.
The distribution is also uneven:
| Region | What it means for your site's language |
|---|---|
| Tallinn and Harju county | Both local audiences are large; two versions usually pay off |
| Ida-Viru county (Narva, Kohtla-Järve) | The Russian-speaking audience dominates; the Estonian version serves mainly B2B and public bodies |
| Tartu, Pärnu, the south and west | Estonian is the main language; a Russian version is rarely justified |
| International audience | Tourists, foreign specialists, e-residents, cross-border B2B - English only |
This is where e-residents and newly arrived founders tend to misjudge the market. Running the company in English feels natural, so the site stays English-only and the assumption is that anyone who matters will find it. In practice an English-only site reaches the expat bubble and the international B2B layer, and is invisible to the majority of local demand. English is the right primary language when your customers are genuinely outside Estonia or genuinely international inside it - not by default.
Why translating pages does not work
This is the most common and most expensive mistake. The logic looks sound: we have good English pages, we translate them into Estonian and we have a second version of the site.
You do not. The reason is that a search query is not a meaning, it is a specific wording. People describe the same need with different words in different languages, at different levels of detail and with different qualifiers. A literal translation preserves the meaning and loses the wording - and a page ranks on the wording.
In practice the difference looks like this:
- Translation: take the English text, translate it, publish. The page describes the service correctly, but does not contain the word combinations people actually type into Google in Estonian.
- Adaptation: collect queries in Estonian from scratch, look at what is actually being asked, and write the page around those phrasings. Same meaning, different structure and emphasis.
The difference in effort between the two approaches is small. The difference in outcome is fundamental.
A note on AI translation. As a tool it has become genuinely decent, and for utility pages - privacy policy, terms, delivery - it is enough. But it translates text, it does not rebuild the semantics. Pages you intend to rank still have to be built around the queries of their own language.
When a second version pays off and when it does not
A second language version is not "a bit more content" - it doubles the work: its own queries, its own pages, its own content, its own backlinks, its own reporting. Before starting one, it is worth answering three questions honestly.
- Is the demand there in numbers? Not "a lot of our customers are Estonian", but how many queries per month for your service are formulated in that language. This is verifiable before any work begins.
- Do you have the resources to keep it running? An abandoned second version is worse than none: it eats crawl budget, goes stale and undermines trust in the site.
- Who answers the customers? If an enquiry arrives in Estonian and nobody can reply in Estonian, you are paying for traffic you cannot process. It sounds obvious, but this is exactly where second versions usually fall apart.
My practical rule: if the budget only covers one direction in full, it is better to do one language well than two halfway. The same logic applies to choosing between paid and organic - I went through it in the article on whether to start with Google Ads or SEO.
The technical parts that break most often
A multilingual site adds several places where you can create a problem out of nothing.
| What breaks | How it shows up | What to check |
|---|---|---|
| Hreflang is not reciprocal | Google ignores the markup entirely | Every version links to all the others and to itself |
No x-default | Unclear what to show for an undetermined language | A default version is specified |
| Link to a version that does not exist | Hreflang points to a 404 | Every listed URL genuinely exists |
| Automatic redirect by browser language | Googlebot only ever sees one version | Language is offered, not forced by redirect |
| Mixed languages on one page | Google cannot determine the page language | Menu, buttons and labels are fully translated |
| Cannibalisation within one language | Two pages fight for the same query | One page = one intent within a language |
Two things are worth stating separately.
Different language versions are not duplicates. There is no penalty for them and nothing to be afraid of. What is dangerous is cannibalisation within one language, not between languages. Half-translated template fragments, however, are a real problem: in my teardown of Estonian affiliate sites I found a site whose entire legal footer had been left in Latvian — across every page type at once.
Hreflang is a hint, not a command. Google takes it into account but may still show a different version if it considers that one more suitable. Correct hreflang is hygiene, not a lever for rankings - I covered how to set it up and check it without the common mistakes separately.
How to choose the site structure
The most common question after "which language" is "where do I put it". There are three options.
- Folders on one domain (
example.ee,example.ee/et/,example.ee/ru/) - the working choice for the overwhelming majority of businesses in Estonia. All the domain's accumulated authority works for every version at once. - Separate domains (
example.ee,example.com) - worth it when you enter another country with a separate legal entity, pricing and logistics. Each domain has to be promoted from zero. - Subdomains (
et.example.ee) - a compromise that in practice rarely beats folders and adds technical work.
If you are only building the site now, put the language structure in from the start - migrating from subdomains to folders later means mass redirects and a drop lasting several months. This is exactly the case where a decision made during web development saves budget for years ahead.
What to do right now
Three steps that give you an answer for your niche rather than in general.
- Look at where people come from today. Search Console has a breakdown by country and by query - it shows which language people already find you in and which phrasings bring visitors.
- Collect queries separately for each language. Do not translate your list, rebuild it. The difference in demand volume between the English, Estonian and Russian results in your niche is the answer to the original question.
- Check that the second version is not technically broken. If you already have one, start with hreflang, redirects and the completeness of the interface translation - often a second version fails not because the language is wrong but because Google barely sees it. Those things surface first in a technical SEO audit.
If the picture still has not come together after these three steps, write to me. I will go through your niche across all three languages and tell you where the demand actually exists and where you would have to create it with ads.
