DevelopmentChecklist: Launching a Site Redesign

Checklist: Launching a Site Redesign

If you do things in a very specific order and double-check each aspect prior to launch, you can avoid a ton of headaches and losses in rankings during a site redesign.

Anyone who’s had a site online for more than a few years has probably had it redesigned at some point or another. I’ve managed a number of these in my day and I’ve often thanked my lucky stars that before I was an SEO I worked for a hosting company, and before I’d even worked on a website had seen how things can go horrible wrong when they’re being moved.

Fortunately it’s fairly straightforward to not mess it up. By simply doing things in a very specific order and double-checking each aspect prior to launch, like Santa checking his list twice, you can avoid a ton of headaches and losses in rankings.

I am having to write this from a fairly general perspective and am making some assumptions. Some of these steps may not apply to your situation, in which case they can obviously be skipped. Similarly, some of these steps may be addressed slightly differently. I’ll try to make note of these points as we discuss them below and focus more on what the end result is meant to be, so you’ll know how to tell if you’ve done it right.

Now let’s begin the site move …

Step One: Uploading Your Site

Obviously the first step in the process is to get your site to the location it will be living in. For those of you who may be thinking this means putting your site live, you are not following the process I would recommend. I never recommend to overwrite your current site with your new site. This results in a scenario where you cannot properly test your site before deploying it on your domain and assumes the way your current site was hosted is going to work great for your new one.

Take this opportunity to investigate your hosting options, but even if you find that your current hosting will work you should set up your new site as either a new account or add-on domain (assuming your account supports multiple domains to be hosted) or as an IP. This will allow you to test your new site on in the hosting environments in which it will live ad avoid finding technical glitches only once your site is live.

Step Two: Set Up Your Email

If you’re moving your site to a new host or even to a different account on your existing host, you’ll need to set up all your mail accounts and forwards. Best to get this out of the way. It has nothing to do with SEO directly, but it’s a pretty critical step.

Step Three: Setting Up Your Redirects

How you set up your redirects will obviously be different in different hosting environments, but there are essentially two groupings of pages that are critical to redirect prior to pushing your site live:

  1. Pages With Links: You will want to use Webmaster Tools and hopefully at least one other backlink tool (I tend to use a few for good measure but ahrefs or Majestic will do the trick). Pull the linked-to pages from the lists and put them in an Excel spreadsheet. Don’t forget to remove duplicates as you don’t have to redirect twice, just because a page might exist in two or more databases.
  2. Pages With Incoming Traffic: Where your cutoff is is up to you; I tend to redirect any page with incoming traffic higher than one per day for most sites but you can go as far as you want. Essentially you want to make sure you don’t tick off your visitors which your new site is being indexed. You will save this to a separate spreadsheet (or separate tab – either/or).

You will then need to map each of the pages on your old site to the appropriate page on the new. You want to map them as closely as possible to ensure that people land where they’re supposed to and folks that have linked to you will still be linking to the same resource or something very, very close to it.

The difference between these two lists is that the first needs to remain in effect indefinitely. These are pages with links and you want these links to pass weight for as long as they exist. For this reason you’ll want these redirects to exist forever. The second list is pages that have incoming traffic but not links. Generally this is either social references or search traffic. These redirects will probably have to stay in place for a month or so but can likely be removed at that point. No need to put an additional load on your server as it checks redirect lists when the page that they were going to is no longer in the search indexes or being shared socially. If you didn’t remove them you likely won’t hurt much, but if you do you’ll avoid a bloating redirect lists, especially as site changes stack up.

Note: This only matters if you’ve changed our URL structure. If all your page names have remained the same, then obviously this step can be skipped.

Step Four: Sending Through a Crawler

I always like to send a crawler through a site prior to launch to check for issues I may not notice going through manually. Depending on the timeframe you have available, there are a number of crawlers you can send through that’ll provide varying degrees of information.

