On this page
A redirect map is a set of decisions about where an old address should lead. It deserves review before the rules are installed, because a technically valid redirect can still send a reader to the wrong content, create a loop, or discard information needed by a form or campaign.
Begin with the reason for the change. Renaming an article, merging overlapping pages, changing a domain, and temporarily moving a service are different situations. Choose the destination and behavior for the actual change rather than applying one broad rule to everything that no longer matches the new structure.
Inventory the URLs people may still use
Collect current routes, known old routes, important inbound links, sitemap entries, and URLs used in navigation, documents, emails, or campaigns. Include the variants your site actually serves, such as an old hostname or a trailing-slash convention.
Do not assume a list of current WordPress posts is the complete inventory. Categories, media links, landing pages, custom routes, and earlier redirects can all matter. An old printed document may keep sending people to an address long after it disappears from the menu.
Record the source of each URL when useful. This helps prioritize review and identify who must update a link outside the website.
Decide the destination by the reader's intent
For each old URL, identify the page that now satisfies the same purpose. A renamed guide usually has an obvious successor. A merged article may map to a more comprehensive page. A removed service may require a clear explanation rather than a misleading destination.
Avoid sending every old URL to the homepage merely to eliminate errors. A visitor following a specific guide expects relevant information, and a general landing page may not meet that need. Google also warns against irrelevant bulk redirects in its site-move guidance.
If no appropriate replacement exists, decide how the site should communicate that outcome. A redirect is not mandatory for every removed page. The choice should reflect the content and the intended HTTP behavior, with technical review where needed.
Keep the map explicit before using patterns
Use a table with the old URL, intended destination, reason, expected status, and review note. Start with specific cases before translating them into a pattern or regular expression.
| Old route type | Mapping question | Review risk |
|---|---|---|
| Renamed article | Is this the direct successor? | Redirecting to a similar but different topic |
| Merged articles | Does the destination cover each old purpose? | Losing a distinct reader need |
| Changed category path | Are the intended category and pagination preserved? | A broad rule catching article URLs |
| Old hostname | Should the path remain the same? | Sending all paths to one page |
| Temporary service change | Is the move expected to reverse? | Declaring a permanent move prematurely |
Patterns can reduce maintenance, but they also expand the set of affected requests. Test representative matches and deliberate non-matches before using one in production.
Find every layer that can redirect
WordPress may not be the first component handling the request. A CDN, reverse proxy, web server, host control panel, plugin, theme, or application route can issue a redirect. A rule that looks correct in one interface may compete with another rule earlier in the chain.
Document which layer owns each class of redirect. For example, the server might normalize the hostname while the application maps renamed articles. Avoid duplicating the same decision across several layers unless there is a clear reason and tested behavior.
The WordPress migration guide covers the wider move. The redirect review is a focused part of that process, with its own evidence and rollback plan.
Check the status and the final response
Inspect the response from the old URL without hiding intermediate steps, then follow the chain to the final destination. Confirm the expected redirect type, each location, the final status, and the final page content.
Google distinguishes permanent redirects, such as 301 and 308, from temporary redirects. Choose according to the intended duration and behavior. Do not select a status solely because a plugin defaults to it.
A final 200 response is necessary for many ordinary destination pages but not sufficient proof of correctness. Check the title, main heading, and actual subject. A custom error page can return 200, and a valid page can still be the wrong destination.
Look for chains and loops
A chain can arise when the new rule points to an older redirect rather than directly to the final page. A loop can occur when separate layers disagree about the preferred hostname, scheme, path, or slash convention.
Review the full sequence for important routes. Where appropriate, update the mapping to the direct final destination and remove obsolete intermediate decisions through a controlled change. Do not delete unrelated rules simply because they appear near the affected entry.
Test both a browser and an HTTP-level inspection. Browser caching can make a corrected permanent redirect appear unchanged on one device. A fresh inspection helps distinguish a cached observation from the server's current response.
Decide what happens to query parameters
Some parameters are incidental tracking, while others affect the requested content or action. Determine which must be preserved, transformed, or intentionally removed. A blanket rule can discard a filter, reference, or state the destination needs.
Use synthetic values when testing sensitive routes. Do not paste private tokens or customer identifiers into a public redirect checker. Avoid redirecting authentication or transaction endpoints through a general article-migration rule without a technical review of their behavior.
Test encoded characters and representative unusual paths from the actual inventory. The purpose is to verify known behavior, not to create an unlimited list of hypothetical URLs.
Align the destination's own signals
Check that the final page's canonical URL, sitemap entry, navigation links, and relevant metadata agree with the intended address. A redirect to one URL followed by a canonical pointing somewhere else leaves competing signals.
Update internal links to the final destinations where practical. Readers should not need an avoidable redirect every time they click the site's own menu. The WordPress SEO guide explains the broader role of crawlable, useful pages; a redirect map supports that foundation without guaranteeing rankings.
For a whole-site move, follow the applicable Search Console and migration guidance. A successful deployment does not mean search engines have already recrawled and processed every changed URL.
Release with a recoverable map
Keep the reviewed map and a backup of the previous rules. Test in an isolated environment where possible, then make a controlled live check of the actual public host and routes. Staging cannot prove behavior controlled by a production-only CDN or virtual host.
After release, monitor errors and representative old links. If a rule catches an unintended route, correct the narrow mapping rather than adding another broad redirect on top. Record the reason and retest the affected cases.
The finished map should let a reviewer answer why each important old address leads where it does. That is the standard that connects the technical rule to a useful experience for the person following the link.
Sources and further reading
Primary and contextual sources used to verify definitions or give readers a relevant next resource.
- Google Search Central: Redirects Redirect type and destination affect how visitors and search engines understand a moved URL.
- Google Search Central: Site moves URL mapping, appropriate redirects, updated links, and monitoring are part of a site move.