Important Things To Consider When Launching a Website – Digital Marketing Madness

John Maher:  Hi. I’m John Maher. This is “Digital Marketing Madness.” This podcast is brought to you by McDougall Interactive. We’re an Internet marketing agency in Massachusetts. Today, my guest is Rick Floyd. We’ll be discussing important things to consider when launching a new website. Welcome, Rick.

Rick Floyd:  Hello there, my people.

John:  Rick, what are the top three things to consider when launching a new website?

Rick:  Assuming your pre‑launch testing is complete…you have completed your pre‑launch testing, haven’t you? Meaning you probably had the website on a staging server, a development server. You can only test it so much, and then you launch it. Ideally, you launch it, and it works exactly like it did in the test environment. But I’m here to tell you that quite often, that’s not true.

Website Development Environment

If it’s not true, depending on what part of it is not working the way it did in the dev environment, it could be really, really important.

John:  The dev environment is one server where you have the website running, so you can test it as you’re building it. Then, you have to take those files ‑‑ or even the database, in some cases ‑‑ and move that over to the server where that website is going to reside.

Depending on what the settings are on that server or things like that, sometimes things can be set a little bit differently, and it can have drastic differences in the way that the website runs on the new server, once you move it.

Rick:  Right. These are computers. Things don’t always go like you want them to. There are a million things to look out for on this, but I’m going to go with a couple of things here that I’ve had experience with having issues with.

3 Things To Consider When Launching a Website

The first is a timeline of tasks to launch seamlessly with no website downtime, meaning your current website stays up, and then all of a sudden, it appears replaced by your new website, and nobody notices the difference. There’s no missing website. There are no 404 errors.

The second is to make sure that you have redirects of your old page URLs for your old website set up to redirect to new pages on your new website, new URLs. That’s very important, obviously, because if you have a page that was called “Widgets,” and your new page is called “Widgets Two,” you need to redirect that.

John:  That’s both for search engines to find the new pages and for people, if they have old pages bookmarked or links from other websites to your old pages, et cetera.

Rick:  Correct. Then, third, even though you’ve tested it before launch, this is very important. Thorough testing after launch. This is the part many people leave out. That’s probably the most critical part, like I said in the beginning.

John:  Let’s take each one of those three things and discuss them a little bit more. What is the timeline of tasks that you need to ensure a seamless launch with no website downtime?

Launching a Website with No Downtime

Rick:  It’s actually pretty simple. It’s just you have to do these things in this order. First, you just leave your current site running, as it is. You don’t have to do anything to that. There are differences in these setups, depending on how you’re setting your website up. I’m going to go with very standard. I’ve got my website on one server.

I’m launching a new website. I’m putting it on a different server or a different place on this server. Essentially, you leave your old website running. Then, you go to your domain manager tool and point your domain, whatever it is, mysite.com, to the new hosting server. Usually, this means you have to enter two or three, sometimes four domain name server addresses.

They’re often like ns1.webhost.com, ns2.webhost.com. Basically, it’s telling the Internet, “When you’re looking for this domain, go to this server. This is where it lives.” That server will serve it to you. Then, you just wait, as the domain name propagates throughout the web. That can be 10 minutes. It can be 48 hours. The new site will just start appearing under the domain name. Then, you can take the old site down.

John:  I’d recommend, if you’re going to be messing around with your domain name, obviously, have somebody do this who knows what they’re doing. It can get pretty complicated. There are the name servers, as you just said. NS1, NS2, whatever.

But then, there’s also the DNS records, where you have the A record that points to where your website goes and your MX record that points to where your mail goes. Those are different, in some cases. You want to make sure that you know what you’re doing or you have somebody who knows what they’re doing do that for you.

Rick:  Really, the only way to screw this part up is to not do that second step before the third step. If you repoint your domain name to your new server, and your site’s not ready to go…

John:  Then, it’s going to be pointing to nowhere.

Rick:  It’s going to be pointing to nowhere.

