How to Recover Search Traffic by Fixing 404 Errors After WordPress Language Migration

For those managing both English and Bengali content on the same website, structuring the site correctly is a paramount aspect of technical SEO. A highly effective and common way to maintain a balance between the two languages is to separate them structurally. This usually implies keeping the main English version on the root domain while setting up a dedicated sub-domain for the Bengali version. However, if you alter this structure for any reason and the transition isn’t executed flawlessly, you risk facing severe complications, such as losing your traffic alongside a complete halt in site indexing.

Recently, I decided to go ahead with this language migration on one of my own websites. Our technical team executed the task well. However, over the following three months, I noticed that we weren’t getting any readers or expected traffic on Analytics; instead, a massive number of articles were racking up ‘Not Found’ errors.

When I hopped onto Google Search Console to investigate, I was absolutely shocked. While a few articles from the English or main site had been indexed, almost none of the articles on the newly created Bengali sub-domain had made it to the index. Readers were naturally landing on the main site by following the old URL structures of the articles, and upon finding no content, they were bouncing right back. This exact scenario was playing out across all of my sites where I had moved the language version over to a sub-domain.

Having successfully sorted out the issue, I felt it was essential to document the process online, so that anyone else running into a similar predicament can deploy the solution effortlessly.

Table of Contents

The Oversight of Migration and Its Cost

To give you some context, my initial site setup looked like this:

economicsgoln.com was the primary root domain, entirely in Bengali.

en.economicsgoln.com was a sub-domain dedicated to English content.

Due to a specific requirement, I had to swap this entire structure around. My staff migrated all the content from the English sub-domain (en.economicsgoln.com) to the root domain economicsgoln.com, whilst transferring all the existing Bengali content from the root domain over to a brand-new sub-domain: bn.economicsgoln.com.

Following the switch, the English content that had been moved to the root domain indexed perfectly fine within about three months. The real nightmare, however, began with the Bengali content; the new sub-domain bn.economicsgoln.com was struggling to index properly even after three long months.

Upon auditing Google Search Console, I discovered that Google’s index was still holding onto the old Bengali URLs mapped to the root domain. Consequently, organic search visitors looking for Bengali articles were landing straight onto the root domain. Since those Bengali posts were no longer present there, both the visitors and Google’s crawl bots were greeted by a blank ‘404 Not Found’ error, causing our bounce rate to skyrocket.

This conflicting signal completely threw off Google’s crawling algorithm. Spotting a massive influx of 404 errors where healthy, functional URLs used to sit, the algorithm put a total freeze on indexing the new sub-domain.

The only permanent remedy was to implement a ‘301 Permanent Redirect’ from every single old Bengali URL on the root domain to its exact corresponding URL on the new sub-domain. But with hundreds of legacy articles on the site, mapping individual redirect rules manually was an impossible and incredibly time-consuming chore.

An Automated Technical Solution via Unicode Filtering

To circumvent spending days on manual mapping or damaging the site further, I wrote a snippet of PHP script to fully automate the entire process. The objective was crystal clear: the script must completely ignore the new English URLs on the root domain, but the moment a visitor or search engine bot hits an old Bengali URL, it should instantly detect the language and route them to the correct URL on the new sub-domain.

This solution relies fundamentally on Unicode character filtering. The logic exploits the specific digital code range reserved for the Bengali alphabet to scan incoming URLs in real-time. The redirect only triggers if a Bengali character is detected within the URL path. The biggest advantage of this approach is that it preserves any tracking tokens or AMP parameters attached to the end of the link, ensuring visitors don’t encounter broken pages once they land on the sub-domain.

Implementation Method 1: Using the Theme’s functions.php File

If you are reasonably comfortable navigating the WordPress admin backend, we can implement this automated redirect without bloating the site with heavy plugins. Using the theme’s backend code is the most lightweight method available.

Log into the WordPress dashboard of your primary English site (economicsgoln.com). Navigate to Appearance > Theme File Editor from the left-hand menu (alternatively, use cPanel/FTP to go to the wp-content/themes/your-active-theme/ directory). Locate your functions.php file and paste the following code right at the very bottom:

add_action( ‘template_redirect’, function() {

$request_uri = $_SERVER[‘REQUEST_URI’];

$path = wp_parse_url( $request_uri, PHP_URL_PATH );

$query = wp_parse_url( $request_uri, PHP_URL_QUERY );

if ( $path && preg_match('/[\x{0980}-\x{09FF}]/u', urldecode($path)) ) {
    
    $destination_url = '[https://bn.economicsgoln.com](https://bn.economicsgoln.com)' . $path;
    
    if ( $query ) {
        $destination_url .= '?' . $query; 
    }
    
    wp_redirect( $destination_url, 301 );
    exit;
}

});

How the Code Works (Line-by-Line Breakdown)

