--- title: "Language switcher best practices for multilingual sites" description: "Where to put a language switcher, dropdown or links, native names, flags, redirects and accessible markup, with the HTML a WordPress site can ship." url: "https://www.langrelay.com/blog/language-switcher-best-practices" --- 1. [Home](https://www.langrelay.com/) 2. [Blog](https://www.langrelay.com/blog) 3. Language switcher best practices for multilingual sites ArticleWordPress # Language switcher best practices for multilingual sites Where to put a language switcher, dropdown or links, native names, flags, redirects and accessible markup, with the HTML a WordPress site can ship. [Chris Jayden](https://www.langrelay.com/about) Founder Published 6 October 2026 Updated 16 October 2026 Reading time 9 min read ![Two people in a long canoe wave to a stilted riverside village whose dock railing is painted with green and orange leaf tiles.](https://www.langrelay.com/_emdash/api/media/file/01M4ET6KSFZJ2D1QP687NRYCVM.webp) On this page 1. Where to put the language switcher 2. Dropdown or a row of links 3. Write each language in its own language 4. Should a language switcher use flags? 5. Link to the same page in the other language 6. Don't force a redirect by browser language 7. Markup that people and crawlers can use 8. How LangRelay's WordPress switcher does it 9. A short checklist A language switcher works when a visitor finds it in the first place they look, recognises their own language in it, and lands on the same page in that language. In practice that means a control in the header (and again in the footer), each language written in its own language, flags only next to a name, plain links to the translated version of the current page, and no forced redirect based on the browser. ## Where to put the language switcher Put it in the top corner of the header on desktop. Nielsen Norman Group's guidance on ecommerce language switchers says exactly that, and adds that on mobile it should sit above the fold or inside the navigation menu. A visitor who cannot read your page has little reason to scroll through it looking for a control. Repeat it in the footer. Smashing Magazine's checklist puts the selector in the header as well as the footer, which catches the visitor who reaches the bottom of a long page and only then decides to switch. One failure to check for on mobile is a switcher that exists on desktop and disappears when the header collapses into a menu button. If the menu is the only place it lives, put it near the top of the menu, where it is visible without opening any submenu. A floating button in a bottom corner is a reasonable fallback when a theme gives you nowhere else to put the control. It is easy to miss on a busy page and it competes with chat widgets and cookie banners, so treat it as a fallback and place a switcher in the header when you can. ## Dropdown or a row of links A dropdown makes sense once the list gets long. With two to four languages, showing every option as a link saves a click and still fits: `English · Deutsch · Español` fits in most headers. Past five or six languages a collapsed control is easier to scan. Build it as a disclosure: a button that shows and hides a list of links. The W3C's ARIA Authoring Practices Guide describes the pattern, and when the list is open the button carries `aria-expanded="true"`. The same guide's example of disclosure navigation explains why it does not use the `menu` role: site navigation does not need the complex keyboard behaviour that assistive technology expects from an application menu. A language list is site navigation, so a disclosure is the right fit. Avoid the native `` for localized content still asks for each option to be written in its own language, as in "français". ## Write each language in its own language Label every option with the language's own name: Deutsch, Español, Français, Nederlands. A visitor who reads only German is looking for "Deutsch". If your English page lists "German", you are asking them to read English to escape English. NN/g gives the same advice with "Español instead of Spanish", and Smashing Magazine's version is "Deutsch instead of German". Mark each name with its language. WCAG success criterion 3.1.2, Language of Parts, uses this exact case as an example: the text of each link is the name of the language in that language, with a `lang` attribute, as in `Deutsch`. A screen reader can then pronounce "Deutsch" with German rules. The same Understanding document notes that a screen reader may still read a link name as one flat string, so the attribute does not guarantee correct pronunciation everywhere. It costs nothing to add, though, and it is what the criterion asks for. Two smaller choices follow from the same rule: - Avoid two-letter codes such as DE or ES as the only label. Smashing Magazine points out that browser translation tools can translate short codes, and the W3C's note on language lists warns that a list of codes only works when visitors know the tag for their language. - If your audience is mixed, you can show both names, as in "Deutsch (German)". Keep the native name first. ## Should a language switcher use flags? Not on their own. The W3C's internationalization note on link destinations puts it plainly: "Don't use flags to indicate languages! Flags represent countries, not languages." Jakob Nielsen named the same problem in 1996, that some languages are spoken in many countries, though his fix was to keep flags and pick the one matching the site's location and main audience. Which flag stands for Spanish? A Mexican visitor shown the Spanish flag, or a Brazilian visitor shown Portugal's, is being told the site was not made with them in mind. NN/g's 2022 article is more positive about pairing the two: it recommends showing a national flag or currency symbol next to the name as an extra cue, and does not recommend a flag alone. Smashing Magazine says to avoid flags for languages, and Weglot's guide cautions against them while allowing that they can work for some audiences. So the defensible rule is that a name is required and a flag is optional decoration. Flags make sense when the choice really is a country, such as a store that changes currency, shipping and prices per market. NN/g recommends letting people change language, country and currency separately, and a combined country and language picker should still say which language each option gives you. ## Link to the same page in the other language When someone switches language on your pricing page, take them to the pricing page in that language, not to the translated home page. Landing on the home page forces them to find their way back to what they were reading, in a language they may only now be able to follow. That means the switcher's links are different on every page. Each one points to the translated URL of the page the visitor is on. A switcher whose links all point at `/de/`, `/es/` and `/fr/` is easier to build and gives a worse experience. Decide what happens when a page has no translation yet. You can hide that language on that page, or link to the address where the translation will live and serve the original until it is ready. Whichever you choose, avoid a link that goes to a 404. ## Don't force a redirect by browser language Google's documentation on multilingual sites is direct about this: avoid automatically redirecting users from one language version to another based on what you think their language may be, and consider adding links to the other versions instead. There is a crawling reason too. Google's page on locale-adaptive pages says Googlebot's default crawler appears to use US-based IP addresses and sends requests without an `Accept-Language` header. A site that decides the language for the visitor can end up showing Google one version and hiding the rest. Not every guide goes that far. NN/g suggests defaulting to the language that matches the browser's settings, and the W3C's note on guiding users to translated pages recommends server-side content negotiation, together with links on every page to the other languages so people can change their minds. Smashing Magazine lands in the middle: nudging is fine and automatic redirects are not. The pattern all of these allow is a suggestion. Keep the URL the visitor asked for, and if their browser prefers another language you have, show a dismissible banner in that language with a link to the matching page. Remember the choice they make, and never redirect a URL that someone requested directly, because that URL may be the one a search result or a colleague sent them to. On WordPress, from plugin 2.10.0, LangRelay suggests by default. On the first page of a visit, when that page is also live in a language the visitor's browser prefers, LangRelay offers the visitor, in their language, the page in that language, and the visitor stays where they are unless they accept. A site owner who wants a redirect can choose one: the visitor is then taken to their language before the page appears, told so, and given a link back. That choice goes against Google's advice above, and the setting says so. In both cases LangRelay never redirects search engine crawlers, only sends people to a page that has a live translation, and never uses the visitor's location. The visitor's answer is kept in their browser for a year and is never sent anywhere. ## Markup that people and crawlers can use Here is a switcher for a page at `/pricing/` with German and Spanish translations, written as a plain list of links: ``` ``` What each part does: - `