In the past several years, I’ve been thrust into the middle of many incredible messes as a result of websites moving from one platform to another. Most of these were purely the result of developers not knowing/caring about preserving traffic, but a couple involved lazy or overconfident SEOs. In either case, here’s generally what happened after these sites went live:
That’s all organic search traffic. Nope, no tracking errors. I’ve seen sites lose as much as 75-80% of their traffic. I’m sure others have experienced worse. Regardless, it’s bad. In the case of the example above, as is the case with many sites, over half of their traffic was from organic search. So that means a net result of 25% total traffic loss. Assume the same percentage drop in revenue/new leads.
As you can imagine, being faced with that kind of hit on your business immediately after shelling out $100-500k (typical prices for a large but not quite enterprise site) on a new site is not ideal. If you’re a massive brand that is constantly pushing out new content and getting many new links, you may be able to recover from a messy move in a couple months. If you’re not, like the vast majority of sites, you may never recover.
So what went wrong?
In a few of the recent cases I had to try and clean up, here’s a quick summary of the issues.
Site 1: Switched to a new ecommerce platform, set up a wildcard style redirect that sent every 404 to the homepage.
Site 2: Site had a massive and dynamic catalog (tons of filters generating lots of new pages) with near a million SKUs. An SEO was involved in the move but only mapped out redirects for about 500 or so URLs. Leaving hundreds of thousands of pages that ranked organically as 404s. (Fun note, when I got involved, it was after the company had moved to a third site, repeating the exact same mistake again)
Site 3: Company had an agency handling SEO, a separate agency handling development. Development agency did not offer any communication about the development process to the SEO agency. SEO agency didn’t ask either.
Worse yet, the developers created a very slow-loading site (lots of background and hero banner videos) with a lot of duplicated content. Meaning, if you had two navigation points to one topic, normally those two items would link to one page. Instead, they just created two pages.
Site 4: I was actually involved in this one, and it turned out the best of the bunch. Same setup as Site 3, but we communicated about up front about the plan to avoid traffic loss. Things seemed great. Then the agency went radio silent up until the week of launch. Even the client could get answers out of them. Turned out they were outsourcing the development and in an especially lame manner. The site was a joke, kind of a frankenstein production. It was replaced by a new platform in about six months.
I could go on with more stories, but those seem to cover the general spectrum. Site one was just a clueless mistake. Two was an SEO in over their head. Three was everyone working in a silo and playing the “not my job” game. Four was a really crappy and unethical developer.
All of these could be avoided though, if developers just took responsibility for basic development practices. This doesn’t mean any of the weird magic tricks a lot of SEOs claim to know. This means following the simple guidelines that Google itself outlines.
Do you have a page selling men’s blazers on the old site? Is there a page selling men’s blazers on the new site? Great, no reason to change that URL. If you absolutely must change URLs (far too many times URLs change because it’s convenient, not because it’s necessary), 301 redirect from point A to B. Rinse and repeat across the site.
That one, simple process goes a very long way in preventing traffic loss issues.
And for you developers that fancy yourself a creative agency as well… don’t be in a rush to rewrite the entire site. If a page ranks well, it’s largely due to links and content. Now, you can certainly destroy a lot of those links when you redo navigation (internal links), and hopefully you’re not doing that, but at least the external ones are preserved by not changing URLs as I mentioned above. Worst case, if you do a redirect properly, the external links remain albeit with some degree of lost value. Now content, there’s nothing preventing you from leaving that. Migrate any copy on the page as well as things like headings, html titles, etc. If the site needs fresh copy because the existing work is poorly done or outdated, preserve as much as you can. But any major changes are going to come with the risk of lost rank. Know that going in.
That’s two things. Neither are much work. There are obviously instances where it is, if the old platform is something very outdated or very proprietary and there’s no database you’re able to export from to move content. But it’s increasingly rare to find that on a larger site, large enough where manual efforts would be impossible. More importantly, neither of those concepts exist within the realm of “SEO wizardry” or any nonsense like that. Any developer at this point in time should know these things are important. Any who doesn’t, I would strongly question their competence in building a website.
Are there other things to worry about? Things that can impact traffic levels when moving to a new site? Sure. A robots.txt file could be copied from the staging environment and set to disallow all. A site move could be coming with a major shift in business direction, thus it’s not even possible to retain the same content. A company could be consolidating several sites on international TLDs into one site and there are complexities there. A site could be developed in a way that makes it complex to crawl, like angular.js. Plenty of other things can happen. But far too often, I’d even say in most cases, it’s the URL and content changes without good reason that kill people. Businesses get excited that their site is changing and want to change a lot more than they need to, and developers don’t think through the ramifications. And if the ramifications involve damaging your largest source of business on the web, than that developer doesn’t care about your business, only theirs.