How to Port Your Blog from TypePad to WordPress (Part 2)

This is Part 2 of a 2-part post on migrating your blog from TypePad to WordPress. << Part 1

While the information in this post uses TypePad as the subject. much is transferable to other platforms.

Part 1 discussed overall migration considerations, preparing for the move, exporting data from TypePad, Importing data into WordPress, cleaning up images and file references, and taking advantage of some of WordPress’s features.

Redirect Traffic to your New Blog

If you’re going to drop any traffic, it’s going to happen right here!

1. Make sure the receiving server is ready for traffic.
2. Go to your domain registrar, and point your domain to the nameservers on your new hosting account or server. You’ll probably also have to delete the MX records that still exist.
3. Wait.
4. Ping your domain name to see which IP address responds, TypePad or your new server. As soon as the responding IP address is your new server, continue.
5. In your WordPress administrative panel, go to Options | General, and make sure your blog is pointing to your domain name, and not the temporary URL or IP address you used to setup your WordPress blog. If you’re using a new domain, this step doesn’t apply to you. Important: don’t perform this step until you know your domain is pointed to your server or you’ll lose access to your administrative panel. If this does happens to you, just open up your MySQL database, and update the entry in the wp_options table.
6. After cutover, go to your TypePad control panel and select Site Access | Domain Mapping. Remove your domain mapping. This step doesn’t need to be done, but I prefer to make a clean break.

DNS is painful. You need to coordinate different servers in different locations, and you can never be sure if what you see is what someone else will see (until propagation completes). So when something goes wrong, it’s often hard to pinpoint where the problem is. If you do things in the above order, you shouldn’t run into any problems.

Update your Feeds

If you’re lucky, you’ve been using FeedBurner all along. This will make cutover a snap. Feedburner only needs to know where to find your new feed. Login to your FeedBurner account, click on the “Edit feed details” link at the top of the page, and enter your new feed address.

This is where I ran into a problem. Although traffic was being redirected to my new server, and I validated my new feed, FeedBurner didn’t recognize the server. If you get messages like “The domain does not seem to exist” or “There was a problem retrieving the feed: java.net.UnknownHostException” a possible cause is DNS propagation (I surmise). Feedburner’s help recommends pinging, resynching, validating your feed, and so on, but for me, all it took was a little time — roughly 18 hours.

If you’re not using FeedBurner, you’ll need to redirect all feed requests to the new location (see below) .

Redirect all Requests to Old URL’s

There are plenty of ways to redirect, including plenty of ways to do it right and plenty of ways to do it wrong.

Wrong Ways to Redirect Traffic

Meta Tags, Bad Idea

<meta http-equiv=”refresh” content=”0; url=yourblog.com/your-new-post/”>

JavaScript, Another Bad Idea

window.location=”yourblog.com/your-new-post/”;

Correct Ways to Redirect Traffic

In short, you want to use a 301 redirect. This tells all traffic to the old URL that the page has permanently moved, and is a search engine safe method of redirection. If you’ve spent some time building page rank, and you want to maintain it, 301 redirects using the same domain should preserve that rank. But note that page rank is assigned to a specific address, so if you were using yourblog.typepad.com/your-post/, and now you’re redirecting to yourblog.com/your-new-post/, this is treated as a new domain and you will drop your page rank, at least temporarily. On the other hand, if you redirect from yourblog.com/your-post/ to yourblog.com/your-new-post/, a 301 redirect should transfer page rank from the old address to the new.

Server Side Scripting

The easiest way to create a 301 redirect (with a high success rate) is to use any server-side scripting language to respond with the appropriate HTTP headers. The problem is that individual posts at TypePad usually end with a “.html,” which makes this method useless for redirecting individual post URL’s, but you can sometimes redirect old categories to new ones. The process is the same for all scripting languages, but because this method is not consistently reliable, I would advise against using it. I only mention it here because it’s such a common method of creating a 301 redirect.

1. Create the corresponding directory structure. If the category you want to redirect is yourblog.com/your-category/, and you want to redirect it to yourblog.com/category/your-category/, you need to create a “your-category” folder in your blog’s root.
2. Add an index page with your scripting language’s extension, e.g. index.asp, index.jsp, index.php.
3. Use the scripting languages to respond with 301 redirect headers.

ASP

Response.Status=”301 Moved Permanently”
Response.AddHeader “Location”,”http://yourblog.com/your-new-post/”

JSP

