Forum Moderators: open
From what i understand, we can only create 301 redirects on IIS only when the page actually exists? what happens if the page has been deleted and needs a 301 redirect? is it done by creating a dummy page? are there other ways?
the reason i'm asking is because we're in the process of cleaning up out site and removed a lot of our pages but we need to redirect them to the new content. Adding dummy pages back not only makes maintainence difficult, but is also making the site having a lot of unnecessary pages.
Please advise.
Thanks.
Simon
<%
Response.Status = "301 Moved Permanently"
Response.addheader "Location", "http://www.newdomain.com/newurl/"
Response.End
%>
but then, how would i configure it so that it will handle a lot of different redirects? is it by adding more header? is it by generating it dynamically using ASP and SQL table? If someone can give me some sample code, it'll be extremely helpful.
Thanks in advance.
Simon
I have one of these on my (.net) site, and it's based on some asp scripts I found *somewhere* on the web a couple of years ago. I'll dig around later today and see if I can figure out where I got it from. I'm pretty sure I found it in this forum, but searching these forums is tedious at best.
The script has a list of "old" and "new" URLs - when a 404 error comes in, the query string contains the "old" url - the script parses it, checks against a list and gives the 301 redirect if appropriate.
Personally, I would stay away from any custom 404 routines. I've seen very few of these that were set up properly 100%. You want to keep your redirects simple and to the point.
[ISAPI_Rewrite] RewriteRule /sub/old-page.asp http://www.example.com/new-page.asp [I,O,RP,L] It is literally that simple. You could set up hundreds of redirects as quickly as you can type the old and new addresses in the .ini file.
[evolvedcode.net...]
Works like a charm!
Really there are two basic solutions; the first is to leave a script in the place of a moved page so that any visitors to that page are automatically redirected to the new location, the second is to move the page and hope the user is willing to look around for whatever it was they were hoping to find. Neither solution is brilliant and while the first solution will work it can also leave lots of little pages laying around all over the place which looks untidy and can often be painful to maintain over time.
As quoted from the site you reference (which is actually against the TOS).
From a management standpoint, your site should not be returning any 404s for moved pages. Any time a page is renamed and/or moved, you should compensate for that by dropping a rule in your .ini file to capture the old and transfer to the new.
Also, the above quote is based on an older and still accepted method of redirecting traffic. You leave the old page there and insert the response header on that page. This makes for a maintenance nightmare as already evidenced by stse's comments. Here is an example of that header...
<%@ Language=VBScript %>
<%
Response.Status="301 Moved Permanently"
Response.AddHeader "Location", "http://www.example.com/new-page.asp"
%> With an ISAPI filter like ISAPI_Rewrite, you won't need the old pages anymore. ISAPI_Rewrite functions just like Apache's mod_rewrite and performs a vital function in long term site maintenance.
Don't get me wrong, a lot of people use the custom 404 method which does work. Many only have that option to them because their host will not install the ISAPI Filter. For those who have hosts who will install the ISAPI Filter, a custom 404 is no longer required.
We normally have a site map for all sites that we manage. We set up the 404 in IIS to redirect to that site map, that takes care of the few 404 requests that may come in. Everything else is handled through the httpd.ini file.
From a management standpoint, your site should not be returning any 404s for moved pages. Any time a page is renamed and/or moved, you should compensate for that by dropping a rule in your .ini file to capture the old and transfer to the new.
The script I referenced above does *NOT* return a 404 error unless it's appropriate. It's a custom 404 HANDLER, which can return any of several responses (404, 301, 403, etc. etc.), depending on the type of redirection you need - the code is pretty self-explanatory if you take the time to read it.
Getting your hosting company to install a custom 404 handler for you is a *lot* easier than trying to get them to add the ISAPI_rewrite stuff.
BTW - I see nothing in the TOS that prevents me from sharing the URL of a web site that directly applies to the question being asked.
Getting your hosting company to install a custom 404 handler for you is a *lot* easier than trying to get them to add the ISAPI_rewrite stuff.
There is a common misconception that the above is true. After going through this a few years ago with my host, it is far from being the truth. The installation of ISAPI_Rewrite is fairly simple. Most hosts will not install an ISAPI filter because they may not be familiar with it. If they would take the time to familiarize themselves with it, they could then see the potential this would have for making their tasks that much easier as a server admin.
I don't want to argue with you on the pros and cons of a custom 404s vs. a rewrite solution. I was just offering the original poster an option for their problem. The custom 404 is one, ISAPI_Rewrite is another. I've gone both routes in the past and can tell you from experience that the ISAPI filter is far more reliable and easier to manage than a custom 404, especially with larger sites.