IIS Redirects and Rewrites in Front of SharePoint Server

Putting IIS URL Rewrite in front of SharePoint Server is a well-trodden way to solve problems SharePoint itself does not address: retiring an old URL, forcing HTTPS, moving a site without breaking every bookmark in the organisation.

It is also a well-trodden way to break a farm subtly, because SharePoint is unusually sensitive to what happens to its URLs in transit. This covers what is safe, what is not, and why.

Redirect or rewrite — the distinction that matters

These are frequently confused and behave completely differently.

	Redirect	Rewrite
Who sees the new URL	The browser	Only the server
HTTP status	301 or 302	200 — no redirect occurs
Address bar	Changes	Unchanged
Extra round trip	Yes	No
Safe in front of SharePoint	Generally yes	Rarely

Redirects are usually fine. Rewrites usually are not. SharePoint generates absolute URLs based on the request it believes it received, and constructs links, form posts and callbacks from them. Rewriting the path underneath it means SharePoint builds links for the internal URL rather than the one the user is browsing, and those links then fail.

Where an internal-to-external URL translation is genuinely needed, SharePoint's own Alternate Access Mappings are the supported mechanism. They exist precisely because the platform needs to know about the translation rather than have it hidden from it.

Redirects that are safe and useful

Forcing HTTPS

The most common and least contentious rule:

<rule name="Force HTTPS" stopProcessing="true">
  <match url="(.*)" />
  <conditions>
    <add input="{HTTPS}" pattern="off" />
  </conditions>
  <action type="Redirect" url="https://{HTTP_HOST}/{R:1}"
          redirectType="Permanent" appendQueryString="true" />
</rule>

Set the zone to HTTPS in Alternate Access Mappings as well. IIS handling the redirect while SharePoint still believes it is serving HTTP produces mixed-content problems and broken postbacks.

Retiring an old path

<rule name="Retired department site" stopProcessing="true">
  <match url="^sites/old-finance/?(.*)" />
  <action type="Redirect" url="/sites/finance/{R:1}"
          redirectType="Permanent" appendQueryString="true" />
</rule>

redirectType="Permanent" emits 301, which is what you want for a genuine move — browsers and search engines cache it. Use Found (302) only while a move is genuinely temporary, because a cached 301 is difficult to undo.

The paths that must never be touched

This is the part that turns a working rule into an outage. SharePoint depends on a set of paths for its own operation, and a broad pattern will catch them.

<rule name="Leave SharePoint internals alone" stopProcessing="true">
  <match url="^(_layouts|_vti_bin|_api|_windows|_forms|_catalogs)/" />
  <action type="None" />
</rule>

Place this first, before any broad rule. Rules evaluate in order and stopProcessing="true" halts the chain, so an exclusion placed after a catch-all never runs.

What each path does, and what breaks:

• _layouts — application pages, settings screens, the ribbon. Break it and the interface stops working.
• _vti_bin — legacy web services still used internally by parts of the product.
• _api — the REST endpoint. Every modern client and integration depends on it.
• _windows, _forms — authentication endpoints. Break them and nobody signs in.
• _catalogs — master pages, page layouts and the solution gallery.

Testing before it reaches users

The failure mode with rewrite rules is that the front page looks fine and something specific breaks — a settings page, an integration, sign-in for one authentication type. A short checklist catches almost all of it:

1. Browse the site collection root and a subsite
2. Open Site Settings, a list settings page, and the ribbon on a document library
3. Upload a document and edit a list item
4. Request /_api/web and confirm it returns rather than redirecting
5. Sign out and sign in again, using every authentication method configured
6. Exercise any integration that calls the farm
7. Check the IIS logs for unexpected 301s on _layouts or _api

Use the Rewrite module's test facility in IIS Manager for the pattern itself, but test the behaviour in a browser. A regular expression that matches correctly can still catch a path you did not intend.

Common mistakes and better practice

• Rewriting rather than redirecting. SharePoint builds absolute URLs from the request it thinks it received. Use Alternate Access Mappings for translation.
• Catch-all rules with no exclusions. They will match _layouts and _api. Exclude those first.
• Exclusions placed after the catch-all. Order is everything; stopProcessing ends the chain.
• Editing web.config by hand on one server. A farm has several. Configuration must be consistent, and manual edits are easily lost when SharePoint rewrites the file.
• Permanent redirects while still experimenting. Browsers cache 301s aggressively. Use 302 until the move is settled.
• Forcing HTTPS in IIS without updating Alternate Access Mappings. SharePoint keeps generating http links.
• No rollback plan. Back up web.config before changing it. Recovery should be a file copy, not reconstruction.

Troubleshooting

Symptom	Cause	Resolution
Site loads but is unstyled	A rule is catching _layouts	Add the internals exclusion, placed first
Integrations fail after a rule change	_api being redirected	Exclude _api; check IIS logs for 301s on it
Redirect loop	The target matches the rule that produced it	Add a condition excluding the destination
Nobody can sign in	Authentication endpoints redirected	Exclude _windows and _forms
Rule works on one server only	web.config differs across the farm	Apply consistently to every web front end
Old redirect persists after removal	301 cached by the browser	Clear the cache; verify with a private window

Frequently asked questions

Is URL Rewrite supported in front of SharePoint?

IIS-level redirects are commonly used and generally safe. Rewriting URLs that SharePoint then serves is where problems begin, because the platform builds absolute links from the request. Prefer Alternate Access Mappings for translation.

Redirect or rewrite for retiring a URL?

Redirect, with 301. It tells browsers and search engines the resource has moved, and leaves SharePoint's own URL handling untouched.

Why does the site look broken after adding a rule?

Almost always _layouts being caught by a broad pattern. Exclude SharePoint's internal paths first.

Does any of this apply to SharePoint Online?

No. There is no IIS layer to configure. Use SharePoint Online's own redirect capabilities or a front-end service.

Where should the rules live?

In the web application's configuration, applied consistently across every web front end. Back the file up before changing it.

The rule that prevents most incidents

Exclude SharePoint's internal paths, and put the exclusion first. Nearly every "the farm broke after we added a redirect" story is a broad pattern matching _layouts or _api, and a five-line exclusion rule at the top of the list prevents all of them.