I want to build a holding page so that during site maintenance we can display something appropriate.
Shopping list:
- Ease of toggling On/Off
- Don't want Google BOT to think all the pages have disappeared NOINDEX/NOFOLLOW
- Don't want users seeing IIS7's "ERROR 500 go away" message - show my Custom Page instead
We used to have an ASP "holding page" in the site that all URLs would be routed to. Since moving to IIS7 and SEO Friendly URL Rewriting that has not been feasible any longer.
So instead we have been using a separate IIS site that only contains a Holding Page DEFAULT.ASP and a 404 handler so that any URL gets routed to that. We then have to toggle over IP addresses, or Host Header domain names in IIS Config (and we have a bypass PREVIEW.MyDomain.com to get into the Live site during rollouts)
We need to set a Response Code - I think 503 "Service Unavailable" would be the most suitable? (although Custom Error Page for Http Error 503 seems to indicate that IIS7 will not display a custom page with Error 503?)
To prevent people seeing the IIS7 "ERROR 500 go away" message I think we need to set this "holding site" to allow Detailed Errors?
Main application is still Classic-ASP but for a holding-page-site we can implement ASP.NET if that gets us over some hurdles.
Is there an alternative way that we could handle this within the site (so all requests go to the Holding Page, but there is some Back Door so that we can test the site upgrades before removing holding page) [pls see my thoughts below]
Toggling the IP addresses (or Host Header names) between IIS sites is not a slick operation at present - doing it manually takes a minute or two for the half dozen IIS sites involved. Perhaps we could just have Web.Config files that we can toggle over - although I think that is likely to mean that some recent changes to settings get lost-in-the-wash :(
Possible alternative implementation:
We have been considering have a DEFAULT.ASP (our site operates through a single ASP page for all requests) which allows a Flag to be set and shows the Holding page. There would then be a "back door" for developers to set a Cookie (or perhaps IP address "bypass" list) so that during Rollout of an upgrade they could see the site was all OK before removing holding page flag.
One benefit of the current separate Holding Site is that any HTML / Images / CSS can be deployed there, whereas on the live site the Holding page has to assume that anything, including Images and CSS files etc, might be being changed as part of the Upgrade - and then Human Error gets in the way!