Website Redesign: A URL Migration Checklist Before You Launch

Before launching a redesigned website, decide what happens to every important existing URL. Keep useful addresses where possible, map changed pages to relevant replacements, test the redirects, and update links and search signals. Assign someone to check the live release. A new visual design is not a migration plan, and a migration plan cannot guarantee unchanged rankings.

This guide is for business owners, museum teams, and event companies approving a redesign. The goal is a concrete handover: someone following an old link should reach the right information, and your team should know how to investigate when they do not.

First, define what is actually changing

Our recommendation is to separate the design brief from the address-change brief. A new typeface, layout, or content management system does not automatically require new page addresses. Ask the team to identify which URLs must change and why.

Use three categories in the kickoff meeting: pages keeping their addresses, pages moving or merging, and pages being retired. Add a separate decision for any domain change. That prevents a visual approval from silently becoming approval to delete a useful archive.

For example, a fictional museum might redesign its exhibition pages while preserving the permanent address of each past exhibition. An event company might combine two overlapping service pages into one detailed replacement. These are planning examples, not Roar client results.

Build a URL map that a non-developer can review

Make the map a shared project deliverable. We recommend one row per old address, with the intended destination, the reason for the decision, an owner, and a test result. Include a notes field for exceptions such as downloadable brochures or links printed on physical signs.

Google recommends gathering existing URLs from sources such as sitemaps, analytics, server logs, and link reports, then mapping them to their destinations. Its migration guidance also includes embedded assets in the move plan. Google's site-move guidance.

Our review questions for each row are:

• Does the destination answer the same visitor question?
• Is important information missing from the replacement?
• Is this address used in a campaign, confirmation email, QR code, or partner listing?
• Who can approve retiring it?
• What should the tester see after following the old link?

Do not leave the destination column as “new website.” Write the exact address. That small discipline makes the plan testable and exposes unresolved content decisions before launch day.

Give moved pages relevant destinations

For a permanent move, Google recommends a server-side permanent redirect where possible; HTTP 301 and 308 identify that kind of move. A redirect is also a canonicalization signal, rather than a promise that the destination will rank. Google's redirect documentation.

Avoid sending every retired address to the homepage. Google warns that irrelevant destinations may be treated as soft 404 errors. Redirect directly to the final destination where possible, and keep migration redirects for at least a year in general. Site-move recommendations.

Our acceptance test includes both the response and the meaning of the page. A technically working redirect from an exhibition archive to a generic ticket checkout still deserves editorial review. A visitor looking for information about a past exhibition should not have to guess why they landed on today's ticket selection.

If there is no relevant replacement, ask the developer to document the removal behavior explicitly. Do not invent a destination just to make a spreadsheet appear complete.

Prepare a launch checklist, not just a screenshot review

Our suggested approval package has four parts: the URL map, a content review, a journey test, and a rollback plan. Name the person responsible for each part. A designer can approve the visual work while a developer verifies routing and an operations owner checks where inquiries arrive.

For search-related configuration, Google's move guide calls for updated internal links, canonical annotations, and removal of temporary indexing restrictions intended only for development. Google's migration checklist.

The sitemap should list the full, preferred URLs you want considered for search. Keep it aligned with the released site rather than copying an old export. Google's documentation explains the supported formats and URL requirements. Building a sitemap.

Our practical launch review also asks the team to:

• Open an old campaign link from outside the site's navigation.
• Follow a museum exhibition or event service page through to its intended action.
• Verify important downloads and externally hosted booking links.
• Send a clearly labeled test inquiry and confirm receipt with its owner.
• Check the experience on a phone as well as a desktop.
• Record the release time and the version that can be restored if a critical journey breaks.

Keep those checks separate from visual preference. A page can look excellent and still lead to the wrong service, an outdated PDF, or an unmonitored inbox. Our accessible booking checklist covers interaction testing in more detail.

Decide what to watch after launch

We recommend a short release log with an owner and a review date for every unresolved issue. Save a pre-launch baseline for important landing pages and completed inquiries, using the reporting tools you already have. Compare equivalent periods and record campaign changes so the team does not attribute every fluctuation to the redesign.

When a problem appears, start with one example. Record the entry URL, the expected destination, the actual result, and whether the issue affects a real visitor task. This is more useful to the delivery team than “SEO dropped” without an affected page or date.

Treat search discovery, indexing, rankings, and completed inquiries as different observations. A working live page does not prove it is indexed, and an indexed page does not prove it produces leads. If performance changes, use our PageSpeed troubleshooting guide to investigate that separately.

Frequently asked questions

Does every redesign require redirects?

No. If an address stays the same, it does not need a migration redirect simply because its design changes. Concentrate the mapping work on changed and retired addresses, then verify that unchanged pages still work.

Can we redirect all old pages to the homepage?

That is a poor default. Choose a relevant replacement for each moved page. When none exists, make a deliberate removal decision with the content owner instead of hiding it behind a catch-all redirect.

Who should own the migration spreadsheet?

We recommend one project owner who keeps it current, with content decisions approved by the business and routing tested by the technical team. The spreadsheet should remain available after launch, not disappear with the proposal.

Will this checklist prevent every search traffic drop?

No. It is a way to reduce avoidable launch mistakes and make diagnosis easier. It does not guarantee rankings, indexing, or inclusion in AI answers. Agree on monitoring and response responsibilities rather than a promise that nothing will fluctuate.

What should we bring to a redesign discussion?

Bring the current domain, access to your page inventory and reporting, the journeys that matter most, and any planned domain or platform change. Roar Creative and Viva can discuss the visual and development scope together. Explore our services or start a conversation.