A Website Redesign Is a URL Migration: Build the Redirect Map Before Launch

A redesigned service website can pass a visual review while still breaking an important contract: existing addresses should continue to lead people to useful information.

Those addresses may appear in search results, customer emails, advertising, proposals, saved bookmarks, and links from other websites. Replacing navigation does not update those references.

Website redesign redirect mapping belongs near the start of the build. It creates an explicit record of what each important URL becomes and prevents migration decisions being improvised during launch.

For a small business site, the process can be straightforward. The challenge is usually ownership and completeness, rather than a need for complicated software.

Inventory the addresses that matter

Start with the current sitemap and the URLs available from the content management system. Supplement them with pages appearing in search performance data, analytics landing-page reports, advertising destinations, and known customer-facing resources.

Include useful documents and other linked assets where their addresses will change. A PDF linked from a proposal can matter to the business even if it is not part of the main navigation.

Keep the inventory in a versioned file. Suggested fields include old URL, content purpose, proposed action, destination, reason, owner, and test result. Preserve the original values so the team can distinguish a deliberate decision from an accidental omission.

Do not assume a low-traffic URL has no value. It may support an important sales conversation or receive visitors only during a particular part of the year. Ask the business before deleting material whose role is unclear.

Choose an action for each URL

Useful actions include keeping the address, updating its content, moving it to a new address, merging it into a genuinely related page, or retiring it when no appropriate replacement exists.

Keeping a useful URL can be the simplest option. A new visual design does not require changing every path.

When content moves, identify the closest relevant destination. If several old pages become one stronger page, explain what information is being consolidated so reviewers can assess whether the mapping makes sense.

For a retired page without a relevant replacement, a proper not-found response may be more appropriate than sending the visitor to an unrelated offer. The decision should reflect what happened to the content, not a desire to make every request return a successful page.

Make the map readable to both teams

The developer needs an implementable mapping. The business needs to understand whether important information survives. A small table can serve both purposes:

Old path	Action	Destination	Reason
/services/	Keep	/services/	Existing overview remains useful
/old-repair-page/	Move	/repair-services/	Same service with a revised address
/legacy-guide/	Merge	/service-planning/	Relevant guidance is retained in the new page
/expired-offer/	Retire	None	Offer ended and has no equivalent replacement

These are illustrative paths, not recommendations for a particular live website. The important feature is that each row explains the intended content relationship.

Review the map before implementation. That gives the business an opportunity to catch missing services while there is still time to revise the structure.

Implement redirects deliberately

Google’s site-move documentation recommends permanent server-side redirects for moved URLs, directing them to relevant destinations and avoiding unnecessary redirect chains. It also calls for updating internal links and URL annotations as part of the move.

Translate the approved map into the mechanism appropriate for the hosting environment. Keep the configuration under the same review discipline as other production changes.

Test the final destination rather than stopping at the first redirect response. A redirect can exist while pointing to another redirect, an error page, an unrelated page, or an address with an inconsistent canonical reference.

Take care with broad pattern rules. A convenient rule that catches many paths may also affect URLs that should behave differently. Test representative matches and exceptions before relying on it.

Test behaviour, not just status codes

A useful migration check asks several questions. Does the old URL resolve according to the map? Does the destination load the intended content? Can a visitor complete the next task? Are the new page’s internal links current?

For retained pages, confirm that the content remains present and that the new layout has not accidentally hidden essential information. For merged pages, confirm that the relevant explanation actually made it into the new page.

Keep redirect tests separate from form and booking tests, but include both in the launch review. A migration can preserve every URL while breaking the enquiry route.

Record failures with enough detail to reproduce them: requested URL, observed result, expected result, and the environment tested. That is more actionable than marking the whole website “SEO checked.”

Plan the launch and monitoring responsibilities

Assign someone to implement changes and someone to verify them. Make clear who can approve a correction if a missing destination is discovered after launch.

Retain a copy of the pre-launch map and a record of the deployed version. If the live configuration differs from the approved file, explain why.

After release, inspect important pages and actual entry routes. Review not-found requests, enquiry failures, and search performance alongside the deployment record. A problem affecting a valuable service page deserves attention even if the overall website appears healthy.

