The WPML language switcher is more than a visual control for changing the language of a WordPress website. Its location, labels, behavior on untranslated pages and handling of URL arguments can all affect how visitors move through a multilingual site. These settings also matter when a visitor arrives through a campaign URL and then changes language.
This guide explains how to configure the WPML language switcher according to the site layout, the available translations and the campaign-tracking requirements. The recommendations are practical rather than universal rules: the appropriate choice depends on the theme, page type, mobile layout, page-builder templates and the site’s conversion flow. After each change, check the actual front end instead of assuming that a saved setting will look the same everywhere.
What the WPML Language Switcher Controls
WPML provides several ways to display a language switcher. It can be added to WordPress menus, widget areas, the footer or inline content above or below posts. It can also be placed through the Language Switcher Gutenberg block or through custom implementations. This gives site owners flexibility when the primary navigation, a template or a specific content area requires a different presentation.
The switcher configuration also covers the order of languages, the form of language labels and whether flags are displayed. Separate settings determine what happens when the current page does not have a translation in the selected language, and which URL arguments should survive a language change. These are different decisions and should be reviewed independently.
The settings covered in this guide
For switcher-specific options, open WPML → Settings → Language Switchers. Broader language configuration is available under WPML → Settings → Languages. A useful workflow is to decide the visual location first, configure labels and order next, then choose the missing-translation behavior and preserve only the URL arguments the site actually needs.
- Review the switcher on representative templates after saving changes.
- Check desktop and mobile layouts separately.
- Test both ordinary navigation and campaign URLs.
Choosing the Right WPML Language Switcher Placement
WPML supports placement in a primary menu, widget area, footer, inline content and Gutenberg-based layouts. The primary navigation or header is the most immediately visible option because visitors can see it as the page loads. This can be appropriate when changing language is an important part of the initial navigation task, especially on a site serving audiences who need to identify the available languages quickly.
The header is not automatically the right choice for every website. A crowded navigation, a complex mobile menu or a page-builder template may make the switcher difficult to use. Review how it behaves at the actual responsive breakpoints used by the theme. Also consider whether the switcher is useful on every page. Checkout and account pages may require a different decision from content pages, particularly when the language control competes with the main task of the page.
Header, footer and content-specific options
WPML describes the footer as a less intrusive placement. It can remain available across pages without competing with the main navigation, which may suit a site where language selection is useful but not the primary action. A widget area can work when the theme provides a clear sidebar or another stable widget location. Inline content can be considered when language selection belongs near a specific post or page rather than in global navigation.
The Language Switcher Gutenberg block provides another layout-based option. It may be useful when the switcher must be placed inside a template or content structure controlled through Gutenberg. Compare the result on translated and untranslated pages, then verify the mobile version. Choose the location according to discoverability, available space and the visitor’s task, not on the assumption that one placement guarantees better engagement or conversion.
Configuring Labels, Language Order and Display Behavior
Language order affects how quickly visitors can identify their preferred option. In WPML → Settings → Language Switchers, administrators can choose the order in which languages appear. Review that order in the actual menu, widget, footer or block where the switcher is displayed, because the surrounding layout can change how easy the list is to scan.
WPML also allows language names to appear in their native form or in the current site language. The appropriate choice depends on the audience and the surrounding interface. Native labels can make a language immediately recognizable to its speakers, while labels in the current site language may fit a consistent navigation style. Flags can be enabled or disabled, so they should be treated as a presentation choice rather than a mandatory part of the switcher.
Labels and flags in a multilingual interface
Before publishing the configuration, use a short review checklist:
- Confirm that the language order matches the intended navigation design.
- Check whether labels are shown in their native form or in the current site language.
- Verify whether flags support the chosen presentation or make the control unnecessarily busy.
- Preview the switcher in each relevant placement and viewport size.
Do not evaluate these options only from the settings screen. A label that appears clear in one context may be less clear in a compact mobile menu or a narrow widget area.
Handling Missing Translations
A language switcher must also define what happens when the current page has no translation in a selected language. WPML provides two documented behaviors in WPML → Settings → Language Switchers. The switcher can omit the unavailable language, or it can link visitors to that language’s homepage.
Omitting the language keeps the switcher limited to languages available for the page being viewed. This preserves a closer relationship between the current page and the choices shown. However, visitors may not see every language configured for the site. Linking to the language homepage keeps every language reachable, but the destination may contain different content from the page the visitor was reading.
Skip the language or link to its homepage
The choice is therefore a user-experience decision rather than a universally correct setting. Consider the site’s content model and the visitor’s expected task. A content-focused site may prefer to show only languages that have a corresponding page. A site that wants visitors to reach the broader translated area may prefer the homepage destination.
Test both behaviors before changing production settings. Use representative pages with and without translations, and check the result from desktop and mobile layouts. Confirm that visitors understand where the selected language takes them. Do not imply that a homepage link preserves the context of the original page; it deliberately sends the visitor to that language’s homepage when the current page is unavailable.
Preserving UTM and Other URL Parameters
Language switching can change the destination URL, so campaign and functional query arguments should be reviewed separately. WPML provides a Preserve URL arguments field under WPML → Settings → Language Switchers. Enter the names of the query-string arguments that should survive a language switch. WPML’s documented format is a comma-separated list.
For campaign tracking, UTM keys can be used as an example. Add the parameter names that the site actually uses rather than adding every possible query argument. The same principle applies to parameters required by filters or other site functionality. A smaller, reviewed list helps avoid unnecessary URL behavior and tracking noise.
A controlled URL-argument configuration workflow
- Open WPML → Settings → Language Switchers.
- Find the Preserve URL arguments field.
- Enter the required query-key names in the documented comma-separated format.
- Save the setting and open a page through a URL containing those arguments.
- Switch languages and inspect the resulting URL.
- Review the behavior of arguments that were not listed.
Test with real campaign URLs and with the redirects used by the individual website. Then check the analytics setup to see how the resulting URL is interpreted. Preserving selected arguments does not guarantee complete attribution in every hosting, caching, redirect or analytics configuration. The site’s actual behavior must be validated rather than assumed.
Troubleshooting Changes That Do Not Appear
A saved language-switcher change may not be visible immediately because WPML caches the rendered HTML of language switchers. This can make the front end appear unchanged even when the configuration has been updated. Start with the WPML-specific cache before investigating broader site behavior.
Cache and front-end verification checklist
- Open WPML → Support and use the option to clear the WPML cache.
- Reload the affected front-end page and inspect the rendered switcher.
- Retest the page in a clean browser session if the previous result is unclear.
- Check whether a separate page, object, browser or CDN cache is serving older output.
- Review theme or plugin styling if the markup is present but the switcher is not visibly updated.
Cache clearing is a focused troubleshooting step, not a guarantee that every display issue will disappear. If the configuration remains invisible, compare the saved settings with the actual front end and investigate the other caching layers used by the website. Also check the specific template: a header, footer, widget and Gutenberg layout may not be rendered through the same page structure.
Configure the WPML language switcher by matching its placement to the page context, then review language order, labels and flags in the real layout. Decide whether unavailable translations should be skipped or linked to a language homepage. Preserve only the URL arguments required by campaigns or site functionality, and verify the resulting URLs and analytics behavior. When changes are delayed, clear the WPML cache under WPML → Support before checking other caches or styling conflicts. The final configuration should be tested across the individual theme, page types, mobile layout, redirects and analytics setup. Explore our WordPress plugins, WooCommerce extensions, themes and membership plans to find the right tools for your website.