HTML to WordPress: Convert a Static Site Manually or Online

You have a static site built with HTML and CSS, and you want it running on WordPress. Maybe the client wants to edit pages without touching code. Maybe you are tired of updating the same footer on 40 files. Either way, html to wordpress conversion is a common job, and it is easier than it looks once you pick the right method.

Here is the short answer. You can convert manually by splitting your HTML into theme template files (header.php, footer.php, index.php) and loading your CSS through functions.php. Or you can use an online converter or plugin that automates part of the work. Manual conversion gives you clean code and full control. Converters are faster, but they often leave messy markup you will need to fix.

This guide walks through both paths step by step, so you can choose the one that fits your project. We also cover what to check after the move, and how a Divi layout can save you from rebuilding the design by hand. At Divihat, we build with Divi every day, so we focus on methods that hold up on real client sites.

Before you convert: what to prepare

Skipping prep is the most common reason an html to wordpress project drags on for weeks. An hour of groundwork saves you from broken image paths, lost forms, and a test site you cannot trust.

Take inventory of your static files

Start by opening the project folder and counting what is in it. Write down the number of HTML pages, CSS files, and JavaScript files, plus every image, font, and PDF. This count becomes your checklist when you verify the finished site.

Then flag the parts that WordPress will not handle on its own:

• Contact forms that post to a third-party service or a PHP script
• Scripts loaded from a CDN, such as sliders or analytics
• Repeated blocks like headers, footers, and sidebars
• Pages with unique layouts that need their own template
• Any existing URLs you plan to keep or change

Set up a safe place to work

Next, install WordPress somewhere that is not your live domain. A local install or a staging subdomain works well. Use a currently supported PHP version and turn on debugging in wp-config.php so errors show up while you build, not after launch.

Never convert on the live domain. Build on a staging copy, and switch over only when every page passes your checklist.

Keep your original HTML folder untouched in a separate location. You will copy files from it, not edit them in place. If something breaks, you can always start that step again from a clean source.

Pick your method before you start

Choose the path now, because each one changes how you handle the files in Step 1. The right pick depends on who will edit the site and how much time you have.

Method	Best for	Code quality	Typical time
Manual theme build	Developers, small to mid-size sites	Clean, fully controlled	Several hours to days
Online converter or plugin	Quick prototypes, simple pages	Often messy, needs cleanup	Minutes to hours
Page builder rebuild	Client sites that need easy editing	Clean, editable visually	A few hours

If you want to convert an HTML site to a WordPress theme and keep every line of markup, go manual. If the client will edit pages weekly, a page builder rebuild is usually the better call, even though it takes a little more design work up front. Converters sit in the middle. They are useful for a first draft, but plan on reviewing every output file.

Step 1. Back up your site and map its structure

Now that your staging site is ready, spend an hour on two jobs before you write any theme code. First, secure the original files. Second, decide where every static page will land in WordPress. Mapping first keeps the rest of your html to wordpress project from turning into guesswork.

Back up the original files

Copy the whole project folder to a second location, then zip the entire folder with a dated name. If the site is live, also pull the server files over SFTP, because the server copy can differ from your local one. Store one copy off your machine so a failed drive cannot take your only backup with it.

zip -r site-backup-2026-10-04.zip /path/to/html-site

Map pages to WordPress templates

Next, list every HTML file and decide its WordPress counterpart. Static pages become Pages, articles become Posts, and repeated blocks become template parts. A simple table keeps you honest:

Static file	WordPress target	Notes
index.html	front-page.php	Home page template
about.html	Page (page.php)	Edited in the dashboard
blog/index.html	home.php	Post listing
blog/post-1.html	Post (single.php)	One template for all posts
404.html	404.php	Custom error page
header and footer markup	header.php, footer.php	Shared on every page

Finally, write the old URL beside each new one. You will need that list for the redirects in Step 4, and fixing a slug after launch is much harder than choosing it now.

A page you did not map is a page you will forget to migrate.

Step 2. Build a custom theme from your HTML

With your map done, the manual html to wordpress build can start. A theme is a folder of PHP files, so most of your markup carries over as is.

Create the theme folder

Add a folder such as mysite inside wp-content/themes. Create style.css with a theme header and an empty index.php. WordPress needs both before it will list the theme in the dashboard.

/*
Theme Name: My Site
Version: 1.0
*/

Split the HTML into template files

