web.config Redirects and URL Rewrite Rules in Plesk for Windows

Overview

On Plesk for Windows, redirects and URL rewrites live in the site’s web.config file, inside <system.webServer><rewrite><rules>. IIS reads the rules through its URL Rewrite module, so there is no .htaccess and nothing to restart: save the file and the rule is live. For the two most common jobs, HTTP to HTTPS and www to non-www, use Plesk’s own settings first and keep web.config for everything else.

This guide is for site owners and developers on Windows hosting with Plesk, whether a shared Windows plan or your own Windows VPS. It gives copy-ready rules for redirecting a page, a folder, a whole old domain and a long list of old URLs, shows the difference between a redirect and a rewrite, and explains the errors a bad rule causes, including the 500.19 that takes the whole site down.

Prerequisites

• A domain on Plesk for Windows and access to File Manager or FTP. New to the panel? See how to access Plesk on Windows Server.
• The IIS URL Rewrite module on the server. Plesk’s own HTTPS redirect depends on it, so it’s present on most Plesk Windows servers; if your rules produce error 500.19 (below), ask your host to check.
• A copy of the current web.config saved on your computer before you change anything.

Step-by-Step: Add web.config Redirects in Plesk

Step 1: Use Plesk’s settings for HTTPS and www

Go to Websites & Domains > your domain > Hosting & DNS > Hosting. Tick Permanent SEO-safe 301 redirect from HTTP to HTTPS and set Preferred domain to the www or non-www form. Plesk then handles both redirects for you, and you don’t need to write rules for them. If the HTTPS option isn’t available, the domain has no certificate yet; installing an SSL certificate in Plesk uses the same screens on Windows. After switching, check for mixed content warnings. The equivalent redirects for cPanel, Apache and Nginx are in how to redirect HTTP to HTTPS.

Step 2: Open web.config and understand its layout

In Files, open httpdocs and click web.config to edit it. If there isn’t one, create it. A minimal file with a rewrite section looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <!-- your rules go here, in order -->
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

If the file already exists (ASP.NET sites always have one), don’t paste a second <system.webServer> section. Add the <rewrite> block inside the existing one. Two sections of the same name is the fastest way to a 500.19 error.

Rules run top to bottom. stopProcessing="true" means “if this rule matches, don’t look at the rules below it”, which is what you want for redirects.

Step 3: Redirect a single page

<rule name="Old about page" stopProcessing="true">
  <match url="^about-us\.html$" />
  <action type="Redirect" url="/about/" redirectType="Permanent" />
</rule>

The match url pattern is the path without the leading slash, the domain or the query string. Writing ^/about-us\.html$ is the mistake I see most, and it simply never matches. Escape dots with a backslash, because an unescaped dot means “any character”.

Step 4: Redirect a whole folder

<rule name="Blog to news" stopProcessing="true">
  <match url="^blog/(.*)$" />
  <action type="Redirect" url="/news/{R:1}" redirectType="Permanent" />
</rule>

{R:1} is whatever the (.*) matched, so /blog/2025/launch goes to /news/2025/launch. Query strings are carried over automatically.

Step 5: Redirect an old domain to a new one

Add the old domain as a domain alias of the new site in Plesk, then put this rule in the new site’s web.config:

<rule name="Old domain" stopProcessing="true">
  <match url="(.*)" />
  <conditions>
    <add input="{HTTP_HOST}" pattern="^(www\.)?old-domain\.com$" />
  </conditions>
  <action type="Redirect" url="https://new-domain.com/{R:1}" redirectType="Permanent" />
</rule>

Every page keeps its path, which preserves most of the old domain’s search rankings. Keep the old domain registered and the rule in place for at least a year.

Step 6: Redirect a long list of URLs with a rewrite map

After a site rebuild you might have dozens of old addresses. One rule per URL gets slow to maintain; a rewrite map keeps them in a lookup table. The map goes inside <rewrite>, next to <rules>:

