Migrating from a static site to WordPress is the most common project I take. The migration pattern below preserves SEO through the transition. Skip the pattern, lose the rankings.
The setup
Source: a static HTML site (often a single-page app or a generator like Jekyll, Hugo, or raw HTML). Destination: a WordPress install on the same domain. The site structure stays the same; the technology changes.
Phase 1: Pre-migration audit (1-2 days)
Inventory all current URLs
Crawl the existing site. Tools: Screaming Frog, or a simple wget. Get every URL into a spreadsheet. Every page, every blog post, every image directory. The destination needs to recreate all of these.
Note current rankings and traffic
Search Console and analytics. Screenshot the rankings for the top 50 pages by traffic. This is the baseline. After migration, you compare against this baseline.
Identify the high-value pages
The 20% of pages that drive 80% of traffic. These get extra attention during migration. Their URLs must stay identical. Their content must be preserved exactly. Their schema must be carried over.
Phase 2: Build the WordPress side (3-7 days)
Install with the right permalink structure
Set permalinks to /%postname%/ (or whatever matches the current site structure). Test on a staging URL. URLs must match the static site exactly, character-for-character.
Match the visual design
Custom theme or close-to-stock theme. The visual change should be minimal — most migrations are about technology, not design. The visitor should not notice anything except a few visual refreshes.
Add the high-value schema
Carry over the schema markup from the static site. Article schema for blog posts. Product schema for product pages. Organization and LocalBusiness on every page. Validate with Schema.org validator after migration.
Phase 3: Cutover (1 day)
DNS swap or hosting migration
Either point the domain to the new WordPress install, or move the WordPress install to the existing host. The exact mechanism depends on the host. Test from multiple locations before declaring done.
301 redirects for anything that does not match
For any URL that changes between static and WordPress, add a 301 redirect in the WordPress .htaccess. Every old URL must resolve to something — never a 404.
Verify in Search Console
Submit the new sitemap. Use Search Console URL Inspection tool to check the top 20 URLs. Make sure they are all indexed, all returning 200, and all carrying the right schema.
Phase 4: Post-migration monitoring (30 days)
Watch rankings daily
Compare current rankings to the pre-migration baseline. Expect some fluctuation in the first 2-4 weeks. If anything drops more than 5 positions for more than 2 weeks, investigate.
Watch crawl errors
Search Console → Pages → “Crawled – currently not indexed” and “Not found (404)”. Any unexpected entries are bugs in the migration. Fix them.
Watch for indexing regressions
Indexed page count should stay roughly the same. If it drops, you have a sitemap, canonical, or robots.txt problem. Diagnose and fix.
The pattern
Audit the existing site, build a WordPress that matches it exactly, cutover with redirects, monitor for 30 days. Total time: 1-2 weeks for a 50-page site. The result is a site that ranks the same as the static version, with the maintainability of WordPress.