Redirection and you: Fun with .htaccess
As part of moving from one Web site to another, our link structure changed massively. With our previous provider, links were not SEO-friendly. In fact, the previous provider didn’t allow us any control over meta data at all. This means that all our pages pretty much looked the same to search engines.
Well, I didn’t want to loose the little what we had built with search engines and other publicity pieces that linked to old pages. I also didn’t want users to be welcomed to the site with 404s, so I needed to get all of the old site redirected to the new one.
The first step that was necessary for this task was to search which URL’s Google had indexed. So, I searched site:www.fbcbelton.org. This showed me 92 pages that Google had spidered.
The problem with our old URLs is that they only included an ID in a query string (ie: www.fbcbelton.org/sites/document.asp?did=1610), a very unfriendly method for people and search engines. This also creates issues in redirection because an .htaccess redirect can’t redirect document.asp?did=1610 to another location unless the new location understands the query string. For instance, if I wanted that 1610 to go to http://www.fbcbelton.org/meet-our-staff/, there’s not a simple way to do it with an .htaccess redirect (it is possible with mod_rewrite).
However, I’m accomplishing the redirect in two steps, first redirecting to a Perl script that correlates the old ID to the new page and redirects to the new page. So, I edited .htaccess with these three rules:
Redirect 301 /sites/calendar.asp http://www.fbcbelton.org/calendar/
Redirect 301 /sites/division.asp http://www.fbcbelton.org/cgi-bin/redirector.cgi
Redirect 301 /sites/document.asp http://www.fbcbelton.org/cgi-bin/redirector.cgi
The first rule says, I don’t care which calendar page you were going to, you’re just getting the current month from now on. (Sad, I know, but I am working on a calendar solution.) The second and third take the majority of the URLs and redirect them to a very simple Perl script that devours the query string and runs another 301 redirect to the actual page. The script is very rude, but the old IDs are hard-coded in as are the new URLs. (I’m hoping David will comment here and tell me an easier way to do all this, but I’m thinking there may not be one, at least short of using mod_rewrite)
Then I took the short URLs that our old provider gave to us and redirected them as well. So, before when you entered http://www.fbcbelton.org/memberconnect, their server would send you to /sites/document.asp?did=8291. Now, the short URL goes to the new location with one line:
Redirect 301 /memberconnect http://www.fbcbelton.org/member-connect-faq/
When using .htaccess redirects to redirect a page to a new location, always use 301. 301 means that the page is moving permanently. It is generally accepted that using that type of redirect is the best way to preserve your search engine rankings.
June 23rd, 2008 at 12:11 am
Hi Matthew!
Well, you asked…and I can’t really provide a silver bullet! However, what I used when we recently moved from non-WordPress to WordPress was Urban Giraffe’s Redirection plugin. It’s quite awesome. It logs 404 requests and you can turn those pretty easily into redirection requests to the correct page. I set up tens of rules for our old site to point people to the correct new page for 404 errors. Many I set up initially, knowing what would get hit, but there were a lot of unknowns I went back in a adjusted later as well based on the 404 error log it kept for me.
It handles all the redirection rules, and you can use regular expressions or not. However, given your specific situation, I’m not sure if it will be quite as useful. Your hardcoded Perl script is not a bad idea. Yes, mod_rewrite might be a bit faster (and a bit more complicated; I’ve set it up before but I usually have to copy and tweak–mod_rewrite from scratch is not for the faint of heart, or me!) but hopefully your 301s will get rid of the redirects for most people soon enough. In my situation, the old URLs were varied enough that adding a bunch of manual rules to Redirection was the easiest. But yours follow a pattern with the predictable ID, so using a script to automate it is pretty slick…you could even tie it to a database, although there you get into adding complexity and performance issues when your quick-n-dirty system is probably best.
Someone feel free to correct me if I’m wrong or missing something. But either the way you’re going now, or Redirection, or possibly both (I think Redirection would catch edge cases you’ve missed, but not anything your .htaccess redirects already send through the Perl script, and it would give you a 404 log of stuff you’ve missed).