Fall Sale! Code FALL2024 takes 25% OFF our Pro Plugins & Books »
Web Dev + WordPress + Security

Redirect All Requests for a Nonexistent File to the Actual File

In my previous article on redirecting 404 requests for favicon files, I presented an HTAccess technique for redirecting all requests for nonexistent favicon.ico files to the actual file located in the site’s web-accessible root directory:

# REDIRECT FAVICONZ
<ifmodule mod_rewrite.c>
 RewriteCond %{THE_REQUEST} favicon.ico [NC]
 RewriteRule (.*) http://domain.tld/favicon.ico [R=301,L] 
</ifmodule>

As discussed in the article, this code is already in effect here at Perishable Press, as may be seen by clicking on any of the following links:

Update: I’ve removed the favicon redirect on this site in order to account for vastly more complex favicon requirements (e.g., android, apple, avatar, etc.). Also, because googlebot now crawls plain-text URLs, I had to change the domain to example.com in the following three examples.</update>
  • http://example.com/wp/favicon.ico
  • http://example.com/press/2007/06/12/favicon.ico
  • http://example.com/absolute-horizontal-and-vertical-centering-via-css/favicon.ico

Clearly, none of these URL requests target the “real” favicon.ico file, yet thanks to the previous method they are all happily redirected to the proper location. This is useful for a variety of reasons, including preventing excessive and unnecessary server strain due to malicious scripts.

Shortly after posting this method, Chris Coyier of CSS Tricks discovered that the code was causing an infinite redirection loop when applied to his site. After some experimentation, I have resolved the infinite loop issue, improved the syntax, and adapted the code to work from virtually any location.

The previous favicon redirection method works as advertised, but only if placed in a subdirectory, such as would be the case for WordPress installations located in their own non-root directory. For example, this WordPress installation for Perishable Press is located in a subdirectory named “press”. Within the HTAccess for the press subdirectory, the first version of this redirection technique works perfectly. When placed in the root directory, however, the code fails by creating the infinite loop. Thus, a better solution is needed..

Universal Redirect for Nonexistent Files

The following technique works in any directory — subdirectory or site root:

# REDIRECT 404 FILES
<ifmodule mod_rewrite.c>
 RewriteEngine on
 RewriteCond %{REQUEST_URI} !^/favicon\.ico [NC]
 RewriteCond %{REQUEST_URI} favicon\.ico [NC]
 RewriteRule (.*) http://domain.tld/favicon.ico [R=301,L] 
</ifmodule>

To implement this technique, replace both instances of “favicon.ico” with any file that you would like to redirect. The favicon is a good a choice for reasons discussed in the previous article, but other good candidates would be your site’s robots.txt file or any other file that seems impossible for people and bots to find. Further, if the location of the “real” file is located somewhere other than the root directory, indicate such in the first RewriteCond (e.g., !^/images/favicon\.ico). Then, after the rewrite conditions are taken care of, edit the RewriteRule to reflect the full URL of the actual file.

A couple of notes.. First, it is recommended that you place this code as far up the directory structure as possible. Begin with the site root HTAccess file. In most configurations, that should work fine; however, in some cases, such as when WordPress is installed in a subdirectory but is serving permalinks written without the subdirectory showing in the URL, the redirect may simply not happen. If this is the case, or if the redirect does not occur for some other reason (conflicting rewrite rules, etc.), try placing the code in the subdirectory. Bottom line: place the code in the root HTAccess and if the redirects don’t kick in, place the code in the blog subdirectory.

The good news here, and the main reason for this improved method, is that the code will no longer trigger an infinite loop and crash your site; it is much safer, much cleaner, and more widely applicable.

Having bored you to tears with all of that detail, allow me to deliver the death blow with an explanation as to what’s actually happening when this code is executed. I think a nice, numbered list will help simplify the process:

  1. Check for the required Apache module, mod_rewrite
  2. Enable rewriting by activating the RewriteEngine
  3. Check if the requested URI is the actual file
  4. Match any nonexistent URI that contains the target file
  5. Redirect any matching URI to the actual file
  6. Close the module check container

Conclusion

Hopefully, this technique will be useful for anyone needing to stop those relentless 404 requests for nonexistent files. Doing so will not only help increase the effectiveness of your error-log investigations, but also help reduce the unwanted server load associated with automated directory prowling via arbitrary file candidates. Or something ;)

About the Author
Jeff Starr = Web Developer. Book Author. Secretly Important.
Wizard’s SQL for WordPress: Over 300+ recipes! Check the Demo »

