Website Redesign and SEO: URL Map, Launch Plan and Checklist

A website redesign should preserve the pages people already find, keep their purpose clear and prove that the new site works before it replaces the old one. Start with an inventory and a dated baseline, then make an explicit decision for every URL: keep it, redirect it to a relevant replacement or retire it. A visual refresh does not require a new URL structure.

Search rankings can change even when a migration is carefully managed. The practical goal is to prevent avoidable failures, identify changes quickly and give someone authority to fix or reverse a broken release.

Download the Website Migration Plan Template

Download the editable migration workbook (.xlsx).

The workbook has reusable Plan template and URL template tabs, alongside a populated Example plan and Example URLs. The example is a deliberately fictional English/Lithuanian service business called Birch Studio. Its reserved .example addresses do not represent a live website, and its simulated evidence references are teaching examples. Some checks remain open so that the launch decision stays on hold.

For a text-based workflow, download the plan and example data (.json), blank URL register (.csv), example old-site inventory (.csv) and example destination inventory (.csv). Read the download instructions.

Use the two example inventories in our SEO Migration Redirect Mapper to practise reviewing matches. Replace the fictional addresses with your own before running live checks. The mapper helps propose and validate URL decisions; the workbook records who approves them, what each test covered and what remains unresolved.

1. Decide What Is Changing

Separate the design decision from changes to the platform, domain, content and URL structure. Combining all of them makes a fault harder to isolate. Google’s site-move guidance, checked on 28 October 2026, recommends sequencing major changes and allowing for temporary search fluctuations.

A hosting move with unchanged public URLs has its own Google preparation and monitoring guidance. Test the new infrastructure before switching traffic, retain access to the old host while needed and confirm that forms, files and verification survive the move.

If the platform is also changing, use our WordPress to Astro scope, cost and checklist guide for the platform-specific inventory and editing decision. This article’s workbook is framework-neutral.

2. Record a Baseline That You Can Compare Later

A sitemap is a useful starting point, but it is not a complete history of the site. Add the CMS export, a crawl, important landing pages, known external-link targets, existing redirect rules and media/download URLs. Record which source contributed each address. Keep pages with no recorded traffic when they still serve customers or a business requirement.

Before development, save:

• A dated URL inventory with response codes, titles, canonicals, indexability and language relationships.
• Search Console exports with the property, search type, filters, date range and data state recorded.
• A list of important tasks: submit an enquiry, call, book, pay, download or publish content.
• Representative performance tests with the page, device profile, tool and date.
• Current hosting, domain, source-code and integration access, plus a tested recovery point.

Search Console clicks describe Google search clicks. Analytics sessions and recorded enquiries measure different things. Preserve the existing consent and event definitions when comparing before and after, and record any intentional measurement changes.

In the workbook, the baseline register asks for an evidence reference, owner and capture date. A blank export or an untested inbox is an open task, even if the new design looks finished.

3. Give Every Old URL a Decision

Keep an address when its purpose still fits. A new design, CMS or framework can usually serve an existing path. When the content genuinely moves, Google recommends a permanent server-side redirect, normally HTTP 301 or 308.

Do not automatically send unrelated deleted pages to the homepage. Google’s site-move guide warns that irrelevant redirects can be treated as soft 404s. It also recommends maintaining migration redirects generally for at least a year, and using Search Console’s Change of Address for domain or subdomain moves, rather than ordinary same-domain path changes.

The URL register records the old URL and title, language, template, inventory source, decision, destination, rationale, owner, dependency, expected response, observed response, expected canonical and evidence. Review bilingual pairs individually. An English service page and its Lithuanian translation need separate working URLs; their relationship does not make one a replacement for the other.

Review the mapper’s suggestions before exporting redirect rules. Similar slugs are a clue, not proof that two pages answer the same need. Check media URLs, parameters and earlier redirects as well as the current navigation.

4. Test Templates and Important Pages

A shared template can spread a fault across many URLs. Test every distinct template, then check all high-priority pages and changed destinations. Record the size and limits of any sampled review.

Remove staging-only access restrictions or noindex rules from the intended public release. Keep protections on staging itself. Check the actual production response after deployment; a correct preview does not prove production has the same configuration.

For a brochure site with no checkout, record “not applicable” with a reason. Do not mark an untested checkout as not applicable merely because testing is inconvenient.

5. Use a Launch Gate With Named Owners

The workbook separates doing a task from approving the release. Each required task needs an owner, dependency, deadline, result and evidence reference. Its launch decision stays on hold while required tests or release gates are unresolved.

Before cutover, the release owner should be able to confirm:

1. Every known old URL has a reviewed outcome, including intentional removals.
2. Required page, language, media and customer-flow tests are complete.
3. The production deployment, DNS and redirect changes have an accountable operator.
4. A recovery point has been tested and the rollback decision belongs to a named person.
5. Someone will check the public site immediately after the switch and handle any failure.

Freeze or coordinate content edits during the final copy. A store or booking system also needs a plan for writes that happen during cutover. Reverting the website code must not silently overwrite new orders, enquiries or bookings with an older database.

6. Write Rollback Actions Before You Need Them

“We have a backup” leaves several questions unanswered. Record the restore point, exact action, access owner and conditions for using it. A frontend deployment rollback, a DNS reversal and a database restore are different actions with different consequences.

Useful triggers are observable: a required form sends to the wrong recipient, checkout fails, key old URLs return server errors, or the public release still blocks intended pages. Agree the site’s critical paths and tolerances before launch. A routine ranking fluctuation by itself does not identify a broken release.

The template asks how to preserve new data. If customers can place orders after launch, do not restore an old database without first reconciling those writes. For a code-only fault, reversing the deployment may be enough. Re-test the customer journey after any recovery action and record what was restored.

7. Monitor at Launch and at 7, 14 and 28 Days

The workbook includes review dates calculated from your planned launch. These are a useful operating schedule, not a promise that Google will finish processing the move in 28 days.

At launch, check public responses, changed redirects, forms, downloads, key pages and measurement. In later reviews, add Search Console indexing and performance evidence, server errors and the business’s actual enquiry or order records. Compare the same page groups and languages, and account for seasonality, consent changes, new content and incomplete recent data.

Keep a row for each finding with an owner and next action. A total can hide a lost service page. A page absent from a filtered export is not automatically a page with zero impressions. Continue monitoring unresolved issues beyond the first month.

What Our Published Migrations Show

Our five-site migration results show why release checks and search outcomes belong in separate columns. The published record says every site kept its domain and the URLs that brought visitors; changed addresses were redirected. Yet individual pages still lost visibility.

Wellington House Repiling became faster in its saved mobile lab tests, while Search Console clicks for 1 July to 17 October fell from 297 in 2025 to 270 in 2026. The saved lab screenshots do not show capture dates. Gridinta’s search growth accompanied continuing content and SEO work. These observations cannot isolate a platform effect or forecast your redesign’s rankings.

The useful lesson is operational: preserve the inventory, date the evidence, check individual pages and keep testing the actions customers need.

If you want us to review your current site and migration scope, see our website redesign service or Get my free website audit. We reply within 24 hours. Audits arrive within 48 hours.