0
votes

I am trying to move a complex redirect logic implemented in Global.asax into a set of rules for the IIS URL Rewrite module in a classic ASP.NET website. Shortly, the logic must redirect requests like

{http|https}://[www.]ourdomain.com/[Home/]Products/old-product-name/page.aspx

to

https://ourdomain.com/new-product-name/

(optional and variable parts are in square and curly brackets).

The first 3 main things I implemented with URL Rewrite rules are the followings:

<rule name="Redirect to HTTPS">
    <match url=".*" />
    <conditions>
        <add input="{HTTPS}" pattern="off" ignoreCase="true" />
    </conditions>
    <action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}" redirectType="Permanent" />
</rule>
<rule name="Canonical Host Name">
    <match url="(.*)" />
    <conditions>
        <add input="{HTTP_HOST}" negate="true" pattern="^ourdomain\.com$" />
    </conditions>
    <action type="Redirect" url="https://ourdomain.com/{R:1}" redirectType="Permanent" />
</rule>
<rule name="Default Page">
    <match url="(.*)default.aspx" />
    <conditions>
        <add input="{REQUEST_URI}" negate="true" pattern="-default.aspx$" />
    </conditions>
    <action type="Redirect" url="{R:1}" redirectType="Permanent" />
</rule>

These rules allow to redirect requests like http://www.ourdomain.com/product-name/default.aspx to https://ourdomain.com/product-name.

However, the browser developer tools report that this conversion causes 301 redirects. I tried to find a solution of this redirect chain problem in the Internet and found this post. After reading it, I managed to recode my rules to have just one final 301 redirect with URL rewriting:

<rule name="Redirect to HTTPS">
    <match url=".*" />
    <conditions>
        <add input="{HTTPS}" pattern="off" ignoreCase="true" />
    </conditions>
    <action type="Rewrite" url="_{REQUEST_URI}" redirectType="Permanent" />
</rule>
<rule name="Canonical Host Name">
    <match url="(.*)" />
    <conditions>
        <add input="{HTTP_HOST}" negate="true" pattern="^ourdomain\.com$" />
    </conditions>
    <action type="Rewrite" url="_{R:1}" redirectType="Permanent" />
</rule>
<rule name="Default Page">
    <match url="(.*)default.aspx" />
    <conditions>
        <add input="{REQUEST_URI}" negate="true" pattern="-default.aspx$" />
    </conditions>
    <action type="Rewrite" url="_{R:1}" redirectType="Permanent" />
</rule>

<rule name="FINAL REDIRECT" stopProcessing="true">
    <match url="^(_+)(.*)" />
    <conditions logicalGrouping="MatchAll" trackAllCaptures="false">
        <add input="{HTTP_METHOD}" pattern="GET" />
    </conditions>
    <action type="Redirect" url="https://ourdomain.com{R:2}" />
</rule>

However, this approach looks non-natural. It makes hard adding new rules because of these workarounds with the underscore character. And maybe, such several rewrite operations for one request may impact on the website performance.

Is there another, more elegant solution, of the 301 redirect chain problem for the URL Rewrite module?

1

1 Answers

1
votes

This is not a limitation of IIS Url Rewrite, but the way the web works. A redirection sends a header to the browser telling it that it should navigate to another place. If you have 3 rules that apply to the same original request, and the 3 apply a redirection, then you'll always get 3 redirections no matter how you do it: IIS Url Rewrite, Apache .htaccess or your own custom code.

The solution you've implemented is a "patch" to change several redirections into internal rewrites in the server and a final "catch" of those special rewrites to transform them into a unique redirection at the end (BTW, if you have any real page that strats with _ you won't be able to access it with this extra rule). That's not bad and won't affect your performance, but it's ugly.

I'm not a SEO expert but I think the 301 chaining thing to reach a final similar URL won't hurt your SEO at all in recent times, if that's what worries you (read the final part specially). And being 301 redirects they will affect only the first visit of your users, so probably won't hurt your loading times or conversions either anyway.

However, if you want to avoid that, try to make a single rule for your purpose, doing all the transformations at once. In your case, you want to transform this:

{http|https}://[www.]ourdomain.com/[Home/]Products/old-product-name/page.aspx

(I guess /Home/ can be present sometimes or not)

into this:

https://ourdomain.com/new-product-name/

Then you can use this single rule:

<rule name="New URLs!!" stopProcessing="true">
    <match url="^(Home/){0,1}Products/(.+?/).+.aspx" />
    <conditions logicalGrouping="MatchAny">
        <add input="{HTTPS}" pattern="off" ignoreCase="true" />
        <add input="{HTTP_HOST}" negate="true" pattern="^ourdomain\.com$" />
    </conditions>
    <action type="Redirect" url="https://ourdomain.com/{R:2}" redirectType="Permanent" />
</rule>

and you will transform everything with a single rule (so, just one redirect). The regular expression in the match URL part will identify this specific kind of URL (old product URLs) and the conditions (matching any of them) will take care of the HTTPs and domain change. The stopProcessing="true" will keep other rules to act, and you'll have this specific kind of URLs under control.

Please note that I've not tested this rule and maybe it has minor problems. But you get the idea...

You'll need extra rules after this one to take care of other less-specific URLs, such as your general HTTP to HTTPS or canonical domain rules. But in the case you want to resolve, this will achieve what you want in a single step.