<rewrite>
  <rewriteMaps>
    <rewriteMap name="OldUrls">
      <add key="/products.aspx?id=12" value="/shop/blue-widget/" />
      <add key="/contact.aspx" value="/contact/" />
      <add key="/old-services.html" value="/services/" />
    </rewriteMap>
  </rewriteMaps>
  <rules>
    <rule name="Old URL map" stopProcessing="true">
      <match url=".*" />
      <conditions>
        <add input="{OldUrls:{REQUEST_URI}}" pattern="(.+)" />
      </conditions>
      <action type="Redirect" url="{C:1}" appendQueryString="false" redirectType="Permanent" />
    </rule>
  </rules>
</rewrite>

Here the keys do start with a slash and include any query string, because {REQUEST_URI} is the full path as the visitor requested it. appendQueryString="false" stops IIS adding the old query string to the new address.

Step 7: Rewrite (not redirect) for PHP apps and pretty URLs

A redirect sends the browser to a new address. A rewrite keeps the address in the browser and serves a different file behind it. PHP frameworks and WordPress on IIS need a rewrite that sends every request for a missing file to index.php:

<rule name="Front controller" stopProcessing="true">
  <match url="^(.*)$" />
  <conditions logicalGrouping="MatchAll">
    <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
    <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
  </conditions>
  <action type="Rewrite" url="index.php" />
</rule>

Put redirect rules above this one. A front-controller rule matches almost everything, so any redirect below it never runs.

Step 8: Test with curl, not the browser

Browsers cache 301 redirects, sometimes for days, so a mistake you’ve fixed can still look broken. Test from PowerShell with curl.exe; in Windows PowerShell 5.1 plain curl is an alias for Invoke-WebRequest, which follows redirects and hides the answer:

curl.exe -sI https://example.com/about-us.html

You should see HTTP/1.1 301 Moved Permanently and a Location: header with the new address. While you’re still experimenting, use redirectType="Found" (a 302, not cached) and switch to Permanent when the rule is right.

Common Issues & Troubleshooting

HTTP Error 500.19 – Internal Server Error (0x8007000d)

Cause: IIS can’t read web.config. Either the XML is malformed (a missing closing tag, an unescaped & in a URL) or the URL Rewrite module isn’t installed, so IIS doesn’t recognise the <rewrite> section.

Fix: restore your saved copy so the site comes back, then add the change again and check it in an XML validator. Write & in URLs as &. If a valid file with a single simple rule still fails, the module is missing; ask your host.

HTTP Error 500.19 with “Cannot add duplicate collection entry” (0x800700b7)

Cause: two rules have the same name, or the same rule is defined in web.config and at server level.

Fix: give every rule a unique name. If the duplicate comes from the server, rename yours.

Plesk’s HTTP to HTTPS redirect stopped working

Cause: Plesk adds its HTTPS redirect as a URL Rewrite rule above your site. A <clear /> line inside your <rules>, or a <remove> naming Plesk’s rule, deletes it. Code samples copied from the web often include <clear />.

Fix: delete the <clear /> or <remove> line from httpdocs/web.config and test again.

ERR_TOO_MANY_REDIRECTS

Cause: the redirect target matches the same rule again (for example ^blog redirecting to /blog-archive/), or your own HTTPS rule fights Plesk’s HTTPS or preferred-domain setting.

Fix: anchor patterns with ^ and $ so the target can’t match, and don’t write HTTPS or www rules when Plesk’s settings from Step 1 are on.

The rule works but Plesk later removed it

Cause: Plesk writes some hosting settings (default documents, handler mappings, ASP.NET options) into the same web.config. Custom rewrite rules normally survive, but a hand-edited file with unusual structure can be rewritten.

Fix: keep your rules in a clean <rewrite> block inside the single <system.webServer> section, and keep a copy of the file offline. For ASP.NET Core sites, the published web.config is overwritten on every deploy, so add your rules to the project’s own web.config as deploying an ASP.NET Core app in Plesk describes.

Running several Windows sites? A Windows Host & Tech VPS gives you full IIS Manager access alongside Plesk, which makes it easier to test rules in IIS’s built-in rule editor before saving them. For IIS on a server without Plesk, see how to install and configure IIS.