WordPress redirect tutorials
A WordPress domain migration redirect checklist
Plan old-to-new URL mappings, check destination pages and preserve a rollback path before moving WordPress content to a different domain.
Updated
A domain migration needs more than a homepage redirect. Inventory the old URLs, map each useful page to its replacement, verify the destinations and retain control of the old domain so that visitors can reach the new one.
Before the move
Export the current URLs and identify important pages from your own traffic and backlink data. Include media and downloadable resources when their addresses will change. Separate pages with a direct replacement from pages that are being retired; a relevant mapping is more useful than sending everything to the new homepage.
Make an independent backup. Record where redirects will run: the old server, a CDN, WordPress or a combination. Do not assume a plugin installed only on the new domain can handle requests that still arrive at an unrelated old server.
Build and review the mapping
- Choose the final HTTPS hostname and consistent URL format.
- Map old paths to the actual new destination URLs.
- Confirm that each destination exists and is appropriate for the old content.
- Check wildcard rules against exceptions before relying on them in bulk.
- Preview the change and resolve duplicate sources or replacement conflicts.
- Keep the previous rule set and a clear rollback procedure.
RedirectNest Free can preview all supported formats and import native basic CSV or reviewed basic exact-rule conversions from Redirection JSON. Rank Math conversions require Pro for trailing-slash matching. Simple 301 exports can be reviewed but require manual conversion in either edition because encoded-path matching differs. Pro adds saved migration drafts, before-and-after rule diffs, destination HTTP checks and post-publication verification. Advanced matching imports still require Pro where supported; unsupported rules must be resolved before import.
Competitor conversions do not guarantee identical matching. Redirection and Rank Math decode incoming URLs; RedirectNest matches literal paths, so /old and /%6Fld are not treated as identical. Review the warning and select the initially unchecked conversion acknowledgement before importing. Native CSV has no extra conversion acknowledgement. Test encoded variants before cutover, and prepare a deliberate manual mapping if you need the original behavior. Unsupported rows still block the whole import.
Treat check results as observations at the time of the check. A destination can later change, and a successful HTTP response does not prove that the page content is the right replacement.
After switching
Test representative old URLs, including important landing pages, nested paths, parameters and retired content. Inspect the full redirect sequence and avoid unnecessary intermediate hops. Update internal links, canonical URLs and the sitemap to use the final destinations. Review search-engine migration tools separately where a domain move qualifies for them.
Monitor errors and real user reports after launch. Pro includes recurring checks, alerts, rule schedules and client reports to support ongoing follow-up. Keep the old domain and redirects available for a planned transition period; do not remove the old infrastructure just because the new homepage loads.
Read migration workspaces, verification reports and monitoring. These are complementary checks, not a guarantee that search traffic will remain unchanged.
Build proposals from local sitemaps
In Pro 0.8.0, Migration Auto-Mapper compares two uploaded sitemaps locally, up to 2 MB and 5,000 URLs each. Review up to three lexical candidates per row, approve or skip each proposal, and create a draft for the existing checks and publication workflow. Similar words do not prove equivalent content. Identical-path domain moves are excluded to avoid local self redirects; routing at the old host is still required.
After launch, internal-link cleanup can preview exact replacements on one eligible classic HTML page at a time. It needs a fresh saved scan, an eligible permanent local redirect, InnoDB and native revisions. Blocks, builders and dynamic content need their normal editor.
KEEP THE NEXT STEP SIMPLE
See how RedirectNest fits.
Compare the editions, explore the workflow and choose what your website needs.