How to Design a Language Switcher for a Multilingual Website

In this guide we cover language switcher design from start to finish. That includes placement, label language, mobile behavior, the downside of automatic redirects, the link to hreflang, and accessibility. At Talha Aslan and team, the most common problem we see on multilingual sites is simple. Teams treat the switcher as a last-minute ornament. In practice, this small component shapes a foreign visitor’s first contact with the site. It also helps search engines discover every version.

At the end you will find a pre-launch checklist and a table that compares the main design options. The examples below are not client cases. Each one is clearly labeled as an example scenario.

Where should you place a language switcher?

The short answer: on every page, in the same spot, where people notice it right away. The W3C Internationalization team’s guide to language negotiation says links to other language versions should not be hidden. It also suggests a visible corner of the page. When people want to change language, they usually glance at the top right corner or the end of the main menu first. That is why we typically place the control at the right end of the header.

In addition, a second copy in the footer helps. A reader who reaches the end of a long page can switch without scrolling back up. However, both copies need the same logic. They should point to the same target pages.

• Desktop: right end of the top navigation, next to search or the contact button.
• Mobile: beside the menu button, or at the very top of the opened menu.
• Footer: a second copy near the legal links.
• Avoid: hiding it on the contact page only, or inside a scrolling banner.

In short, visitors should never have to hunt for the language switcher. Keep it in a fixed spot across the site. Then users learn it once and use it without thinking.

Should you use flags or language names?

Use language names. After all, a flag stands for a country, while a language crosses borders. Spanish has native speakers in dozens of countries, and Switzerland has more than one official language. The W3C guide states plainly that flags are not appropriate for linking to pages that are simply translations. A flag only makes sense when the content truly changes by country. For example, regional stores with different prices and shipping terms fit that case.

Example scenario: you put a German flag next to your German pages. A visitor from Austria or Switzerland may not read that flag as their language. Likewise, if you pick the UK flag for English, readers from the US or India may feel left out. Also, small flags look alike, and color-blind users can struggle to tell them apart.

So our advice is simple. First, make the text label primary. If you want a visual cue, add a globe or a generic language icon next to the text. That way people recognize the control quickly, and it sends the right message.

Which language should the language names use?

Write each language in its own name: "Türkçe", "English", "Deutsch", "Français". Specifically, linguists call this an endonym, the name speakers use for their own language. In practice, the logic is easy to follow. Someone who cannot read the current page will only find their language if it appears in a form they recognize. A Turkish visitor who lands on a Japanese page cannot read the Japanese word for Turkish. Still, they will spot "Türkçe" instantly.

The W3C "Language of Parts" explanation for WCAG 2.2 uses exactly this example. The text of each link is the name of the language, in that language, and each link carries its own language code. As a result, screen readers pronounce "Deutsch" with German rules rather than English ones.

• Do not abbreviate. Write "Deutsch" instead of "DE", and add the short code next to it if you like.
• Follow each language’s own capitalization habits. Even so, a capitalized first letter in a menu is common practice.
• Keep the list consistent. Use either full names everywhere or full names plus codes everywhere.

Also, mark the active language clearly in the list. After all, users need to know where they are. Otherwise they click the same option again and wonder why nothing changed.

Is a dropdown or an open list better?

It depends on how many languages you offer. With two or three languages, open links are usually the fastest choice. A simple row such as "Türkçe | English | Deutsch" switches in one click. As a result, users see every option at a glance and never need to open a menu.

On the other hand, once you pass five or ten languages, an open list crowds the header. At that point, therefore, a dropdown makes sense. The W3C guide also notes that a pull-down can work for many languages. However, the purpose of the control must be clear in a language-neutral way. In other words, the trigger button should show a language icon plus the current language name, not only the word "Language".

Example scenario: a travel company runs its site in six languages. On desktop, a button with a globe icon and the label "English" opens a panel. The panel orders languages by how often visitors use them, not alphabetically. On mobile, the same list appears as open links at the top of the menu. Each screen then gets a pattern that fits its constraints.

