Skip to content
Windows Hosting

How to Redirect HTTP to HTTPS on IIS

By 5 min read
In this article9 sections

Once a site has an SSL certificate, the plain HTTP address must redirect to HTTPS. Without that redirect, visitors and search engines reach both versions, and the search ranking splits between them. On Windows hosting, IIS handles the redirect with the URL Rewrite module and a rule in the site’s web.config file. This guide shows the rule, where it goes, how to test it, and how to avoid the redirect loop that catches many first-time setups.

SiteHarbour’s Windows hosting includes free SSL and IIS 10 on every plan. The redirect is part of the site’s own configuration, so it works the same way for an ASP.NET Core app and for a classic site.

Before you start

  • A working HTTPS address for the site. Check it in a browser, with the padlock showing, before you add the redirect.
  • The URL Rewrite module available on the server. It ships with IIS on the Windows plans. If the rule is rejected with an unknown element, ask your host to confirm the module is installed.
  • Access to the website’s files, through Plesk’s File Manager or SFTP.

Step 1: Add the redirect rule to web.config

Open web.config in the website folder. Inside the system.webServer element, add a rewrite section with one rule. If the file already has a rewrite section, add the rule to it rather than creating a second one:

<rewrite>
  <rules>
    <rule name="Redirect HTTP to HTTPS" stopProcessing="true">
      <match url="(.*)" />
      <conditions>
        <add input="{HTTPS}" pattern="^OFF$" />
      </conditions>
      <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent" />
    </rule>
  </rules>
</rewrite>

Expected: the file still parses, which you can see when the site loads. A syntax error in web.config stops the whole site, so keep a copy of the original before you edit it.

In an ASP.NET Core site, the aspNetCore element stays in the same system.webServer block. The rewrite rule goes before it, so the redirect runs before the request reaches the app.

Step 2: Check the redirect

From a terminal, request the HTTP address and read the response headers:

curl.exe -sI http://example.com/some-page | findstr /i "HTTP Location"

Expected: a 301 status and a Location header that starts with https://example.com/some-page. Check the request for the bare domain too. Use curl.exe on Windows, because PowerShell’s curl alias behaves differently.

Step 3: Watch for the redirect loop

A loop happens when the site thinks every request is HTTP, usually behind a proxy or a load balancer that terminates the TLS connection. The browser then keeps redirecting and shows “too many redirects”. The fix depends on the path. If Plesk’s own HTTPS redirect is also enabled, turn one of them off, so only a single redirect rule is active. If a proxy sits in front of IIS, the rule must check the forwarded protocol header instead of {HTTPS}:

<add input="{HTTP_X_FORWARDED_PROTO}" pattern="^http$" />

Use this only when the proxy sets the header, and only when the site is not reachable directly, because a client can send the header itself.

Step 4: Keep the redirect and the certificate together

Install the certificate for the domain before you enable the redirect. A redirect to an HTTPS address with no valid certificate shows a warning page, which is worse than the plain HTTP site. The certificate steps are in how to create a website and install SSL in Plesk.

Also check that the redirect covers the www address you use. If the site serves both, pick one version as the canonical address and redirect the other to it, so search engines see one address.

A redirect works for the visitor, but every link in the site that uses HTTP makes the browser redirect again, and it slows the page. Search the site’s files for http:// and change the links you control to HTTPS. Leave links to sites that do not offer HTTPS as they are.

Step 6: Check the search engine side

Submit the HTTPS address as the property in your search console, and keep the HTTP property, so you can see the redirect working. Check the sitemap address too: it should be served over HTTPS and list only HTTPS pages.

Common mistakes

  • A redirect with no certificate. Install the certificate first.
  • Two redirects. Plesk’s option and a web.config rule together can loop. Use one.
  • A broken web.config. Keep a copy of the original before you edit, and test the site immediately after.
  • Using 302 instead of 301. A temporary redirect does not pass the ranking to the HTTPS address the way a permanent one does.
  • Ignoring the mixed content. A redirect does not fix an image that loads over HTTP inside a page.

Frequently asked questions

Is a 301 redirect the right status code?

Yes. A permanent redirect tells search engines that the HTTPS address is the real one, so the ranking moves to it.

Can I use Plesk’s option instead of a rule?

Yes, for most sites. Use the rule when you need a specific pattern, or when a proxy sits in front of the server. Use only one of them.

Why does the redirect work in my browser but not in a test?

A browser may cache a redirect you made earlier. Test with curl, which does not cache, or clear the browser’s cache and try again.

Does the redirect affect my ASP.NET Core app?

Only the requests it matches. The app itself does not need to change, as long as the rule runs first.

A correct HTTP to HTTPS redirect on IIS is one rule in web.config, placed after the certificate is working. Test the response with curl, watch for a loop if a proxy is involved, and change the internal links to HTTPS. For the full setup of a new Plesk website, read how to create a website and install SSL in Plesk.

Share this guide

Keep exploring