nigelhayler
asked on
Rewrite friendly URLs using Custom ASP 404 error page - is it search engine safe?
Hi,
I'm using a custom 404 ASP error page to rewrite friendly-style URLs to standard asp ones, and I then use server.transfer to call the actual page.
eg. www.mysite.com/london.htm (which doesn't exist)
invisibly becomes
www.mysite.com/cities.asp?name=london (which does exist)
My question is this - is there any danger that search engines will recognise this as a 404 not found error and so not bother indexing it, or does server.transfer fully hide the fact?
Many thanks.
Nige
I'm using a custom 404 ASP error page to rewrite friendly-style URLs to standard asp ones, and I then use server.transfer to call the actual page.
eg. www.mysite.com/london.htm (which doesn't exist)
invisibly becomes
www.mysite.com/cities.asp?name=london (which does exist)
My question is this - is there any danger that search engines will recognise this as a 404 not found error and so not bother indexing it, or does server.transfer fully hide the fact?
Many thanks.
Nige
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks kevp75 and Steve,
I wondered about all of this - a sudden chill went down my spine, having reworked my site to allow friendly URLs, when I thought what if the dreaded 404 gets through to the search engine? On the face of it, it does seem like it should, but I've just tried the utility you suggested Steve, and I get the same - 200 OK. Does this suggest that a custom 404 doesn't return 404 in the header at all? I wonder if anyone has used it, and found it does create a problem?
Nige
I wondered about all of this - a sudden chill went down my spine, having reworked my site to allow friendly URLs, when I thought what if the dreaded 404 gets through to the search engine? On the face of it, it does seem like it should, but I've just tried the utility you suggested Steve, and I get the same - 200 OK. Does this suggest that a custom 404 doesn't return 404 in the header at all? I wonder if anyone has used it, and found it does create a problem?
Nige
personally i haven't even tried url re-writing (other than with a component...)
It does seem like it should, however (if) Steve's pages are the custom 404 errors, I was able to spider them with no problem...so...looks like you should be good to go..
It does seem like it should, however (if) Steve's pages are the custom 404 errors, I was able to spider them with no problem...so...looks like you should be good to go..
My understanding of custom error handling in IIS is that it is exactly that: Instead of taking control over what should be done when a 404 error is triggered, IIS hands control over to the specified page.
When our ASP page takes control over redirecting to an actual page, we should still be generating our own 404 error if the requested content is not available. We do that by writing out whatever we wish for page content and specifying our own status code.
For example, if the URL requested is obsolete because it's been replaced by a page at a new address, we should issue a 301 response as follows:
Response.Status="301 Moved Permanently"
Response.AddHeader "Location", "http://www.mydomain.com/NewPage.html"
This code redirects the browser to the correct page AND tells the browser as well as search bots that they should update their records to show the new address.
And, when a nonexistent page is requested, so we need to trigger a 404, we need to use:
Response.Status="404 Moved Permanently"
Response.Write [A page with the error message and links to the home page and site search page]
So, the answer to "a custom 404 doesn't return 404 in the header at all?" is "Exactly, unless we tell it to do so in our code."
--Steve
When our ASP page takes control over redirecting to an actual page, we should still be generating our own 404 error if the requested content is not available. We do that by writing out whatever we wish for page content and specifying our own status code.
For example, if the URL requested is obsolete because it's been replaced by a page at a new address, we should issue a 301 response as follows:
Response.Status="301 Moved Permanently"
Response.AddHeader "Location", "http://www.mydomain.com/NewPage.html"
This code redirects the browser to the correct page AND tells the browser as well as search bots that they should update their records to show the new address.
And, when a nonexistent page is requested, so we need to trigger a 404, we need to use:
Response.Status="404 Moved Permanently"
Response.Write [A page with the error message and links to the home page and site search page]
So, the answer to "a custom 404 doesn't return 404 in the header at all?" is "Exactly, unless we tell it to do so in our code."
--Steve
Ooops, obviously the second response.status should have been:
Response.Status="404 Not Found"
--Steve
Response.Status="404 Not Found"
--Steve
ASKER
Thanks Steve, that's something extra I'll bear in mind for a simple custom 404 Not Found page - to ensure the correct header is returned.
On the original question of friendly URL re-writes - I'm so glad I haven't wasted time today - I can pack up for the day happy! Thanks to you both.
On the original question of friendly URL re-writes - I'm so glad I haven't wasted time today - I can pack up for the day happy! Thanks to you both.
So, curiosity has a grip now....what happens when a client requests a page that does not exist?
Does the code on the custom 404 page send it into an endless loop, or would you simply setup some error checking?
Does the code on the custom 404 page send it into an endless loop, or would you simply setup some error checking?
Nope, IIS doesn't get involved again if the custom page sets the status to 404.
ahh....good stuff to know...thanks opho
p.s. I'm just outside of Springfield, MA ;-)
The search engine will go to that page, and no matter how hard you try (unless you use a component), the initial headers that get sent to the browser is that of a 404 (page does not exist) error. Which is exactly what the search engine will see. That the page does not exist...