How to Set Up Redirects After Moving to WordPress
Map old website URLs to relevant WordPress pages, choose permanent redirects, test status codes and prevent loops or unnecessary redirect chains after migration.
Set up redirects by mapping each changed old URL to its relevant new page, adding a permanent redirect for a permanent move, and testing the response and destination. Keep unchanged URLs working directly. Do not send every old address to the homepage or assume WordPress knows the paths used by your previous platform.
For a Niwa Business migration, include the old-to-new URL map in the work before launch. That gives the team a concrete list to implement and verify. Ask Niwa to review your migration requirements with the important existing addresses attached.
Build the map from real old addresses
Start with the old sitemap, important landing pages, navigation, downloads and campaign links. Search Console and traffic reports can help identify addresses people still use. Include pages that were removed from navigation but remain linked elsewhere.
Record the old URL, intended destination and decision. A service page might move to a new service path, while an obsolete event might have no replacement. Give each decision a reason so another person can review it.
If the path remains the same, the correct result is usually a working page at that address. Keeping your domain is useful, but it does not preserve a changed path automatically.
For example, /commercial-cleaning.html can redirect to /services/commercial-cleaning/ if that new page covers the same service. The destination should answer the visitor's original need.
Choose an implementation that fits the hosting
Use the redirect capability already available in the host, server or a suitable maintained WordPress redirect tool. Choose one place to manage a particular rule. Conflicting rules spread across a proxy, hosting panel and plugin are difficult to diagnose.
For an Apache-based setup, server redirects may use configuration such as .htaccess; Nginx uses its own server configuration. Do not paste an Apache rule into an Nginx system and expect it to work. If the hosting panel manages those files, follow that host's instructions instead of overwriting generated configuration.
The WordPress permalink guide explains how WordPress structures its own page addresses. Permalink settings and migration redirects do different jobs. Choosing a new permalink structure does not create a complete cross-platform URL map.
Ask the administrator to save the current configuration before changing it. The WordPress migration documentation includes backup and rewrite considerations for a move.
Create one redirect in WordPress
On a site where WordPress receives requests for the old address, the maintained Redirection plugin provides an admin interface for this work. Install and activate it, then open Tools > Redirection and complete its setup. The getting-started guide shows where to find the interface.
For an old page at https://example.com/commercial-cleaning.html and its replacement at https://example.com/services/commercial-cleaning/:
- Open the Redirects screen and its Add new redirection form.
- Enter
/commercial-cleaning.htmlas the Source URL andhttps://example.com/services/commercial-cleaning/as the Target URL. Replace the example domain with yours. Use a plain path for this single-page rule. - Open the form's cog for advanced options. Keep When matched set to Redirect to URL and choose HTTP code 301, meaning moved permanently.
- Click Add Redirect to save the rule and confirm it appears in the redirect list.
The plugin's official create-redirect instructions explain relative source paths and the form. Its redirect-action guide documents the action and HTTP codes.
To verify it in Chrome, open Developer Tools before visiting the old address. In Network, enable Preserve log and Disable cache, then load https://example.com/commercial-cleaning.html. Select that request and inspect Headers: expect status 301 and a Location header pointing to the intended replacement. The final page should return 200 and display the correct service. Chrome's Network reference explains preserving requests and viewing response headers.
If the old address never reaches WordPress, configure the redirect at the host or server that receives it instead. For a Niwa migration, include implementing the reviewed map and checking these actual responses in the site's launch work.
Use the appropriate response for the move
For a permanent move, Google recommends permanent server-side redirects such as 301 or 308. Temporary redirects communicate a different situation. See Google's redirect guidance for the distinction.
Set the destination to the final preferred HTTPS address where possible. An old link should not need to pass through several successive rules before it reaches the useful page.
Consider the page path and meaningful query parameters. A rule for one product should not accidentally catch every product URL. Broad pattern rules need testing against addresses that should match and addresses that should remain unchanged.
If an old domain also changes, the request still has to reach a server able to issue the redirect. Keep the required old-domain registration, DNS and certificate arrangement in the handover plan. WordPress on the new domain cannot answer a request that never reaches a configured redirect service.
Test the rule, not just a browser click
Check the first response from the old URL and then follow it to the final destination. Record the status, the Location destination and the final page result. A browser can hide several hops while making the page appear to work.
Test a representative group and every important landing page. Include root and www variants where relevant, HTTPS, paths with trailing slashes, encoded characters and meaningful campaign parameters.
Watch for these failures:
- A loop sends the request back to an earlier address.
- A chain adds avoidable redirects before the final page.
- A broad rule captures unrelated pages or administrator routes.
- The destination redirects again to the old address.
- The final page is missing, blocked or about a different subject.
A permanent redirect is a routing instruction, not proof that the destination is useful. Read the page and try the customer action on it.
Update your own links and search signals
Change internal links to point directly to final URLs. Update navigation, content links and sitemap entries rather than relying on redirects for routine browsing.
Review canonicals and any language-alternate references for the migrated pages. Google's canonical documentation describes the preferred-URL signal; it should agree with the destination you intend to keep.
Keep external-link redirects in place. Google's site-move guide advises keeping redirects for at least a year, and longer where they continue serving users. Removing a rule as soon as the new sitemap is submitted can break old links still in use.
Monitor genuine missing-page requests after launch. Decide whether they reveal a missing map entry, an obsolete address or unrelated bot traffic before adding another broad rule.
Keep the map maintainable
Retain the reviewed URL map, the implementation location and dated test results. When a destination later changes, update the original rule to reach the new final page directly instead of adding another hop.
Niwa can be part of the ongoing WordPress owner workflow, but redirect decisions should still be based on the real pages and a reviewed migration plan. An AI suggestion needs the same destination and response checks as a manually written rule.
Share your existing addresses with Niwa before the migration. A clear map lets the move preserve useful routes to the business and gives you evidence that the redirects work.
