For SEO (Google), it’s useful to redirect renamed or moved pages or files to their new location.
Although DNN has built in functionality for renamed pages, this does not work for all situations.
The SEO redirect allows you to see the incoming 404’s and add a redirect to a new location if needed.

There's a download link for the latest version on the right of this on desktop and at the bottom of this page on mobile devices.

If you find any issues or suggestions please log them on Github
But please be aware that some of our choices are based on the options available in IIS / .NET / DNN.

This module is open source. We've published the source code on GitHub.

DNN does not generate 404 errors for URL's below an existing page.
For example: if /Banana does exist, there will not be a 404 error for /Banana/Green, even when that page does not exist.

This feature, introduced in version 2.4 of this module, will allow you to force that 404 by checking the page on the edit-page for Force-404.

So called static files are files normally not handled by .NET / DNN.
This are files like images, stylesheets, but also URLs that point to unsupported extensions like .php.
When you make a request to this type of URL and it does not exist, you get the IIS 404 page by default.
Our SEO Redirect supports a few options to also log static file 404 requests.

This module is helpful when you setup a new website and want to maintain your SEO ranking.
When you do this we advise you to use a subdomain for the new website and not a child portal.
So new.mywebsite.com and not mywebsite.com/new as the Portal Alias.
Due to the way DNN handles domain-names, the module can handle relative URL’s but not on child portals (without serious performance implications). When you use a subdomain you can use relative redirects and they will keep working when you switch to the live DomainName.

To explain the function of this module and some of the design choices we made, we’ll first explain how 404 page handling works in DNN.

DNN has some built in 404 handling, but this  also has some limitations.
The DNN Core functionality is mainly targeted at the situation where the URL of a page changes.
When you change the URL of a DNN page, the old URL remains in the TabURLs table in the database.

This helps to create redirects when you change the URL of a page, but it does not help for deleted pages as in that case the Tab URL is also removed.
This also does not cover URLs that never existed or static files (images, documents).
Moved pages are also not always correctly redirected by DNN.

Also the built in DNN redirect to the 404 page, only works for root pages.
URLs that point to higher levels will be severed as the first page up the tree.
This is "by design" because in DNN, detail-URLs of modules are handled by the module itself.
The core does not know what detail URLs (could) exist for a module on the page.

So for this page structure Example:

Home
Products
---- Product 1
---- Product 2
---- Product 3
---- Product 4
Contact

When a user requests the following URLs:
www.website.com/nothing:
The user will be shown the DNN 404 page.

www.website.com/products/nothing
The user will see the products page and not the DNN 404 page.

This is why our HttpModule is needed for redirects.
When you create a redirect for the “nothing” page in the second example, the HTTP module will do the redirect before DNN tries to serve it (as it would show you to the “products” page).

FYI; there is currently no way to force DNN show the 404 page for pages other than the root level.
To overcome this we introduced the "Force 404" list

Take the following steps:

1. Create your 404 page
2. Make sure the 404 page is a language Neutral page if you are gooing to redirect static files.
3. Put the module on the page, you probably want to hide the page from the menu.
4. Make sure that the page, as well as the SEO Redirect module are visible for all users.
5. Place the “message” content on the 404 page.

The module should be visible on the page for unauthenticated users, but it will not show any content to those users.

This base configuration will allow you to track and redirect all pages that are not a child of an existing root page.

To be able to redirect all possible DNN pages you would have to do that before DNN handles the URL.
The only way to do this is by using the HttpModule, which will fire before DNN tries to resolve the URL.
.(see section “DNN Pages & 404s“ above)

HTTP module (Configuration  IIS7):

Place this as the first element in <modules>

<system.webServer>
    <modules>
        <add name="SeoRedirectModule" type="FortyFingers.SeoRedirect.Components.SeoRedirectModule, 40Fingers.DNN.Modules.SeoRedirect" preCondition="managedHandler" />
    </modules>
</system.webServer>

If you want to log and redirect static files using our HTTP Module, you need to make sure these are also processed by >NET by adding this attriute to the <modules> entry in web.config:

<modules runAllManagedModulesForAllRequests="true">

This is the "easiest" option

But you can also use option C. for this..

If you are only interested in a specific extension (like php) you can make
IIS handle them through .NET by adding this rule to web.config:

<system.webServer>
…
<handlers>
…
<add name="php.redirects" path="*.php" verb="*" type="System.Web.UI.PageHandlerFactory" preCondition="integratedMode" />

