Multilingual websites: doing it right for SEO and conversion

You want to sell in other countries or serve customers who speak another language, and the question is always the same: how do I add languages without breaking the SEO I already have? A multilingual website is done right with three things: a clear URL structure (subdirectories like /en/ and /es/ are the most common and robust), hreflang tags that tell Google which version to serve each user, and native human translation on the pages that sell. Mass machine translation and forced IP-based redirection are the two mistakes that lose the most traffic. Here is how to build it step by step, what it really costs, and when it is not worth it.

First: choose your URL structure

Before you translate a single word, decide how languages will live on your domain. This decision is hard to reverse, so it pays to understand it.

Structure	Example	When it fits	Downsides
Subdirectories	yoursite.com/es/	Most SMBs and startups	One hosting; everything together
Subdomains	es.yoursite.com	Separate teams or servers per language	Google treats them almost as separate sites
Country domains	yoursite.es / yoursite.mx	Large brands with strong local presence	You must build each domain's SEO authority from scratch
URL parameters	yoursite.com?lang=es	Almost never	Terrible for SEO; Google ignores or duplicates them

For roughly 90% of cases, go with subdirectories. All the authority you have built stays on one domain, you manage a single SSL certificate, and setup is straightforward. Separate country domains (.es, .mx) only make sense when a large brand wants to dominate local results and has the budget to do SEO for each domain separately, which is essentially starting from zero several times over.

Avoid parameters (?lang=es) at all costs: they clutter URLs, confuse Google, and are the recipe for your two languages to compete against each other as duplicate content.

Hreflang: the piece almost everyone breaks

Hreflang is a tag that tells Google which version of a page corresponds to each language and region. Without it, two bad things happen: Google shows the English version to someone who searched in Spanish, and your two versions can cannibalize each other as duplicates.

A correct implementation has three rules that get broken constantly:

1. Bidirectionality. If the EN page points to the ES page, the ES page must point back to the EN one. If one side is missing, Google ignores the whole set.
2. Absolute URLs. Always https://yoursite.com/es/..., never relative paths.
3. The x-default tag. It points to the "default" version for languages you do not cover. It keeps a French-speaking user from landing on a page they cannot read.

A minimal example for a bilingual English/Spanish page:

<link rel="alternate" hreflang="en" href="https://yoursite.com/en/services/" />
<link rel="alternate" hreflang="es" href="https://yoursite.com/es/servicios/" />
<link rel="alternate" hreflang="x-default" href="https://yoursite.com/en/services/" />

The classic mistake we see in audits: hreflang only on the homepage and missing everywhere else. Hreflang is per page. Every pair of equivalent URLs needs its own block, which is why you want to generate it automatically from your content system instead of by hand. If your site is built on a modern framework like Next.js or managed through custom software, this is solved once in code and stops being a source of errors.

Translation: where conversion is won or lost

SEO brings the traffic; translation decides whether it converts. And there is a very concrete quality hierarchy here:

• Raw machine translation (embedded Google Translate): destroys conversion. Awkward phrasing, wrong gender, idioms that do not exist. At scale, Google can read it as low-value auto-generated content.
• Machine translation + human post-editing: acceptable for volume, like a large blog. An AI drafts and a native speaker corrects.
• Professional native translation: mandatory for the homepage, service pages, pricing, and forms. This is where the sale is decided.

One detail that is expensive to ignore: translating is not just swapping the language, it is localizing. Currency (USD vs MXN vs COP), date format, phone numbers, cultural examples, and even testimonials. An English pricing page showing amounts in Argentine pesos triggers instant distrust.

Not sure which language architecture fits you, or how much to translate? Book an intro call and in 30 minutes we will tell you which structure fits your case and budget, without overselling you.

How to build it step by step

A sequence that works, in priority order:

1. Define real markets. Who will actually buy in the other language, and why? If there is no proven demand, stop here.
2. Choose your URL structure. Subdirectories unless you have a strong reason for something else.
3. Decide what gets translated. Start with the pages that generate revenue, not everything.
4. Build the technical architecture: per-language routes, a visible language switcher, automatic hreflang, and a sitemap with all versions.
5. Translate and localize the priority pages with native speakers.
6. Set up analytics per language to see which version converts and where.
7. Maintain it. Every price change and new page gets done in both languages.

Step 4 is the most underestimated. A language switcher hidden in the footer loses half its value; it needs to be at the top and visible. And if your site has a catalog, cart, or payments, multilingual touches your ecommerce too: prices, taxes, and payment methods change per country.

Conversion: beyond translating the words

Three concrete levers that move the needle on multilingual sites:

• A visible language switcher, never a forced redirect. Show a notice ("Prefer to read this in Spanish?") and let people choose. Automatic IP-based redirection is the number-one cause of English pages indexed that nobody asked for.
• The same design quality across all languages. It happens constantly: the English version ends up with fewer sections, no testimonials, and a weaker form. Visitors notice.
• Support and replies in the visitor's language. If a customer writes in English and gets answered in Spanish, conversion collapses. A multilingual AI chatbot handles the first response without adding headcount.

When a multilingual website does NOT make sense

It is not always worth it. Cases where you should stop:

• Your market is 100% local. A bakery that only sells in its own neighborhood does not need a second language. The effort never pays off.
• You cannot serve customers in the other language. Attracting English-speaking leads that nobody can answer is worse than not having them.
• You expect machine translation to "fix" weak content. If your content in the first language is already thin, translating it just multiplies the problem.
• You are doing it "just in case." With no proven demand, you end up maintaining twice the pages with zero extra customers. In that case, validate first with an MVP in one language and expand when the numbers justify it.

The simple rule: if you cannot name who will buy in the second language and why, it is not time yet.

Wrapping up

A multilingual website done right is not translating a site: it is a clean URL architecture, correct hreflang on every page, native translation where the sale happens, and the discipline to keep everything in sync. Built that way, it doubles your reach without cannibalizing your SEO. Built badly, it leaves you with duplicate pages, leads you cannot serve, and maintenance that weighs twice as much.

At Deepyze we build multilingual sites with the technical architecture solved from the ground up (automatic hreflang, per-language routes, separate analytics) so you can focus on selling in each market. Start your project and we will build the structure that scales to the languages and countries your business actually needs.