wp_parse_url: This function allows us to cleanly split the core page URL path (/post-name/) away from any trailing query parameters (?amp=1 or ?fbclid=…). This guarantees that URLs don’t break or throw a 404 error after being forwarded to the sub-domain.

preg_match(‘/[\x{0980}-\x{09FF}]/u’, …): This acts as a digital Unicode filter. The range U+0980 to U+09FF defines the block allocated for the Bengali script in computing. Consequently, the script only springs into action if the URL contains Bengali characters, leaving English pages completely untouched.

wp_redirect(…, 301): This sends an explicit ‘permanent redirect’ signal to Google’s crawlers. It informs Google that all the historical SEO authority and ranking power of the old Bengali links on the root domain should now be passed entirely to the new sub-domain.

Implementation Method 2: Using the Code Snippets Plugin (Safer for Beginners)

For beginners, editing the theme’s functions.php file directly carries an element of risk. A single missing semicolon (;) or an misplaced bracket can bring the entire website down, triggering a Critical Error.

The easiest and safest way to bypass this risk is by utilizing the Code Snippets plugin. The beauty of this plugin is that it leaves your theme files completely stock, meaning your custom code won’t get wiped out when the theme updates. Here is the step-by-step setup guide using the plugin:

Install and Activate the Plugin

Go to Plugins > Add New from your WordPress dashboard side-menu. Type “Code Snippets” into the search box on the top right. Once you locate the plugin (by Code Snippets Pro), click Install Now and follow up by clicking Activate.
Create a New Code Snippet

Once activated, a new menu option labelled Snippets will appear on your dashboard. Click Add New. In the top Title field, give it an identifiable name like: Bangla URL 301 Redirect to Subdomain.
Paste and Save the Code

In the large text area below the title, paste the exact core PHP code provided above. Right below the code editor, ensure the option “Run snippet everywhere” is checked (this is usually selected by default). Scroll down to the bottom and hit Save Changes and Activate.

A Crucial Warning: If Your Site Uses ‘LiteSpeed Cache’

If your server runs the LiteSpeed Cache (LSCache) plugin, you might notice the problem persists even after adding the code. This happens because LiteSpeed often caches the old 404 (Not Found) pages of the root domain. As a result, returning visitors might still see the cached 404 error page repeatedly instead of being redirected.

To clear this roadblock, you must tweak a minor setting inside LiteSpeed Cache right after activating your script:

From the WordPress dashboard, head to LiteSpeed Cache > Toolbox.
Click on the Purge tab at the top.
Click the Purge All button to clear out all legacy cache from the site.
Next, navigate to LiteSpeed Cache > Cache from the side menu.
Switch over to the Advanced tab at the top.
Look for the setting named “Cache 404 Pages”. If this is toggled ON, change it to OFF, then scroll down and hit Save Changes.

Disabling the caching of 404 pages ensures the LiteSpeed server doesn’t hold onto error screens, allowing our PHP script to scan incoming URLs flawlessly on every single hit.

How to Test the Redirect After Setup

Once the code is in place—either via your theme file or the plugin—you should validate that it’s working properly using these three simple diagnostic steps:

Live Testing Using Browser Incognito Mode

To prevent old local browser cache from interfering, open an Incognito Window or private browsing session in Google Chrome or your browser of choice. Type out a full legacy Bengali URL from your root domain into the address bar (e.g., https://economicsgoln.com/সামষ্টিক-অর্থনীতি/) and hit enter. If the page seamlessly and instantaneously transitions to the new sub-domain URL structure (https://bn.economicsgoln.com/সামষ্টিক-অর্থনীতি/) without any errors, your code is working beautifully.
Testing Tracking or AMP Parameters

Traffic originating from platforms like Facebook or Google often comes appended with extra URL parameters. To ensure the script handles these properly, append a test parameter to your old Bengali URL path and press enter, like so: https://economicsgoln.com/সামষ্টিক-অর্থনীতি/?amp=1 or https://economicsgoln.com/সামষ্টিক-অর্থনীতি/?fbclid=123. After the redirect takes place, verify that the parameter (?amp=1 or ?fbclid=123) is still perfectly preserved at the end of the new sub-domain URL and the page loads without throwing a 404 error.
Technical Verification of the 301 Response Code

To be absolutely certain that Google’s crawlers interpret this as a legitimate “301 Permanent Redirect”, use a free online header checker tool like httpstatus.io or redirectcheck.com. Paste your legacy root domain Bengali URL into the tool and run the analysis. If the results return a green 301 Moved Permanently status code pointing to your new sub-domain URL as the destination, your technical SEO migration is flawless.

Once I deployed this code and flushed out the LiteSpeed cache on my network, Google’s crawl bots rapidly picked up the changes, indexing the new sub-domain URLs within days, and our analytics numbers bounced right back to life.