Whatever pattern you choose, do not build a dropdown that opens on mouse hover only. On touch screens and with keyboard navigation, that behavior often fails.

How should a language switcher work on mobile?

On small screens, designers often bury the language switcher at the bottom of the hamburger menu. That is a poor start for a foreign visitor. Someone who cannot read the page may never think to open the menu and scroll to the end. For that reason we recommend keeping language access on the first screen on mobile too.

1. Place a small language icon and a two-letter code in the header bar, next to the menu button.
2. When users tap the icon, list the language names in a full-screen or bottom sheet panel.
3. Give each option a comfortable tap height. Avoid links that sit too close together.
4. Mark the active language in the panel and keep the close button easy to find.
5. After a choice, take the user to the same content in the new language.

Target size matters as well, so plan for it. WCAG 2.2 defines a minimum size and spacing expectation for pointer targets. Check the current threshold in the official W3C documentation. The most common issue we see in the field is three language codes squeezed into a tiny area, which leads to wrong taps.

In short, the mobile goal is a language change that takes no more than two taps.

Why are automatic language redirects a problem?

An automatic redirect sends a visitor to another language version based on IP address or browser language. On paper it sounds user friendly. In practice, however, it creates two serious problems. The first one hits users: a Turkish speaker living in Germany may want the Turkish page but land on the German one. Meanwhile, the second one hits search engines.

Google’s guide to managing multi-regional and multilingual sites advises you to avoid automatically redirecting users from one language version to another. Such redirects can stop users and search engines from viewing all versions of your site. Google also explains that Googlebot usually crawls from the US and does not send Accept-Language headers. So redirects based on language or location can keep Google from finding some of your versions at all.

We covered the SEO side of this topic in our article on the SEO impact of IP-based language redirects. From a design point of view, therefore, our position is clear. Instead of a forced redirect, show a suggestion that leaves the choice to the user.

What should you do when you detect the browser language?

You do not have to ignore the browser’s language preference completely. Instead, the right approach uses that signal for a suggestion. For example, a visitor who prefers German lands on your Turkish page. A slim banner appears at the top: "Diese Seite gibt es auch auf Deutsch," with a link. The user can then switch or simply close the banner.

Keep a few principles in mind when you design that banner. First, write it in the language it suggests, because the person reading it speaks that language. Second, it should not push content down and cause a layout shift. Elements that appear after load and move the layout hurt reading. They also hurt visual stability metrics.

• Show the banner only when the matching version really exists.
• Make the close button obvious, and remember that the user closed it.
• Do not serve a different page to search engine crawlers. The banner should follow the same logic for everyone.
• Do not turn the banner into a full-screen popup. Elements that cover content annoy users.

That way you benefit from the browser preference, yet the user keeps the final word.

How should you remember the user’s language choice?

Once a visitor picks a language, the site should respect that decision. The W3C guide explains that you can store the preference in a cookie or in browser storage. Subsequent pages can then follow that choice. That said, there is a subtle distinction. Remembering a preference should never replace a clear URL structure.

Every language version needs its own permanent address, such as example.com/de/. The cookie should only remember the previous choice and personalize the suggestion banner or the home page entry. If the same URL shows different languages depending on a cookie, search engines cannot tell which language to index. Also, a shared link might open in a different language for the recipient.

Example scenario: a user switches to German and later clicks a Turkish blog link. In that case, the correct behavior opens the Turkish page the link points to and shows a German version suggestion on top. The wrong behavior silently throws the user onto the German home page. Put simply, the link target always comes before the stored preference.

Which page should users land on after switching language?

They should land on the equivalent of the content they were reading. This is the most neglected rule in language switcher design. If someone reading a product page switches to English and lands on the home page, they have to search again. In practice, many of them simply give up.

To avoid that, every page on your site needs to know its counterparts in other languages. If your content management system stores a translation relationship between pages, it can generate the switcher links automatically. As a result, you get rid of hand-edited links that break over time. Moreover, the same mapping table becomes the source of your hreflang tags.

