Sitecore Reverse Proxy (8.1 → 10.4) – Part 2: Solving Language Code and Media Issues

- August 28, 2026

In my previous post , we covered how to install the ARR (Application Request Routing) module in IIS to set up a reverse proxy.

Before configuring the reverse proxy, there's one important thing to consider: we're not just proxying the homepage URL, but also the static assets used on the homepage, such as:

CSS
JS
images

While implementing this reverse proxy, I ran into a number of issues when a language code was present in the domain for the homepage.

Let me walk through the issues I faced so this can be helpful to others.

Our new Sitecore 10.4 instance has two language versions, en and ar, so I created IIS rules to handle this as shown below. However, no redirect happened from the old site to the new Sitecore site for the homepage.
I first focused on getting the reverse proxy working without a language code in the URL, as shown below for the homepage.
The reverse proxy wasn't working; I still got the old site's homepage when loading the domain. I traced this to the fact that the homepage was still being resolved by the old Sitecore 8.1 site because of Sitecore's pipelines. So, I added a custom item resolver pipeline to abort the pipeline when the request was for the homepage ("/"). This resolved the issue for the homepage without a language code; the page now loaded correctly from the new Sitecore site.
Next, I focused on handling the language code for the homepage using the IIS rule below. However, after applying the rule, the page still loaded the old site's homepage whenever a language code was passed in the domain. This was odd, since the rule was in place, and we have also added the homepage paths "/", "/en", and "/ar" to the item resolver to abort the pipeline so the IIS rules could pick up the request and reverse-proxy it to the new homepage in the requested language.
Even though the pipeline aborted correctly when a language was passed in the domain (ex: {domainname}/en), the reverse proxy still wasn't happening.
I tried several different approaches and confirmed that ARR was properly enabled in IIS and that the rewrite rules were also correct. The issue only occurred with reverse proxy rules; when I used a redirect instead of a rewrite in the IIS rules (just to confirm the rules were firing after the Sitecore pipeline aborted), it correctly took me to the new site's homepage. The catch was that the browser URL also changed to reflect the actual domain of the second site, as shown below.
This confirmed that the rules were firing, but the request wasn't being properly proxied. I re-checked the item resolver and found no issues; it was aborting the pipeline correctly. So something else was causing the failure specifically when a language code was present in the domain URL.
This pointed to the possibility that the language segment was being stripped somewhere in the Sitecore pipeline. I checked the Sitecore.config file on both the old and new Sitecore instances and confirmed both had identical settings, as shown below.

These settings helped confirm that the language code passed with the homepage request was indeed being stripped.
I then tried updating the Languages.AlwaysStripLanguage setting to false. After that, requesting {domainname}/en threw a 404 instead of the 500 it had thrown previously with the setting set to true.

In this case, the old site was trying to resolve "en" as a separate Sitecore item, attempting to find it in the old instance, but since no such item existed, it threw a 404.
Based on this analysis, it was clear that some custom handling was needed for the language code. So, I created a custom pipeline inheriting from StripLanguage, designed to ignore the en and ar language codes instead of following the default StripLanguage behavior.
After implementing this CustomStripLanguage pipeline, the reverse proxy started working correctly for domains with a language code. At this point, we had both the custom item resolver and the CustomStripLanguage pipeline in place.
Now we have both the custom item resolver and the CustomStripLanguage pipeline.

Media Assets:
To serve media assets from the new Sitecore instance on the homepage, I ran into another problem: both sites were serving images from the same media folder structure, which created conflicts between the old and new Sitecore instances. As a result, the reverse proxy didn't work for media items; the only shared media items that worked correctly were ones used identically on both sites, like the logo (which, in this case, was actually still being served from the old site with no reverse proxy involved).
To fix this, I created a dedicated folder and added all homepage-related media assets there, since we needed to reverse-proxy the media URLs. By default, all Sitecore media URLs start with /-/media/. I excluded this specific route from Sitecore processing using the IgnoreUrlPrefixes setting (ex: /-/media/foldername). After applying this rule, all media items within the ignored folder were correctly served from the new Sitecore instance, while all other images continued to be served from the old Sitecore site.
I also created the corresponding IIS rules to reverse-proxy these media items.