Redirecting visitors to a maintenance page or other temporary page is an essential tool to have in your tool belt. Using HTAccess, redirecting visitors to a temporary maintenance page is simple and effective. All you need to redirect your visitors is the following code placed in your site’s root HTAccess:

# MAINTENANCE-PAGE REDIRECT
<IfModule mod_rewrite.c>
 RewriteEngine on
 RewriteCond %{REMOTE_ADDR} !^123\.456\.789\.000
 RewriteCond %{REQUEST_URI} !/maintenance.html$ [NC]
 RewriteCond %{REQUEST_URI} !\.(jpe?g?|png|gif) [NC]
 RewriteRule .* /maintenance.html [R=302,L]
</IfModule>

That is the official copy-&-paste goodness right there. Just grab, gulp and go. Of course, there are a few more details for those who may be unfamiliar with the process. Let’s look at all the gory details..

Continue Reading

If you’ve been keeping an eye on your 404 errors recently, you will have noticed an increase in requests for nonexistent mobile files and directories, especially over the past year or so. The scripts and bots requesting these files from your server seem to be looking for a mobile version of your site. Unfortunately, they are wasting bandwidth and resources in the process. It has become common to see the following 404 errors constantly repeated in your log files:

• http://domain.tld/apple-touch-icon.png
• http://domain.tld/iphone
• http://domain.tld/mobile
• http://domain.tld/mobi
• http://domain.tld/m

So some bot comes along, assumes that your site includes a mobile version, and then tries its hand at guessing the location. In the common request-set listed above, we see the bot looking first for an “apple-touch icon,” and then for mobile content in various directories. If this only happens once in awhile, it’s no big deal. But these days I’ve been seeing many different bots requesting these nonexistent resources.

Even worse, these mobile-hungry bots can’t seem to remember where they’ve been – they typically request the same resources repeatedly, and in multiple locations within the directory structure. I frequently see hundreds of these types of requests in my weekly error-log analyses. Needless to say, this is an incredible waste of time, bandwidth, and server resources.

Continue Reading

Jeff Morris recently demonstrated a potential issue with the way WordPress handles multipaged posts and comments. The issue involves WordPress’ inability to discern between multipaged posts and comments that actually exist and those that do not. By redirecting requests for nonexistent numbered pages to the original post, WordPress creates an infinite amount of duplicate content for your site. In this article, we explain the issue, discuss the implications, and provide an easy, working solution.

Understanding the “infinite duplicate content” issue

Using the <!--nextpage--> tag, WordPress makes it easy to split your post content into multiple pages, and also makes it easy to paginate the display of your comment threads. For both paged posts and paged comments, WordPress appends the page number to the permalink. So for example, if we have a post split into 3 pages, WordPress will generate the following set of completely valid permalinks (based on name-only permalink structure):

Continue Reading

With the imminent release of the next series of (4G) blacklist articles here at Perishable Press, now is the perfect time to examine eight of the most commonly employed blacklisting methods achieved with Apache’s incredible rewrite module, mod_rewrite. In addition to facilitating site security, the techniques presented in this article will improve your understanding of the different rewrite methods available with mod_rewrite.

Blacklist via Request Method

This first blacklisting method evaluates the client’s request method. Every time a client attempts to connect to your server, it sends a message indicating the type of connection it wishes to make. There are many different types of request methods recognized by Apache. The two most common methods are GET and POST requests, which are required for “getting” and “posting” data to and from the server. In most cases, these are the only request methods required to operate a dynamic website. Allowing more request methods than are necessary increases your site’s vulnerability. Thus, to restrict the types of request methods available to clients, we use this block of Apache directives:

Continue Reading

In my previous article on temporarily redirecting visitors during site updates, I present numerous PHP and HTAccess methods for handling traffic during site maintenance, updates, and other temporary periods of downtime. Each of the PHP methods presented in the article allow for access from a single IP while redirecting everyone else. In this article, we modify our previous techniques to allow access for multiple IP addresses while temporarily redirecting everyone else to the page of our choice. Plus, while we’re at it, we’ll explore a few additional ways to adapt and use the general technique.

Continue Reading

Here’s the scene: you have been noticing a large number of 404 requests coming from a particular domain. You check it out and realize that the domain in question has a number of misdirected links to your site. The links may resemble legitimate URLs, but because of typographical errors, markup errors, or outdated references, they are broken, leading to nowhere on your site and producing a nice 404 error for every request. Ugh. Or, another painful scenario would be a single broken link on a highly popular site. For example, you may have one of your best posts mentioned in the SitePoint forums, but the person leaving the link completely botched the job:

