Plugin Sale! Save 15% on pro plugins with discount code: FALL2020
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 in the following three examples.</update>

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

Jeff Starr
About the Author
Jeff Starr = Web Developer. Book Author. Secretly Important.
WP Themes In Depth: Build and sell awesome WordPress themes.

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

    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 »
USP Pro: Unlimited front-end forms for user-submitted posts and more.
Happy Birthday to Perishable Press, celebrating 15 years online! :)
Hide in the basement and hope for the best.
Part of my success is from being able to look ahead down the road and see things coming before they actually get here.
Spent some time refreshing my business portfolio at :)
Tried lots of apps for making animated GIFs from screen captures, so far Kap is my favorite. For example the GIF on this post.
Autumn is my favorite time of year.
Stoked! Had a great interview with Eric over at :)
Get news, updates, deals & tips via email.
Email kept private. Easy unsubscribe anytime.