• Product page: the same product in the other language.
• Blog post: the translated post, or the blog home of that language if no translation exists.
• Category page: the matching category.
• Search results and filtered pages: if possible, the equivalent page with the same query and filters.

Testing this rule is easy. Pick ten random pages and switch language on each one. Then check whether the new URL is the translation of the same content. For instance, if a service page switches to the English home page instead of the English service page, the mapping has a gap. Repeat the test after each new content release so you catch broken pairs early.

In short, the switcher is not a "back to home" button. It is a translation key that preserves where the user is.

What should the switcher show on a page with no translation?

Not every page will exist in every language. For example, you may never publish an English version of a campaign page aimed only at customers in Turkey. In that case you have three options, and each one has trade-offs.

Option one: show the missing language as disabled, with a note that this page is not available in that language. Next, option two: point the missing language link to the nearest parent page in that language, such as the related category or the home page. Finally, option three: remove the missing language from the list. However, that can give the impression that the site no longer supports the language.

We usually recommend option two, with one condition. Specifically, users must know where they are going. A short note next to the link, or a message on the target page, removes the confusion. Something like "this content is not available in English, here is the related section" works well. Also, do not create hreflang pairs between pages without a translation relationship. Hreflang exists only to connect truly equivalent pages.

How does a language switcher relate to hreflang?

The language switcher serves people, and hreflang serves search engines, yet both carry the same message: this page has equivalents in these languages. Feed both from the same source and never let them contradict each other. Google’s documentation on localized versions asks each language version to list itself and every other version. If two pages do not point to each other, Google may ignore the tags.

For example, a frequent mistake looks like this. The language switcher links page A to page B, while hreflang pairs page A with page C. Users and search engines then see different maps. The fix is to keep one translation mapping table and generate both the links and the tags from it.

We explained the basics in our guide on what the hreflang tag is. To prepare tags quickly, try our hreflang generator tool. Also, switcher links should be normal HTML links that help crawlers find the other versions, as Google recommends. Script-only buttons without a real URL do not do that job.

When do you need x-default and a language selection page?

x-default is the hreflang value that names a fallback page for visitors whose language preference matches none of your versions. Google’s documentation says this value was designed for language selector pages and works best with them. So if you run a global entry page, it is the natural candidate for x-default.

Does every site need a separate language selection page? No. On a three-language corporate site, making the main version x-default is usually enough. Still, on sites with many country and language combinations, an entry page where users first pick a region and language can make sense.

• The entry page should show every language name in its own language on a single screen.
• It should not be an empty gate. Include a short brand intro and navigation links.
• After a choice, do not force users through this page on every visit.
• The page you mark as x-default also needs reciprocal hreflang links with the other versions.

Example scenario: an industrial manufacturer offers Turkish, English and German. It marks the English version as x-default. A visitor with a Spanish or Arabic browser setting then sees the version that reaches the widest audience. If the same company later expands into ten countries, it can consider a dedicated entry page at that point.

How do you build an accessible language switcher?

Accessibility in a language switcher comes down to a few concrete details, and you can apply all of them at a conceptual level. First, mark the text of each language link with its own language code. In HTML, that means giving the link the lang attribute of that language. You can also add the hreflang attribute to state the language of the target page.

1. Use the language name as link text, not a flag image alone. If you use an image, provide a text alternative.
2. Mark the active language both visually and for screen readers. A state attribute such as aria-current suits this job.
3. Give the dropdown trigger a clear accessible name, such as "Select language", and expose its open or closed state.
4. Make the menu open, navigate and close with the keyboard, including the Escape key.
5. Never remove the focus indicator. Users need to see which language they are on.

Next, remember that the lang attribute for the whole page must be correct as well. We covered that in our article on the html lang error and wrong language detection. For the broader framework, see our guide on web accessibility and WCAG standards.

How do you present language and region together?

