Bilingual Website Design: Two Languages, One Brand.

A bilingual website gives two audiences the same brand in the language each one already thinks in. Most projects treat that as a translation job, and that is where they go wrong.

Designing a multilingual experience is not the same as translating one: translation moves the words. What has to move is the positioning, and positioning rarely survives a literal trip from one language into another.

For an expert-led service business, the stakes are higher than for a store. Your website is where people decide whether your expertise is worth a conversation, so the second language version has to earn that same trust on its own terms, not read like a courtesy copy of the real page.

This guide covers what changes when a website serves two languages: the structure of the URLs, the language switcher in the header, the parts of the site that are not text at all, and the multilingual SEO work that keeps both language versions visible. The same best practice applies whether you are building bilingual websites or adding a third language later.

It is written from building websites for clients in seven countries, and from running this one in English and Spanish.

What a bilingual website is, and how it differs from a translated one

A bilingual website serves the same business in two languages, with a real page behind each one. A multilingual website does the same for three or more.

Bilingual or multilingual, the rules that follow are identical, and only the volume of work changes.

Both are different from a translated website, where one original page is pushed through a translation tool and served as if the job were done.

The distinction that matters is translation against localization. Translation carries the sentence across, and localization carries the meaning.

Carrying the meaning sometimes means writing a different sentence, and occasionally means dropping a section that only made sense in the first market.

An automatic website translation tool is useful for a first draft and dangerous as a final answer. It has no way of knowing that your category name is a positioning decision rather than a noun, so it renders the phrase word for word, and a sharp claim comes out of the other side vague.

Start with the audience, not with the language

Before any web design work begins, the question is not which language to add. It is which people the second version is for, because that answer changes the content, not just the vocabulary.

Ask what percentage of your target audience does not read English comfortably, and which new language that points to. The bilingual case we can show you in full is this site, because it is ours.

Most of the practices we build for run in a single language on purpose. They choose it for where their clients search rather than for where the office is, and that decision is what this section is about.

Ask whether the products and services vary by market, whether the business operates under the same brand in both, and how a client who writes to you in their native language will be answered.

A second language version that generates inquiries nobody on the team can reply to creates a worse experience than not having it. That is the first of the benefits of a multilingual website to check against reality: it works when the business behind it can hold the conversation.

A practice in Latin America selling into the United States has the same problem in reverse as one in the United States selling south, and both end up needing the same two versions.

Sometimes the honest answer is one language, and not the one you would guess. Calm Protocols, a client of ours, runs its programmes from Panama with a site written entirely in English, because the families who research this kind of treatment are searching in English from abroad.

Adding Spanish there would serve the country the practice sits in rather than the audience it sells to, which is the whole point of asking who the second version is for before you build it.

For most expert-led service businesses the honest answer is that both audiences buy the same thing for the same reasons, and the difference is the language they search in. That is the easiest case to build well, and it is still not a translation job.

Two route trees, not one website with a switch

The structural decision comes first because everything else depends on it. Each language version needs its own address, its own page, and its own place in the search engine index.

Slugs get translated along with the content. On our own website the services page lives at `/web-design` in English and at `/es/diseno-web` in Spanish, and that is deliberate: the URL carries the words a buyer types, and those words are different in each language.

A single template serving both from one address gives search engines one page where there should be two.

That choice has a consequence worth knowing before you commit. Once the slugs differ, four separate systems have to agree that those two addresses are the same page in different languages:

1. The hreflang tags, which are the line of code on each page that tells search engines which language it serves and where its twin lives.
2. The language tags in the page metadata, which say the same thing to the browser and to the tools that read the page.
3. The language switcher, which needs to know where the visitor goes when they press it.
4. The redirect map, which sends anyone arriving from an old URL to the right version.

When each of those learns the pairing independently, they drift apart in silence and nobody notices until a page stops appearing in one language.

The fix is unglamorous. One source of truth in the codebase lists every pair, and the four systems read from it.

Ask any studio you hire how they keep those in sync, and the quality of the answer tells you most of what you need to know.

The language switcher people actually find

The language switcher belongs in the header, visible without scrolling, on every page. It sounds obvious until you see how many multilingual websites bury it in the footer next to the copyright.

Three rules cover most of the user experience. Name each language in its own language, so the Spanish option reads "Español" rather than "Spanish", because a visitor who cannot read the page also cannot read the word for their language in it.

Store the language preference once it is chosen, so a returning visitor gets content in their preferred language without hunting for the control again.