Cut everything from the doctype through your closing nav tag and paste it into header.php. Move the footer markup into footer.php. Each template then calls get_header() and get_footer() around its own content, as in front-page.php or page.php.

Also add wp_head() before and wp_footer() before . Without them, plugins and enqueued scripts never load.

A converted theme without wp_head() and wp_footer() is a theme that quietly breaks.

<?php get_header(); ?>
<main>
  <!-- page content -->
</main>
<?php get_footer(); ?>

Load CSS and JavaScript the WordPress way

Hard-coded link and script tags cause conflicts with plugins. Enqueue every asset in functions.php so WordPress controls the load order. Copy your css and js folders into the theme first.

<?php
function mysite_assets() {
  wp_enqueue_style('site', get_template_directory_uri() . '/css/site.css');
  wp_enqueue_script('site-js', get_template_directory_uri() . '/js/site.js', [], '1.0', true);
}
add_action('wp_enqueue_scripts', 'mysite_assets');

Finally, activate the theme and compare each page to your original. Replace relative image paths with get_template_directory_uri(), since a bare images/logo.png will return a 404 on nested pages.

Step 3. Rebuild with a page builder or converter

Not every project needs a hand-coded theme. If a client will edit pages weekly, rebuilding in a page builder is the faster route. It also keeps your html to wordpress move maintainable for people who never open a code editor.

Rebuild the design in Divi

Divi works well for an HTML to Divi rebuild because you copy the old design section by section instead of translating it into PHP. Use your Step 1 map as the build order.

1. Install and activate Divi on your staging site.
2. Create a page and open the Visual Builder.
3. Add a section, then rows and modules that match each block in the original HTML.
4. Paste in your text and upload images through the Media Library.
5. Build the header and footer once in the Theme Builder so they apply site-wide.

Starting from a ready-made layout cuts the work further. A pre-built Divi layout from Divihat gives you the structure, and you swap in your own content and brand colors instead of drawing every row yourself.

Use a converter or plugin

Online converters and plugins take your HTML and output theme files or page content. They are fine for a first draft, but the markup is rarely something you want to ship untouched.

Treat converter output as a first draft, never as a finished site.

Before you move on, run through this cleanup list:

• Remove inline styles and duplicate IDs
• Replace hard-coded absolute URLs
• Check that scripts are enqueued, not pasted into templates
• Confirm headings and image alt text survived the conversion

Run every converter on staging only. If the output needs more than an hour of fixes, switch to the manual theme build or the Divi rebuild above.

Step 4. Test, redirect, and launch

Your theme or Divi build is done, but an html to wordpress project is not finished until it passes testing. Launching without a check is how broken links and dead forms reach real visitors.

Test every page on staging

Work through the site page by page, using your inventory from the prep stage as the answer key. Every page should match your original count, and every form should deliver a real test email.

• Click every menu item, button, and footer link
• Confirm images, fonts, and PDFs load on nested pages
• Submit each form and check the inbox and spam folder
• View the site on a phone, tablet, and desktop
• Open the browser console and fix any errors

Redirect your old URLs

Changed URLs need 301 redirects, or visitors hit 404 pages and you lose the rankings the old pages earned. Use the old and new URL list from Step 1. On Apache, add the rules at the top of .htaccess, above the WordPress block.

A 301 redirect tells Google the move is permanent, so the old page’s ranking follows it to the new URL.

Redirect 301 /about.html /about/
Redirect 301 /blog/post-1.html /blog/post-1/

Test a handful of old URLs in a browser after saving. If your host runs Nginx or blocks .htaccess edits, a redirect plugin does the same job from the dashboard.

Launch and monitor

When redirects work, move the site to your live domain and set Settings > Permalinks to Post name. Then open Settings > Reading and uncheck "Discourage search engines", a box that staging often leaves ticked. Submit your sitemap in Google Search Console, and watch the page indexing and 404 reports for the first two weeks.

Choosing the right path for your site

The best html to wordpress method depends on who maintains the site. If you are a developer who wants clean code, build the theme manually. If the client edits pages every week, rebuild in Divi. Use a converter only for a first draft, and expect to clean up its output.

Whatever you choose, the steps around the build stay the same. Back up and map first, test everything on staging, set up 301 redirects, and watch Search Console after launch. Those habits prevent most migration problems.

If you take the page builder route, you do not have to design every section from zero. Browse the ready-made Divi layouts at Divihat, pick one close to your old design, and swap in your content. You will finish faster and hand over a site the client can actually edit.