In that case any existing urls (mostly from the previous website) are logged and redirected if you add the right redirect rules.
There's no need to add the entry under A.

When you want to server users the DNN 404 page when they request a non existant file, you can do this by adding a web.config entry.
You don't need to use the A. or B. option.
 

<system.webServer>
…
        <httpErrors>
            <remove statusCode="404" subStatusCode="-1" />
            <error statusCode="404" prefixLanguageFilePath="" path="/[path-to-your-404-page]" responseMode="ExecuteURL" />
        </httpErrors>
</system.webServer>

This has one limitation (for multi langual sites):
The 404 page needs to be a Neutral Culture page (as the redirect is done by IIS) and they need to have the same name on every portal.

When you log static 404s you should be aware that this will result in a long list of files.
Nowadays all websites get a lot of traffic by bots/hackers trying to get in.
A lot of this traffic will end up in your listings (like hacks for wordpress, joomla etc.)
This could potentially worry Admins and it would be best not to allow these attempts..
You can avoid this kind of traffic in many ways, but the most reliable we have found is by using URL rewrite rule in IIS.

You can block these requests by using the IIS URL rewriter functionality.
(Please note this is not installed by default, check that before dropping this in your web.config)

Here’s an example of the rules we use in web.config

<?xml version="1.0"?>
<rewrite>
    <rules>
        <!-- Block known incoming other CMS URLs -->
        <rule name="CMS" enabled="true" stopProcessing="true">
            <match url=".*"/>
            <conditions logicalGrouping="MatchAny">
                <add input="{URL}" pattern=".*joomla.*"/>
                <add input="{URL}" pattern=".*/wp-.*"/>
                <add input="{URL}" pattern=".*filezilla.*"/>
            </conditions>
            <action type="CustomResponse" statusCode="403" statusReason="Forbidden: Access is denied." statusDescription="You do not have permission to view this directory or page using the credentials that you supplied."/>
        </rule>

        <!-- Block Known |Incoming unsupported extensions -->
        <rule name="Extensions" patternSyntax="Wildcard" stopProcessing="true">
            <match url="*"/>
            <conditions logicalGrouping="MatchAny">
                <add input="{URL}" pattern="*.php"/>
                <add input="{URL}" pattern="*.ini"/>
            <add input="{URL}" pattern="*.ftpconfig"/>
            </conditions>
            <action type="CustomResponse" statusCode="403" statusReason="Forbidden: Access is denied." statusDescription="You do not have permission to view this directory or page using the credentials that you supplied."/>
        </rule>
    </rules>
</rewrite>

An admin will see the top 404s when logged in.
Here you can directly create a redirect for one of the URLs

Manage existing URLs through the Module Action “Edit Mappings”.
Here you can add, change or remove mappings.

The module also allows for regular expression parsing of URL paths, you can use regex like in the above screenshot (don’t forget to check the “use regex” checkbox):

https://www.mydomain.nl/oldpath/(.*)  

meaning a wildcard to everything after …path/

https://www.domainnew.nl/newpath/$1

The $1 references the above wildcard (you can use multiple variables)

In the module settings you can enable or disable a scheduled task that will remove logs from the logging table. You can specify a maximum number of log entries, and a maximum age in days. Other entries will be removed on a daily basis, but you can of course change the frequency yourself in DNN..

When you want to generate this list, make sure you also add a unique ID. This is used to identify the redirect internally.
The module itself generates a guid when you add an item, but if the id is unique the module should pick them up correctly.
 

The structure is as follows:

<?xml version="1.0"?>
<RedirectConfig xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <Mappings>
         <Mapping>
           <Id>a7df76ca-2bd6-4fb4-bda8-e62c949a8ae8</Id>
            <SourceURL><![CDATA[https://www.40fingers.net/Service/Contact]]></SourceURL>
            <TargetURL><![CDATA[https://www.40fingers.net/Contact]]></TargetURL>
            <TargetTabId>685</TargetTabId>
            <UseRegex>false</UseRegex>
        </Mapping>
        <Mapping>
           <Id>690b62c0-9500-4441-96e0-77194780cf60</Id>
            <SourceURL><![CDATA[.*\service]]></SourceURL>
            <TargetURL><![CDATA[https://www.40fingers.net/]]></TargetURL>
            <TargetTabId>120</TargetTabId>
            <UseRegex>true</UseRegex>
        </Mapping>
     </Mappings>
</RedirectConfig>

The ID can be something random as long as it's unique