Why Use It:
From a search engine optimization point of view, mod_rewrite is a great tool to help your sites get more pages indexed in more search engines. For example, although search engine spiders are getting better at it, some still have a hard time with dynamic pages.
Take this filename:
Forgetting the notion that it's not good to use the variable id as some spiders think it's a session id, many search engines have a hard time crawling these types of pages. As I said, they're getting better at it, but what if you could help them crawl your site in the meantime?
Enter mod_rewrite. With the module you can rewrite the above URL into something like:
Or, even better:
You can see where I'm going with this, I hope, and why it might help your pages rank in the search engines.
The module is also useful for a variety of other tasks; managing a lot of virtual hosts, dealing with the trailing slash problem on URLs, and even stopping people from using images from your server on their site (running up your bandwidth).
Setting it Up:
As you may know, you can compile Apache with different modules, adding functionality to your webserver. You can either add it as a static module (at compile time) or a as a dynamic module that can be added without having to recompile Apache.
As it is a potentially dangerous tool if you don't know what you're doing, I recommend working with it initially on a test server or sandbox area somewhere if you can. If you plan on using it on your live webserver, you'll need to check if your current hos offers the feature.
A quick email to support should answer the question. Or, if you have command line access (and access to Apache's conf file), you can peek at the file to see if the LoadModule command for the module is commented out or not.
Once you have an Apache server up and running with mod_rewrite installed, you may have to load the module in your conf file and restart Apache if it's being run as a dynamic module.
You can either put the Rewrite directives in your httpd.conf file or in a .htaccess file. (If you use the latter, you may have to change the Apche conf file to allow the .htaccess to override any rules in the conf file.)
This may be one pitfall if you're not familiar with Apache's conf file. You need to understand the order in which different rules and directives are applied by the webserver. One thing I ran into at first was having [
AllowOverride None] in my httpd.conf file for the directory where I was using a .htaccess file.
The above directive tells Apache to ignore any .htaccess file you may have on your server. You can also add the rewrite code directly in your httpd.conf file, but again you need to be aware of what overrides what.
Also, it's probably a good idea to include the following lines in your httpd.conf file in a container like <Directory> or <VirtualServer>:
This will log what's happening behind-the-scenes when mod_rewrite is in action. It is of great help when you're not getting the expected result and you can't figure out why.
Which method (.htaccess or httpd.conf) is better? Most likely putting it in the conf file, but the difference may not be enough if you're really looking for bottle-necks. You can put rewrite code in both places, but again be careful of what overrides what.
Or, what I learned in the last few days about mod_rewrite.
I'd been meaning to start using mod_rewrite and had done some initial reading on it, but my current server didn't have the capability. So, I put it off, trying some other manual techniques to help search engines spider my dynamic content more easily.
About a month ago, I started planning a migration of my site (with many sub-sites on it) to a larger server. Traffic was growing at a steady rate and I knew I would have to do it eventually. With a lot of my 'very first code' on the site, though, it took a little bit of work to get the site set-up on the new server.
The move was worth it, though, because on the new server, I had the ability to start and stop Apache (among other things) and I finally had access to mod_rewrite.
First off was a simple test. I created a .htaccess file with vi:
#start the engine
#this needs to be set to allow the URL manipulation
#the directory the manipulations will take place on
# mod_rewrite allows you to use Regular Expressions
# to define the manipulations
RewriteRule ^/foo.html /bar.html [R,L]
# the above looks for a file called foo.html
# and any request for that file gets redirected
# to bar.html
The above is a really simple example to see if mod_rewrite is actually working in a .htaccess file. If you're wanting to use it to help with search engine indexing, you'll have to take it a little further.
For it to work, you have to change your application to construct links as static files rather than dynamically. I have an online app and on one page there's a link to another section.
In the original, the link in the code had a '?' and variables after the filename. I had to change this to what I wanted the resulting files to look like in the browser's address bar.
Once I did this, I had to write some mod_rewrite rules to translate any requests for:
That's what some newbies to the whole concept don't understand - not only do you have to have mod_rewrite doing something, your application also has to change the way it links within the script. This concept confused me a little at first.
Next came the decision on whether to include the rewrite rules in a .htaccess file or in the httpd.conf file. If you think about it, you can see how having it in the .htaccess file might cause more overhead, but some have said the loss is minimal. I'm testing this for myself currently.
It looks like the server is holding up now, but as the search engines eventually find the new content, I'll be keeping a close idea on how much they grab and what affect they have on the performance of my server.
Mod_rewrite has a high learning curve, and it may not be for people who don't have a lot of scripting or unix experience. If you have time to look into it, though, it's a very powerful resource (in many aspects) that's worth the time it takes to figure it out.