Polylang Multisite Language Switcher Redirected to Main Domain and the SiteURL Override That Fixed Subsite Language Routing

Published On - November 26, 2025

ivan Blogging

Managing a multilingual WordPress site with Polylang in a multisite environment can be both a blessing and a curse. While Polylang offers a powerful way to translate content and handle language locales, integrating it seamlessly into a multisite setup can present obstacles that aren’t always adequately addressed in documentation. One of the most common issues experienced by developers and site administrators alike is an unexpected redirect to the main domain when switching languages using Polylang. But thankfully, there is a solution—overriding the site URL for each subsite. This article breaks down the problem, explores the cause, and offers a clean, working fix.

TL;DR

When using Polylang across a WordPress multisite network, users may encounter a bug where language switchers redirect them to the main site domain, instead of the expected subsite. The issue typically stems from incorrect or default handling of the site URL value. By explicitly overriding the site_url in a targeted way for each subsite, developers can retain proper language routing. This guide walks through the problem and shows how to implement the fix effectively.

Understanding the Problem

Polylang is known for its adaptability in managing multilingual content. In standalone sites, it rarely exhibits critical issues. But in a multisite WordPress setup, where each subsite may represent a different language or region, users often notice that switching languages via a widget or menu redirects to the main domain instead of staying within the current subsite.

This behavior defeats the purpose of having multiple subsites and can cause serious confusion or errors for users, especially on websites that are segmented by region. Imagine a French user trying to switch to the English version of the site, only to be redirected to the homepage of the parent domain—that’s not a user-friendly experience.

Symptoms of the Issue

  • The Polylang language switcher redirects to the main site instead of staying within the subsite.
  • Translated permalinks lead to 404 errors or unexpected destinations.
  • Language-specific domains or subdirectories do not resolve correctly.

A Deep Dive into the Cause

At the core of the problem lies how WordPress handles site_url and home_url in a multisite configuration. Polylang relies on these internal functions to generate URLs for language-specific links, menu items, and switchers. When site_url defaults to the main domain due to improper configuration or plugin interference, the result is misrouted language changes.

In essence, Polylang assumes the base URL should be that of the current context (the current subsite). However, in some environments—particularly those relying on domain mapping or manually configured redirections—WordPress returns the main site’s URL instead, causing all Polylang-generated URLs to point to the parent domain.

The Workaround: Overriding site_url

To correct this routing misbehavior, developers can override the site_url programmatically to ensure WordPress and Polylang always return the correct subsite base URL. This fix involves tapping into WordPress’s filters and selectively rewriting the site_url value when Polylang or related functions request it.

The key is to prevent this fix from applying globally, which could break the main site’s behavior. Instead, the override must be scoped to specific subsites.

Code Snippet to Fix Language Routing

The following code can be added to the functions.php file of the relevant subsite or within a custom site-specific plugin:

add_filter('site_url', function($url, $path, $scheme, $blog_id){
    if (is_main_site()) {
        return $url;
    }

    $current_blog = get_blog_details($blog_id);
    if ($current_blog) {
        return set_url_scheme($current_blog->siteurl, $scheme);
    }

    return $url;
}, 10, 4);

This snippet checks whether the site is the main site. If not, it fetches the correct siteurl for the subsite and forces WordPress to use it. As a result, any plugin—including Polylang—depending on site_url for link generation receives the appropriate domain or path.

Alternative Scenario: Domain Mapping

For sites using domain mapping (e.g., different top-level domains for each language or region), WordPress sometimes serves domain information inconsistently, especially if the mapping plugin does not hook correctly into site_url and home_url.

If you’re using plugins like WP Multisite Domain Mapping or a managed host doing domain mapping at the DNS/server level, the fix might need to incorporate home_url overrides in a similar fashion. Always test on staging environments before pushing to production.

Testing and Verification

Once the fix is in place, be sure to test it thoroughly:

  • Use different browsers and incognito modes to simulate a first-time user experience.
  • Switch languages using the Polylang menu or widget and confirm the destination remains in the same subsite.
  • Check SEO-friendly URLs for translated pages to confirm proper behavior.
  • Monitor error log files or console outputs in case other plugins conflict with the changes.

Best Practices for Multisite + Polylang Deployment

To ensure a smooth ongoing experience with Polylang in a multisite network, keep the following best practices in mind:

  • Use consistency: Make sure that each subsite uses a consistent permalink structure and language code.
  • Audit domains: Whether using subdomains, subdirectories or custom domains, ensure they are configured correctly at the server level.
  • Limit plugin conflicts: Only install plugins on subsites when necessary to reduce global conflicts.
  • Backup regularly: Before testing new configurations or filters, always back up your database and files.

Frequently Asked Questions (FAQ)

Why does Polylang redirect to the main site in a multisite setup?

This typically happens when WordPress returns the main blog’s URL instead of the current subsite’s. Polylang depends on functions like site_url() for creating switched URLs. If these functions return incorrect values, users are redirected inappropriately.

Is the override filter safe for production use?

Yes, when scoped correctly, such as checking with is_main_site() or other identifiers, it provides a safe method to fix URL routing without affecting the entire network.

Can this fix work with subdirectory multisites?

Absolutely. Whether using subdomains or subdirectories, as long as each subsite has a distinct siteurl, the override method will maintain correct routing.

Do I need to install any additional Polylang add-ons?

No, the base version of Polylang supports multisite configurations. However, for more advanced features like translating slugs or WooCommerce integration, the Pro version or add-ons may be beneficial.

Will this work with WPML or TranslatePress?

This article specifically addresses Polylang. WPML and TranslatePress handle language routing differently, and while the concept is similar, the implementation of overrides will differ across plugins.

Conclusion

Fixing unintended redirects in a Polylang multisite environment isn’t just about plugging in a filter—it’s about understanding how WordPress generates URLs and how Polylang depends on them for language switching. From overriding site_url to accounting for domain mapping intricacies, this guide offers a step-by-step strategy to eliminate redirect bugs and ensure clean, consistent language navigation across your multisite network. Done right, it restores usability and preserves the multilingual UX that Polylang users value so highly.