Forum Moderators: phranque
I'm a newbie to .htaccess and have a very general understanding of how it works.
Three questions
1.) The company did a new site update a few months ago and when they did so they added a few lines to the .htaccess file. Here is an example:
RedirectMatch permanent ^/DIR/$ [mydomain.com...]
Is it correct to use redirectMatch permanent? Is there a better more effective way to write this to achieve a 301 permanent redirect? After reading multiple posts it seems like there are a variety of ways to do this. Should I included the full url in the redirect or simply the directory from root. example:
[mydomain.com...]
or
/a_different_directory/article_info.html
2.) When the company did the update they added about half of the redirects that the needed. In other words the old site is still available and is still being indexed by google and users. I want to finish doing all the redirects so that users and Search Engines are permanently redirected to our new site and new content. However, in January 2008 we are moving our website to a new content management system and I am concerned about putting a 301 redirect on content now and then doing it again to a different url in January. Any thoughts or advise on how this might affect search engine rankings? From my limited knowledge of 301 redirects there is a reason they are called permanent... but at the same token I need to get users to the correct content.
3.) Lastly as I mentioned above we are moving to a new CMS (content management system). Currently all our content is being referenced by dynamic urls and ids.
example:
[mydomain.com...]
With the new content management system it will also be referencing content by ID.
example [mydomain.com...]
What is the best method for permanently redirecting all of our pages? Do I create a line item in my .htaccess file for every piece of content and redirect each one to it's new url? We have 100's if not 1000's of content pieces. I can't think of another way to do this because both the old and new system have dynamic variables. Any help is appreciated.
However, the single most important message to get across right now --and one I repeat often, this being the second time today-- is this: Filenames are not URLs, and URLs are not filenames. The fact that you are moving to a new CMS does has *no* impact on what your URLs should look like.
Now is the time to sit down with all concerned and design a new URL system that makes sense, taking into account the major 'partitions' of your site and the keywords you want to include in your URLs.
I suggest that you eliminate file extensions from you 'page URLs' and use them only for included objects that cannot exist as the same object with a different file extension -- for example .css, .js, .gif, and .jpg files -- Each of these is a unique type of object that can be produced and rendered in only one way, and it makes sense to retain file type extensions for them.
However, pages can be produced as hard-coded HTML, be generated by PERL or PHP scripts, or be produced by your CMS. There is no reason to 'publish' the technology that produces these pages, and users and search engines don't care. So consider moving NOW to an extensionless page-URL system.
What you will do is externally redirect to these new (and final, never-to-be-changed-ever-again) URLs. Then when your server receives a request for one of them, internally rewrite the request to the correct file. As a clean-up step, you may also wish to externally redirect all of your legacy dynamic URLs and 'old' URLs to the new system.
But the key is to actually design a new URL system that is easy to maintain, can grow with your company, and that 'makes sense' to all involved.
Jim
You stated:
What you will do is externally redirect to these new (and final, never-to-be-changed-ever-again) URLs. Then when your server receives a request for one of them, internally rewrite the request to the correct file. As a clean-up step, you may also wish to externally redirect all of your legacy dynamic URLs and 'old' URLs to the new system.
So when you say externally redirect to the final URLs are you referring to using .htaccess to accomplish this?
as an example:
old URL - [mydomain.com...]
can be rewritten to
new URL - [mydomain.com...]
This is an example of what I would want. Then using internal rewrite I set this as the URL displayed in the browser and have the request call the correct content. Am I understanding this correctly?
And I am not familiar with how to do internal rewrite of URLs. Can you point me in the direction of good resources and reading? I'm assuming internal rewriting is not done with .htaccess.
You mention also doing redirect on all the old dynamic URLs to the new URLs. Is this only accomplished via .htaccess? I have 100's of URL's that would need to be redirected. Will this slow down the server by adding hundreds of lines to a .htaccess file? What are best practices? how have people done this in the past when they have large quantities of redirects.
Lastly, since we will be getting the final permanent URLs in a few months time should I bother redirecting the URLs that are currently still going to our old site? Perhaps using a 302 code rather than a 301 code?
Internal rewrites and external redirects can both be accomplished using Apache mod_rewrite. The difference is largely a matter of the syntax used in the mod_rewrite RewriteRule directive.
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