Avoid attributing every traffic change to a single redirect decision. Timing, content changes, search demand, and other marketing activity can also influence results. Use the map and launch record to narrow the investigation.

Treat the URL map as a reviewable project asset

Keep migration decisions alongside the work they affect. A spreadsheet or a simple structured file can be enough, provided the team knows which version is authoritative and how changes are approved.

Add an explicit reason when a destination differs from the original plan. If two services are combined during content review, update the map before the redirect configuration is generated. Otherwise the design, content, and technical implementation can quietly drift apart.

The owner of a row does not need to be the person implementing it. A service lead may confirm that the replacement page is appropriate, while a developer handles the response behaviour. Separating those responsibilities helps avoid treating a technical success as proof that the content decision was correct.

Where search performance informs the review, include the relevant evidence without using it as the only decision rule. Bizfront’s SEO services emphasize the pages and searches that matter to the business. A low-volume page can still deserve attention if it serves a valuable, specific customer need.

Define a small set of migration invariants

Write down the conditions the launch must preserve. For a typical service website, these might include keeping the agreed priority pages reachable, retaining essential service information, and ensuring that existing marketing destinations continue to lead to relevant offers.

Make each condition testable. “Protect SEO” is too broad for an acceptance check. “The old repairs URL resolves to the approved repairs destination, which contains the agreed service explanation and a working enquiry route” is something a reviewer can verify.

Use these conditions to prioritize testing when the inventory is large. Every mapping still needs review, but a broken route into a priority service may require more immediate attention than a low-value archival resource.

For projects involving Bizfront’s website planning and development, agree on these migration conditions as part of the scope. The service page describes the overall planning-to-launch process; the specific URL requirements should be made explicit for the website being replaced.

Test an old link as a customer would use it

Automated checks can identify response behaviour, but the customer’s task continues after the redirect. Open representative old links in a browser and review the resulting page with its actual content.

Start with links used in advertising, proposals, sales emails, and important external references. Check the page title, the service explanation, and the next step. If a visitor was promised a guide, a redirect to a general homepage may be technically functional while failing the expectation created by the original link.

Also test links with the query parameters your marketing uses. Confirm that the intended page still loads and that the application handles those parameters according to the agreed design. Do not assume all tracking or campaign URLs behave identically to the clean path.

Record the result in the map or a linked test log. The combination of automated status checks and a small number of realistic customer journeys provides a clearer picture than either alone.

Keep commercial context in technical prioritization

Developers may see a set of URLs where the business sees different services, customer groups, and opportunities. Ask the project owner to identify those distinctions before launch.

The service-page work described in Bizfront’s client case studies illustrates why this matters. A page may exist because the business wants more of a particular type of work, not simply because the site needed another navigation item.

That context can influence the order of verification and the response to a fault. If a priority advertising destination is wrong, the team may need to correct the page and review active campaign links immediately. If an outdated informational resource has no appropriate replacement, the decision may be to retire it deliberately.

Technical consistency still matters across the whole site. Commercial context helps the team recognize which failures interrupt the most important journeys and communicate their consequences clearly.

Prepare for corrections without losing the decision history

Launch reviews sometimes reveal omissions even after careful planning. Decide how corrections will be recorded, reviewed, deployed, and retested so the map remains an accurate description of the live site.

Avoid making a series of undocumented one-off changes in the hosting interface. When practical, retain the relevant configuration and the reason for the correction in the project’s normal change process.

A clear record reduces the chance that a later update reintroduces the problem. It also gives the next person maintaining the website enough context to understand why a redirect exists instead of removing it because the original page is no longer visible in the content system.

Make migration part of the project scope

The URL plan connects design decisions to existing customer and search journeys. It is easier to manage when page structure, content, and technical implementation are discussed together.

Bizfront’s website design process describes planning the messaging and pages before the build and testing before launch. When a project replaces an existing site, teams should explicitly agree how URL inventory, migration, and monitoring fit into that scope.

A redirect map is a small deliverable with a clear purpose: every important old address receives a deliberate outcome. Build it while the structure is being decided, review it while changes are still inexpensive, and use it as a testable record when the new website goes live.