15 replies to this topic

[Randy]

Since there is so much discussion around here about using .htaccess for redirects, I thought I would offer up some info on when it's not the best way to go. Even though I'm a proponent of server level redirects each situation is different and .htaccess is not always the best solution. Real story here, since I spent several hours last night helping out a designer friend.

The site in question was moving to a new shopping cart, which of course meant all of the URLs were going to change. Not the best thing to do in any case, but in this one it's was pretty much a requirement. They'd outgrown the capabilities of the older cart, not to mention that it had a really badly optimized database structure that would likely cause unnecessary server load as traffic levels increase. And there simply weren't the funds available to build a custom cart application around the old URLs.

In a nutshell, the old urls looked like:

CODE

http://www.domain.com/index.php?category=72
and
http://www.domain.com/index.php?maincat=16
and
http://www.domain.com/display_page/php?i=3

Even though the site is not overly large (around 300 pages) forcing Apache to parse through a large .htaccess file for every page request would not be the way to approach it IMO. To do standard 301's for all of the various category and manufacturer pages would end up looking something like:

CODE

RewriteCond %{QUERY_STRING} category=72 [NC]
RewriteRule ^index\php$ http://www.domain.com/category/Category_Name/c72 [R=301,L]

Not too bad when you look at just one redirect for one page migration. But when you're looking at 100 or more you're asking Apache to do a lot of heavy lifting and putting undue strain on the server.

A better solution is simply to let PHP do the heavy lifting. It's much better for the server, and a scripted solution would limit when the redirects fired since all of the old pages were tied to either index.php or display_page.php.

So what was the solution?

Simple really. The old index.php page was replaced with a scripted redirect page, where the php code analyzed the query string, compared it against an array of possible values, then assigned the correct value to the redirect. We were also able to easily insert some error handling since a couple of manufacturers/categories were going bye-bye.

Because it's contained at the file level, Apache doesn't get bogged down. In fact, nothing kicks in at all unless someone/something accesses one of those two affected files. Bottom line, instead of having a .htaccess file that was a couple hundred lines long and would have to be processed for every file request, the .htacess file contains only a few lines to handle www/non-www issues.

[Jill]

Pinned this for ya, Randy!

[linux_lover]

I agree Randy, I recently modified some of my redirects in PHP, I found I had more controll too, as for example you could store your list of viable redirects in your db whereas a large .htaccess can get messy.

[Randy]

Thanks Jill. I didn't even consider pinning it, but probably a good idea.

More control and much easier for the average person to use too LiLo.

FWIW, the main reason I mentioned it is that many of the 301 redirect questions these days seem to revolve around someone having changed shopping carts. In almost every case, these are easier and better to do at the file level than at the server level since they typically revolve around just one or two actual files being invovled in all of the former pages.

Tis why I've always said that it's impossible to give much in the way of general advice for redirects. Each situation is different, so one way lend itself to being a better option.

[MaKa]

A guideline I normally go by:

If redirecting (almost) every file on the server use .httaccess

If the redirect only affects a few files (as in the shopping cart example) use a .php location redirect.

[blueivy]

This is assuming of course the original files that you are redirecting are actually PHP files. If they are HTML files you can't execute code (PHP or otherwise) so .htaccess is the only way you can go!

[torka]

Or you could just use .htaccess to tell the server to parse HTML as though it's PHP, then you could use the PHP redirect code on the old HTML pages.

I'm not sure, but I think that would probably be less of a load on the server than having .htaccess handle all the redirects itself. Randy would be able to speak more definitively to that than I can, though.

Of course, in Randy's example way back up there at the top of the thread, the old pages were clearly not static HTML to start with (the .php extension and query strings in the URLs were a pretty strong clue)...

--Torka

[Randy]

The thrust of the post above and thread is really revolving around a dynamic site where one file actually delivers 100's or thousands of different pages. Blue Ivy's example(?) is a lot different in that it's dealing only with single static pages.

But yes you could simply tell the server to send .html files through the php parser. Not that it would gain you much.

If I were doing redirecting with a bunch of .html files I would personally use mod_alias and RedirectMatch rather than mod_rewrite if at all possible. It's just easier on server load.

[etzeppy]

The thrust of the post above and thread is really revolving around a dynamic site where one file actually delivers 100's or thousands of different pages. Blue Ivy's example(?) is a lot different in that it's dealing only with single static pages.

But yes you could simply tell the server to send .html files through the php parser. Not that it would gain you much.

If I were doing redirecting with a bunch of .html files I would personally use mod_alias and RedirectMatch rather than mod_rewrite if at all possible. It's just easier on server load.

What a great topic and exactly what I'm struggling with. I just moved my old static html site into an OSCommerce php platform. I would like to perform a search engine friendly redirect of my old html pages to the appropriate php replacement. Everything I had found prior to this thread said to use a 301 redirect commands in the .htaccess file. However, I am concerned about server load and thus access time for my site if I setup a .htaccess file with 150 or so instructions. I only need to redirect these pages if they are requested so I don't want to bog down the whole site any more than necessary.

Are you saying that a RedirectMatch 301 command is a less intensive process and is still search engine friendly? Is that the best choice for my application?

[Randy]

Welcome etzeppy !

As usual, the answer is going to be It Depends.

First, how many pages are you going to need to redirect? Are we talking 20 or 2,000? Yes I saw your mention of 150 pages but just want to confirm that the number is what you're really dealing with.

As a very general rule RedirectMatch is probably going to be your best bet if you use .htaccess in a situation like you describe. It is considerably less load intensive because there is less going on that requires the server resources to get tied up crunching data. This would work quite well if you're talking under 200 or so pages.

