I’ve been in digital marketing for over 10 years now, and it’s amazing to me that I still run into these scenarios as frequently as I do. I’ve learned, through experience, to look for all of the triggers for these potential problems and to alert my clients about them. Even then, these easily avoidable mistakes still happen because clients don’t always follow through with our recommendations.

While these items are – most of the time – easy to fix post-launch, these everyday mistakes can carry a heavy burden. I’ve seen websites temporarily loose very important (and profitable) rankings, and leak a lot of their paid media budget because of these easily avoidable mistakes.

Mistake #1: Staging Server At Launch

It is commonplace to have a staging server (also called a dev site) setup for your website re-design / re-model project. It is also a good practice since you shouldn’t be building a site in a live environment where your users can interact with an unfinished product.

There are two very important and often overlooked actions developers should take with staging servers. These aren’t just for SEO reasons, but they are a big deal as far as SEO is concerned:

1. The same way you have your staging server password protected (you do right?) to keep the lookie-loos away, you should have your staging server blocked from the Search Engines to prevent premature crawling. This also prevents the creation of duplicate content issues. I can’t tell you how many staging servers I’ve run across that are fully crawled, indexed and even show up in Search Results! You can easily block the Search Engine crawlers from your staging site via the Robots.txt file.
   • Create a .txt file labeled “Robots.txt”.
   • In it, add the following code:
     • User-agent: *
     • Disallow: /
   • Have it uploaded to the root folder of your staging server (NOT THE LIVE SITE).
2. Now that you’ve successfully blocked the Search Engines from crawling and indexing your staging site, be sure to unblock it when you launch the website. If you launch your new website with that block, well you can say goodbye to your rankings. All you have to do to unblock your site is change the contents of your Robots.txt file to the following (note that the “/” is gone):
   • User-agent: *
   • Disallow:

There’s a lot more you can do with your Robots.txt file, and your site may have more advanced needs. To learn more about Robots.txt files, check out this tutorial.

Mistake #2: 301 Redirects Mapping

One of the top questions I hear from clients that are about to embark on a website re-design / re-model is:

Are we going to keep our SEO rankings?

That’s a great question, and the answer isn’t a black and white “yes” or “no”. In order to have the best chance at keeping all of your rankings intact you need to ensure that you have covered all of your bases around SEO and site migrations, and 301 redirects are one of the most important action items on this list.

The “redirects” I’m referring to here are response codes that are given to user-agents such as Search Engine spiders. There are several different types and ways of using “redirects”. The one you’ll want to focus on for your site migration is the 301 Redirect. The 301 Redirect sends a message that this page has been “permanently redirected to a new location”. Don’t get too stuck on the word “permanent” here, as 301 redirects can be changed at any time. All that this word is doing is letting the Search Engines know that they’re clear to transfer any SEO authority from the old page to the new page, and also helping them re-learn the website.

The most appropriate way to map your 301 redirects is by looking at your old sitemap side-by-side with your new sitemap, and connecting the dots. Old Page A is now New Page A, and so on. Try to do this on a page-by-page, category-by-category, product-by-product level. Orphaned pages can be redirected to the most relevant page on the new site.

Redirects are only needed when the URLs are changing. Any change in the URL path should be addressed with a 301 redirect.

Last but not least, the way you’ll deploy your 301 redirects will depend on your server type. Linux servers are easier, as they allow you to use an .htaccess file. Windows servers require an isapi rewrite. Check with your developer to see how you should plan to deploy your redirects.

Mistake #3: Paid Media Landing Pages

This is a simple one, but I’ve had several *facepalm* moments in the past when this has happened. Whenever your URL changes, think of what you may have going on that’s attached to those URLs.

You may have SEO assets with hard coded links to those old pages, and you may also have a Google Adwords campaign running with certain URL paths being used as Landing Pages.

The moment your URL structure changes, your Landing Pages may start loading 404 Errors, and that creates a gaping hole for your PPC budget.

This is why it’s important to alert your vendors of changes to your websites. Your agency may not be able to check for changes multiple times a day, so communication is key!

Mistake #4: Analytics & Goal Tracking

This is one of the most overlooked items during new site launches. Everyone is usually so pre-occupied and / or excited about the new site, that they forget to import in the Analytics tracking codes prior to launch.

The result is at least a few days of zero visibility right when you’re the most curious to see how well the new site is performing.

Be sure to fully check that your Analytics platform is installed and working on the new site, as well as any goal tracking parameters.

Mistake #5: Never Launch on a Friday!

Picking a launch date for your newly designed / remodeled website is often times an arbitrary choice. There should be some timing strategy taken into consideration, but be smart about expecting bugs and unforeseen problems.

Expect that once the site launches you enter the final phase of your web-development  / design project rather than seeing it as finished. Virtually every website has post-launch bugs, or things that don’t work or look as they did back in the staging site. Things are just different in the live environment, and you also have your visitors, who are interacting with your website in unexpected ways, and finding little glitches and problems you couldn’t have possibly found on your own. It’s completely normal.

For that reason, never launch your website on a Friday! Unless you have a production team who’s available 24/7 around the clock, launching on a Friday will greatly limit your team’s ability to make quick fixes on the go. You may find an overwhelming email inbox on Monday morning with all sorts of website problems brought up by users over the weekend.

I hope this list of everyday costly and easily avoidable mistakes helps you avoid them!

What are some of the easily avoidable mistakes you’ve run into while launching a website? Share them with us via the comments below, and be sure to let us know if we can help you with your next dev project!