John:  You won’t have any website there.

Rick:  I’ve seen that happen. Somebody, “My web host said that they’d repoint the server for me.” Your new website wasn’t ready to go, and now you’ve got your website’s not found. It could be dropped by Google. You could lose business. All kinds of stuff like that. It’s important to do it in that order.

Get your new website on the server. Transfer your domain so it’s pointing to the new server, and then just wait.

Setting up Website Redirects

John:  Then, the second thing was, “What are the steps in correctly setting up redirections?”

Rick:  I’m going to go over this pretty quickly. We have info elsewhere on this blog that’s more in‑depth about redirections.

John:  You and I talked about 301 redirects, at one point.

Rick:  Correct. I’m assuming, again, you’ve done your homework, and you already have the old URLs, the addresses of your pages mapped to the equivalent new URLs on your website. Then, you need to have a strategy for actually putting the redirections in place, usually either in what’s called an “htaccess” file on the web server — it can be a different file name if you’re not on a Unix or Apache server, and you’re on a Windows‑based server, there’s a place to do that there, as well — or possibly via plug‑in in WordPress or a similar CMS, which is a content management system. You want to make sure this is done before the new site goes live, not after.

You can do it after, but as soon as that new site goes live, you don’t want people not finding the pages. You definitely don’t want Google not finding your pages. You want these redirects all set up and ready to go before you launch your new site.

John:  Then, what do I need to do post‑launch?

Rick:  First thing you want to do is check those redirects, make sure they’re working. This part is really boring. Everybody wants to skip it. If you have a really large site, you might need a team of people to do this. The more testing of that new site ‑‑ and I don’t care how much you tested it pre‑launch ‑‑ the more testing that you do, the better off.

You want to test those redirections. Type the old URL in a browser, make sure it redirects you to the new page.

John:  One thing you can do, too, is go to Google and find all of your pages in Google and click on those links. That can be a good way to do that, as well.

Website Post-Launch Testing

Rick:  Correct. You want to, basically, really try to visit every page. Scroll up and down. Make sure all the content’s there. It may sound crazy. I’ve seen things where a page looks fine, and something strange happened. I scrolled down, and the bottom half is missing. There are things that you would not believe that can happen.

You just want to visit and use your site. Visit the pages. Click on the links. Submit the forms. If you have e‑Commerce, you want to buy a product. Test product purchases. A lot of shopping carts have a test mode that you can put them into, so you don’t have to actually get your credit card out and buy stuff.

You may want to have a friend even try to buy something. Make sure that when someone does use a credit card, it works. You want to check that all your phone numbers are correct still.

John:  You mentioned filling out the forms. Make sure that the person that the form is being sent to actually does receive that form in their email, et cetera. Make sure that all those important things like lead generation and you said for an e‑commerce website, make sure that you can actually purchase a product.

Those may seem like obvious things, but we’ve seen that in the past, where somebody will launch a new website, and then a few weeks goes by, and they say, “Why aren’t we getting any of our leads from the forms?” We say, “You have to test that.” Of course, we do that for our clients, but we’ve seen that in the past with people that come to us and don’t know what’s going on.

Then, we find out, you just launched a new website, and you never tested it.

Rick:  There have been so many times when I’ll say to a client, “What happens when someone submits this form?” The answer is, “I don’t know.” It’s your business. You do want to know. It’s not a big deal if you don’t. Somebody like us can help you find that out pretty quickly, but you can also, like John just said, submit the form.

See what email comes to you as a result of that submission. See what “Thank you” message comes to you as a result of that submission. If you were a client, are you happy with that? That’s going down a whole other road right now. It’s site testing. Just make sure it works.

John:  That’s all excellent advice, Rick. Thanks again for speaking with me today.

Rick:  Thank you, John.

John:  For more information about digital marketing, visit mcdougallinteractive.com and subscribe to this podcast on iTunes. Thanks for listening. I’m John Maher. See you next time on Digital Marketing Madness.