And keep the visitor on the same page when they switch, rather than dropping them on the home page to find their way back.

Detecting the browser language and redirecting automatically is tempting and usually a mistake. Plenty of people work in one language and prefer to read in another, so a good multilingual site suggests the other language version and lets the person decide.

Translate the words, recreate the message

This is the part that separates a bilingual website that works from one that reads like a document. The clearest example we have is our own.

Our English positioning line describes the clients we serve as expert-led service businesses. The literal Spanish rendering runs to eight syllables where the English has a compound adjective of two, and it collapsed under its own weight every time it appeared on a page.

Worse, it did not filter what it claimed to filter, because a logistics operator can be led by an expert and still grow on price and coverage.

So the Spanish version does not translate the phrase. It states the mechanism as a clause instead: when your expertise is the product.

Same idea, same filter, written the way a Spanish speaker would have written it in the first place.

Smaller decisions follow the same logic. A discovery call is not a "llamada de descubrimiento", which is a calque nobody says, so the Spanish site calls it an initial call or names it by its length.

Even the buttons changed, because in Spanish you visit somebody else's website, not a section of your own.

None of that comes out of a website translation tool, and none of it is visible to a client reading only one version. It is visible in whether the page sounds like a person or like a document.

What changes besides the words

A bilingual website design touches parts of the site that contain no sentences at all, and these are the pieces most projects forget.

The booking flow is the first. Our own website points each language at a different calendar, because the call gets held in the language the person booked in, and pretending otherwise wastes everyone's time.

Forms, autoresponders and confirmation pages belong in the same language as the page that produced them.

Then there is the proof. Testimonials, case studies and client logos carry weight only when the reader recognises the names or the situations, so each language version needs its social proof chosen for that audience rather than copied across.

Images with text baked into them need a second version or they need to lose the text.

Finally, the practical details: how dates and currency are written, which phone format appears, and whether business hours mean anything to somebody in another time zone. Design has to leave room for expansion too, since the same sentence in Spanish typically runs longer than in English and a button sized to the English label will break.

Multilingual SEO, and now the AI answers

Multilingual SEO starts with a rule that costs people rankings every day: keywords do not translate. Machine tools will translate your website in minutes and leave every keyword decision unmade.

Each language version needs its own keyword research, because the words people search are not the words a dictionary offers.

The Spanish twin of one of our articles is not a translation of its English keyword. It targets what a Spanish speaker actually types, which turned out to be a different phrasing of the same problem, and the article was written to that phrase rather than converted into it.

Beyond keywords, the technical layer is small and non-negotiable. Every page declares its own language, each language version links to the other through hreflang to tell search engines which language it serves, both versions of your website appear in the sitemap, and neither is blocked from indexing.

Search engines then treat them as one piece of content in two languages rather than as duplicates competing with each other.

The same work now feeds the AI answer engines. When somebody asks ChatGPT or Perplexity for a recommendation in Spanish, the model needs a Spanish page to read, and a machine-translated one reads exactly like what it is.

A website that answers real questions in both languages, with the business information consistent across both, is the one that gets cited.

What it costs to keep both versions alive

The build is the cheap part. The expensive part is that every new page, article and offer now exists twice, and a bilingual website dies the moment the second language falls behind the first.

The way through it is to decide up front what gets both versions and what does not. Core pages get both versions, without discussion.

Articles selectively, chosen for the website users who will read them rather than published in pairs out of obligation. A multilingual marketing strategy that publishes everything twice tends to stall in both languages at once.

Anything time-sensitive gets a rule about what happens when only one version is ready.

Our own blog runs on that discipline: the English article is written and published first, and the Spanish one is a recreation of the approved argument with its own keyword and its own page, not a copy that came back from a tool.

The platforms that hold a second language

Every website builder now advertises support for multiple language content, and the phrase covers three different things. Some platforms create a real second page for each language version.

Others swap strings on one page, and a few hand the visitor to a machine translation layer that runs in the browser.

Only the first gives a search engine a page to index in the new language, which is the whole point of building a multi-language website in the first place. The multilingual website platforms worth shortlisting are the ones that treat each language as content rather than as a display setting.

You do not have to judge the names, you have to ask one question of whichever one you are sold, and it is at the end of this section.

WordPress multilingual work is usually a plugin decision, with WPML and Polylang as the two that support multilingual content properly rather than overlaying it. Shopify, Squarespace and Wix each have their own version of the feature, with their own limits on how much of the website content you can edit per language.

