WordPress migration redirects should preserve the route from an old address to its closest relevant replacement. They are needed when URLs change, not simply because the website moves to another server. A host change that keeps the domain and paths intact usually calls for traffic routing and validation rather than a new redirect for every page.
Redirect behavior can come from WordPress, a plugin, the web server or a CDN. Those layers may disagree about the preferred hostname or HTTPS scheme, creating chains and loops. An effective migration plan inventories the current rules and gives each change one clear destination before new rules are enabled.
This article from getaboutcolumbia explains how to map URLs, update the application and test the resulting paths. The objective is a predictable experience for visitors and crawlers, with useful monitoring after launch rather than a blanket rule that hides every missing page behind the homepage.
Build a mapping based on real content
Collect important existing URLs from the sitemap, analytics, server records and a crawl where available. Include media or downloads that receive direct traffic. Group them into unchanged addresses, moved content, merged content and pages with no replacement. This inventory should reflect what actually exists, not an assumed list generated from a few menu links.
Google’s site move documentation recommends mapping old URLs to relevant new destinations and using permanent server-side redirects when possible. It also cautions against irrelevant mass redirects. If several articles become one genuinely equivalent resource, a shared destination may make sense. If no equivalent exists, a truthful missing-content response can be more appropriate than a misleading redirect.
Keep content restructuring separate from the operational move when that reduces uncertainty. The process for migrating WordPress between hosts addresses data transfer and cutover; the URL map addresses navigation. Combining a domain change, permalink redesign and hosting migration creates more variables, so document each transformation explicitly if the project requires all three.
Update WordPress and choose the redirect layer
The WordPress migration documentation explains that changing domains leaves stored references that may require attention. Confirm the intended home address, application location and permalink structure. Examine hard-coded URLs in custom code and integrations separately. A server redirect can send visitors onward, but it does not repair every internal reference or callback setting automatically.
For stored URLs, WP-CLI search and replace provides serialized-data handling and a dry-run option. Back up first and inspect the intended scope before applying changes. Preserve identifiers or historical records that should not be rewritten. A carefully selected replacement is easier to verify than a global string change across unrelated tables and columns.
Choose where redirects belong based on the hosting architecture and who maintains it. Centralize overlapping rules where practical and record exceptions. Coordinate HTTPS enforcement with the proxy or CDN so the origin understands the original request correctly. The distinction between DNS changes and website-level behavior matters: DNS routing does not itself produce an HTTP redirect.
Test destinations, loops and dependent signals
For each representative old URL, inspect the status and final destination. Prefer a direct route to the intended current URL instead of sending visitors through several historical addresses. Check hostname variants, HTTP and HTTPS, trailing slashes and paths with query parameters. Confirm that legitimate application parameters remain available where the destination needs them.
Open the destination itself and verify that it returns useful content rather than redirecting back. Inspect its canonical address and internal links, then update sitemap entries to the intended current URLs. For multilingual sites, include alternate-language references in the review. These checks should agree on the destination instead of sending mixed signals through separate components.
Keep the old domain and its certificate operational if redirects depend on them. Monitor missing pages, redirect failures and traffic reaching unexpected paths after launch. Prioritize errors affecting real visitors or important inbound links. Maintain the mapping as a readable record so a future redesign can point directly to the newest destination instead of extending another chain.
Mistakes to avoid
Do not redirect every unknown path to the homepage to make an error report look clean. That can confuse users and conceal genuinely broken links. Also avoid testing only while signed in; plugins and caches may treat anonymous requests differently. Verify the path from an ordinary visitor’s perspective and inspect response behavior rather than relying on visual appearance alone.
Do not layer a new HTTPS or hostname rule over existing rules without tracing the complete request. A CDN forcing one hostname while WordPress forces another creates a loop that content edits will not fix. Document cache invalidation after redirect changes because stale redirect responses can persist in intermediate caches or browsers after the underlying configuration is corrected.
Two final recommendations
Keep a machine-readable redirect inventory with the old URL, destination and reason for the mapping. Use it to run repeatable checks before and after deployment. Include a small set of important URLs in routine monitoring so an unrelated server or CDN configuration change does not silently break the migration later.
Assign one owner to approve new redirect rules and retire redundant ones. Keep the current destination as the reference point and review changes when content is merged or removed. This prevents years of individually reasonable rules from accumulating into a confusing network that nobody can troubleshoot during an outage.
Conclusion
WordPress migration redirects work best when each changed URL has an accurate, relevant destination. Preserve unchanged URLs where practical, update stored references carefully and coordinate rules across the application, server and CDN. A hosting move alone does not require inventing a redirect plan for addresses that remain identical.
Verify response status, final content, canonical addresses and internal links using representative paths and visitor states. Monitor the old routes after launch and keep the required domain and certificate available. These checks make navigation predictable and reveal gaps that a successful homepage test cannot detect.
Treat the URL map as part of the website’s permanent operating record. A clear map supports future redesigns, faster incident diagnosis and simpler direct redirects when content moves again. Accuracy and maintainability matter more than the number of rules installed.
