[Resolved] Avoid WPML to hijack redirect to another language domain
This thread is resolved. Here is a description of the problem and solution.
Problem: You are experiencing issues with redirects on your multilingual site, where users and Google bots are redirected to the incorrect language domain when visiting old URLs with language parameters. This problem arises after moving each language to a separate domain. Solution: Our investigation confirmed that WPML does not trigger redirects between languages when 'display as translated' mode is used. Instead, the same product is displayed on all language URLs without altering the slug or structure. We recommend implementing custom redirection rules in your redirection plugin or .htaccess. For example:
This approach depends on how your server handles redirects and the availability of target slugs. Additionally, check any server-level rewrites or caching layers that might enforce canonical redirects. If further customization is needed, consider contacting one of our certified partners: https://wpml.org/contractors/
Please note that this solution might be outdated or not applicable to your specific case. We highly recommend checking related known issues at https://wpml.org/known-issues/, verifying the version of the permanent fix, and confirming that you have installed the latest versions of themes and plugins. If the issue persists, please open a new support ticket for further assistance.
This is the technical support forum for WPML - the multilingual WordPress plugin.
Everyone can read, but only WPML clients can post here. WPML team is replying on the forum 6 days per week, 22 hours per day.
Background of the issue:
We have a multilingual site, evrotrans.lv, with 40,000 products, each having translations in three languages. Initially, all languages were on the same domain, but we later moved each language to a separate domain: evrotrans.lv (main site), evrotrans.fr, evrotrans.co.uk, and ru.evrotrans.lv. We are trying to redirect users from old language-specific URLs to the new domain-specific URLs.
Symptoms:
When a user or Google bot visits an old link with a language parameter, such as hidden link, they are redirected to the Latvian domain instead of the French domain. This is causing issues with Google indexing as many pages are being dropped.
Questions:
How can we prevent WPML from hijacking redirects to the correct language domain?
What steps can we take to ensure that users are redirected to the correct domain-specific URL?
Our end goal is to redirect any user visiting
hidden link
to
hidden link
At the moment we tried doing that with Rank Math Redirects and htaccess - but it didn't worked as WPML seems to be hijacking this redirect earlier
I checked this product hidden link and could see it has no translation into French (or any of the other languages. Please see the attached screenshot, no-fr-translation.jpg.Moreover, I can see that none of the products have translations into the different languages. It's possible that all the translations are in draft status. Please see the attached screenshot list-of-all-products.jpg. This typically occurs when you import products into your site but fail to complete the import process using the WPML Export and Import plugins.
In any case, the missing translations explain the redirection. WordPress is working to resolve this issue and therefore provides the product in the default language.
I confirm I see this product showing in French, Russian, and English. I'm unsure how you achieved this, but, at least to the best of my understanding, it is not translated with WPML. When I check any of the translated versions of this product from the front end and click the option to edit the product, I get the Latvian product editing screen: hidden link. Please see the attached edit-391312.jpg. And there I can see it is not translated. Please see the attached screenshot not-translated.jpg.
Could it be that we are seeing a cached version from previous versions of this site?
If you have no answer for this or an idea of how it happens, please proceed with the following. (You'd better try the following on a staging site and not on your live site.)
1. Clear and disable any caching on your site.
2. In WPML -> Languages -> Language URL format, switch from 'A different domain per language' to 'Different languages in directories'. Click the Save button, and re-save the permalinks of the site.
3. Switch the theme to the default WordPress theme, Twenty Twenty-Four.
4. Deactivate all the third-party plugins except WPML, Strings Translation, WooCommerce, and WooCommerce Multilingual & Multicurrency.
5. Check the following:
A. Do you see the translated version of the product?
B. Do you still get the redirection to the Latvian version of the product?
**** Important! Please make a full site backup (files and DB) before you proceed with those steps****
*** If your site is live, you might want to try those procedures in a staging environment or a snapshot of your site on your local server or another server. ***
Please note that my weekend is Friday to Saturday, and I'll be able to continue checking this issue and helping you on Sunday.
Regards,
Itamar.
Here is an overview of how site translations work:
All translations are done via String Translations + ACF.
For example product names are combined from car brand + part category + part ID number.
And those individual items are translated beforehand. Meaning we have all categories translated via wpml. Car brands and ids doesn’t need a translation, they are duplicated.
So in some way we are not using regular translations, however we are also not using some third-party tools and plugins to translate.
To the best of my understanding, your customizations make this case outside the scope of our support forum. I'm consulting with our second-tier supporters to gather their feedback on your case. I'll update you here once I have their reply.
George and Nigel, two of our second-tier supporters, have reviewed your case, and this is their finding.
Summary of Our Findings
Thank you for your patience while we investigated the redirect issue further with our second-tier supporters.
What We Confirmed:
Your current setup uses “display as translated” mode for products. This means that a product created in the default language (Latvian) is shown on the other language domains without being fully translated or duplicated as separate posts in those languages.
When this mode is used, WPML does not trigger redirects between languages. Instead, the same product is displayed on all language URLs without altering the slug or structure.
George’s Input:
Since your site was previously using language directories and has since been switched to language-specific domains, old URLs like /fr/product/... are no longer valid in the new domain setup.
George suggests using custom redirection rules in your redirection plugin or .htaccess to rewrite these URLs. For example:
He notes that this approach might work, but it depends on how your server handles redirects and the availability of target slugs.
Nigel’s Input:
Nigel tested both setups — languages in directories and languages in different domains — with the same “display as translated” configuration, and in neither case did WPML cause a redirect.
He confirmed that:
Product slugs remain the same across languages (e.g., /product/cap/ in both English and Spanish).
WPML does not redirect users back to the default language.
Therefore, WPML is not the component triggering the 301 redirect you're seeing.
Recommendation:
The redirect is likely triggered by WordPress itself or a server-level configuration (e.g., .htaccess, caching, Cloudflare rules).
We recommend testing with a clean redirection rule, as suggested by George, and reviewing any server-level rewrites or caching layers (e.g., Cloudflare, NGINX) that might enforce canonical redirects.
Since your setup includes custom logic (e.g., product titles via ACF and string translation, rather than standard WPML product duplication), this may be contributing to the issue and is outside the scope of standard WPML support. If you need further help with what you are trying to achieve, I would suggest you consider contacting one of our certified partners from this link:
