DNN websites, modules, skins and support

Introduction to the DNN SEO Redirect module

The SEO redirect module was first created by 40FINGERS  in 2012 when we “converted” a client website from PHP to DNN. Because the existing website ranked quite well in google we needed a way to add mapping for redirects from the old pages to the new ones.
Over the years we have add more functionality to the module and its interface and we now use it on most of our websites.

If there's something unlcear in this manual or if you find a typeo, please us know: https://github.com/40fingers/DNN-SEORedirect.

404 and 301

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.

Issues & suggestions

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.


- The module can logs what URLs generate a “Page not Found” on the 404 page.
- An admin can see a list of 404s and add redirect (301) rules to another location.
- This is possible for DNN pages and static files.
- The mappings are stored in an XML file in the portal Folder.
This allows you to prepare a redirect list when moving a website from another system to DNN.

Force 404 on URL's with an existing top-level page

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.

Static Files

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.

A note on setting up a new DNN website

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.

How SEO Redirect Works

SEO redirect consists of 2 parts.

  1. A DNN module you place on your 404 page.
  2. A .NET HttpModule to do redirects before DNN resolves the URL.

There are three types of 404s you can log/redirect.

  1. DNN pages
  2. Static Content (images, documents, php etc.)
  3. Non existant URLs

DNN Pages & 404s

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:

---- Product 1
---- Product 2
---- Product 3
---- Product 4

When a user requests the following URLs:
The user will be shown the DNN 404 page.

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. Please backup your DNN installation.
  2. Install as a normal module, minimum DNN version: DNN 07.02.01


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 Configurating

HTTP module (Configuration  IIS7):

Place this as the first element in <modules>

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

Redirecting & logging Static Files 404s in DNN

With static files we mean images, stylesheets etc.
For performance reasons these static files are by default not served by .NET / DNN, but by IIS directly.
When a 404 occurs for a static file the use gets to see the default IIS 404 page by default.
There are several options to make sure your 404’s are logged and / or redirected by our module.

FYI, urls with a php extension are also seen as static files by IIS by default.

A. Handle all Static files

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..


B. Handling only a specific extension

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:

<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.

C. Show the DNN 404 error page for Static files

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.

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

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.

Side Effects of logging 404s

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"?>
        <!-- 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.*"/>
            <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."/>

        <!-- 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"/>
            <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."/>

Managing Redirects

The module offers two option to manage redirect.

  1. There’s a list of logged URLs on the 404 page for Administrators
    Every URL has a + to allow adding redirects
  2. There’s a Module action to manage the Redirects.
    Here you can also add and remove Redirects.
    This is also the place to add Regular Expression redirects

Add mapping for listed URL

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

Edit Mappings

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

Regex feature for redirects

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):


meaning a wildcard to everything after …path/


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

Prevent the log table from growing too large

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..

How the Redirect List is stored

The module stores above data in the “redirectconfig.xml” file, in the “\Portals\[PortalFolder]\40Fingers\SEORedirect” folder. You can replace this file with one you generated from other sources.
A backup of the file is made every time you save a new version.


Generating a redirect list

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">

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

Force 404

As mmentionede before 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.
One could say a module can create "virtual child pages", a good example is a News Module.
In many cases when you view a detail news article, the visitor reamins on the same page, but genreates a "virtuel child url"
The core does not know what detail URLs (could) exist for a module on the page.

The Force-404 functionality was added so you can set what pages don't have "Module Generated Sub Url" and create a 404 when a non existant child page ulr is requested.

To use this you click the "Force 404 pages" entry under the edit pen.
Any Page checked in the Treeview will be considered a page without "virtual child pages" and our module will force a 404 if a non existant child page is requested.


SEO Redirect Module - 02.06.07

Released: 21 May 2024

Release notes:

This release contains these changes: Milestone 2.6.7 on Github

Fixed : 2

  • Have to click Save twice to create redirect

    More info on Github.

  • Cancel add entry issue

    More info on Github.

SEO Redirect Module - 02.06.06

Released: 1 February 2024

Release notes:

This release contains these changes: https://github.com/40fingers/DNN-SEORedirect/milestone/6?closed=1

SEO Redirect Module - 02.06.05

Released: 25 March 2022

Release notes:

Fixes issue 100: Regex matching should be case insensitive.

Fixed : 1

  • Regex matching now case insensitive

SEO Redirect Module - 02.06.04

Released: 4 March 2022

Release notes:

This version fixes the HttpModule. The error might prevent the HttpModule from doing anything at all.

Fixed : 1

SEO Redirect Module - 02.06.03

Released: 30 November 2021

Release notes:

This release contains several bugfixes, especially one that might block a DNN upgrade. More info on GitHub.

Fixed : 2

SEO Redirect Module - 02.06.02

Released: 28 May 2021

Release notes:

Fixes log cleanup number issue
Adds license file

See: https://github.com/40fingers/DNN-SEORedirect/milestone/4?closed=1

SEO Redirect Module - 02.06.01

Released: 7 January 2021

Release notes:

Bugfix issue 81 with force404 and composite files 

Fixed : 1

SEO Redirect Module - 02.06.00

Released: 21 December 2020

Release notes:

This release adds the feature to configure the Http Status Code to use for each redirect. The default behaviour hasn't been changed.

Also, a few minor issues have been resolved.

Added: 1

  • Option to use other status codes than just 301

    Implemented issue #79.

Improved: 1

  • Fix conflict between 404 page setting in web.config vs DNN

    Issue #73.

Fixed : 1

  • Services called for non-admins

    Issue #77.

SEO Redirect Module : Log Cleanup Release - 02.05.00

Released: 1 May 2020

Release notes:

Main feature added this release is #25: added a scheduled task and some settings to keep control over the size of your RedirectLog database table.

Added: 1

SEO Redirect Module : Force 404 Release - 02.04.03

Released: 3 April 2020

Release notes:

Main feature added this release is #53:

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 will allow you to force that 404.

Also, several bugs and UI-issues have been solved.

SEO Redirect Module : Feature release - 02.03.00

Released: 24 January 2020

Release notes:

Main issues fixed/features added in this release:

  • #7 Duplicates when entering URLs ending with spaces
  • #3 Store redirect XML as .resources file
  • #12 Add option to Ignore a url for logging
  • #28 Missing close of the edit screen

Plus some UI improvements

SEO Redirect Module - 02.02.07

Released: 25 September 2019

Release notes:

Bug fix

Fixed : 1

  • Editing issue

    In the list with "Top x Urls" there was an issue when you used a custom url that we fixed in the version.