How to Convert an HTML Website to WordPress

I often see questions asking how to convert an HTML website to WordPress and, back here, I covered some of the things you need to think about before doing so.

Anyway, I recently converted an old HTML site to WordPress so I figured I’d set out the step-by-step process – so here it is:

Overview of the Process

The process I’ve set out in the steps below involves:

  1. Creating a test domain, installing WordPress and importing the content of the site you’re moving
  2. Taking a copy of the WordPress-based site on the test domain
  3. Clearing out the folder where the old site sits and installing the new WordPress-based site.
  4. Tidying up various loose ends.

Here are the detailed steps

Step 1: Create a test domain

If you don’t already have one, create a test domain and install WordPress.

You can install WordPress in a subdirectory of your main domain, if you like – I have 3 test WordPress sites installed in separate directories under my admin domain. Just be sure to set the privacy settings to exclude search engines.

Step 2: Create your layout and design

Once you’ve set up WordPress, create your new site layout and design.

This may be as simple as installing a theme, or as complicated as developing the design from scratch – up to you!

Step 3: Create the new pages

Create a new page in WordPress for each of your old pages. You have an opportunity here to consolidate and rationalise your pages if you want to.

Step 4: Import your content

Decide how you want to move your content across.

I copied it from the front pages of the old site, pasted it into a Text file (Notepad), then re-copied it from Notepad and used the Paste as Plain Text button to insert it into WordPress.

This approach generated less re-formatting work than trying to copy the HTML and paste it into the HTML view – that route is full of hassles!

Whichever process you choose, you’ll definitely need to do some work on the formatting, so be prepared for that.

Important point: when you’re importing your content using the process I just outlined you’ll need to re-insert the images you used. Make sure you use the ‘From computer’ method for adding images, as this will upload the images to the /uploads folder.

The reason this is important is because we’re going to use a backup plugin to move the site from the test domain to the live domain, and we want it to include all the images.

Images that you insert from an external URL will not be included in this backup.

Step 5: Install BackupBuddy

Once the new site is complete on your test domain, install the BackupBuddy plugin – you can find it here. BackupBuddy is a paid plugin, but it’s well worth the expense.

If you don’t want to use BackupBuddy find another plugin that does full site backups and enables you to migrate sites between servers and domains.

Step 6: Create a full backup

Create a full backup of your test site (database and system files) and download it to your machine along with the importbuddy.php file.

Step 7: Create a MySQL database

Create a MySQL database on your domain, keeping a record of the Database Name, User Name and Password – you’ll need these later. Make sure the user you set up has authority for all changes.

Step 8: Prepare the folder where your WordPress site will sit

Important: before you clear out your old files, copy the URLs of each page on your site and paste them into a text file. You’ll need these later for creating the re-directs.

Clear out any old files, particularly making sure there’s no index.html file in the domain (or folder) where your WordPress-based site will sit.

I simply moved the entire site (all files and folders) to a new folder that I created called ‘Old-Site’. This also enabled me to restore my old site quickly if I needed to.

Step 9: Upload your WordPress site

Upload the importbuddy.php file, and the zip file of the full-site backup, to the domain (or folder) where your WordPress based site will sit.

Step 10: Navigate to the Importbuddy script

Fire up your browser and go to the importbuddy.php file – e.g.:

Step 11: Run the import script

Follow the on-screen instructions. As it’s a new (i.e. different) domain from the test domain on which you created the WordPress site, fill in the details of the database you created earlier when you’re prompted.

Complete the rest of the steps (7 in all, at the time of writing).

Step 12: Complete the clean-up, if necessary

If there are any files that cannot be cleaned up by the importbuddy script delete them manually using FTP or your File Manager. The script will alert you if this is needed.

Step 13: Set up the redirects

Set up old-page-to-new-page redirects in the .htaccess file.

The WordPress Permalinks will be in a different format to the old HTML URLs, so anyone typing one of the HTML links will get a 404 page, and all your links will be broken, without the redirects – so they’re important.

Here’s the format for the 301 re-direct command in the .htaccess file:

redirect 301 /page.html

Note that your source URL only needs to be the page filename, not the full URL. The destination URL must be the full URL, including the http://.

If you have files in sub-directories on your old site you’ll need to include the subdirectory in the path after redirect 301 – e.g. /folder/page.html.

This will need to be done for each page on the site, and you can use the old page URLs that you copied into the text file earlier for the source and copy the new page URLs for the destination.

Step 14: Install a new sitemap

Install the Google XML Sitemaps plugin and build a sitemap. There are some tips on how to set up the plugin here.

Step 15: Re-verify your site in Google Webmaster Tools

Go to Google Webmaster Tools, re-submit your sitemap and re-verify your site using the HTML file method – there’s a video describing the process here.

Step 16: Re-install your stats tracking

Re-install your analytics tracking script.

Step 17: Update any links, if necessary

If you’re using Thesis you’ll need to update any internal links in your custom-functions file (e.g. links to images) from the test domain to the production domain. External links are not affected.

Most other internal links are taken care of by the importbuddy script, but it’s worth checking to make sure!

That’s it – you’re all done. Any questions leave a comment or drop me a line.


Martin Malden.

About the author: Martin has been working online since 2006 and focuses on two areas: 1) affiliate marketing and 2) designing and building websites based on WordPress. He has his own WordPress agency, and serves clients in Hong Kong, Australia and the UK.

What do you think?

