Objective
Migrate an old domain to a new WordPress site without losing paths by keeping HTTPS on both domains, defining a URL mapping, issuing server-side 301 redirects, testing at scale, updating Search Console, and monitoring 404s.
Prerequisites
- Administrative access to WordPress plus hosting, PHP or web-server access when required.
- A known-good backup and the ability to restore the previous plugin/theme/configuration state.
- Administrative access appropriate to the system being changed or diagnosed.
- A clearly identified scope: affected users, systems, addresses, services and the time of the observed problem.
- A maintenance or test window when the procedure can affect production traffic or availability.
- A copy of the current configuration or other recovery material before any irreversible action.
Step-by-step procedure
Establish the baseline and scope
Before changing anything, reproduce the issue or document the requested change on a representative system. Record the affected users or services, exact time, current configuration, recent changes and a known-good comparison point. This baseline is the reference used to decide whether each later step improves the situation.
- The scope and current state are documented well enough to reproduce or verify the procedure.
HTTPS on both domains
Prepare and validate this migration element: HTTPS on both domains. Inventory the source and target state, identify dependencies and ownership, test the action on a pilot scope, and define a measurable success condition. Keep the previous path available until the target has been validated end to end and users or applications no longer depend on the old state.
- Evidence for this area is explicit, reproducible and consistent with the intended design.
A URL mapping
Prepare and validate this migration element: a URL mapping. Inventory the source and target state, identify dependencies and ownership, test the action on a pilot scope, and define a measurable success condition. Keep the previous path available until the target has been validated end to end and users or applications no longer depend on the old state.
- Evidence for this area is explicit, reproducible and consistent with the intended design.
Issuing server-side 301 redirects
Prepare and validate this migration element: issuing server-side 301 redirects. Inventory the source and target state, identify dependencies and ownership, test the action on a pilot scope, and define a measurable success condition. Keep the previous path available until the target has been validated end to end and users or applications no longer depend on the old state.
- Evidence for this area is explicit, reproducible and consistent with the intended design.
At scale
Prepare and validate this migration element: at scale. Inventory the source and target state, identify dependencies and ownership, test the action on a pilot scope, and define a measurable success condition. Keep the previous path available until the target has been validated end to end and users or applications no longer depend on the old state.
- Evidence for this area is explicit, reproducible and consistent with the intended design.
Updating Search Console
Prepare and validate this migration element: updating Search Console. Inventory the source and target state, identify dependencies and ownership, test the action on a pilot scope, and define a measurable success condition. Keep the previous path available until the target has been validated end to end and users or applications no longer depend on the old state.
- Evidence for this area is explicit, reproducible and consistent with the intended design.
404s
Prepare and validate this migration element: 404s. Inventory the source and target state, identify dependencies and ownership, test the action on a pilot scope, and define a measurable success condition. Keep the previous path available until the target has been validated end to end and users or applications no longer depend on the old state.
- Evidence for this area is explicit, reproducible and consistent with the intended design.
Validate the complete service
Repeat the original user, system or application workflow from the real source and verify the complete result, not only one command or one local check. Confirm that logs and monitoring show the expected behavior and that no temporary debug, bypass, test account, rule or maintenance setting remains enabled.
- The end-to-end service works or the remaining failure is isolated to a clearly identified component.
Technical commands from the original procedure
These technical blocks are preserved byte-for-byte from the historical procedure and kept in their original order. Review names, addresses, paths and parameters before use.
wp option get homewp option get siteurlopenssl s_client -connect old.example.tld:443 -servername old.example.tld </dev/null 2>/dev/null | openssl x509 -noout -subject -datesRedirect permanent / https://new.example.tld/curl -I https://old.example.tld/ancienne-page/curl -IL https://old.example.tld/ancienne-page/Validation
The procedure is validated when:
- The original symptom or change request has been tested end to end.
- The effective configuration matches the intended design and no unexplained error remains in the relevant logs.
- Temporary troubleshooting controls have been removed and monitoring remains normal.
- The result, evidence and any follow-up action are documented.
Rollback
- Restore the configuration, policy, binding, route, credential assignment or service state recorded in the baseline when the change does not meet its success criteria.
- Remove temporary rules, test objects and diagnostic settings that were introduced only for the procedure.
- After rollback, repeat the minimum health checks to confirm that the previous service level has been restored.
Troubleshooting / common errors
- Separate WordPress application errors from PHP, database, DNS, SMTP and web-server errors.
- When testing mail or redirects, use a controlled example and verify the complete external path, not only the local UI.
- If the result changes between tests, compare source, destination, identity, time and policy context before changing additional settings.
- If a command succeeds but the application still fails, continue at the next protocol or application layer instead of widening access.
- If the expected evidence is missing, verify that logging, auditing and the test path actually cover the failing component.
- If the change does not improve the measured symptom, restore the previous state and reassess the working hypothesis.