WordPress redirect map planning is the step that decides whether a domain consolidation preserves years of search rankings and backlinks, or quietly throws them away. A redirect rule written without a complete map behind it might work for the ten URLs someone tested by hand and silently fail for the hundreds nobody thought to check. By the time that shows up as a traffic drop, the old domain is often already gone.
One-to-One Redirects vs. Pattern Fallback Redirects
Every URL in your consolidation falls into one of two categories, and the map needs to treat them differently:
- One-to-one redirects: a specific old URL maps to a specific new URL. Use these for pages, posts, and products that have a clear, direct equivalent on the new site.
- Pattern or fallback redirects: a whole path structure maps to a single destination or a rewritten pattern. Use these for large groups of URLs that share a predictable structure, where writing a one-to-one rule for each would be impractical.
Reach for one-to-one redirects first, for anything with real search visibility or backlinks. Save pattern redirects for the long tail of low-value URLs where a close match is good enough.
A practical way to decide which category a group of URLs belongs in: check whether each one, individually, has meaningful search traffic or an external backlink pointing at it. If it does, it earns a specific one-to-one entry in the map. If a whole path pattern has negligible traffic across the board – old tag archives, for example, or auto-generated author pages – a single fallback rule for the entire pattern is a reasonable trade of precision for practicality.
Choosing a Sensible Default Fallback
Some old URLs won’t have a direct equivalent anywhere on the new site, and you need a decision for those before go-live, not a generic 404 by default. A sensible fallback sends orphaned traffic somewhere genuinely useful – a relevant category page, a product’s own landing page, or the site’s homepage as a last resort – rather than a dead end.
Pick this fallback deliberately per content type. A lost blog post and a lost product page shouldn’t necessarily land in the same place.
Handling Renamed Products and Slugs Consistently
If a product or section is being renamed as part of the consolidation, that renaming has to apply the same way across every domain’s map, not just the one you happen to be working on first. A slug that becomes /downloads/new-name/ on one domain but stays /downloads/old-name/ on another creates exactly the kind of inconsistency that makes a redirect map impossible to audit later.
Decide the renaming convention once, write it down, and apply it identically everywhere it appears in the map. If the same underlying product exists under three different old slugs across three domains, all three deserve an entry pointing to the same new URL, using the same naming logic – not three separate ad hoc decisions made at different points in the project.
Documenting Deliberate Exceptions on Purpose
Not every redirect follows the main pattern, and that’s fine as long as it’s on purpose. A product that’s staying on its own domain instead of merging, or a specific path that needs to redirect to an entirely unrelated domain, are legitimate exceptions. What makes them safe is documenting them explicitly, in the same map as everything else, instead of leaving them as a verbal agreement or a rule someone will add “later.”
An exception that only exists in someone’s memory isn’t a decision. It’s a gap waiting to be discovered during testing, or worse, after launch.
Keep the map in a format the whole team can review and comment on, not a local file only one person can open. Treat it as a living document until testing is complete: exceptions get added as they’re identified, and every addition goes through the same review as the original map, not around it.
Build the Full Map as a Document Before Writing Any Server Config
Resist the urge to start writing Nginx or Apache rules as soon as you’ve mapped the first few URLs. A redirect map is a planning document first – every source URL, its destination, and the reasoning behind exceptions – reviewed and confirmed complete before a single line of server config gets written from it. The source-URL column should come directly from the full content inventory you already built, using the same URL export tool from the audit stage, not a fresh list typed out from memory.
A minimal redirect map, built from that inventory, looks something like this:
| Old URL | New URL / Rule | Type | Notes |
|---|---|---|---|
| oldsite-a.example.com/product-x/ | newsite.example.com/downloads/product-x/ | One-to-one | Renamed slug, high existing traffic |
| oldsite-b.example.com/blog/* | newsite.example.com/blog/* | Pattern | Slug structure unchanged |
| oldsite-a.example.com/help/* (no direct match) | newsite.example.com/downloads/product-x/ | Fallback | Deliberate exception, documented on purpose |
Every row should be reviewable by someone who wasn’t the one who wrote it – if the “Type” or “Notes” column can’t explain why a rule exists, that’s a sign the decision behind it hasn’t actually been made yet.
Google’s own guidance on site moves with URL changes makes the same point from the search engine’s side: a complete, correct 301 redirect from every old URL to its new equivalent is what preserves ranking signals during a move. Config written from an incomplete map can’t deliver that, no matter how well the config itself is written.
A Fallback That Sends Unmatched Paths to the Right Landing Page
For example, imagine a product being consolidated onto a shared hub domain, with dozens of old blog, help, and download URLs that don’t have direct equivalents on the new structure. Rather than letting all of that traffic hit a generic 404, the map sends any unmatched path under that product’s old prefix to the product’s own new landing page on the hub. It’s not a perfect one-to-one match, but it’s a deliberate, useful fallback instead of a dead end, and it’s documented in the map as exactly that: a fallback, not an oversight.
The Pitfall: Mapping URLs Product-by-Product Instead of Building One Complete Map
It’s tempting to map redirects one product or one site at a time, checking each one off as “done” before moving to the next. The problem is that a redirect map built this way is never reviewed as a whole. Inconsistent naming between products, conflicting fallback rules, and gaps between what one map assumes and what another map does all hide inside separate documents that nobody reads side by side. Build one map, covering every domain, and audit it end to end before any of it becomes server config. This also protects the SEO value tied to your existing rankings and backlinks – value that a fragmented, unreviewed redirect plan puts at real risk.
Your WordPress Redirect Map Planning Checklist
Before any server config gets written, confirm the map includes:
- A clear split between one-to-one redirects and pattern fallback redirects
- A deliberate default fallback, decided per content type
- Consistent renaming and slug conventions applied across every domain in scope
- Every deliberate exception documented in the map itself, not left verbal
- One complete map, reviewed end to end, before any config is written from it
If any of the sites being consolidated run an EDD or WooCommerce store, the next step is preparing that store data – customers, products, and subscriptions – before the redirect map ever touches a checkout page.