Forum Moderators: Robert Charlton & goodroi
I'm really just looking for members opinions and past experiences on this topic. I know there are other similar posts referring to the 301 permanent redirect solution ... but I'm asking on the wisdom of this move...
We have a three year old popular and successful site, which has acheived its success largely through word of mouth and write-ups on various forums etc.. (i.e. we haven't relied on Google).
We rank well in Google for our homepage for our main term (after a LONG wait initially of a couple of years). We don't particularly monitor our internal pages - but we feel they don't do too well, although they are starting to pick up.
As we are an .aspx, IIS site, we currently use a 404 page error trap in order to serve dynamic pages, but as htm pages. (I believe this is perfectly acceptable - but if this isn't seen as white-hat, then please let me know). The tech team now say that this is a very inefficient way of managing the code of the site and want to use a new micrsoft way of doing things to switch the format of our URLS from :
www.example.co.uk/retailerdetailcompanyx.htm
to
www.example.co.uk/retailerdetail/companyx
I would really appreciate members views..
1) Do people think there is anything 'wrong' with the current way we do things in the eyes of Google?
2) In the long run, will there be an advantage to this move, i.e. is the second format more acceptable to Google?
3) How much risk is there to this move?
4) Most imporantly perhaps ... would you make the move yourself.
Thanks very much - I hope I'm not going over old ground too much
moveontoo
We rank well in Google for our homepage for our main term (after a LONG wait initially of a couple of years). We don't particularly monitor our internal pages - but we feel they don't do too well, although they are starting to pick up.
I'd be monitoring those internal pages just as closely as the home page, if not closer! ;)
As we are an .aspx, IIS site, we currently use a 404 page error trap in order to serve dynamic pages, but as htm pages. (I believe this is perfectly acceptable - but if this isn't seen as white-hat, then please let me know).
I am not real fond of 404 error traps. Many of the ones I've seen were incorrectly implemented, did not return the proper server headers, etc. Are the .htm pages served "on the fly" or are they pages that actually reside on the server?
The tech team now say that this is a very inefficient way of managing the code of the site and want to use a new Microsoft way of doing things to switch the format of our URLS from www.example.co.uk/retailerdetailcompanyx.htm to www.example.co.uk/retailerdetail/companyx
Ah, they are most likely using IIS 7 and the new tools available for rewriting .net. They want to go extensionless which I highly recommend, definitely a good move since you are making the change, or are considering it.
1) Do people think there is anything 'wrong' with the current way we do things in the eyes of Google?
There could be plenty wrong. A .NET site out of the box has many challenges to overcome before a clean indexing can occur. Have the developers addressed the VIEWSTATE element? Does it sit at the top of the HTML and fill up with thousands of characters? If so, that needs to be addressed.
2) In the long run, will there be an advantage to this move, i.e. is the second format more acceptable to Google?
I think so. The move to extensionless is an excellent choice and one that most should be considering moving forward. Extensions are meaningless at the consumer level, they don't need to be there.
3) How much risk is there to this move?
It is significant. You are going to go through a gestation period where the SEs have to recalculate the entire site because the URIs are changing. Once you change those URIs, the pages start out fresh again. But, you will be 301'ing the old to the new so that period of gestation shouldn't be too long. I usually suggest a waiting period of 90-120 days depending on the scope and depth of the site. Deeper click paths take a bit longer to resurrect.
4) Most imporantly perhaps ... would you make the move yourself.
Yes I would. And, I have been for the past few years. I've got a few more large properties to convert but for the most part, we've got our bases covered on our Windows Servers.
Thanks very much - I hope I'm not going over old ground too much.
No. Thank you for joining us. You can never go over old ground too much when discussing rewrites, especially with the .NET platform.
I have no idea what a 404 error trap is (perhaps you could explain), Conventional wisdom is when you link to a page it should appear with a 200 (OK) header with no redirects along the way. If you link to a page that doesn't exist return a 404 (page doesn't exist).
It's not a technology issue. ASP.net rewrite can be persuaded to work sensibly.
Wow - thanks for the great and thorough replies.
Pageoneresults - thanks very much for your very thorough reply. I think you've pretty much answered all of my questions. The only point I'd like to clarify is your answer to point (1). Assuming we've done the coding right in the early days (and I'm not saying we necessarily have - but assume so for now), then is there anything wrong with our current practice or our current URLs in the eyes of Google?
i.e. is using a 404 trap to produce a page www.example.co.uk/retailerdetailcompanyx.htm any better or worse than using the new IIS 7 tools to create a URL such as www.example.co.uk/retailerdetail/companyx (assuming all coding was done correctly) ? (The pages are produced 'On the fly' but are fairly static apart from some panels within the pages which might change. i.e. Our details for the retailer don't change often - but a little statistics panel for the retailer might change daily for instance).
Thanks
moveontoo
Your answer seems to be virtually the exact opposite of pageoneresults.
You feel that it is best not to make changes. Our current pages are certainly indexed by Google - but we feel they perhaps could be higher. (This is just a feeling though - we haven't really spent too long measuring their performance).
The 404 trap is, I would say, simply a workaround that those using microsoft technology had to employ in order to compete with Unix websites in Google. (There are other ways of doing this nowadays). As I understand it, Unix based technology has always provided tools to allow you to rewrite your URLs (perhaps to make them more 'spiderable'). In microsoft IIS, the 404 trap workaround is to link to a URL which doesn't exist and wait for IIS to throw a 404 error. However, you can tell IIS to return one of your pages instead of the default 404 page. Therefore, you can tell IIS to return a page which dynamically determines what you wanted to show based on the non-existant URL. So the end result of this is that you can give your dynamic pages 'static looking' URLs.
I'm not sure I've explained that very well - but I hope you get a rough idea.
Thanks
moveontoo
i.e. is using a 404 trap to produce a page www.example.co.uk/retailerdetailcompanyx.htm any better or worse than using the new IIS 7 tools to create a URL such as www.example.co.uk/retailerdetail/companyx (assuming all coding was done correctly)?
Is something broke? I mean, is there something "inherently" wrong with the current URI structure other than it is flat? When I say flat I mean everything appears to be at the root with no sub-directories? They may be suggesting that you move into a more "sectioned" website structure. But, if something isn't broke, I'd be asking why?
I'm not real fond of www.example.co.uk/retailerdetailcompanyx.htm either but if there is "no need" to change it right now, then leave things be.
I am fond of www.example.co.uk/retailerdetail/companyx but I'd be structuring it a bit differently. Maybe something like this...
www.example.co.uk/companyx/detail
I try to keep the relevance of the sub-directory naming intact. It doesn't make sense to push the detail up to the top because it is not going to remain constant. The /companyx/ will remain constant. You'll most likely have /companyx/summary or other additional pages that will reside after the /companyx/ level. If you move into this type of structure, be sure to have an index page at /companyx/ that allows a drill down to /detail, /summary, /contact, etc.
There has to be a solid reason for making a change like this. Is there a direct ROI associated with it? You'll most likely lose some revenue during that recalculation period. Is it worth it? Can you "slowly" move into the new structure without upsetting the current flow too much? Why do they want to change? Ya, that question keeps coming to mind. I don't see anything really wrong with your current URI structure.
P.S. That whole 404 setup makes the hair on me neck go Mohican.
Should we change our URLs as our tech team suggests?
Heh! It's usually the tech guys wanting to confirm the SEO guy's changes. Someone on the Tech Team must be reading WebmasterWorld. ;)
1) Do people think there is anything 'wrong' with the current way we do things in the eyes of Google?
No - we've used the 404 method for years now. I assume you are issuing the correct 200 header so there is no problem here.
2) In the long run, will there be an advantage to this move, i.e. is the second format more acceptable to Google?
Not more acceptable IMHO - maybe easier for you to maintain. We use a database for our 404 (and 301 redirects). Not perfect but useful enough.
3) How much risk is there to this move?
I'd add that if you do this change you'll need to put a 301 in place for each "old" url. Not a major issue - we've done this.
4) Most importantly perhaps ... would you make the move yourself.
I'm a natural conservative - unless the tech team could convince me of the $$ value of a change (better rankings, less maintenance, I'd say no.
Cheers
Thanks very much for your replies.
Based on these our current thinking is as follows.
We should make the tech changes - but do all we can to keep the current URL's the same. This is obviously more complicated for the tech team (and future development) - but still probably makes the code quite a bit nicer for them in future.
We may well slowly move our pages over to the new URL format - maybe only a few at any one time - then watch how these get on before tackling the next set.
For information, we're also planning a graphic/html redesign of the pages. From reading comments, it looks like we're going to have to be very careful there too - and probably best to do that separately to any URL changes so as not to confuse Google too much.
Thanks again for all replies... looking forward to any other comments..
moveontoo
If its an error page, it should return "404" in the HTTP header.
There's a lot of misconfigured servers that return a 302 redirect, or 200. That can cause a lot of problems.
Correct - but it is not an error page though. The "404 error page method" is a badly named method for achieving URL rewrites in IIS without using ISAPI, as IIS does not support mod_rewrite.
And you can configure the method to return a 404 code for non existent pages (and 301 redirects)
It is quite versatile.
Cheers
