temporary full site redirection via htaccess with ip deny

send visitors to mirror on subdomain during maintenance

[ttdttd]

I'm about to carry out a major website update that will require the site to be inaccessible to visitors for a few days. During the downtime, I'd like to redirect visitors to a mirror of the old site on a temp subdomain.

Currently, I have an htaccess file in place denying access to all ip address except mine so that I can access and test the website. Any other visitors get a custom 403 error document mentioning that the site is temporarily under construction. However, I thought it would be handy to employ a full site redirection so they can still browse the old content while the new site is being tested.

Something along the lines of... check ip of visitor to [http://www.mydomain.com] if allowed, grant access. If denied, send them to [http://temp.mydomain.com]

A real plus would be to send them to the page they've requested. For instance, if they try to access [http://www.mydomain.com/content/story.html] then they are redirected to [http://temp.mydomain.com/content/story.html]

Can this be done site-wide? Is there a more sensible approach to pull this off that I've overlooked? Any insight would be appreciated.

Also, is there a way to not have this negatively effect search engine indexing? I don't want the temp subdomain to be indexed so I'd use a disallow in robots.txt. Will this step alone suffice?

Thanks for your consideration,
-ttd

[jd01]

I haven't ever tried anything like what you are mentioning, but if I was going to, I would probably:

1. Use a 307 redirect to the temporary domain.
2. After the update is complete, use a 301 from the sub-domain back to the main domain.

Justin

[jdMorgan]

This whole approach sounds upside-down to me.

First, you probably don't need *any* redirects. Just steer the requests to different filespaces based on the requestor's IP address.

You can easily rewrite 'tester' requests to a subdirectory of the main site, instead of redirecting the world.

Or copy the old site into a subdirectory, and then use a rewrite to point *all except* tester IP addresses to that content.

The confusion may stem from the common misperception that a URL and a filename are the same thing. They are not, and a URL and a filename need have nothing in common -- thanks to the ability of mod_rewrite to change the URL-to-filepath translation in any way you wish.

Redirecting the whole site just seems to me to be like using torpedoes to fish for guppies.

Jim

[ttdttd]

Thanks for the feedback.

jdMorgan wrote:

...thanks to the ability of mod_rewrite to change the URL-to-filepath translation in any way you wish.

Great point, it seems like mod_rewrite could work nicely. I've not used mod_rewrite before but am lightly familiar with the concept.

Seems like this is what I'm after...

if ip address = 123.123.123.123 allow access to [mydomain.com...]

else rewrite [mydomain.com...] to [temp.mydomain.com...]

If anyone knows a quick code example it would be greatly appreciated.

Thanks again for the insight.

[jdMorgan]

The concept of an internal rewrite versus an external redirect is what's important here.

If you can put the old and new content on the same server, in different directories, then a subdomain is not needed, a redirect is not needed, and there will be zero impact on visitors or search engine spiders until you decide to "throw the switch" from old to new site contents -- all at once, and instantly.

Inside a server, domains and subdomains mean nothing -- they are the concepts used to get to the server, and past that they're not needed. Only directories and filepaths are used within the server. It's like if you ask your wife/girlfriend, "Where did I leave my glasses?" They don't reply, "On the coffee table in the living room at 123 Maple Avenue, Smallville, Kansas, USA." Just "On the coffee table" will do. So in the same way, the domain and subdomain are unimportant inside the server, just as your country, state, street, and house number are unimportant when looking for your glasses inside your house.

Let's take your site as an example. If it were mine, here's what I'd do -- making a few assumptions, admittedly:

Copy all current "old" content to a subdirectory, "old".

Use mod_rewrite to rewrite all incoming requests down one subdirectory level to /old.

You can now delete the old content from the main directory.

Create another subdirectory, "/dev." Put all new content into /dev.

Add another rule to rewrite all requests coming from your tester's IP address range down one subdirectory level to "/dev".

As soon as the new site is finished, move all the /dev files back to the main directory, then delete the rewriterules, and poof -- The site switches from old to new content instantly.

Alternatively, you could leave the "old" and "/dev" directories in-place, and add two more called called "/production" and "/archive." You can then easily and continuously work on your site: Delete the old "/archive" subdirectory (or rename it), then rename "/old" to "/archive," then rename "/production" to "/old," then rename or copy "/dev" to "/production." Then you can once again begin working on the site some more in the "/dev" directory. You just use the rewriterules to make your "dev" subdirectory look like the "production" directory while you're working on it, an no-one is the wiser.

I assume your site isn't too big to copy the files around. I also assume you're on shared hosting, where your options are most limited. You can actually do more, and more easily, if you have server config access.

But the whole idea is that you don't need redirects, and the whole process can take place behind the scenes in the server filesystem, and no-one needs to know that the site is being worked on and tested except for you. There is hardly ever a good reason to "shut down your site" for maintenance or even for a complete overhaul. Even with a database-driven dynamic and interactive site, there are ways to develop and test without such "suicidal" silliness. I say that because "closing your site" can destroy your traffic, and having your URLs all change can destroy your search engine ranking. Hopefully these effects will be temporary, but do you want to bet on it? -- Better to just avoid the whole issue.

The keys you're looking for (we don't do "write my code" requests here, so this is just an example -- see the forum Charter) are:

RewriteCond %{REMOTE_ADDR} ^192\.168\.0\.1$
RewriteCond $1 !^test/
RewriteRule ^(.*)$ /test/$1 [L]

Using the references provided on our Forum Charter page, you can look up those mod_rewrite directives, decode the regular-expressions patterns, and find out what they do. Then please feel free to post specific questions back here.

For more information, see the documents cited in our forum charter [webmasterworld.com] and the tutorials in the Apache forum section of the WebmasterWorld library [webmasterworld.com].

Jim

[ttdttd]

Jim,

Big thanks for all the useful info.

In my initial test, I opted for copying the current website to an "/oldsite/" subdirectory where everyone except my ip grabs the site from by way of a RewriteRule. It works great.

Before trying your method, I was under the impression visitors would see the "/oldsite/" subdirectory in their browser's address bar. Then I tried it out and thankfully this is not the case since the address rewrite makes it transparent. I imagine if I was simply redirecting to the "/oldsite/" subdirectory then visitors would see it in the url. This is a huge benefit (among others) of your rewrite method over my initial plan to redirect. When the time comes, the ease of "flipping the switch" (deleting the rewrite rules) will eliminate any downtime.

I can also appreciate how this method is easily expandable to accommodate additional subdirectories (/dev, /production, /archive, etc.) and rewrite rules for other development purposes.

This solution works great for my current situation (an initial change from a static website to one with a membership database, protected content, etc.) as I'm able to setup the database and fully test everything in the main directory behind the scenes while visitors can still access the old content. I'll admit that right now I'm a little unsure about how to handle future site testing with this rewrite method since a database will be involved (but these uncertainties are beyond the scope of this thread as I have a lot more to learn on the subject).

Thanks again for your insight and patience while I feel my way through this.

-ttd

ps. Apologies for not being familiar with the charter and asking for a code example. The code you provided was essentially what I went with and I'll post it below in hopes that it will help others (or for review in case I've overlooked something).

RewriteEngine ON
# check that ip address is not mine
RewriteCond %{REMOTE_ADDR}!^12\.345\.678\.90$
# then display files in oldsite subdirectory
RewriteCond $1!^oldsite/
RewriteRule ^(.*)$ /oldsite/$1 [L]