How to Move Your Web Site without Chaos

Zero minutes between sessions is not good! Also it’s cold. And my wrists hurt. And other complaints that you’ve heard from me before.

Jake Baillie, Managing Director, STN Labs, is pulling double duty today as moderator and speaker. Also speaking is Guillaume Bouchard, CEO, NVI and Ralf Schwoebel Founder & CEO, Tradebit Inc. Ralf is actually presenting in this panel and in another panel this session. Wow. That’s better than Andy Langton, who isn’t here at all.

Ralf Schwoebel is going first, because of the aforementioned doublebooking.

Reasons to move your site:

• More than three downtimes in the last three months
• Scalability
• Operating System change
• Space requirements

Requirements of the process:

• No down-time
• Database integrity
• Within short time frame
• SERPs preservation

Concepts of moving:

• Sudden death: “this domain has moved and your name server doesn’t know — come back later”
• Slow death nameserver switched – both servers deliver the same pages, orders might be messed up.
• New domain – “this domain has moved here…” – redirects, links
• Tunnel view – Reverse proxy setup on old IP to the new one

Prepare the new site — in peace

Edit your hosts file to point to the new server and double-check your set up. There was more on that slide but Ralf is zipping right through. He’s got places to be, after all.

You should test all aspects of your Web application once you move. This includes: Installed mods, language, dynamic pages, database, tools like ffmpeg, file system/OS and drives / storage.

The tough part is moving databases. If you run a larger e-commerce site, you might have a large databse with orders coming in very minute. What now?

• Disable the order process for “maintenance”
• Dump the DB
• Copy and load the dump
• Flip the switch.

For 30 GB, it took 180 minutes. Pretty fast.

For those with no downtime, there’s the slow death method:
After the new server is prepared and up, move the database like described above, change database host in application to remote, change DNS entries

For the tunnel view, switch off the webserver on the old serve, fire up the reverse proxy (Squid, nginx, IP tables, Apache, others), change the DNS entries. Easy-peasy.

Now he’s got to go. Bye, Ralf!

Oh, hey, Andy’s back! Hi, Andy. But before we get to Andy, it’s time for Guillaume Bouchard.

Things to do during the pre-move:

When starting the pre-move, you have to take into account the need vs risk in switching domain names. The first question is do you really need to change the domain name? No, really, do you NEED to change the domain names? Think about this. Is this the brilliant brain child of some marketing exec who has no clue of how the internet works?

Answer: Probably.

Fight to death to avoid weak reasons for changing the domain name. Tell your boss:

• Rankings will inevitably going to drop, temporarily
• Chances are when rankings return, they won’t be as strong as before
• There is a fair amount of work involved
• There is a fair amount of risk that it won’t be done right
• If it’s not done right, rankings might tank for months and months.

There are a lot of steps to taking in switching domain names, and it’s easy to miss one. Seriously, don’t take the risk if you don’t have to.

But if you simply must, here’s some things to consider:

Nature of the move (whole or partial transfer)

• Shifting to a new domain and transferring all content
• Shifting to a new domain and transferring partial content
• Splitting off some content to a new domain for RP or marketing purposes
• Splitting to a new domain and changing URI structure
• Splitting to a new domain and changing content

In each case you would need to do 301s properly.

What to expect in terms of indexing time and rankings:

Indexing time for a new domain after the old site has been redirected:

• Google: one month
• Yahoo: one to three months
• Microsoft: Quick indexing, less than a month

To get rankings back:

• Google two to four months
• Yahoo: one month
• Microsoft: one month

Make sure you’re pointing links at your new page. Seriously.

Registration of the domain and the IP neighborhood.

Make sure it’s really new, not just burned and dumped by a spammer in the past. Do a bit of research. Do the same with your IP neighborhood. Use seoegghead.com to find out what’s hosted on that IP.

Some people recommend registering a domain for at least two years before you move to it. Rand says to post in Google’s webmaster forum. Guilliame thinks that’s pretty much just something that works because he’s Rand. Hee.

The Move:

Before any content is moved to the new domain, TEMPORARILY block search engines from indexing with Robots.txt. Do NOT forget to take it down again later.
Be careful of your database, and test test test. Use comprehensive 301 redirects for each type of content move. And please don’t rush. You only have one chance to do it right.

Post move:

Ask your biggest referrers to update their links to the new site. Launch your new domain with a bang – include press releases and news mentions and linkbait, etc. etc… This is a good time to try for really good new links.

Maintain the old site and 301 redirect for an extended period. Minimum 6 months but he recommended never taking down the 301s.

Andy Langton …is so forgiven for being late. Cutest accent ever. This is the best session. German Ralf, Quebecois Guillaume and English Andy. [girlie happy sigh][*insert jealousy on behalf of the rest of the writers*]

Do 301s still rule the day? Yes.

Even well planned migrations go wrong. The only way to ensure rankings are maintained is not to change them. Cool URIs don’t change, so plan for permanence.

A 301 is a permanent move (check out all the status codes on the W3C site). Use the new URL in the future, not the old one.

301s can preserve ranking signals. It’s more than just links. It’s history and trust and analytics data. That’s all tied into the URL. [Ooh, good point.] Theoretically, a 301 will maintain all those things but it’s no guarantee.

When should you use a 301?

Whenever your URLs that don’t change, change:

• Domain names
• Content into a subdomain (or vice versa)
• Moving pages or files
• To avoid duplication problems

How to implement 301s:

• Best way: mod_rewrite, mod_alias (apache) or an ISAPI filter (IIS)
• On Web server (eg for IIS)
• Via “smart 404 pages”
• Via individual server-side scripts. Not good in bulk.
• Meta Refresh=0 [Google and Yahoo claim it works but the audience here is skeptical of this.]

Best practices:

• The goal is to preserve ranking signals so redirect to same or similar content.
• Don’t chain redirects.
• Avoid blanket redirects (many pages to one page).

At minimum, focus on pages with external links and visitor entry points.

404 or 410 if similar content isn’t available anymore. If you have pages without external links, don’t worry about redirecting those. You can fix any links heading to that page internally.

Monitor impact:

• Crawling activity
• Indexing activity
• Rankings, traffic and other existing KPIs (Web analytics)

Q&A

What if you want to take down a 301?
Andy: Try not to do that.

Is there a danger in having a lot of 301s in an .htaccess file?
Guillaume: Only from a speed standpoint, yes. Use regular expressions to avoid that if you can.
Andy: They’ll probably look at it case by case rather than a numeric limit. It’s more about linking to similar content.

What about changing shopping cart software?
Guillaume thinks that would be even faster than changing domains because Google still trusts it. Submit your XML sitemap and it should be fine.
For a new web site, submit to the social networks, not to try to rank on Digg but just to get a few links and hope you don’t get buried. They get indexed a lot so you’re link will get picked up fast too. Heh.

My new domain is 302ing to my old domain: is that good, bad or indifferent?
Andy: That’s fine. 302 is temporary, it basically just says ‘keep checking back here for the original content.’
Guillaume: It’s not bad but I’d put up a wordpress blog up instead and throw up a few pages of content with a call to action. Get some trust.

Susan Esparza is former managing editor at Bruce Clay Inc., and has written extensively for clients and internal publications. Along with Bruce Clay, she is co-author of the first edition of Search Engine Optimization All-in-One Desk Reference For Dummies.

See Susan's author page for links to connect on social media.