Understand what changes between HTML and a WordPress template
A static HTML file is self-contained; a WordPress template is a PHP file that WordPress assembles at request time from smaller parts (header, footer, sidebar) plus content pulled from the database via the Loop. Converting means splitting your monolithic HTML files into these reusable pieces.
The good news is your CSS generally needs zero changes — WordPress doesn't care how you style things — the conversion work is almost entirely in the HTML structure and how scripts are loaded.
Mapping index.html to WordPress
Your homepage's index.html usually splits into three files: header.php (everything from <!DOCTYPE html> through the opening of <main> or the content wrapper), footer.php (everything from the closing of that wrapper to </html>), and index.php or front-page.php, which contains just the homepage-specific content in between.
In header.php, add <?php wp_head(); ?> immediately before </head> — this is a required hook that lets WordPress, plugins and many scripts inject styles and tracking code. In footer.php, add <?php wp_footer(); ?> right before </body> for the same reason with scripts.
Mapping about.html, contact.html and other inner pages
Inner static pages typically map to page.php, which should include get_header(), then a loop with the_title() and the_content() to pull in whatever you type into the WordPress block editor, then get_footer(). This keeps the design fixed while making the page's content editable.
If a page needs a genuinely different layout — a contact page with a form, for example — create a custom page template by adding a comment block at the top like /* Template Name: Contact */ so it appears as a selectable template in the Page Attributes panel.
Mapping blog.html or a listing page
If your HTML site had a blog or news listing page, this becomes archive.php or home.php, using WordPress's post loop (have_posts() / the_post()) instead of hardcoded post cards, so newly published posts appear automatically without editing template files again.
Fixing asset paths and scripts
Relative paths like css/style.css or img/logo.png will break once WordPress serves the file from a theme folder, so replace them with get_template_directory_uri() . '/css/style.css' in your PHP, or better, register and enqueue them properly in functions.php with wp_enqueue_style() and wp_enqueue_script().
Any inline <script> that manipulated the DOM on page load generally keeps working as-is, but external JS files should be enqueued rather than left as raw <script src="..."> tags, since enqueuing avoids duplicate loading if a plugin also needs the same library.
- Replace relative image and CSS paths with get_template_directory_uri()
- Enqueue every external JS/CSS file in functions.php
- Keep inline scripts inside the correct template file
- Test forms and sliders after the path changes
Required files checklist
Before uploading, confirm you have: style.css with a proper theme header, index.php, a screenshot.png at 1200x900, and functions.php. Missing any of the first two means WordPress will refuse to list the theme in Appearance → Themes.
If your HTML source is large, or came from a site you don't have clean files for, a browser extension like Themify can generate all of this automatically by capturing the rendered page in the browser rather than requiring you to manually split each file — worth considering if the manual mapping above is more work than the project justifies.
Final testing
Upload via Appearance → Themes → Add New → Upload Theme on staging first, click through every page type, and open browser dev tools to check for 404s on CSS/JS assets, which almost always indicate a path that still points to the old relative structure.
Once satisfied, resave permalinks under Settings → Permalinks, then move to production and set up 301 redirects if any URL structures changed from the original HTML site.
Frequently asked questions
- How many HTML files do I need to convert per WordPress page type?
- Usually one HTML file maps to one WordPress template, but the header and footer sections of every file get consolidated into single shared header.php and footer.php files used across all templates.
- Do I need to rewrite my CSS to convert HTML to WordPress?
- No. CSS generally transfers unchanged; you only need to update the file paths that reference it and make sure it's properly enqueued.
- What is wp_head() and why does my converted theme need it?
- wp_head() is a required hook in header.php that lets WordPress core, themes and plugins inject styles, meta tags and scripts. Omitting it breaks many plugins silently.
- Can I keep hardcoded HTML content instead of using the WordPress Loop?
- Yes, technically, but then the page becomes uneditable from wp-admin. Using the_content() with the Loop is what makes a converted page editable like a normal WordPress page.
- Is there a way to convert HTML to WordPress without manually splitting files?
- Yes, browser extension tools like Themify capture the rendered page and generate the split template files automatically, which is faster for straightforward marketing sites.