Celebrating 20 years online :)
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:

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

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:

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

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


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. Security Specialist. WordPress Buff.
BBQ Pro: The fastest firewall to protect your WordPress.

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

  1. Ok. I found the problem.

    The set of lines that you suggested to be in put in .htaccess file should go all the way to the top of the file – only then it kicks in. Otherwise it has been ignored.


  2. Jeff Starr 2008/12/21 9:49 am

    @JK: yes, that may be the case, depending on the contents of your htaccess file(s), it might be necessary to arrange the various rewrite rules in such a way as to avoid potential conflicts. In any case, I am glad to hear you got it working! :)

  3. I just discovered all these favicon 404’s after installing CyStats. Rather annoying. Thanks for the code, it seems to help. But what ARE all these 404’s? Who or what is looking for my favicon in all possible places, and above all – why??

  4. Jeff Starr 2009/01/01 9:51 am

    Hi Kalle, Glad to hear the method is helping you. I recently participated in a comment thread over at CSS Tricks that discusses the technique in greater detail and even gets into “why” these types of requests occur in the first place. Check it out at:


  5. Thanks so much!!! This saved my butt. I was hit with this problem in the worst way and this completely cleared it up in 5 minutes.

  6. Happy to help, Jeff — Thanks for the positive feedback! :)

Comments are closed for this post. Something to add? Let me know.
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 »
SAC Pro: Unlimited chats.
Crazy that we’re almost halfway thru 2024.
I live right next door to the absolute loudest car in town. And the owner loves to drive it.
8G Firewall now out of beta testing, ready for use on production sites.
It's all about that ad revenue baby.
Note to self: encrypting 500 GB of data on my iMac takes around 8 hours.
Getting back into things after a bit of a break. Currently 7° F outside. Chillz.
Get news, updates, deals & tips via email.
Email kept private. Easy unsubscribe anytime.