Forum Moderators: open
The new site will have a different structure to the old one (different folders, directories), but will have the same property pages.
Let's say there are around 1000 property pages, each with this URL format
www.mypropertysite.com/property-name/index.html
In the new website, these property pages will have URLs such as
www.newpropertysite.com/indexpage323xy1.aspx?pageid=20
For search engine purposes, I want 301 redirects from all the old URLs to the relevant new URLs (mapping them to the right new page)
What's the best method of doing this?
We have a Windows server (IIS5, I think) if that's any help.
Why would you go from this...
www.example.com/property-name/index.html ...to this...
www.example.com/indexpage323xy1.aspx?pageid=20 Not a really friendly URI if you ask me. Oh, it will most likely get spidered but you would have been much better off using the old URI structure.
I'm not worried at all about them getting spidered (I've see examples of other sites ranking very high with those kind of URls), but I AM worried about the existing pages keeping their rankings. So if we can easily 301 them across to the new (ugly) URLs, I'll be delighted.
Is the ISAPI method a quick one, or does it involve a long manual task?
Is the ISAPI method a quick one, or does it involve a long manual task?
If you are familiar with Regular Expressions, it could be quick.
The host needs to install a global ini file. Once that is installed, you can then drop a local ini file in each site root. The ISAPI license is good for one server. If there are 200 sites on that server, they can all have their own ini and the host would never have to get involved with 301s, rewrite routines, etc.
You don't have to have that URI structure with .net.
Pageone, do mind expanding on how you'd implement the www.example.com/property-name/index.html structure?
Hmmm, let me see if I can answer this with some level of knowledge...
First you have to look at the URI structure of the asp.net pages. Then you need to map the asp.net URIs to the rewritten URIs via the httpd.ini file that will now reside in the root of your web once ISAPI_Rewrite is installed on the server.
Here's an example of a rule in the httpd.ini file that would control something like the above...
<added>See f00sion's comments below</added>
[edited by: pageoneresults at 7:38 pm (utc) on Jan. 26, 2005]
1. Make a new rule for every property to redirect to its new dynamic page, which would be time consuming but not impossible. Like this:
RewriteRule /property-name/index.htm www.newpropertysite.com/indexpage323xy1.aspx?pageid=20 [I,O,RP]
2. Are these old pages asp?.. You could create a database table with the old page address and the new corresponding pageid, when a visitor hits the site it can look up the pageid and then redirect, you would just need to include that code snippet at the top of every old page. Do a quick google search for asp 301, as response.redirect is 302 which you don't want.
If the pages are straight html then I lied and you only have 1 option.. either way its nothing pretty and will take some doing but would probably be worthwhile.
actually another possibility would be to still create the lookup table from solution #2 and have a rewrite rule like this:
RewriteRule /(\w+)/index.htm www.newpropertysite.com/lookup.aspx?page=$1 [I,O,RP]
the lookup.aspx page would then query the db and find the pageid and then redirect finally do the dynamic page with the property info... not sure if the 2 redirects would be bad though.
(1)You can configure IIS to invoke the ASP engine for pages with the shtml extension, assuming your host will allow this. I'm not sure I would choose a database solution. Since the mappings are not likely to change, I'm not sure I see the benefit.
(2) Seems there are a couple issues here. First you need to 'redirect' the old structure to the new structure. Although you could do that with a sever.tranfer, thus eliminating the hop back to the client, that's not optimum because you'll end up with duplicate content (SE's see same page on both old and new structure). Don't know how ISAPI Rewrite would fit here, but I think you want 301. With a 301 you might eventually retire the old structure.
(3) As Pageone points out, the new structure doesn't look very friendly. ISAPI Rewrite is often used when you want a different physical structure than what is visible to users and SE's.
(4) There's a discussion going on in the supporters forum about the wisdom of doing a major restructure and the jeopardy of the Google Sandbox. This is a very important issue if you care about google traffic.
I summary, I would:
a. Look at 301's to retire the old structure, pointing to the new friendly structure.
b. Look at ISAPI rewrite for mapping the new friendly structure to the new physical structure.
c. Probably not do any of this at all until the sandbox issue resolves.
d. Be very leary of this advice.
<edit>typos</edit>
(a) I'm not worried at all about the pages "friendliness". I've seen a very similar structure used on a hotel website and they're doing fine on Google.
(b) Sandbox should not come into it (don't panic me please!) because it's an old domain.
Here's another thought, though. Do we even need the individual mapping to protect page rankings. Won't a simple 301 to the homepage or a high level page protect any rankings?