Comments on this entry are closed.

  • Anaya Mar 12, 2012 @ 21:29

    Thank you so much for detailed information. I have just moved my HTML website to Worpress, I had to do it manually, page by page which took too much time but I am not an expert so I am still happy its successfully transferred. your post helped me a-lot

    • Martin Mar 13, 2012 @ 7:43

      You’re welcome, Anaya, glad it was useful!



  • Ljuba Jul 28, 2012 @ 19:14

    I done something that you describe in article but I have one question for you.Can you show the example of .htaccess file before and after adding the redirection lines in it?
    I use redirection plugin but I will like to learn how to change the .htaccess file in right way.
    Thank you so much..

    • Martin Malden Jul 28, 2012 @ 21:54

      Hi Ljuba,

      There is no ‘before’, because you’re adding the redirections to the .htaccess, not editing or changing them.

      Here’s a real life example that follows the exact format I gave in the article:

      redirect 301 /contact.html



  • Rob Jul 30, 2012 @ 10:29

    Hi, excellent article, there’s not a lot of resources online on this topic.

    I’m converting from an old cms to wp.

    I’ve a quick question about how many pages I need to change over, this is an old site… so, has quite a bit of content.

    I’ve used xenu link sleuth (free)

    It say’s 1736 urls… when I generate the report, it shows a list of valid URLs you can submit to a search engine: there’s 702 of these.

    Are these the only ones I need to worry about?


    • Martin Malden Jul 30, 2012 @ 10:51

      Hi Rob,

      When I migrated the old HTML site I referred to in the article, I reviewed each of the pages and ended up consolidating a few (merged the content), leaving some out and transferring the rest intact.

      It really depends on what your site is about, but it maybe worth taking the opportunity to review and streamline your site – it would very likely improve its performance in the search engines.



      • Rob Jul 30, 2012 @ 11:33

        Thanks for the swift reply Martin.

        Luckly… sort of, only 10% of our traffic is organic search engine traffic… 🙂

        I’m using a Chinese CMS… which looks like a hack of a bad, 15 year old western CMS.

        My plan is to completely change the site structure/navigation… as it’s pretty bad right now… and keep the names of all the main pages…

        My main worry is a loss in PR… my boss is a bit obsessed with it… I think PR is overrated myself.

        Anyway… I’m sure an update to wp, with decent seo plugins and site structure, can only help.


        • Martin Malden Jul 30, 2012 @ 12:33

          I’ve no doubt it will..!

          Organising a WordPress site well means giving some thought to how you use your categories and tags.

          More on that here,



  • Lisa Nov 19, 2012 @ 8:26

    Good article but you don’t define the difference between pages and posts when importing the content into WordPress. If there is a current HTML site (that’s very large) with the path and structure such as, how would this work in WordPress if imported as a “page”? WordPress doesn’t allow categories with “pages” so would all these pages be imported as “posts” instead? I’m confused and have search everywhere for the answer. Thank for the info you’ve posted here as it’s been very useful.

    • Martin Malden Nov 19, 2012 @ 9:31

      Hi Lisa,

      I think the way to do that may either be to use the WordPress page parent/child functionality (so the pages show up appropriately grouped as drop downs in the nav menu) or the custom taxonomies functionality.

      The simplest solution would be the page parent/child one, but if you want to be able to search by specific sections or sub-sections then you would need to use custom taxonomies (to which you can add pages, or anything else).



  • Lisa Nov 19, 2012 @ 11:04

    Thanks for the reply Martin. But the parent/child solution doesn’t seem a good one because it is not as though (on the current html site) that there is one page that IS the parent – rather the content is divided into specific and distinct sections. I’m not really concerned about the nav menu as I’ll be creating a custom nav system. I have read that having too many “pages” as opposed to “posts” can slow down a site. Do you have an opinion on this? The custom taxonomies information is completely new to me – thank you so much for pointing me in the right direction! Is this still the correct direction based on the additional information I’ve laid out here?
    Thanks again! Lisa

    • Lisa Nov 19, 2012 @ 11:31

      Sorry Martin for the additional post here… I should have asked something in my original post that I didn’t. If it were you – would you import them as posts or pages? The site is quite large (over 500 pages) only about 10% of the pages get regularly updated, however, there could be a rare situation where a whole slew of them needed a modification. I lean toward “pages” because “posts” do not seem correct to me – perhaps coming from my html background. What would you do if it were you?

      • Martin Malden Nov 19, 2012 @ 15:57

        No worries, Lisa.. 🙂

        There are three questions you’ve asked in your two comments, so let me try to take them in order:

        1. Pages do not slow down the site any differently from posts. Displaying a page simply requires a call to the database, exactly the same as displaying a post. There’s no difference.
        2. If you thought of a parent page in the same way as a WordPress category, or a section in your current site, then using the parent/child structure for pages could work. However, given the number of pages you’re talking about I agree that it would not be the correct approach
        3. You would be better off importing your existing pages as WordPress pages, rather than posts. This is because WordPress pages are static and work in the same way as your current HTML based pages, whereas posts are ordered chronologically and also don’t figure in the nav menus.

        There’s more information on custom taxonomies here, and here, and there are some plugins that make setting them up and managing them easier for non techie people. 🙂

        Hope that helps a bit,



        • Lisa Nov 20, 2012 @ 11:06

          Martin ~

          Thank you for your generosity in sharing your knowledge. I appreciate the advice you’ve given me. You Sir are a gentleman and a scholar!


          Best regards,


          p.s. The reason I asked about the pages slowing down the site is because I read that that was true on the forum. That information came from one of the main contributors to the WP code. At any rate, if this project proceeds forward I will be importing the content as “pages”.