Handling 404 Error Messages For Live WordPress Site Development
Recently we had a problem fall in our lap. The current web developer of a hosting client deleted their live site (oops!), and they wanted us to get it back.
Short story was, we couldn’t. The developer thought the site was no longer being served from their account on WP-Engine, so they deleted it (HINT: Check the current domain DNS settings as well as current Analytics/website stats to determine of a site is live or not!). They had no backups (HINT: If your developer doesn’t routinely backup your site or set routine backups for you, you need a new developer!) so there was nothing we could do.
Still in shock, they couldn’t invest in a new site — so they’re going to give creating their own WordPress site a shot. We immediately moved them to our servers to get the email accounts up and running, then quickly installed WordPress and the fantastic Coming Soon Pro plugin from SeedProd.
We used an archive.org grab of the homepage (that’s all they captured) to get back the tagline and some content and created a temporary landing page for them that would be in existence for the time it took for them to develop the site. This cut us out and also left them in a position where they could work without the clock ticking too loudly.
The sticking point though, was what to do about all the old page URLs — from an SEO perspective as well as visitor usability, all their old links were now going to throw 404 errors. Because of the unknown time-frame for launch and unknown content (were they going to replace the old pages page for page, or restructure the site? They were going to think it through), going through and redirecting the pages as needed was going to be time-consuming and somewhat painful.
We needed a quick solution that not only worked now, but also in the future and something they could manage on their own.
The solution was simple – one line in the .htaccess file to redirect all 404 pages back to the site root — the Seed Prod coming soon page. By letting the server deal with these 404 errors rather than WordPress, we get something working now, while also future-proofing the development.
ErrorDocument 404 /
It also saves us time and the client money.
Simple is [almost] always best.
Is this the way to do it always? Of course not. Relaunches should be managed for many, many reasons. But this is the best solution for a terrible situation.