| 2:15 am on Mar 4, 2009 (gmt 0)|
Hello cascade, and welcome to the forums.
I've been involved with two companies who had a similar challenge and they both resolved it with a 302 redirect -- and Google continued to accumulate PR to the domain root in both cases. After those two experiences, I'd venture to say that a domain root redirect to an internal url might be the one situation where a 302 status redirect is more the right choice than a 301.
There are two concerns I'd have in your plan:
1. It's not good practice to used mixed case urls - someone is going to get it wrong sooner or later, and file paths ARE case sensitive. So I'd use /new/ instead of /New/
2. Think about those internal urls and what will happen if you ever do fix the environment so you "could" drop the /new/ directory from the filepath. All your indexed internal pages, and their backlinks would change -- and that would mean a new 301 redirect. Better not to go in this direction if you can avoid it - it pretty much guarantees another speed bump in the site's future.
[edited by: tedster at 7:27 pm (utc) on Mar. 4, 2009]
| 6:48 pm on Mar 4, 2009 (gmt 0)|
Thank you tedster, this is exactly the validation I was hoping for.
| 7:46 pm on Mar 4, 2009 (gmt 0)|
Just because the new content is located in a subdirectory of the server's filesystem does not mean that you must show that subdirectory in the URL; Consider using mod_rewrite on Apache or ISAPI Rewrite on IIS to detect the domain root URLs, and then insert the subdirectory into the filepath used to locate the content.
This action occurs completely inside the server in the context of the original HTTP request, and does not involve sending any redirect response to the client. The fact that files are not located in the server's DocumentRoot is completely invisible to visitors or search engines, and the URLs do not change.
| 1:48 am on Mar 5, 2009 (gmt 0)|
Additionally don't show 'index.html' within the URL. End the URL with a trailing slash and let your DirectoryIndex directive get the right content for that URL. See also [webmasterworld.com...]
| 12:30 am on Mar 6, 2009 (gmt 0)|
Thanks to everyone for their information. As we consider the option of the 302 v. the mod_rewrite, I would like to just confirm one thing as it relates to inbound links and the use of the 302 redirect.
It would seem that in this scenario someone could either link to us using example.com or example.com/new. Wouldn't this be seen as two different pages by the search engines therefore hurting our inbound link contribution towards page rank for our home page?
| 12:33 am on Mar 6, 2009 (gmt 0)|
*** option of the 302 v. the mod_rewrite ***
Mod_Rewrite is used to produce both 301 and 302 redirects as well as for internal path rewriting.
| 12:51 am on Mar 6, 2009 (gmt 0)|
I think I'm referring to internal path rewriting - the option listed in JDMorgan's response. It would seem I have two choices here, either use a 302 redirect which would still show example.com/new as the destination page, or JDMorgan's approach and make the /new invisable to users and search engines.
Thanks for enduring my newbieness.
| 3:18 am on Mar 6, 2009 (gmt 0)|
> It would seem that in this scenario someone could either link to us using example.com or example.com/new.
Assuming you choose to internally rewrite URL example.com/<anything> requests to filepath /new/<anything>, then you can also detect any direct client requests for URL example.com/new/<anything> and generate a 301-Moved Permanently redirect back to URL example.com/<anything>.
Generally, this is only necessary if you have already (intentionally or accidentally) published the example.com/new/<anything> filepaths as URLs, and search engines have already listed them in results and people are already linking to them. If not, then properly-implemented, no-one will ever know that you are internally rewriting URL example.com/<anything> requests to filepath /new/<anything>.
In other words, do both. :)