Creating a multilingual website on a hosted platform is mostly a configuration job, and building a multilingual site on a custom stack is an architecture decision you make once. On a custom build the language versions are part of the architecture instead of an add-on, which is what lets the pairing live in one place and the rest of the site read from it.

Whether you hire an agency or build a website with an in-house developer, that single source of truth is what keeps the four systems from drifting.

The question to ask any studio or website translation services provider is the same in every case. Does each language version get its own URL, its own entry in the sitemap and its own editable content, or is the second language a layer sitting on top of the first?

Four checks you can run on your own website today

Before deciding whether any of this applies to you, measure what you already have. Lists of the best bilingual websites are easy to find and mostly useless, because a screenshot shows what a great multilingual website looks like and never how it behaves.

Multilingual website examples, your own site included, are worth studying only if you open them and use them. The most useful examples of multilingual websites are the ones in your own market, because those are the sites your clients compare you against.

Four website features tell you most of it, and each one takes a minute. Switch language on a deep page of your site and see whether you stay on that page or get thrown to the home page.

Read a paragraph in the second language and judge whether it was written or converted.

Then look at the URL to see whether the slug changed with the language, and look at the proof, because a localized website shows testimonials its own audience recognises.

Run those four on your own site, then on the best multilingual sites in your industry, and you will have a better brief than any list of successful multilingual examples will give you.

You can run them on dancingpels.com as a worked example. This site is bilingual, every check above is one we had to answer while building it, and the Spanish version is where you can see whether we took our own advice.

Four noes means the second language is decoration. One or two means the structure is there and the writing is what needs work, which is the cheaper of the two problems.

Frequently asked questions

How do I create a multi-language website?

Decide who the second audience is, give each language version its own URL and page, write the second version rather than converting it, and connect the pair with hreflang. The multilingual website design work is mostly structural, and the writing is where the result is won.

What is a bilingual website?

A bilingual website is a website that serves the same business in two languages, with a separate page and address for each language version, connected so that search engines and visitors know they belong together.

How much does a bilingual website cost?

More than the same website in one language and less than twice as much, because the design system, the development and the structure are built once. The second language adds content work, and that part continues for as long as the site does.

Our own custom website projects start at US$6,000, and a second language is one of the things that moves a scope up from there.

Should I use Google Translate or hire a professional?

Use machine translation to understand a page, not to publish one. For the pages where your positioning lives, the home page, the services, the about page, a professional who understands the business writes better copy than any tool, because those pages are arguments rather than sentences.

Is AI translation good enough for a website?

It is good enough for a first pass on straightforward content, and it is not good enough for anything that carries your positioning. Treat it as a draft that a person who knows both the language and the business then rewrites.

What is the difference between translation and localization?

Translation converts the words. Website localization adapts everything around them: the examples, the proof, the formats, the currency, and sometimes the structure of the page.

A localized website reads as if it were written for that audience, because in the parts that matter it was.

How do you structure URLs on a multilingual website?

Give each language version its own URL and translate the slug into the words that audience searches, then declare the pairing with hreflang so search engines can match them. Keep the pattern consistent across the whole site so the language switcher can be built on a rule rather than on exceptions.

Will a multilingual website slow my site down?

Not in itself. Each visitor loads one language version, the same as any other page.

Slowness comes from translation plugins that load a full second layer of scripts on every request, which is a reason to build the language versions into the website rather than bolt them on.

Are multilingual sites allowed in WordPress?

Yes. WordPress supports multilingual content through plugins, and the same rule applies as anywhere else: choose the setup that creates a real page per language version rather than one that translates on the fly.

Can I use a template for a bilingual website?

A template will hold two languages. What it will not do is make the second version say the right thing, and that is where these projects are won or lost.

Where this leaves a business working across two markets

If your clients live in two languages, your website already has two jobs. The one that fails is almost never the one you wrote first, and it fails without a complaint, because the people it was meant to convince leave instead of writing to say why.

The work to build a multilingual website is smaller than it sounds when it is planned from the start, and much larger when it is retrofitted onto a site that never expected it. Our Custom Websites service builds both language versions as one system with a single source of truth for the pairing, Growth Marketing keeps both of them publishing instead of letting the second one stall, and AI Systems handles the operations behind the inquiries that arrive in either language.

If you are weighing whether a second language version is worth it, run the four checks above on the site you have and look at where your inquiries already come from and in which language people write to you. Both are free and neither of them needs us.

If what you find says the second version is worth building, bring it to a 30-minute call and we can tell you what it would take, including when the honest answer is that your one language is doing its job.