The best importer is not the one that swallows the most HTML. It is the one that produces WordPress content you can still edit six months later.
There is no universal one-click winner because static sites encode titles, bodies, dates, authors, and images differently. Choose a tool only after sampling the source and defining the destination model.
Table of contents
- Audit the source before choosing a plugin
- Match the tool to the input
- Run a safe pilot import
- Plan the migration beyond content
- How this fits the rest of the stack
- FAQ
Audit the source before choosing a plugin
List the files, templates, encodings, URL patterns, image paths, and metadata embedded in the markup. Determine whether the body has a stable selector such as main or article, and whether navigation or footer content is repeated inside every file.
Export a representative sample: a simple page, a long post, a page with tables, one with galleries, and one with unusual characters. If the sample cannot be mapped cleanly, a thousand-file import will merely create a thousand cleanup jobs.
Match the tool to the input
WP All Import is strong when content can be converted to structured XML or CSV and mapped into posts, taxonomies, and custom fields. Dedicated HTML importers or a small WP-CLI script can be better when each local HTML file is the record and selectors are consistent.
- Verify support for post type, status, slug, date, author, and taxonomy.
- Test whether images enter the Media Library and URLs are rewritten.
- Confirm repeatable imports can update rather than duplicate records.
- Prefer tools that log failures and expose a dry run or small batch.
Run a safe pilot import
- Back up files and database.
- Import ten representative pages into a staging site.
- Inspect generated blocks or classic HTML in the editor.
- Crawl internal links and missing assets.
- Compare titles, canonicals, and redirects with the source.
- Delete the pilot and repeat until the mapping is deterministic.
Plan the migration beyond content
Preserve valuable URLs with matching slugs or explicit 301 redirects. Rebuild menus, forms, search, metadata, and analytics deliberately rather than assuming the importer can infer them. Sanitize source HTML and remove obsolete scripts.
After launch, crawl the public site, review 404 logs, and keep the old URL map. A successful migration is measured by clean content, preserved discovery, and maintainability—not the import progress bar reaching 100 percent.
How this fits the rest of the stack
Stage the import, keep backups, and judge output inside the editor before committing to a tool. For the destination site, compare managed WordPress resources in the RunxBuild calculator and create it from the RunxBuild dashboard.
Useful related references:
- How to Duplicate a Page in WordPress, With and Without a Plugin
- Downloading a Full WordPress Site: What the Plugins Actually Do
- WordPress Plugin Development: The Structure That Keeps It Maintainable
- Managed WordPress on RunxBuild
FAQ
Can WordPress import raw HTML files directly?
Not reliably in every layout. A plugin or script must identify content and metadata, create records, move media, and rewrite links.
Is WP All Import suitable for HTML files?
It is strongest with structured XML or CSV. Convert the source first, or choose a file-oriented importer or script when raw HTML is consistent.
How do I avoid duplicate posts?
Use a stable unique key, test update behaviour, and make imports repeatable before running the full batch.
Should I import directly into production?
No. Use staging, backups, a small representative pilot, and a crawl before the final migration.