International SEO for small teams: a practical plan

International SEO is the work of making each language or country version of your site findable by the people it is for, in the search results they use. For a small team the plan is short: pick one or two markets you can actually serve, give each version its own URL, tell search engines how the versions relate, write the pages people in that market search for, and measure each market on its own.

Step 1: decide whether you are targeting languages or countries#

Google draws the line clearly. "A multilingual website is any website that offers content in more than one language," and "a multi-regional website is one that explicitly targets users in different countries." The two often overlap, and they lead to different setups.

If you sell the same thing in the same way everywhere, you are targeting languages. One Spanish version can serve readers in Spain, Mexico and Argentina, and one French version serves France, Belgium and Quebec. If prices, products, shipping or legal terms differ by country, you are targeting countries, and two countries that share a language may each need their own version.

Most small teams should start with languages. A country version commits you to local prices, local contact details and local terms, so take one on only for a market where you can keep those up.

Step 2: choose markets you can serve#

Pick markets from evidence you already have: countries that show up in your analytics or in your sales, languages your support inbox already receives, and partners who could sell for you there. Then check the search side with international keyword research, done separately for each market, because a translated keyword list rarely matches what people in that market type.

Each version needs someone who can review its text, answer its visitors and notice when it breaks. If you cannot name that person for a language, that language can wait.

Step 3: give every version its own URL#

Google recommends "using different URLs for each language version of a page rather than using cookies or browser settings to adjust the content language on the page". A page that changes language on the same URL gives a search engine one page to index, in whichever language it happened to see.

The reason is in how the crawler works. Google's page on locale-adaptive sites says "the default IP addresses of the Googlebot crawler appear to be based in the USA" and that the crawler "sends HTTP requests without setting Accept-Language in the request header". It also crawls from addresses outside the USA, and Google still recommends "separate locale URL configurations" annotated with hreflang. A site that guesses the language from the visitor's IP or browser will mostly show Googlebot one version.

Google's documentation lists four URL structures:

For a small team the subdirectory is usually the right default: one domain, one host, one set of links pointing at it. A country domain makes sense when you already own it, run a separate business in that country and can maintain a second site. Our article on subdomains, subdirectories and country domains goes through the trade-offs in detail.

Step 4: send the signals search engines read#

Google uses the text on the page to decide what language it is in. Its documentation says so directly: "Google uses the visible content of your page to determine its language. We don't use any code-level language information such as lang attributes, or the URL." Google suggests "using a single language for content and navigation on each page". A French page with an English menu and an English footer gives a mixed answer, so translate the whole page, the parts in the theme included.

For the relationship between versions, use hreflang. Google's rule is that "each language version must list itself as well as all other language versions", and the reserved x-default value covers visitors whose language matches none of them. The hreflang guide has the syntax and a checklist. Pair hreflang with a canonical on every version that points at that version itself, so search engines do not fold the languages together.

For countries, Google lists the signals it combines: a country-code domain, hreflang, server location, and other signals that "can include local addresses and phone numbers on the pages, the use of local language and currency, links from other local sites". It also says it "ignores locational meta tags (like geo.position or distribution)". There used to be a setting in Search Console for pointing a site at a country. Google deprecated that International Targeting report in 2022, saying country targeting "was determined to have little value for the ecosystem", and that hreflang is still supported.

Step 5: let people switch, and never force them#

Google's guidance is to "avoid automatically redirecting users from one language version of a site to a different language version", because those redirects "could prevent users (and search engines) from viewing all the versions of your site". Suggest a language if you like, with a banner the visitor can dismiss, and put plain links to the other versions on every page. Our article on language switcher best practices covers placement, labels and the markup that keeps the links crawlable.

Step 6: write pages for the market, and translate the rest well#

A translated page competes with pages written by people in that market, and searchers there compare them.

