---
title: "Website Redesign and SEO: URL Map, Launch Plan and Checklist"
description: "Plan a redesign around existing URLs, content and customer journeys. Download an editable migration workbook with owners, launch checks and rollback."
canonical_url: "https://webaloha.co/website-redesign-without-losing-seo/"
markdown_url: "https://webaloha.co/website-redesign-without-losing-seo.md"
date_published: "2026-10-28T00:00:00.000Z"
date_modified: "2026-10-28T00:00:00.000Z"
author: "https://webaloha.co/authors/lucky-oleg/"
---
# Website Redesign and SEO: URL Map, Launch Plan and Checklist

Author: [Lucky Oleg](https://webaloha.co/authors/lucky-oleg/) | Published Oct 28, 2026

**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)](https://webaloha.co/downloads/website-migration-plan/website-migration-plan.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)](https://webaloha.co/downloads/website-migration-plan/website-migration-plan.json), [blank URL register (.csv)](https://webaloha.co/downloads/website-migration-plan/url-map-template.csv), [example old-site inventory (.csv)](https://webaloha.co/downloads/website-migration-plan/example-old-urls.csv) and [example destination inventory (.csv)](https://webaloha.co/downloads/website-migration-plan/example-new-urls.csv). [Read the download instructions](https://webaloha.co/downloads/website-migration-plan/README.txt).

Use the two example inventories in our [SEO Migration Redirect Mapper](https://webaloha.co/tools/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](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes), checked on 28 October 2026, recommends sequencing major changes and allowing for temporary search fluctuations.

| Change | Planning question | Evidence before launch |
| --- | --- | --- |
| Visual redesign | Can the existing URLs and useful content stay? | Old/new page comparison using real content |
| CMS or framework | How will editors, forms and integrations work? | Editor publishing test and complete customer journeys |
| URL structure | Which moves are necessary? | Reviewed source-to-destination map |
| Domain | Who controls both domains and their verification? | DNS, HTTPS, ownership and redirect checks |
| Hosting only | Can the same public addresses serve the same content? | New-host tests and a reversible traffic switch |

A hosting move with unchanged public URLs has its own [Google preparation and monitoring guidance](https://developers.google.com/search/docs/crawling-indexing/site-move-no-url-changes). 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](https://webaloha.co/wordpress-to-astro-migration-scope-cost-checklist/) 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](https://developers.google.com/search/docs/crawling-indexing/301-redirects), normally HTTP `301` or `308`.

| Decision | Example | What to verify |
| --- | --- | --- |
| Keep | `/contact/` remains the contact page | The same URL returns the intended page directly |
| Redirect | An old service page moves to a clearer service URL | The source goes directly to that equivalent page |
| Consolidate | Two overlapping guides become one complete guide | The replacement answers the purpose of both sources |
| Retire | An expired event has no useful replacement | The intended 404/410 is deliberate and internal links are updated |

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.

| Area | Acceptance check | Evidence to keep |
| --- | --- | --- |
| Content | Main text, headings, meaningful images and downloads survive | Old/new comparison and approved exceptions |
| Crawl access | Intended public pages are reachable and indexable | HTTP, robots and HTML/header inspection |
| Canonicals | Each intended indexable page declares the correct destination | Rendered HTML or header capture |
| Languages | Translated URLs, navigation and reciprocal language links agree | Pair-by-pair review for each published language |
| Internal links | Links point to final public URLs | Crawl report and resolved exceptions |
| Forms and booking | Submission reaches the right recipient and confirms success | Test reference from both the browser and destination |
| Commerce | Required cart, payment, order and notification flows work | Agreed test-environment transaction evidence |
| Analytics and consent | Events follow the agreed consent state and definitions | Network/event evidence and measurement notes |
| Editing | An authorised editor can preview, publish and correct content | A completed editor task and handover notes |

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](https://webaloha.co/wordpress-to-astro-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](https://webaloha.co/website-redesign-services/) or [Get my free website audit](https://webaloha.co/free-website-audit/). We reply within 24 hours. Audits arrive within 48 hours.

## Frequently asked questions

Can I redesign a website without losing SEO?

You can reduce avoidable losses by keeping useful URLs and content, mapping necessary URL changes, checking crawl access and testing the production site. No redesign can guarantee unchanged rankings. Record a baseline and review individual pages after launch.

Do I need redirects if my website design changes?

A visual change alone does not require redirects. Keep an existing URL when it still serves the same purpose. When a page moves permanently, send its old URL directly to the relevant replacement with a permanent server-side redirect.

What is in the website migration plan template?

The editable workbook contains reusable plan and URL-register tabs, plus a populated fictional English and Lithuanian service-site example. It covers baseline evidence, template owners, dependencies, acceptance tests, launch gates, rollback and 7-, 14- and 28-day reviews. Separate CSV files work as URL inventories in our redirect mapper.

Should every deleted page redirect to the homepage?

No. Choose a replacement that satisfies the old page's purpose. Where there is no useful replacement, an intentional 404 or 410 can be appropriate. Record the decision rather than redirecting unrelated pages to the homepage.

How long should migration redirects stay in place?

Google recommends keeping site-move redirects for as long as possible, generally at least one year. Useful old links may justify keeping them longer. Keep the domain and infrastructure needed to serve them.

Is the migration workbook a real client project?

No. Birch Studio, its reserved .example domain, people, dates and evidence references are deliberately fictional. The example includes open checks to show why a populated plan is not automatically approved for launch.

Recommended tools

## Recommended tools for this guide

Use these free tools to apply the ideas from this guide to your own website.

[![HEX RGB HSL Color Converter Tool Online](https://webaloha.co/_astro/tool-color-converter.CqO9sl9t_1KACKl.webp?dpl=dpl_361ezMzWCgtUtFxFQVMru9SddmJo)

Color Converter

](https://webaloha.co/tools/color-converter/)[![Favicon Generator Tool Online](https://webaloha.co/_astro/tool-favicon-generator.CJJwaINN_nR6HT.webp?dpl=dpl_361ezMzWCgtUtFxFQVMru9SddmJo)

Favicon Generator

](https://webaloha.co/tools/favicon-generator/)[![Image Compressor & WebP Converter Tool Online](https://webaloha.co/_astro/tool-image-compressor.BZRx6f1H_1V4b5Y.webp?dpl=dpl_361ezMzWCgtUtFxFQVMru9SddmJo)

Image Compressor

](https://webaloha.co/tools/image-compressor/)

Useful info? Spread the Aloha:

[![Lucky Oleg](https://webaloha.co/_astro/lucky-oleg.EPOIIvwX_ZX2S03.webp?dpl=dpl_361ezMzWCgtUtFxFQVMru9SddmJo)](https://webaloha.co/authors/lucky-oleg/)

[Lucky Oleg](https://webaloha.co/authors/lucky-oleg/)[](https://www.linkedin.com/in/luckyoleg/)

Lucky Oleg is the founder of Web Aloha, a web design & SEO agency helping businesses ride the digital wave. With years of experience in WordPress, technical SEO, and web performance, he writes about what actually works in the real world.