18 responses to “Redirect All Requests for a Nonexistent File to the Actual File”

  1. I wonder if it’s a good idea to redirect the request to the favicon. That won’t make the automatic requests stop, and that will burn some bandwidth that would not have been burned if you just ignore the request.

    My point would be that your idea is cleaner, but will waste ressources :/

  2. Jeff Starr 2008/08/13 9:42 am

    Let’s think this through. With the rewrite rule in place, all requests for favicon.ico require a redirect and an image request. Without the rewrite rule in place, the htaccess file is still parsed yet instead of an image, a web page is served. Which of these cases consumes more resources? I don’t know for sure, but if I remember correctly, servers deliver images at much lower cost than web documents. It also may depend on the size of the image or file being requested. Favicons and robots.txt files are pretty small, but larger files would likely have a greater impact on performance.

  3. I am pretty new to this, exactly where do I put the script. Is in the htaccess file?

  4. Jeff Starr 2008/08/17 7:06 am

    Hi IMaggie, technically the code presented in the article is not a script, but yes, if you are planning on using it, you would place it in an htaccess file, as described in the post itself. I hope that helps :)

  5. play games 2008/08/24 3:15 pm

    Great Work Perishable

    I’ve customised your code to meet my specific reqs, namely to protect against hotlinkers linking directly to my content.

    RewriteCond %{HTTP_REFERER} xx.xxxxx.com [NC,OR]
    RewriteCond %{HTTP_REFERER} xxxxx.org [NC]
    RewriteRule .(swf)$ redirect.swf [NC,L]

    If you were in the UK I’d buy you a beer.

  6. Jeff Starr 2008/09/01 9:29 am

    Thanks for the feedback — I’ll be taking you up on that beer next time I’m in the UK! ;)

  7. htaccess redirect 2008/09/11 7:37 pm

    I was looking for this rewrite code for WordPress for quite awhile, couldn’t get it to work myself. Thanks!

  8. Hello,

    I am having some trouble redirecting URL on my site. I used Expression Engine to mount it, and suddenly something happened and this kind of redirectioning are not working anymore:

    http://loscuchillos.com/letras should go to http://loscuchillos.com/index.php/letras

    So, what I basically need to perform is an automatic redirection to /index.php/NAME of whatever NAME typed as a subfolder. Without showing the whole address.

    So the code the Expression Engine provides to get this kind of redirectioning (http://expressionengine.com/wiki/Remove_index.php_From_URLs/) is not working anymore.

    It was working before and now I wounder what could be wrong.

    Rewrite Module is enabled, same as .httaccess

    Is there anythins else I should consider?

    I’d really appreciate any comments on this issue.

    Thanks,

    Piller

  9. Gabriel H. 2008/09/28 12:32 am

    Hello,

    Be careful with the redirection, you can have an infinite loop.

    To avoid that, you can rename the favicon.ico file by something else.

    Eg :

    RewriteCond %{THE_REQUEST} favicon.ico [NC]
    RewriteRule (.*) /favicon_all.ico [R=301,L]

    If I don’t do this, I get infinite redirections…

  10. Jeff Starr 2008/09/28 8:01 am

    Hi Gabriel, I am wondering if you read the entire article, or happened to copy & paste that first chunk of code. The reason I say this is because this article is essentially about preventing infinite loops. The htaccess code presented at the beginning of the article was given in a previous article and may indeed cause infinite loops, which is precisely why I wrote this article. If you read through, you will see that the infinite loop issue is resolved with a new and improved version of the code. I know of at least several sites that use the technique with no problems whatsoever. With the proper technique there should be no need to rename any files. I hope this helps!

  11. Gabriel H. 2008/09/28 7:27 pm

    Hello Jeff Starr,

    My apologies, you are right, I didn’t read the whole article and just copy-pasted blindly the code… Now that works much better with the new code ;)

    Have a nice day.

  12. Hi Jeff,

    First of all, you have a great site.

    I too get tons of 404s with favicon.ico missing like your example post URLs from your site shown above. I followed your steps and read several times to get this correct. For some reason, the redirect does not happen at all. Let me explain further on my site configuration.

    I have the main site in the root directory which is not blog (plain static site). In the sub-directory I have a blog with it’s own domain name. So I have a .htaccess file specifc to my blog in this sub-directory. Currently that’s where I have all rewrite commands. So I added your rewrite commands to this file towards the bottom. Still I get 404s for favicon.ico & .gif files.

    What am I missing?

    Thanks for your help.

Comments are closed for this post. Something to add? Let me know.
Welcome
Perishable Press is operated by Jeff Starr, a professional web developer and book author with two decades of experience. Here you will find posts about web development, WordPress, security, and more »
BBQ Pro: The fastest firewall to protect your WordPress.
Thoughts
I disabled AI in Google search results. It was making me lazy.
Went out walking today and soaked up some sunshine. It felt good.
I have an original box/packaging for 2010 iMac if anyone wants it free let me know.
Always ask AI to cite its sources. Also: “The Web” is not a valid answer.
All free plugins updated and ready for WP 6.6 dropping next week. Pro plugin updates in the works also complete :)
99% of video thumbnail/previews are pure cringe. Goofy faces = Clickbait.
RIP ICQ
Newsletter
Get news, updates, deals & tips via email.
Email kept private. Easy unsubscribe anytime.