A website migration can look successful while quietly breaking the paths people and search engines use to reach important content. The homepage loads, the new design is live, and the launch checklist is marked complete. Then traffic reports show a drop in organic visits, campaign links land on 404 pages, or a bookmarked service page sends users to a generic homepage.
The missing control is often a redirect inventory: a working list of old URLs, their intended destinations, the reason for each redirect, and the tests that prove the mapping works.
This guide explains how to build that inventory before a WordPress migration, redesign, domain change, or information-architecture update. The focus is practical: protect search traffic, preserve user paths, and make the redirect layer part of the website ecosystem rather than a last-minute server task.
Why a migration needs more than a new sitemap
A new sitemap describes the structure of the destination site. It does not tell you what happens to every address that already exists.
Old URLs can live in many places:
- Search results and external links
- Paid campaigns, email templates, and social posts
- Printed materials, QR codes, and partner resources
- Bookmarks and browser history
- Forms, PDFs, images, feeds, and embedded content
- CRM records, automation rules, and reporting dashboards
A migration that only compares the old and new navigation trees can miss high-value URLs that are not visible in the main menu. A redirect inventory makes those paths explicit.
Start with a source list, not a redirect plugin
The first step is to gather URLs from multiple sources and label where each one came from. A crawl of the current site is useful, but it is only one input.
Build a working list from:
- The current XML sitemap and server or crawl data
- Analytics landing-page reports
- Search Console queries and pages with impressions
- Backlinks and referral reports
- Campaign URL sheets and email templates
- Known forms, confirmation pages, downloads, and media files
- CRM, marketing-automation, or donation links that point to the site
- Stakeholder lists of pages that must remain reachable
Keep the original URL exactly as discovered, including path casing, trailing-slash behavior, query strings, and file extensions. Normalizing too early can hide the difference between two real paths or make it impossible to trace the source of a URL later.
Give every old URL a destination decision
Do not force every URL into a 301 redirect. Each row should receive a deliberate outcome:
- Redirect: the new page is a close replacement.
- Keep: the URL remains valid and needs no change.
- Retire: the content has no replacement and should return an intentional response, often a 410 where appropriate.
- Merge: several old pages are consolidated into one stronger destination.
- Review: the team needs a business or content decision before launch.
The destination should match the visitor’s intent. Redirecting an old service page to the homepage may technically resolve the request, but it does not preserve the user’s task. A close, useful destination is usually better than a generic fallback.
Separate URL mapping from redirect implementation
The inventory is a content and systems artifact. The implementation may happen in the web server, hosting layer, WordPress configuration, a redirect plugin, or a combination of those tools.
Keep the mapping independent from the implementation so it can be reviewed by people who do not need access to production. A useful row includes:
- Old URL
- New URL or final disposition
- Redirect type or response expectation
- Source of the old URL
- Page owner or reviewer
- Reason for the mapping
- Priority or business impact
- Test status and date
This separation also helps when the redirect method changes. A WordPress plugin may be convenient for a small site, while server-level rules may be preferable for a large migration or a path that must resolve before WordPress loads.
Protect special paths that ordinary crawls miss
Some of the most damaging migration failures are not ordinary content pages. Give extra attention to:
- Form landing pages and confirmation URLs
- Payment, registration, and donation paths
- PDFs, images, and other downloadable files
- Campaign URLs with UTM parameters
- Personalized links and tokens
- Preview or staging URLs that accidentally escaped into public use
- Feeds, API endpoints, and integration callbacks
- Multilingual or multisite paths
Do not copy sensitive identifiers into a public redirect spreadsheet without a clear reason. For personalized links, store a redacted example or a pattern when possible, and keep the working file access-controlled.
Watch for redirect chains and loops
A redirect from an old URL to a temporary URL that then redirects to the final page creates a chain. Chains add latency and make troubleshooting harder. A rule that points back to an earlier path creates a loop that never reaches content.
Validate the final destination directly. If an old path should resolve to /services/integrations/, map it there instead of sending it through an intermediate category or an earlier legacy slug.
Also check rules in the order they are evaluated. A broad pattern placed above a specific rule can capture the wrong path. This is particularly important for language prefixes, directory migrations, and rules that handle both pages and files.
Test the full user path after the site is live
A redirect returning a 200 response is not enough. The final page needs to be the right page, and the journey after arrival still needs to work.
Use a test set that includes:
- Top landing pages from analytics and search data
- Pages with external backlinks
- Every old URL marked high priority
- Representative query-string and trailing-slash variants
- Campaign links from current email and advertising workflows
- Form, payment, registration, and download paths
- Mobile and desktop requests where behavior may differ
For each test, record the requested URL, status sequence, final URL, page title or content check, form or conversion result, and timestamp. A simple spreadsheet is enough if the columns are clear and someone owns the review.
Keep redirect monitoring after launch
The inventory is not finished when the migration launches. Search engines, users, and partners will continue to reveal paths that were not in the original source list.
For the first several weeks, review:
- 404 logs and redirect-hit reports
- Search Console indexing and page errors
- Analytics landing pages with unusual changes
- Campaign links and referral traffic
- Form, checkout, and integration error logs
Add newly discovered URLs to the inventory rather than making one-off fixes that only exist in a plugin screen or server file. The list becomes a useful record of how the site actually connects to the wider digital operation.
Make the redirect inventory part of the migration gate
A website migration is ready to launch when the important paths have decisions, the rules are implemented in the correct layer, and the tests show that people can still reach the content and actions they came for.
That means reviewing redirects alongside content, forms, analytics, integrations, accessibility, and performance. The website is not an isolated collection of pages. It is a set of routes used by people, search engines, campaigns, and other systems.
If you are planning a WordPress migration or redesign, DigitalWerks can help build the redirect inventory, map old paths to useful destinations, test the live rules, and connect the migration checklist to the forms, analytics, and integrations your website supports.