The humble 404 error – it belongs to a select group of error codes that has risen into the public consciousness. Ask the average web-addict what 404 means and they will tell you ‘something to do with the link not working'. This widespread knowledge is the result of webmasters returning error pages since the beginnings of the world wide web. When a person asks for a URL that doesn’t exist, they need to know that it doesn’t exist – and that’s what the 404 Error Page has always been for. The early users of the web were all well-versed in technical matters such as HTTP response codes, and somehow over time the use of the ‘404’ has stuck.
Page Not Found for Search Engine Optimization (SEO)
It isn’t just people that view and take notice of 404 errors – search engine robots that continually scan websites need this information to know when a link doesn’t work.
A search engine needs to be up to date – returning a broken link in a search result isn’t any help to anyone. That’s why it’s vital that sites return 404 errors when links are broken – so that the search engines know how to remove them.
The search engine story doesn’t end there, however. Many websites don’t return 404 errors properly for invalid URLs, and instead they return a 302 temporary redirect to a normal web page, which is used to inform the visitor that the link wasn’t found. While this works well for informing visitors that a URL wasn’t recognized, it doesn’t work well for search engines, which are more interested in the hard data of HTTP status codes than the various interpretations of ‘Page not found’ in various languages, cultures and styles.
Many implementations of ASP.NET websites utilize the error page redirect functionality as it is quick and simple, but unfortunately this leads to the above problem, where a temporary redirect is done to a normal page that shows the error.
As a result of many websites not issuing ‘correct’ HTTP error codes, Google started classifying certain pages as ‘Soft 404 Errors’. These are pages that Google scans and thinks are 404 or other Error pages, based on the content, but isn’t sure because it isn’t returning a 404 HTTP status code.
The linked Soft 404 Error page comes with this ominous warning:
“Because of the time Googlebot spends on non-existent pages, your unique URLs may not be discovered as quickly or visited as frequently and your site’s crawl coverage may be impacted (also, you probably don’t want your site to rank well for the search query [File not found]).”
What this really means is that if Google doesn’t find any 404 status codes from your site, it will start guessing what is a 404 Error page, and start removing those pages from the index, or at least not crawling your site as much.
Either of those are not good results for those wishing their pages to rank well in Google. The worst thing about this is that in practice, many site owners start seeing valid pages get classed as Soft 404 errors, and their site can start to disappear from rankings.
Page Not Found for Visitors
It’s not just Search Engines that appreciate well constructed ‘Page Not Found’ error pages. While most visitors will never read or care about a 404 HTTP status code, they certainly do appreciate being told when some content is missing, but they especially appreciate being told what they can do next (apart from hit the ‘back’ button). Such actions might include a link to the search page, a link to some FAQs – whatever suits the content of the site in question.
DNN and Page Not Found Errors
DNN administrators have always faced two challenges when it comes to handling what to do with a link that no longer works. It’s not a coincidence that these are the two challenges already laid out above, with a further wrinkle when it comes to showing visitors site specific, attractive ‘Page Not Found’ error pages.
DNN is based on ASP.NET, and so many DNN sites inherit the problem of ‘Soft 404 Errors’, in which Google ranks the site lower. But don’t think DNN is alone here – many popular CMS packages are plagued with the same problem, and it isn’t just restricted to those running on ASP.NET either.
One of the strengths of DNN is the multi-tenant capability of the software, giving the site owner the ability to run one or more sites on the same installation. This becomes a challenge for showing ‘page not found’ errors, because, ultimately, this is handled at the ASP.NET level. At this level, all the various sites in a DNN installation look like a single website, and showing a different error page for each is a challenge.
Page not Found in DNN 7.1
As part of the many different improvements around URL handling introduced with DNN 7.1, all of the above issues are solved. These are built into the DNN framework itself and require no additions.
Each new DNN 7.1 installation includes a ‘404 Page not Found’ page. This is configured for the installed portal so that any URLs that are not found are shown this page. When the ‘404 Page not Found’ page is shown, the originally requested URL is still in the browser address bar, and a HTTP 404 status code is returned to the browser (or search engine).
The ‘404 Page Not Found’ page is an ordinary DNN page, so you can add any content you like to the page using a Text/HTML module, or indeed any other content module – with one or two caveats, see below. So you can design and layout this page to suit the specific site that it belongs to, even when your DNN installation contains multiple sites.
It is important to note the precise language here – the ‘404 Page Not Found’ is shown to the user when an URL that doesn’t match any content is requested. This is not a ‘404 redirect’ – the requested page doesn’t exist, so the ‘404 Page Not Found’ page is shown instead.
Note: the use of the 404 Error Page in DNN requires that the Friendly Url Provider is configured in ‘advanced’ mode. This is switched on by default for new DNN installations, but older sites being upgraded would need to have the different URL Provider mode activated.
Important Information relating to DNN 404 Pages
The first thing to note is that, while the ‘404 Page Not Found’ page is constructed as a normal DNN page, when it is displayed in relation to a 404 Error, it isn’t displayed in the same way. There are a few things that don’t work the same way. If you’re developing or administering a DNN 7.1 site, then visit the 404 Page Not Found in DNN wiki page, which has detailed explanations of some of the nuances with using and understanding the 404 handling in DNN.
Conclusions
Improvements to 404 Handling will be welcomed by many site administrators and is yet another incremental improvement for DNN that some will be passionate about, while others may not even notice. The great thing about this change is that it will improve both the visitor experience and search engine rankings for many new DNN site owners, and all they will have to do is modify the content on the page to suit their new site.
Questions? If you have questions about DNN 404s, feel free to ask about this feature in the comments below.