Have you ever created an Azure Web App to host a website or blog? Did you then decide to purchase a custom domain, and now want to re-direct all traffic to that custom URL? That’s the scenario that I found myself in recently (even though I’ve had a custom domain for several years). The reason for that is, I’m not a developer. So after purchasing my custom domain, I never really thought about the “other” URLs that also still pointed to my site.


When you first create an Azure Web App, there is a field for Instance Name. This will become the initial URL of your site (ie. AdinErmie.AzureWebsites.Net). While this is fine, if you have purchased a custom domain name (ie. AdinErmie.com), you want people to use that URL vs the default one provided by Azure.

Azure Web App - Instance Name
Azure Web App – Instance Name

The real root of my issue stemmed from my use of the WordPress plugin called Jetpack. Because I had purchased a custom domain (and even though I configured the Azure Web App to use this custom domain) Jetpack would constantly (even several times a day) place itself into “safe mode” due to finding my site via the *.AzureWebsites.Net URL. Even though I would select “Fix Jetpack’s Connection” and “Migrate Stats & Users” to indicate that AdinErmie.com was the “new” location of AdinErmie.AzureWebsites.Net, the message would still return.

Wordpress Jetpack Plugin - Safe Mode
WordPress Jetpack Plugin – Safe Mode


Since I’m running an Azure Web App, it’s not like I have access to the underlying IIS server directly. However, there are still methods available to access and modify the files you need to. To get to this area, login to the Azure portal, navigate to your Azure Web App, and click on the ‘Advanced Tools’ option under the Development Tools heading. When you do this, you will see a simple explanation page, with the word “Go” with an arrow. Click on ‘Go’ and you will be re-directed to the Kudu service for your Web App.

Note: If for some reason you can’t navigate to the right location in the portal (perhaps due to lack of permissions), the Kudu service for your Azure Web App has the URL pattern of: https://SiteName.scm.azurewebsites.net/

Azure Web App - Advanced Tools
Azure Web App – Advanced Tools

From there, navigate to Debug Console > CMD. You’ll notice that there is a CMD and a PowerShell option. In this case, it doesn’t matter what option you choose, since we won’t be using the command-line interface. But, if you are more comfortable with the CLI, choose the appropriate shell.

Azure Web App - Kudu Environment - Debug Menu
Azure Web App – Kudu Environment – Debug Menu

From the file/folder menu that’s presented, navigate to site/wwwroot/ and scroll down a little to locate the web.config file. When you find the file, click the pencil icon to edit it.

Important: It is strongly recommended that you download and save a backup copy of this file before you make any potential site-breaking changes!

Azure Web App - Web.Config File
Azure Web App – Web.Config File

When you edit the file, you need to add a redirect rule within the <RULES> section like so. Notice that I actually have 2 redirects in my rule, one for the *.AzureWebsites.Net URL, and another for the WWW.* URL.

Don’t forget to hit SAVE!

Azure Web App - Modified Web.Config File
Azure Web App – Modified Web.Config File

For posterity, here is the code block, so that you can more easily copy/paste it for your needs.

<rule name="Redirect requests from default Azure websites domain" stopProcessing="true">
<match url="(.*)" /> 
<conditions logicalGrouping="MatchAny">
<add input="{HTTP_HOST}" pattern="^adinermie\.azurewebsites\.net$" />
<add input="{HTTP_HOST}" pattern="^www\.adinermie\.com$" />
<action type="Redirect" url="https://AdinErmie.com/{R:0}" appendQueryString="true" redirectType="Permanent" />

Now that we have that modification in place, whenever anyone hits either of these other URLs (namely http://AdinErmie.azurewebsites.net or http://www.AdinErmie.com), they will be redirected to my primary custom domain of https://AdinErmie.com.


And so, that’s it! If you find yourself in a similar situation, you’re now armed and prepare to make the required modifications, to ensure all traffic is being directed to your custom domain name, regardless of how someone may locate your site’s content.