Continue Reading

Time for another Feedburner redirect tutorial! In our previous FeedBurner-redirect post, I provide an improved HTAccess method for redirecting your site’s main feed and comment feed to their respective Feedburner URLs. In this tutorial, we are redirecting individual WordPress category feeds to their respective FeedBurner URLs. We will also look at the complete code required to redirect all of the above: the main feed, comments feed, and of course any number of individual category feeds. Let’s jump into it..

Continue Reading

Simple one for you today. After posting on how to use HTAccess to redirect subordinate URLs to the root (or parent) directory, I thought I would share an alternate way of accomplishing the same trick using PHP. Fortunately, using this PHP redirect technique doesn’t require access to or fiddling with your site’s HTAccess (or Apache configuration) file and it is very easy to implement.

The scene, as discussed in greater detail in my previous article on this topic, involves a very specific type of redirect whereby some target URL is redirected up the directory structure to one of its parent directories. Redirecting such subordinate content generally falls into one of two categories:

Continue Reading

Recently, a client wanted to deliver her blog feed through Feedburner to take advantage of its excellent statistical features. Establishing a Feedburner-delivered feed requires three things: a valid feed URL, a Feedburner account, and a redirect method. For permalink-enabled WordPress feed URLs, configuring the required redirect is straightforward: either install the Feedburner Feedsmith plugin or use an optimized HTAccess technique. Unfortunately, for sites without permalinks enabled, the Feedsmith plugin is effectively useless, and virtually all of the HTAccess methods currently available on the Web are designed for permalink-enabled configurations. In this article, we will modify our existing HTAccess technique to work with default WordPress feed URLs.

Continue Reading

One of the most useful techniques in my HTAccess toolbox involves URL redirection using Apache’s RedirectMatch directive. With RedirectMatch, you get the powerful regex pattern matching available in the mod_alias module combined with the simplicity and effectiveness of the Redirect directive. This hybrid functionality makes RedirectMatch the ideal method for highly specific redirection. In this tutorial, we will explore the application of RedirectMatch as it applies to one of the most difficult redirect scenarios: redirecting all requests for a specific subdirectory (or any subordinate directory or file) to the root (or any parent) directory. We will explore how to accomplish this redirect using PHP in a subsequent article.

Continue Reading

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:

• http://perishablepress.com/press/favicon.ico
• http://perishablepress.com/press/2007/06/12/favicon.ico
• http://perishablepress.com/press/2007/09/25/absolute…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.

Continue Reading

For the last several months, I have been seeing an increasing number of 404 errors requesting “favicon.ico” appended onto various URLs:

http://perishablepress.com/press/favicon.ico
http://perishablepress.com/press/2007/06/12/favicon.ico
http://perishablepress.com/press/2007/09/25/absolute-horizontal-and-vertical-centering-via-css/favicon.ico
http://perishablepress.com/press/2007/08/01/temporary-site-redirect-for-visitors-during-site-updates/favicon.ico
http://perishablepress.com/press/2007/01/16/maximum-and-minimum-height-and-width-in-internet-explorer/favicon.ico

When these errors first began appearing in the logs several months ago, I didn’t think too much of it — “just another idiot who can’t find my site’s favicon..” As time went on, however, the frequency and variety of these misdirected requests continued to increase. A bit frustrating perhaps, but not serious enough to justify immediate action. After all, what’s the worst that can happen? The idiot might actually find the blasted thing? Wouldn’t that be nice..

Continue Reading

In a previous article, I explain how to redirect your WordPress feeds to Feedburner. Redirecting your WordPress feeds to Feedburner enables you to take advantage of their many freely provided, highly useful tracking and statistical services. Although there are a few important things to consider before optimizing your feeds and switching to Feedburner, many WordPress users redirect their blog’s two main feeds — “main content” and “all comments” — using either a plugin or directly via htaccess. Here is the htaccess code as previously provided here at Perishable Press:

Continue Reading

If you are using Feedburner to deliver your feeds, chances are high that most — if not all — of your loyal readers have subscribed to the Feedburner-specific version of your feed’s URL. This is not a good idea for a couple of important reasons:

• Complete content-delivery failure if/when the Feedburner service goes down
• Cohesive branding strategy impossible because visitors see Feedburner’s name in feed URL instead of your own