If you're talking about having to do it with a lot of pages I would go another route myself. In this type of case I would see if I could get the server to send .html pages through the php parser, and if I could I would drop a scripted redirect into each of those files to get people (and spiders) to the correct page. When using scripted redirects it requires no massive .htaccess file because the redirects are handled at the file level instead of the server level.

[etzeppy]

Welcome etzeppy !

As usual, the answer is going to be It Depends.

First, how many pages are you going to need to redirect? Are we talking 20 or 2,000? Yes I saw your mention of 150 pages but just want to confirm that the number is what you're really dealing with.

As a very general rule RedirectMatch is probably going to be your best bet if you use .htaccess in a situation like you describe. It is considerably less load intensive because there is less going on that requires the server resources to get tied up crunching data. This would work quite well if you're talking under 200 or so pages.

If you're talking about having to do it with a lot of pages I would go another route myself. In this type of case I would see if I could get the server to send .html pages through the php parser, and if I could I would drop a scripted redirect into each of those files to get people (and spiders) to the correct page. When using scripted redirects it requires no massive .htaccess file because the redirects are handled at the file level instead of the server level.

Thanks for the input. Yes, it will be less than 200 pages total. The .htacess approach sounds like the easist method. However, I do like the php parser idea since it's handled on an as-needed basis. I'll have to find out if and how I can do this on my server.

If I use the php parser approach, can I still use html pages that I don't want to redirect, or will the php parser "break" any real html pages that I might want to keep.

[Randy]

You can test it real quick and tell if it's allowed by your server. Put the following line in your .htaccess file.

CODE

AddType application/x-httpd-php .php .html

Then create a file that has some php in it. The easiest is to create a new file called phpinfo.html and put the following in it:

CODE

<?php
phpinfo();
?>

Upload that to your server after making the .htaccess change and call it up in your browser. If it works youi'll see a page full of information regarding your server's php configuration.

Regarding if you can still use .html files for plain old html code, sure you can. The php parser won't even attempt to kick in unless and until it sees the <? php opening tag. So if there's no php in the file it'll never fire.

Chris gave some examples of how to write a scripted redirect in our pinned [url=http://www.highrankings.com/forum/index.php?showtopic=5644]301 redirect thread[/url] if you need the correct syntax to use.

[etzeppy]

Hey that works great. I really like this method. Now for the follow-up question. Do I need to do anything in robots.txt to tell the search engines not to keep indexing the old html file names or does the "HTTP/1.1 301 Moved Permanently" command take care everything for me?

[Ron Carnell]

Regarding if you can still use .html files for plain old html code, sure you can. The php parser won't even attempt to kick in unless and until it sees the <? php opening tag. So if there's no php in the file it'll never fire.

While I agree you can certainly use plain old HTML code, I'm not sure it's strictly true that the PHP parser doesn't kick in unless and until it sees the <? opening tag. It's the PHP parser, after all, that is looking for the opening tag. It's still parsing the file, even when it finds no commands to execute. That necessarily entails a server load that wasn't there when the web server was just throwing those pages out port 80 as bits and bytes.

As Randy said, "It Depends," and I sure agree there's no stock answer. In general, however, I think using .htaccess and mod_alias directives is going to often be less abusive to the server than sending everything through the PHP preprocessor. In large part, that's because even a huge .htaccess is going to be cached on most machines with sufficient memory. The PHP/HTML pages won't be. It's also important to consider the number of "real" HTML pages being unnecessarily sent through the preprocessor. When you change your AddType handler to include .html pages, it's going to include ALL .html pages, not just the ones you need. That can be a heavy price in some environments.

Of course, if all your .html pages contain PHP then there's no hidden cost to calling the preprocessor. You'd be calling it any way. Similarly, if the scripted Redirects only fire off once in a blue moon, then the fact that can't be cached like .htaccess isn't important. You're essentially saving your cache for better things. Yep, it definitely depends.

I'm a little surprised, however, that we haven't yet explored another fairly common alternative.

If you have 200 or more pages in the root that need to be redirected, I think it makes sense to start looking for ways that won't create a large .htaccess file. If they're not in the root, however, I think it makes even more sense to take advantage of the fact that .htaccess is a directory-level option.

You're not stuck with just the one sitting in your root, after all.

If you have a large number of redirects, those redirects should be placed as close to the associated files as possible. Not in the root. So, for example, if you have 200 pages to redirect in /oldstuff you should create an .htaccess file IN /oldstuff to do the redirects. That .htaccess, unlike the one in the root, will only be read and only be parsed and only be executed when someone actually enters that folder. Server load becomes a non-issue because the server is only doing what it needs to do when it needs to do it. There is no unnecessary load.

I think Randy's original scenario, where there were a large number of redirects based on scripted parameters, is very much a valid time to consider scripted redirects instead of a bloated .htaccess. When you deviate from that scenario, however, it's once again time to reconsider options.

p.s. If I did have several hundred pages sitting in the root that needed to be redirected, I suspect I would abandon them and just face the costs of my mistake. Bad me. If that wasn't feasible, if I felt the cost was just too high, I would probably use a zero-second meta-refresh in each file and let the search engines figure it out as best they were able. Hope, they say, springs eternal.

[Randy]

Do I need to do anything in robots.txt to tell the search engines not to keep indexing the old html file names or does the "HTTP/1.1 301 Moved Permanently" command take care everything for me?

You don't need to do a thing with robots.txt.