Website Redesign Planning: Phases, a URL Migration Map, and Launch Checks
Published:
Last Updated:
Category: Marketing DX, Marketing Strategy
Authors: Shusaku Yosa
A website redesign is more than a new visual treatment. It should address a user problem, preserve useful information and entry points, and leave the team able to operate the result. Finished layouts do not establish launch readiness when legacy URLs, forms, permissions, or handover responsibilities remain unresolved. Connect the problem, phases, URL decisions, tests, and recovery arrangements in one plan.
Define the problem and how the redesign will be evaluated
Translate “the site looks old” into observable problems for visitors and operators. Examples include difficulty finding relevant service information, long copy-review waits, or a form users cannot complete. Separate observations from hypotheses about their causes. A decline in traffic alone does not prove that appearance or copy caused it.
Separate business goals from delivery conditions. More inquiries may be the business goal; a form behaving as specified is a testable acceptance condition. Advertising, seasonality, competitors, and sales handling can also affect outcomes. Delivery completion does not guarantee an increase in demand.
Problem | Evidence to gather | Possible decision | Evaluation condition |
|---|---|---|---|
Visitors cannot identify the right service | Observed tasks and questions | Revise information order and navigation | Repeat comparable user tasks |
Updates stall | Waits between drafting and review | Clarify roles and review steps | Compare the same workflow stages |
Forms are abandoned | Validation behavior and submission tests | Revise fields and error messages | Fix test and reporting definitions |
Record the audience, scope, budget, immovable dates, decision owner, and evaluation method at the start. Assign investigations and decision dates to unknowns. Use the evidence to decide whether a full redesign or a smaller improvement is appropriate.
Inventory pages and choose what to preserve or change
Inventory page purpose, owner, usage, update need, and migration decision as well as the title and URL. Include search landing pages, important explanations, support materials, and post-submission pages. Low traffic alone is insufficient reason to delete information that customers or operations still need.
Classify pages as retained, revised, consolidated, or retired. A consolidation destination must cover the information and purpose of the old pages. Excluding content from migration does not remove the need to decide what its old URL should do.
Include images, downloads, forms, external-service connections, and language variants. Client-supplied materials need an owner, date, and permission to use them. Page count alone does not describe the cleanup and verification effort. Search-history evidence can help prioritize review, but past impressions do not establish current index status or content quality. Distinguish analytics observations, technical checks, and hypotheses needing user research.
Set deliverables, owners, and launch gates by phase
Phase | Retained output | Example owner | Proceed when | Stop when |
|---|---|---|---|---|
Inventory and scope | Target list and decisions | Buyer owner | Retention, consolidation, retirement agreed | Scope and budget conflict |
Design and build | Approved structure, copy, implementation | Delivery lead | Requirements connect to tests | Mandatory behavior fails |
Migration tests | URL map and test evidence | Migration lead | Critical URLs, submissions, permissions pass | Critical misredirect or submission failure |
Launch and operations | Contacts and recovery steps | Launch decision owner | Stop and recovery rules agreed | No decision owner or usable recovery method |
A fictional small project might allocate weeks 1–2 to inventory, 3–4 to design, 5–8 to build, 9–10 to migration tests, week 11 to corrections and the launch decision, and week 12 to launch and initial checks. Copy preparation runs in parallel during weeks 3–8. The main allocation is 2 + 2 + 4 + 2 + 1 + 1 = 12 weeks; do not add the parallel copy period again.
This is not a standard lead time. It assumes review availability, supplied content, and assigned capacity. Rebuild the dates around actual dependencies, external answers, and approvals. Effort totals are not elapsed duration. Each phase needs a decision and evidence, not merely a document marked complete. If a mandatory condition remains unmet, defer launch or agree a scope change and its consequences.
Fill the URL migration map and update URL references
An unchanged URL does not need a redirect. A changed URL needs a relevant destination. These paths are fictional examples; check the new page’s successful response separately from the old URL’s redirect.
Old URL | Decision | New URL | Treatment | Check |
|---|---|---|---|---|
/service/ | Retain | /service/ | Keep 200 | Content and self-referencing canonical |
/case/a-old/ | Move | /cases/a/ | 301 or 308 to new URL; new URL returns 200 | Direct redirect, final URL, new canonical |
/guide/a/ and /guide/b/ | Relevant consolidation | /guides/complete/ | 301 or 308 to relevant combined page | Destination preserves both information needs |
/events/2023/ | Retire without replacement | None | 404 or 410 | Update internal links; no irrelevant redirect |
Google Search Central’s site-move guide covers URL mapping, permanent redirects, canonicals, internal links, applicable hreflang, and sitemaps. Use 404 or 410 for removed pages without a replacement. Avoid sending unrelated old pages to the homepage; this differs from consolidating relevant content into a suitable replacement.
Use self-referencing canonicals on destinations and update same-language internal links. Review corresponding hreflang where language alternatives exist, and list the new canonical URLs in the sitemap. Test unnecessary redirect chains and unintended reappearance of old paths. Google generally advises maintaining redirects for at least a year; user access and external links may justify longer retention. The Change of Address tool concerns domain-type moves, not path-only changes. None of these steps guarantees rankings or a fixed processing period.
Agree pre-launch tests and a recovery plan
Test relevant screens, valid and invalid inputs, submission destinations, permissions, migrated data, URL mappings, and supported environments. Record the tested version, evidence, owner, and unresolved items. A success message alone does not establish that a submission reached its intended destination.
A recovery plan needs more than the existence of a backup. Define what will be restored, from which point, by whom, using which access, and how it will be checked. Consider new inquiries and updates received after launch so a rollback does not silently discard them. Rehearse migration and recovery steps where feasible.
If a serious submission or permission failure stops launch, specify who receives the report and who decides. Minor display differences can sometimes be accepted with a recorded correction date, but do not redefine severity merely to meet the launch deadline.
Review crawl, search, and inquiry data on comparable terms
Immediately after launch, prioritize access to important pages, redirect destinations, forms, permissions, and errors. Then review crawling, search visibility, organic landing sessions, and inquiries as distinct series. Impressions, visits, submissions, and qualified inquiries measure different things.
For before-and-after comparisons, align duration, language, target URLs, search type, channel, country, and device where relevant. Use the URL map to distinguish changed reporting locations from changed usage. With small numbers, inspect absolute counts as well as percentages, and note seasonality or campaign changes. Do not label every ranking fluctuation normal or a failure. Investigate using evidence, and hand the inventory, URL map, open issues, change process, and next review date to the operating team.
For the next step, use Requirements Document Template: Examples, Acceptance Criteria, and Change Log; How to Build a WBS: A Deliverable-Based Example and Effort Totals Without Double Counting; Build a Gantt Chart in Excel or Google Sheets: Worked Table and Formulas.