At this point, millions of feed subscribers have Feedburner-branded feed URLs listed in their feed readers. If/when the venerable Feedburner service should ever fail, the results would be disastrous. Feedburner needs to provide a comprehensive way for content producers to deliver their feeds through user-specified channels. Currently, Feedburner demonstrates that this is possible by enabling a partial method of redirecting feed traffic to custom URLs.

Continue Reading

Here is an example of one of the most frequently asked PHP/htaccess-related questions I receive here at Perishable Press:

How do I redirect a specific page/URL using PHP/htaccess?

So common is this inquiry that I have decided to just post a quick, “one-minute” tutorial describing the technique.

Continue Reading

WordPress users employing permalinks via htaccess to optimize their dynamic URLs transform complicated-looking links such as:

http://example.com/blog/index.php?page=33

..into search-engine friendly links such as:

http://example.com/blog/post-title/

Every rewritten URL relies on a common set of htaccess rules to transform the links. The htaccess rules for all WordPress permalinks look like this for root WP installations:

# BEGIN WordPress
<ifmodule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</ifmodule>
# END WordPress

..and like this for subdirectory WP installations:

Continue Reading

In our article Stupid htaccess Tricks, we present the htaccess code required for redirecting visitors temporarily during periods of site maintenance. Although the article provides everything needed to implement the temporary redirect, I think readers would benefit from a more thorough examination of the process — nothing too serious, just enough to get it right. After discussing temporary redirects via htaccess, I’ll also explain how to accomplish the same thing using only PHP.

Continue Reading

Not the most interesting title, but “oh well”..

Recently, a reader named Alison left a comment requesting help with a particular htaccess trick. She wanted to know how to permanently redirect (301) all requests for a specific page when requested from a specific IP address. In other words, when a visitor coming from 123.456.789 requests the page requested-page.html, the visitor will be redirected to just-for-you.html. All visitors not coming from that specific IP address are not redirected, and thus will see the originally requested page. Further, the redirect must apply only to requested-page.html, such that every visitor — including the one coming from 123.456.789 — will be able to see all of the other pages. Here is the htaccess code to make it happen:

# permanently redirect specific IP request for single page
RewriteEngine On
RewriteBase /
RewriteCond %{REMOTE_HOST} 123\.456\.789
RewriteCond %{REQUEST_URI} /requested-page\.html$
RewriteRule .* /just-for-you.html [R=301,L]

To use this redirect, simply edit the IP address, requested page, and redirect page. Copy and paste the code into your htaccess file and upload to your server. Test the 301 redirect via proxy and that’s it. Relax and enjoy!

Welcome to the Perishable Press Redirection Lounge!

What?

We keep a very close eye on all 404 (resource not found) errors. Every time a legitimate 404 rears its ugly head, we take the necessary steps to solve the issue. In most cases, we use htaccess redirects to prevent 404 errors. Often, the missing resource remains available, but has been moved to another location. In this situation, we simply redirect visitors to the new location. Easy. However, there are also a relatively small number of 404 errors that are generated due to content that is no longer available. For example, temporary posts, test posts, and duplicate posts often result in 404 errors, even if they were only online for a very short time. So, rather than redirecting such requests to the home page or to the 404 page, we have created an exclusive Redirection Lounge at which roaming search engines, misguided robots, and wandering visitors may find information and reassurance.

Where?

This page is actually a post handcrafted especially for this very moment in time. The post is public, exists online, and is archived at Perishable Press. In other words, you are currently deep within the Perishable Press Archives. To escape such ancient realms, click here to return to the Perishable Press home page. Otherwise, click on some other link to fight your way out of the archive database. Otherwise, enjoy your stay here at the Perishable Press Redirection Lounge. It may not be exactly what you originally had in mind, but you have to admit, the solitude provides plenty of time to think about that interesting life of yours.

Why?

You are here because you tried accessing a resource at perishablepress.com that is no longer available. Please note that the content you are seeking has not been relocated, misplaced, or renamed — it is simply no longer available on this domain. Most likely, the content has been deleted permanently. If you are absolutely convinced that the content you are seeking is worth pursuing, please check out the Google index or the excellent Wayback Machine. Indeed, if the requested content were still available on this domain (perishablepress.com), our diligent web gimps would have redirected you swiftly to the new location of the resource. However, as the requested resource is not available, and because we try to avoid as many 404 errors as possible, we have created this Redirection Lounge to serve as our official redirect target for otherwise dead-end requests. We hope you find it as comfortable as it is informative.

Huh?

If you feel that you have arrived at the Redirection Lounge in error, or have information concerning the requested resource, please use our official contact form to drop us a line.