This note turns the central question into concrete decisions, checks, boundaries, and ownership.
A URL is a promise made outside the current design
People arrive through search results, saved links, email, documents, partner sites, browser history, and old campaigns. Those paths continue to exist after a new navigation launches. A redirect is the interface between an old promise and a new destination. If every retired route points to the homepage, the visitor loses context and must restart. Map each meaningful old URL to the closest route that answers the same intent, and explain unavoidable discontinuities rather than concealing them.
Create the inventory from more than the menu
Navigation exposes only a portion of a site. Crawl internal links, review sitemaps, analytics landing pages, search console data, server logs, indexed results, backlinks, media directories, and campaign records. Include alternate protocols, hostnames, trailing slashes, case variations, file extensions, query parameters, and downloadable assets. Record status code, canonical target, inbound internal links, external importance, and content decision. A migration inventory is useful only when it describes paths people actually use.
Choose targets by intent, not by word similarity
An old page called ‘solutions’ might describe one current service, an archive, or a discontinued offer. Read it before selecting a target. Preserve the question it answered, not merely a matching noun. If several pages are merged, point each source to the relevant consolidated destination. If no equivalent exists, consider a useful explanatory page or a deliberate 410 response. Redirect chains and irrelevant targets waste crawl signals and frustrate visitors who expected specific information.
Preserve metadata long enough to verify the move
Record titles, descriptions, headings, canonical URLs, structured data, language, images, and publication dates for important routes. The new page need not copy the old design or wording, but reviewers need evidence that the purpose and search context were considered. For articles, preserve authorship and dates only when they are accurate and appropriate. For a newly independent project on an acquired domain, avoid implying continuity with a previous organisation; a clear independence statement is more honest than manufacturing heritage.
Implement rules in a reviewable order
Normalise protocol and hostname first, then path conventions, then individual redirects. Avoid broad regular expressions until specific edge cases have been tested. Preserve relevant query parameters only when the destination understands them; remove tracking parameters safely. Ensure redirects return a permanent status only when the mapping is truly settled. Create automated tests for high-value routes and representative patterns. A spreadsheet without runtime verification is an intention, not migration evidence.
Launch with a baseline and a route back
Before release, record crawl results, top landing pages, indexed counts, performance measurements, conversion definitions, and known errors. Keep a deployable copy of the previous state or a documented rollback method. Name the person authorised to stop or reverse the launch. A rollback is not an admission of likely failure; it is a control that makes careful release possible. Define conditions such as widespread 404 responses, broken forms, inaccessible navigation, or critical indexing directives that trigger action.
Monitor patterns, not only totals
After launch, watch 404 paths, redirect chains, soft 404s, canonical conflicts, excluded pages, sitemap processing, organic landing pages, and real user journeys. Group failures by cause: missed legacy directory, case sensitivity, encoded characters, attachment paths, or external links using an obsolete format. A stable total can hide a severe failure on one valuable route. Review after the first day, first week, first normal crawl cycle, and after significant content updates.
Close the migration with documentation
Update internal links so they point directly to final destinations rather than relying on redirects. Remove temporary rules after confirming they are unnecessary, but retain mappings for externally used legacy paths. Document where redirect rules live, who can change them, how they are tested, and how to inspect logs. Share the final exception list. Migration ends when future maintainers can understand the route history without reverse-engineering configuration under pressure.
Handle files, media, and embedded references
Migration plans commonly focus on HTML routes while old PDFs, images, feeds, calendar files, and embedded resources continue to receive traffic. Inventory those assets and decide whether each remains authoritative, moves, is replaced, or should return a clear removal status. Preserve filenames only when doing so is safe and meaningful. Check documents for links to retired routes and update them where possible. If an attachment contains outdated policy or contact information, redirecting to the same file under a new path preserves the problem. Asset migration requires content judgement, not only storage copying.
Test query strings and campaign variants
Old links may include tracking parameters, filters, pagination, language choices, or identifiers consumed by an integration. Group observed parameter patterns and decide which should be ignored, preserved, translated, or rejected. A broad rule that drops every query can break useful filtered views; preserving everything can create duplicate destinations or pass sensitive values into a new system. Test encoded characters and repeated parameters. Document the expected canonical URL after resolution. Search, email, and paid campaign owners should review mappings for routes they still distribute.
Give the 404 page a diagnostic role
Not every unknown route deserves a redirect. A useful 404 response confirms that the requested address is unavailable, provides stable navigation, and allows the path to appear in monitoring. Avoid a soft 404 that returns status 200 or a page that resembles the homepage so closely that visitors cannot tell the route failed. Offer search only if it really works. During QA, deliberately request a misspelling, a removed file, an uppercase variant, and a malformed nested route. Confirm both the visible explanation and the HTTP status in the deployed environment.
Protect migration rules from accidental cleanup
Redirects may look obsolete to a future maintainer because successful requests no longer appear as errors. Store the mapping source, rationale, creation date, and external importance near the deployment configuration. Add automated checks for a small permanent set of valuable legacy paths. Review rules for loops, chains, and collisions when new routes are introduced. Removal should be a conscious decision supported by logs and search evidence, not a routine attempt to simplify configuration. External links can remain active for years after the original site disappears.
Turn the method into a reviewable record
Apply the ideas in Redirects Are Part of the Interface to one real route, decision, or update rather than discussing the entire website in the abstract. Record the current condition, the audience question, available evidence, responsible owner, proposed change, risk, and acceptance check. Attach screenshots or route lists where they clarify the record, but do not substitute visual evidence for an explanation. Ask a reviewer who did not prepare the record to identify the decision and reproduce the check. If they cannot, revise the language or evidence. Keep the record with the project source so a future maintainer can distinguish an intentional rule from an accidental implementation detail. This small discipline reduces repeated debate and makes later corrections safer.
Use a stop condition, not endless refinement
Define what would make the recommendation inappropriate, incomplete, or unsafe. A missing content owner, unverifiable claim, inaccessible interaction, unmapped legacy route, unknown data destination, or absent recovery path may be a reason to pause. Write who can resolve the condition and what evidence allows work to continue. This prevents schedules from converting uncertainty into silent assumptions. It also protects creative work: once the named conditions and acceptance checks pass, the team can stop polishing details that do not improve the audience decision. Review the condition after an ordinary publishing cycle, because real use may reveal a different constraint from the one imagined during design.
The useful standard is a decision somebody else can understand, test, and maintain.
Questions to carry into the project
- Which decision is this work meant to improve?
- What evidence is available now, and who can verify it?
- Which owner can maintain the result after launch?
- What condition should stop, revise, or reverse the release?