One of my favorite crawlers for this sage is Xenu. Start it at the homepage and let it go. When complete it’ll give you a list of all the broken resources (pages, images, scripts, etc.) on your site and where they’re linked from.

You’re obviously also welcome to use other crawlers to pull additional data. Screaming Frog or even Moz campaigns can be used to find the issues you might miss going through it in a browser.

Step Five: The Usual Tech

Once all the resource issues are sorted out I always like to give a check of issues that will cloud the SEO results. Assuming that the basic content is similar and the titles and descriptions are moved over properly it’s important to make sure that you don’t end up shooting yourself in the foot at launch with poor tech. Make sure site speed is addressed, the mobile version works on all common devices, and that you have your secure certificate ready to default the site to HTTPS, and further, that you have all the redirections rules in place so that the site in fact will redirect properly to HTTPS.

For many of you the site will already be in HTTPS. Obviously the only task here is to maintain this, but if your site does not default to HTTPS, now’s as good a time as any to deal with that.

Each site being, unique there will be other tech issues you may have to deal with – these are just the global ones.

Step Six: Deploy and Test

Now it’s time to deploy the site; depending on how you’ve set up the hosting environment this step varies. Here are the three basic mechanics and what you’ll have to do in each:

Replacing your site: OK, so you didn’t pay attention to the recommendation above and are simply overwriting your current site with the new. Here are the steps:

  1. Make a full backup of the site (including the database if applicable)
  2. Delete all the files on the remote server. Little is more frustrating that working on a site with three or four different versions floating around. You need to delete the current site. You can throw up a quick index.htm page noting that you’re site is being upgraded and will be back online shortly.
  3. Upload your new site files and database.
  4. Run the crawler across your site again and test, test, test.

The perk to this route is that there is no DNS propagation nor emails to deal with. Once uploaded you just need to delete the index.htm “site down” page and you’re good to go.

Same host, different package or add on domain: There are a couple of ways to deal with this depending on the access you have, but for most you’ll simply contact your hosting provider and have them change how your domain resolves through their system. There may be a slight cost to this (again, depending on your hosting) but it’ll be more or less seamless and worth every penny.

New host: The most complex of the scenarios here is if you’re switching hosts. In this event the steps are different:

  1. Set up your email to check your new host for your mail but don’t delete your old, you need it checking both for a few hours.
  2. Login to your domain registrar.
  3. Point your DNS to the new name servers
  4. Monitor DNS propagation using a service (free) like This will let you know which version of your site is being displayed to different parts of the world.
  5. After a few hours (or heck … wait a couple days if you like) you can stop checking your email at the old location. The reason we do this is that as DNS propagated different people will access your site in different location (i.e. some will see the old while others see the new). During this time your email may be sent to either and so both need to be checked until propagation is complete.

Once propagation is complete you can remove your other site but I highly recommend keeping it online for a while until you’re 100 percent confident that everything about your new site is working and your analytics support that. With your site still up at the old location, if something does go wrong you simply need to switch your DNS back and your site will revert and you can fix the problem where it won’t impact real visitors.


Obviously there are little stages in here that I can’t include. A conversion of HTML pages to WordPress is going to have a few steps that a move from one WordPress theme to another either does or that are different. That said, the core principles of the steps listed remain the same and done correctly will minimize or eliminate any negative issues that can creep up during a site redesign and maximize the speed with this the benefits will be realized.

For those of my valued readers that have other tips for redesigns…please feel free to comment below.


The Third-Party Data Deprecation Playbook

whitepaper | Digital Marketing The Third-Party Data Deprecation Playbook

Utilizing Email To Stop Fraud-eCommerce Client Fraud Case Study

whitepaper | Digital Marketing Utilizing Email To Stop Fraud-eCommerce Client Fraud Case Study

21 Steps To Email Deliverability Success

whitepaper | Digital Marketing 21 Steps To Email Deliverability Success

Email, The Weapon Against Identity Fraud

whitepaper | Digital Marketing Email, The Weapon Against Identity Fraud