Bing's webmaster blog, in a December 2025 post on duplicate content, says localization creates duplicates "when regional or language pages are nearly identical and do not provide meaningful differences for users in each market", and advises localizing "with meaningful changes such as terminology, examples, regulations, or product details". That applies most to country versions in one language: an English page for the UK and one for Australia that differ only in spelling give search engines little reason to show both.

Translation at scale has a limit too. Google's spam policies name "automated transformations like synonymizing, translating, or other obfuscation techniques" among the ways of producing scaled content abuse when "little value is provided to users". Translating your own useful pages for readers in another language is ordinary localization. Machine-translating thousands of thin pages in the hope that some of them rank is the pattern the policy describes. A review step before publishing, by someone who reads the language, is what separates the two in practice.

Search engines read more than the body. Titles, meta descriptions, URL slugs, image alt text and structured data each need their own language version. Our article on SEO localization is a field-by-field list.

Step 7: measure each market on its own#

Look at every version separately. In Search Console the Performance report has a country dimension that "groups data by the country where the search originated". Filter by country and by the language folder (/de/) to see which queries find each version, and compare them with the ones you planned for. A version that gets impressions and no clicks usually has a title or description problem. One that gets no impressions at all is often not indexed, or not linked from the other versions.

Give a new version a few months before judging it, and keep a short log of what changed and when, so you can tell your own edits apart from the search engine's.

A plan that fits a small team#

1. Month one: choose one language from evidence, and name the person who will review it.
2. Research the queries for that market and decide which pages to translate first: usually the home page, the pages that sell, and the two or three articles that bring most of your current traffic.
3. Set up subdirectories, hreflang with x-default, a self-referencing canonical per language, and a language switcher with plain links.
4. Translate the whole page, including theme text, titles, descriptions and alt text, and review before publishing.
5. Check the live pages: the lang attribute, hreflang, canonical and robots on each version.
6. Measure that market for a quarter, fix what the data shows, then decide whether to add the next language.

How LangRelay handles the technical side#

LangRelay's WordPress plugin serves each language under its own subdirectory, such as /fr/, from your own server. It writes hreflang for every version with x-default pointing at the original, a canonical per language, the html lang attribute and the Open Graph URL, and it rewrites internal links so a French page links to French pages. Titles, meta descriptions, social tags and structured data are translated with the page, and translations go live by default, with free checks that hold a page with untranslated text, the wrong language or a changed price.

After each activation a delivery check reads the live page and confirms the translated text, the lang attribute, the canonical, hreflang and the robots rules are what they should be. That covers step 5 of the plan above after every activation.

LangRelay serves subdirectories only: there is no country domain or subdomain option, and it does not proxy other platforms. Each Target locale is a language today, written as a bare tag such as es. Regional versions such as es-MX with their own folder are on our roadmap. The plugin does not write a multilingual XML sitemap; hreflang is in each page's head, which Google accepts. On a site that is not on WordPress, a script tag translates in the browser for visitors and makes no SEO claim.

If you are planning your first market and want to see what the plugin serves on your own site, book a demo.

Questions people ask about international SEO#

What is the difference between international SEO and multilingual SEO?#

Multilingual SEO is about languages: one site in several languages, each version findable. International SEO includes that and adds countries, with local prices, terms and signals such as a country domain. Most small sites start with the multilingual part. Our multilingual SEO page shows what LangRelay serves for it.

Do I need a separate domain for each country?#

No. Google lists a country domain as one of four structures, with clear geotargeting and real costs. A subdirectory on your main domain works for languages and, with hreflang region codes, for countries too.

Does hreflang make my pages rank in another country?#

It tells Google which version to show to which searcher. It does not make a page rank where it would not have ranked. The content, the links and the signals in step 4 still do that work.

Can I just machine-translate my whole site?#

You can translate it with a machine, and many sites do. Review before publishing, translate the theme text and the meta fields with the body, and start with the pages that matter, so the result is useful to readers and does not look like the scaled content Google's policy describes.