On some sites, language alone is not enough. Prices, currency, shipping and legal texts change by country. In that case you ask two separate questions: "Which language do you want to read?" and "Which country are you shopping from?" Merging both questions into a single list of flags, therefore, creates confusion.

Example scenario: an online store sells to Switzerland in German, French and Italian. In a good design, the user first picks the region, Switzerland, and then chooses among the languages that region supports. A flag next to the region selector is reasonable here, because the flag really stands for the country. The language options, however, still use language names.

Also, when the region changes, show clearly that prices and stock information have updated too. Otherwise, if the currency changes silently, users lose trust. Since these sites run several regional versions, we suggest reviewing the URL structure options in our multilingual website SEO guide.

Comparison of language switcher patterns

The table below compares the patterns we meet most often in the field, by use case. In other words, these ratings reflect general tendencies from field experience. They are not guaranteed outcomes for every site.

On most corporate sites, the best result is a combined setup. Specifically, it pairs open links or a dropdown at the top with a backup copy in the footer. If needed, it adds a suggestion banner based on browser language.

What are the most common language switcher mistakes?

Across the multilingual sites we have reviewed over the years, the same mistakes keep coming back. Most of them happen because the team adds the component a few days before launch instead of during design. The list below sums up these mistakes and quick fixes.

• Language names in the page language, such as "Almanca" on a Turkish page. Fix: write "Deutsch".
• A flag as the only cue. Fix: a text label.
• Switching language sends users to the home page. Fix: page-level mapping.
• Forced redirects by IP. Fix: a suggestion banner.
• Language links as script buttons without a URL. Fix: real links.
• Hreflang and the switcher pair different pages. Fix: one mapping table.
• On mobile, the switcher sits at the bottom of the menu. Fix: an icon in the header bar.
• A translation plugin translates content without changing the URL. Fix: a permanent URL for every language.

The last item deserves extra attention. Plugins that translate inside the browser offer users a quick fix. However, they do not create a separate language version for search engines. Therefore that approach cannot replace a real multilingual structure.

Language switcher pre-launch checklist

Before we launch a new multilingual site, our team goes through the list below item by item. You can run the same steps on your own site.

1. Does the switcher appear on every page, in the same position?
2. Are language names written in their own languages and tagged with their own language codes?
3. Do you use flags only for region choice?
4. Does each language link go to the equivalent of the same content?
5. Did you define consistent behavior for pages without a translation?
6. Are automatic redirects off, with a suggestion banner in their place?
7. Do hreflang pairs match the switcher links exactly, and are they reciprocal?
8. Does a language change on mobile take two taps at most?
9. Can you open and close the menu with the keyboard and reach every language?
10. Does a screen reader announce the active language and the menu state correctly?

In short, every "no" on this list is a gap. Either it costs you users, or it causes a search engine to miss a version. We recommend running the list again after every major design change.

How can we build the language switcher on your site?

On a multilingual site, the language switcher sits where content model, URL structure, hreflang and accessibility decisions meet. So you should build it as part of the site architecture, not as a separate plugin. At Talha Aslan and team, our web design service designs the translation mapping table from day one. Then we generate the switcher and the hreflang tags from the same source.

Maybe your current switcher dumps users on the home page. Maybe flags cause confusion, or Google cannot find some of your language versions. In each case, we can build this on your site. First we review the current setup. Then we prepare a written proposal that sets scope and timeline. To request a proposal, use the contact form on our web design page.

In this process we think beyond the visual component. We also plan the workflow of the people who will manage translation links in the CMS. After all, keeping the mapping accurate takes more effort over the long run than the design itself.

Summary: what makes a good language switcher

A good language switcher is easy to find, predictable and honest. It sits in the same place on every page, names languages in their own words, uses text instead of flags, and takes users to the equivalent of the content they were reading. It also never forces a redirect. Instead, it only suggests, and it remembers the user’s choice.

Behind the scenes, moreover, one translation mapping feeds both the switcher links and the hreflang tags. People and search engines then see the same map of your site. Follow these principles, and the switcher becomes the first touchpoint that earns a foreign visitor’s trust.