We are moving a website from Joomla to Mura and some of the pages are going to be located at different URLs.

I can set up 301 redirects in the rules section of the web.config file in order to redirect the old URLs to new locations.

However, my boss wants me to create a custom 404 page that will determine the requested url and then redirect to the new one. Both pieces of information would be stored in a database that the custom 404 page will use to to make the correct redirection.

It's a question between doing

<rule name="rulename">
      <match url="OLD_URL" />
      <action type="Redirect" redirectType="Permanent" url="NEW_URL" />

in the web.config file or,

<cfset path = cgi.path_info>
<cfif path eq "OLD_URL">
<cfheader statuscode="301" statustext="Moved permanently">
<cfheader name="Location" value="NEW_URL">

In the header of the custom 404 page in the Coldfusion template. I did check and the Coldfusion redirect does return a 301 status code.

To me it seems like the 301 redirects in the web.config file are the better way to go, is there something I am missing here?

  • 1
    By "custom 404 page" do you mean a server-side catch-all handler that responds with 301 and 404 status codes? Or do you mean an actual page served with a 404 header? – Maximillian Laumeister Dec 8 '18 at 0:54
  • @MaximillianLaumeister The idea would be to write code in Coldfusion on the server side that handles any missing urls and redirects the user that way – user95472 Dec 10 '18 at 15:33

is there something I am missing here?

I think there is.

By using the custom 404 page to check the URL and then redirect results in a 301 redirect being returned to the client. The same as when creating the redirect directly in the server config. The client does not see a 404 when a redirect takes place. Only when no redirect occurs (ie. the URL is not in your database lookup) does the custom 404 page fallback to returning a default 404 response.

This is a good idea... instead of processing the redirect logic early, on every request - which can potentially impact the performance of legitimate page requests (if you have 1000s of custom redirects) - you instead process the redirect logic late in the request, ie. when you have already determined that the page doesn't exist. This way, your redirect logic has no impact on normal site usage.

If you only have a handful of redirects then it makes no difference performance wise which way you do it. A 301 redirect still occurs in both situations. (Although managing redirects in a database might be easier to maintain.) However, once you have 100s, 1000s, 10000s of redirects (due to a site migration) then using a "custom 404" is really the only way to go.

A "custom 404" is perhaps a bit misleading (although that may be how it is implemented, depending on your application/CMS)... what you are really doing is running your redirect logic only once you have determined that the URL does not exist in the current site.

  • "depending on your application/CMS" -- you mean the 52% of sites using Apache? Apache allows code that changes the 404 status in the custom 404 document. – Stephen Ostermiller Dec 8 '18 at 0:31
  • "By using the custom 404 page to check the URL and then redirect results in a 301 redirect" This is true but only if the redirect is done server-side and not on the actual 404 page itself. When turning a potential 404 into a 301 on the server side, it's more accurate to call the server-side logic a "404 handler" than a "404 page". The approach in your answer is solid so I'm going to give it a point, however the term "404 page" is misleading because you're really making sure the 404 page never actually occurs in the first place. – Maximillian Laumeister Dec 8 '18 at 0:48
  • @StephenOstermiller I wasn't specifically referring to Apache. The Apache 404 ErrorDocument won't be relevant to most CMSs - they have their own "custom 404" document. eg. The WordPress 404.php. – MrWhite Dec 8 '18 at 1:14
  • 1
    @MaximillianLaumeister Yes, I agree. Although the term "page" in this context simply refers to the file/document that handles the response, not the response itself. Granted, it is a bit vague - but this (casual) usage is reasonably common I think. The WordPress docs often refer to the "404.php page", when it's really a "template". For the "custom 404 page to use the information stored in the database", you could only realistically do this server-side. – MrWhite Dec 8 '18 at 1:40
  • @MrWhite "you could only realistically do this server-side." -> All I'll say is: If the only tool you know is JavaScript really anything is possible, no matter how convoluted or semantically devoid. – Maximillian Laumeister Dec 8 '18 at 1:50

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.