Convert HTML to WordPress: 3 Ways (Including the Lazy Way)

I had a static HTML site once that I was proud of, in the way you can only be proud of something you built with your own two hands. Every page was a file. Every change meant opening a file, editing it, saving it, FTPing it. Updating the menu on twelve pages meant updating twelve files. The site was beautiful and the site was a small prison, and after the years of editing the same footer links in twelve different places, I started looking for a way out.

That way out, for most people who have built something in plain HTML and CSS and now want to add a blog, sell something, or simply stop touching twelve files at once like I used to, is WordPress. WordPress runs roughly 43% of all websites on the internet, a number that does the slow, quiet work of telling you nobody is going to run out of tutorials, plugins, or hosts any time soon (W3Techs usage statistics).

Why Move at All

The honest reason most people convert HTML to WordPress is not that HTML is broken. HTML is fine. It is fast, it is light, it does not need a database. The reason people move is that they want a content management system, an admin panel where you log in, click “Add New Post,” type, and publish, without touching a file or knowing what FTP stands for.

Think of it the way you would think of moving from a notebook to a filing cabinet. The notebook is faster for one entry, and prettier, and it never crashes. The filing cabinet is heavier, and it requires drawers and folders, but the moment you have a hundred entries, the cabinet wins. Editing a footer in twelve places is the notebook revealing its real cost.

So: three routes from one to the other. The manual build, the plugin import, and the visual rebuild. None of them are wrong. They are answers to different questions.

Route One: Build the Theme by Hand

This is the route for the person who wrote the HTML themselves and wants to keep the design pixel-for-pixel. Every other route is a compromise on fidelity. This one is not.

A WordPress theme, at its bare minimum, is two files in a folder: style.css and index.php (WordPress Theme Handbook – Required Theme Files). Everything else is optional and most of it is helpful. You will almost always also want header.php, footer.php, sidebar.php, and functions.php, which together make the theme behave the way a CMS should rather than the way one long PHP file should.

The way I think about it: your old HTML page is one continuous document, top to bottom. WordPress wants that document chopped into reusable pieces, the way a kitchen chops a meal into prep stations. The chopping is the work.

Step 1: Make the folder and the stylesheet.

Inside wp-content/themes on your WordPress install, create a folder. Name it something lowercase, no spaces, e.g. my-theme. Inside it, create style.css. At the top of that file, paste the comment header WordPress reads to identify your theme:

/*
Theme Name: My Theme
Theme URI: https://example.com
Author: Your Name
Description: Custom theme converted from a static HTML site.
Version: 1.0
*/

Below that header, paste the entire contents of your old site’s CSS. The header is what makes WordPress see the folder as a theme at all (WordPress Theme Handbook — Main Stylesheet).

Step 2: Split the HTML into header, footer, and the middle.

Open your old index.html. Find the closing </head> tag — everything from the top down through that tag plus the opening <body> and your top navigation goes into a new file called header.php. Find your footer markup at the bottom — everything from there to </body></html> goes into footer.php. If you have a sidebar, that comes out into sidebar.php. The middle, the part that actually changes from page to page, stays for index.php.

Inside header.php, the <head> tag needs one line WordPress requires so plugins and the admin bar can inject what they need:

<?php wp_head(); ?>

Place it just before </head>. The mirror call goes in footer.php, just before </body>:

<?php wp_footer(); ?>

Without those two hooks, half the WordPress ecosystem stops working – you’ll wonder why analytics plugins don’t load, why the admin bar disappears, why caching is broken. The hooks are small and load-bearing.

Step 3: Stitch the pieces back together in index.php.

index.php becomes the conductor. It calls in the header, calls in the content area, calls in the sidebar, calls in the footer. The template tags that do this are get_header(), get_sidebar(), and get_footer() (WordPress Developer Resources — get_header()).

Between them lives the part that turns a static page into a CMS — what WordPress calls “the Loop.” The Loop is the small piece of PHP that asks the database, “are there posts for this page? If yes, hand them to me one at a time,” and prints whatever you put inside it for each post (WordPress Theme Handbook — The Loop).

A minimal index.php looks like this:

<?php get_header(); ?>