response.setStatus(301);
response.setHeader(”Location”, “http://yourblog.com/your-new-post/”);
response.setHeader(”Connection”, “close”);

PHP

Header(”HTTP/1.1 301 Moved Permanently”);
Header(”Location: http://yourblog.com/your-new-post/”);

Using mod_rewrite with .htaccess

mod_rewrite is a powerful and complex Apache module. It is really a Swiss Army knife, and can do so many things if you know how to use it properly. mod_rewrite hates me. Sort of like Digg hates me, but that’s another story. In turn, I hate it. But I still respect it. I will always try to get mod_rewrite to listen to my commands, but I plan for the worst. If I can’t get it to bend to my will within a short while, I move on. When I’ve gotten it to work, it’s all flowers, wine, and candy, but more often than not, it just breaks my heart.

mod_rewrite is a very clean, neat, and search engine safe method of redirection. You can initially redirect all of your URL’s, then after a month or so gradually drop your redirections as your URL’s are updated in indexes.

Add all of your mod_rewrite rules to the .htaccess file in your blog root. Here’s an example of redirection using mod_rewrite:

RewriteCond %{HTTP_HOST} ^.*$
RewriteRule ^2008/03/my-old-post.html$ http://www.joefission.com/2008/03/my-new-post/

Using .htaccess

Using .htaccess should be a simple way of redirecting traffic. It’s a very neat solution — all of your redirects are stored in one file — and it’s a search engine safe way of implementation. Additionally, it works for all URL’s. For each URL to redirect, add a line to your .htaccess file (use the one in your blog’s root, if your blog root is different from your site root, e.g. if you blog is located at yourblog.com/blog/).

Redirect 301 /old-post.html http://www.yourblog.com/your-new-post/

Simple, yes? It should be, but .htaccess and I don’t often see eye to eye. This method has many advantages and is the second method I would try, right after mod_rewrite.

Objection Redirection

When mod_rewrite and .htaccess fail you, you can always fall back on the Objection Redirection plugin. You’ll also get the benefit of using one of the funniest WordPress plugins available.

1. Download Objection Redirection, install it, and activate it.
2. Go to Options | Redirection in your WordPress administrative panel.
3. In the second pane, add the old URL in the “URL requested” field, and the URL to redirect to in the “Redirect their ass” field.

You’ll need to repeat this for each URL to redirect. If you have quite a few, it’s a better idea to create a SQL INSERT statement, and just add the redirections directly to the database.

Update the Engines

This step couldn’t be easier, thanks to the Google XML Sitemaps plugin. Install it, generate your sitemap, and let the plugin submit it automatically to Google, Yahoo! and Ask.

Backup

I’m probably a bit too cautious when it comes to backups, but at the very least, now that your blog is populated and traffic has been redirected, you should generate a complete backup. A backup of your data and all of your WordPress files. I backed up after every hour of work or so during the migration. My test is always: “do I want to do this again?” If the answer is no, I do a quick backup.

Have a Drink

A nice IPA would hit the spot right now.

Conclusion

All-in-all, migrating to WordPress from TypePad can be made simple, though there are many pieces that need to be organized. My biggest tip would be to prepare. Think through all of the steps that you’ll need to take before you take them, so you make the process go as smoothly as possible. The last thing you want is to change your DNS information, only to find that you’ve forgotten to set up something on your target server, resulting in hours of unnecessary downtime.

Follow the steps in these two posts, and you should come out of the migration just fine. I’ve been a WordPress fan for some time, and looking back to the effort that was involved in the migration, I’m 100 percent satisfied with my decision to move.

To recap, here are the steps to follow to migrate your blog:

1. Prepare for the Migration

• Make sure your new hosting account and platform are stable
• Install WordPress on your hosting account
• Apply your themes, plug-ins, and any customizations
• Backup your WordPress installation
• Gather your account information
• Inventory your backlinks

2. Export your data from TypePad

3. Import your data into WordPress

4. Clean up the migration

• Reorganize your categories
• Replace TypePad-specific URL’s
• Re-reference your images
• Clean up your hacked styles
• Update your 404 page
• Tag your posts
• SEO anchor pages and posts
• Replace widgets

5. DNS redirect traffic to your new blog

6. Update your feeds

7. Redirect all requests to old URL’s

8. Update the engines

9. Backup

10. Have one or many drinks

Good luck with your migration!

Read Part 1 of this 2-part post on migrating your blog from TypePad to WordPress. << Part 1