A WordPress migration needs a URL decision for every important page, a tested release, and a practical way back. A new design alone does not show that search engines or customers can still reach the right content.
This guide includes a small, reproducible redirect exercise run on 22 October 2026. It is an educational local test, not a client migration or a claim about traffic recovery. Ramfa SEO’s main website runs on Next.js; our Insights publication runs on WordPress.
1. Build the inventory before changing URLs
Combine the current crawl, XML sitemap, Search Console landing pages, analytics landing pages, and URLs with known external links. Record the old URL, its purpose, traffic evidence where available, proposed destination, owner, and expected status. A missing analytics row does not prove that a page has no value.
Keep a useful URL when its content and purpose remain the same. When a URL must change, choose the closest equivalent page. Do not send every retired page to the homepage: a visitor asking for a specific service needs that service, and an unrelated destination can be treated as a soft 404.
2. Separate the staging site from production
Protect staging with authentication, exclude it from indexing, and route forms and transactional email to a test destination or a dry run. Check canonical and hreflang output in the rendered HTML, but do not let a staging hostname become the production canonical. Keep production credentials out of browser code and source control.
For WordPress, list the PHP version, theme and child theme, active plugins, scheduled tasks, permalink structure, media paths, and integration dependencies. A core update, theme change, and hosting migration in one release make failures harder to isolate. Confirm that the host has enough temporary disk space to download and extract updates as well as store the live site.
3. Test a redirect map with real HTTP requests
The supplied exercise starts an isolated server on an available local port. It maps /old-service/ to /services/technical-seo/ and /old-contact/ to /contact/. Both old paths return a permanent 308 response with the expected Location header; both destinations return 200. An unknown path returns 404.
A 301 is also a permanent redirect. The exercise uses 308 explicitly so the expected response is unambiguous. Your production mapping should reflect the actual server configuration and request behavior, including form endpoints. Do not redirect an old form submission endpoint without testing method and body handling.
- Download the two-path example map (CSV)
- Download the reproducible Python exercise
- Read the recorded exercise result (JSON)
Run python test_migration.py with Python 3. The script uses the standard library and does not change a WordPress installation. Read it before running it. The recorded run passed 10 assertions: five in the migrated state and five after switching back to the original local routes.
4. Write rollback triggers before release
Choose an owner who can stop the release. Useful triggers include important landing pages returning 5xx, widespread wrong redirects, a broken checkout or enquiry form, or production pages accidentally carrying noindex. Define the acceptable observation window and the evidence required to proceed.
The local exercise restores two original URLs to 200 and returns 404 for the two new destinations, while retaining a 404 for the unknown path. This checks the example’s reversible routing behavior only. It does not test a database restore, DNS propagation, media recovery, WordPress plugin compatibility, or recovery time on a real host.
A production rollback needs the correct application version, configuration, database and media recovery strategy. If users can place orders or submit content during the release, restoring an old database can lose those new records. Decide how writes will be preserved before choosing a rollback procedure.
5. Verify the release from the visitor’s side
Test important old URLs without automatically following redirects, then test the final destinations. Check for chains, loops, mixed hosts, missing images, incorrect canonicals, wrong language alternatives, and accidental indexing blocks. Complete a real form journey and confirm receipt in the intended inbox. An HTTP 200 response is not proof of successful delivery.
Update internal links and the sitemap to final URLs. Submit the sitemap to the relevant webmaster tools and inspect representative URLs. Keep the old-domain redirects operational when a domain changes. Search indexing and rankings take time to respond; launch-day HTTP checks cannot establish long-term SEO success.
Use the checklist as a working document
Download the migration checklist. Its rows start as “not started” deliberately. Add your owner, evidence, completion date, and decision for each stage. The template is not a completed audit of your site.
For related technical details, read our redirect chains and loops guide. Google’s official site-move documentation explains the search engine side of URL changes.
Need a migration plan for your own setup? See Ramfa SEO’s WordPress and migration service and the scope of this educational exercise. Prepared by Ramin Amirhaeri.
