Moving a legacy PHP site to WordPress can unlock easier content updates and better design flexibility — but only if the migration protects your search traffic. Follow this checklist to migrate with minimal downtime, preserve rankings, and hand a predictable site to your marketing or development team.
1. Audit the current site and prioritize pages
Start by cataloging every URL and its value. Run a crawl with Screaming Frog, Sitebulb, or a cloud crawler. Export a list of:
- All indexed URLs
- Top organic landing pages by sessions/transactions from GA4
- High-converting pages and unique content (downloads, forms, case studies)
Mark pages as “keep as-is”, “merge”, or “retire”. Prioritize pages that drive most traffic or revenue: these deserve exact-path preservation or careful redirects.
2. Benchmark technical SEO and performance
Capture current performance so you can prove the migration helped (or fix it quickly if not). Record:
- Core Web Vitals and page speed scores (PageSpeed Insights, Lighthouse)
- Index coverage and mobile usability in Google Search Console
- Top keywords and impressions (Search Console and a rank tracker)
- Backlink profile (Ahrefs, Majestic, Moz)
Export sitemaps, robots.txt, and any server-level rules (custom headers, redirects, canonical rules) from your current host.
3. Create a migration plan and staging environment
Build the WordPress site in a staging environment, not on the live domain. Use the same URL structure where possible. If you must change URLs, document a 1:1 redirect map (old URL → new URL).
- Choose a hosting environment similar to production (same PHP version, similar caching). Consider managed WordPress hosting if you don’t want server-level headaches.
- Install an SSL certificate on staging or ensure you can test HTTPS behavior.
- Set robots.txt to disallow indexing of staging to avoid duplicate content issues.
4. Move content carefully — prioritize quality and metadata
Automated import tools help but validate everything. For each high-priority page:
- Keep or improve the title tag and meta description. Transfer schema markup where present (product, article, FAQ).
- Preserve header structure (H1, H2) and on-page content. Avoid thin pages that were previously ranking.
- Import images and update src paths; optimize images and lazy-load responsibly.
For dynamic PHP-driven content (custom scripts, forms, searches), either recreate them as WordPress plugins, convert to REST endpoints, or keep them on the old server behind stable URLs and proxy if necessary.
5. Implement redirects and keep URL parity
If possible, keep the same URLs. When you change a URL, implement a 301 redirect from the old path to the new path. Best practices:
- Use server-level redirects (NGINX or Apache) for performance; avoid chaining redirects.
- Test every redirect in bulk (use the redirect map and a crawler).
- Keep the redirect map as a living document until no traffic hits legacy URLs.
6. Preserve technical SEO settings
Replicate or improve these features on WordPress:
- robots.txt rules and sitemap.xml. Use an SEO plugin to generate sitemaps with the same URLs.
- Canonical tags matching your preferred URL versions (www vs non-www, trailing slash).
- Structured data (JSON-LD). Transfer existing schema where relevant.
- Hreflang tags for multilingual sites.
7. Test before DNS cutover
Run a full QA pass on staging:
- Crawl the staging site to find broken links, missing meta, and redirect errors.
- Compare server response codes and content with the legacy site for top pages.
- Test forms, tracking pixels, analytics events, and conversion funnels.
- Verify robots and sitemaps are correct once you prepare to go live.
8. Plan the launch to minimize downtime
Schedule the DNS switch during low-traffic hours. Steps at launch:
- Put up a lightweight maintenance page with a 503 header during the final sync if necessary.
- Perform a final content sync and database export/import for any late changes.
- Swap DNS and monitor propagation — keep old server online to serve 301s until traffic stabilizes.
9. Post-launch checks and monitoring
After launch, monitor for at least two weeks closely:
- Check Google Search Console for indexing issues and coverage errors.
- Monitor traffic and rankings for critical pages; compare to your pre-migration benchmarks.
- Watch server logs for unexpected 404s and fix missing redirects quickly.
- Validate structured data, Core Web Vitals, and mobile usability.
10. Practical tips and common pitfalls
- Don’t change too many variables at once. If you change design, content, and URL structure simultaneously, it’s hard to diagnose ranking changes.
- Avoid temporary “soft-404” maintenance pages — use 503 with Retry-After during real downtime.
- Keep the old site live behind redirects for at least 30 days and monitor 404 reports for missed pages.
- Delegate technical tasks to a developer when you hit custom PHP features — mistakes there cause the most invisible SEO damage.
Conclusion and next steps
Migrations succeed when they’re treated like a combined technical and content project. Use the checklist above as your playbook, keep records of every redirect and configuration change, and monitor performance closely after launch. If you prefer a partner who handles the build, redirects, and post-launch monitoring, consider professional help that understands both development and SEO — for more about web development and migration support, see our web development services: Edwin Quijada Web Development.