<main>
  <?php if ( have_posts() ) : while ( have_posts() ) : the_post(); ?>
    <article>
      <h2><a href="<?php the_permalink(); ?>"><?php the_title(); ?></a></h2>
      <div><?php the_content(); ?></div>
    </article>
  <?php endwhile; else : ?>
    <p>No posts yet.</p>
  <?php endif; ?>
</main>

<?php get_sidebar(); ?>
<?php get_footer(); ?>

That is the whole CMS, in eleven lines. The if/while is the part doing the actual work: checking, fetching, printing, and the rest is glue.

Step 4: Wire up the stylesheet through functions.php.

style.css does not load itself. WordPress wants you to enqueue it from functions.php, which lives in the same theme folder. Create it, and paste:

<?php
function mytheme_enqueue() {
    wp_enqueue_style( 'mytheme-style', get_stylesheet_uri() );
}
add_action( 'wp_enqueue_scripts', 'mytheme_enqueue' );

This is the part beginners skip and then spend an afternoon wondering why the site looks like 1996. The enqueue function is how WordPress wants stylesheets and scripts registered (WordPress Theme Handbook – Including CSS & JavaScript).

Step 5: Activate it.

Log into wp-admin, go to Appearance → Themes, find your theme, click Activate. If you did the steps above, your site now looks the way it always did, except the content area is fed by the WordPress database instead of a file.

Route Two: Use a Plugin to Import the HTML

The hand-built route is the right answer if your design matters and the site has structure worth preserving. If you have a folder of forty old HTML pages and you just want them inside WordPress as posts or pages, a plugin is faster.

The two routes worth knowing: a plugin like HTML Import 2 (or successors as the plugin landscape shifts) that ingests a directory of .html files and turns each one into a WordPress page; or the built-in Custom HTML block inside the editor, which lets you paste raw markup into a single post without touching theme files.

The flow for the import plugin: install it from Plugins → Add New, activate, open its settings, point it at the directory where your old HTML lives, tell it which CSS selectors mark the content area versus the navigation, run the import. It will create a page for each file, strip the wrapper, and keep the content.

The catch is that your old design does not come along for the ride. You’ll be inside whatever active theme you have, and the imported content will inherit that theme’s styling. This is fine if you wanted a fresh look anyway. It is not fine if pixel fidelity mattered, in which case go back to route one.

Route Three: Rebuild Visually With a Page Builder

Some people do not want to write PHP and do not want to fight with a plugin. They want to open a builder, drag, drop, and stop. For them the answer is a visual builder like Elementor is the most common, and the work is design work, not code work (Elementor’s guide to visual rebuilds).

The flow: install WordPress, install Elementor (free version is fine to start), open a page, hit Edit with Elementor, and rebuild your old layout block by block. The builder gives you sections, columns, headings, images, buttons. You look at your old HTML page on one screen and reconstruct it on the other.

This route trades pixel fidelity and code purity for speed to get it done and the ability to keep editing without ever opening a file again. For a five-page brochure site, it is often the right call. For a heavily custom design, it isn’t.

How to Convert HTML to WordPress: Picking the Right Route

The boring honest answer is: it depends on the site, and it depends on you. If you wrote the HTML and the design is the point, hand-build the theme. If you have a stack of old pages and you want them inside WordPress as content, use an import plugin. If you don’t write code and you want to be done by Friday, rebuild it visually.

What you should not do is start route one, get stuck on wp_enqueue_scripts, and conclude WordPress is broken. The first time you do this it may take a weekend. The second time it will take an evening. The third time the steps will be in your fingers and you will be wondering what else you can move out of the notebook and into the cabinet.

A static site is a notebook. A WordPress site is a filing cabinet. The filing cabinet is heavier and the filing cabinet has drawers, and the day you have a hundred entries, you will be glad you carried it home.

When Hiring a Developer Makes More Sense

If your HTML site runs to 50 pages or more, if it contains custom JavaScript applications, if the design is intricate enough that a page builder can’t reproduce it, then the manual conversion is a job for a professional. At WPSaul we handle this service end to end; pulling the old site apart, rebuilding it as a clean WordPress theme, and handing it back to you.

What it costs depends on what you’re moving. A small brochure site is not the same job as a 200-page archive with custom search and a membership area, so rather than print a number that won’t apply to your site, reach out and tell us what you have, we’ll look at the pages, the design, and come back with a real scope. The money buys you something your own time often can’t: a migration that doesn’t break your search rankings or your patience.