Website redesign planning guide: SEO, URLs, content, testing and launch.

A website redesign should improve the future site without accidentally discarding the value of the current one. That requires more than a design file. It requires an inventory, migration plan, technical constraints, testing criteria and a clear definition of what success looks like.

Start by defining what the redesign needs to fix.

A redesign can involve visual design, information architecture, copy, templates, performance, accessibility, conversion paths, content management and platform changes. Trying to improve all of these without priorities can create a larger project without creating a better website.

Write down the problems the current site creates for users and for the team maintaining it. Examples include confusing navigation, duplicate service pages, weak mobile layouts, slow templates, unclear calls to action, difficult editing or content that no longer matches the business. If those problems already point to structural rebuilding, Website Redesign Services explains the PWS project approach.

An eight-step redesign sequence.

1. Audit the current website before replacing it.

Start with evidence. Review analytics, Search Console, lead paths, top landing pages, indexed URLs, backlinks, performance data and the content the business still needs. A page that looks outdated may still rank, attract links or answer an important customer question.

The audit should produce a URL inventory with a decision for each meaningful page: keep, improve, consolidate, redirect or remove. This is also the time to identify duplicate topics that are competing with each other. For crawlability, indexability, canonical and status-code checks, use the Technical SEO Audit Checklist as a companion review.

2. Rebuild the content architecture around clear jobs.

Each important page should have a reason to exist. Service pages should explain the services offered. Case studies should provide proof. Insights should answer informational questions. Local landing pages should address genuine local needs. When multiple pages try to do the same job, the redesign can simplify the architecture rather than reproduce the overlap in a new design.

Navigation should reflect the final structure, not simply mirror the old menu. Internal links should help users move from education to proof and then to the related service when they are ready.

3. Plan SEO migration and URL changes before launch.

Whenever possible, keep established URLs that still make sense. When a URL must change, map the old address directly to the best new equivalent. Google describes redirects as a way to tell users and Search that a page has moved, and its site-move guidance recommends careful mapping and monitoring.

Avoid redirect chains such as old URL → temporary URL → final URL. The redirect plan should point directly to the final destination and be tested before launch.

References: Google site-move guidance ↗ · Google canonicalization guidance ↗

Plan URL changes and redirects before launch.

Keep established URLs when they still make sense. Changing addresses creates migration work and the possibility of broken links, lost history or redirect mistakes. When a URL genuinely needs to change, map the old address directly to the closest relevant new destination.

Google recommends permanent server-side redirects such as 301 or 308 for permanent moves. Avoid chains such as old URL → temporary URL → final URL. Build the redirect map before launch and test it against the final production destinations.

Reference: Google Search Central: Redirects and Google Search ↗

Check canonical URLs and duplicate signals.

Canonicals, redirects, internal links and XML sitemaps should reinforce the same preferred URLs. During a redesign, check that production pages are self-canonical where appropriate and that staging domains or legacy duplicate paths are not declared as preferred versions.

Google notes that canonicalization can consolidate signals across duplicate URLs. Treat that as part of the migration plan rather than a plugin setting to review after launch.

Reference: Google Search Central: Canonicalization ↗

Build accessibility into reusable components.

Keyboard focus, colour contrast, form labels, heading structure and responsive layouts are easier to solve once in a design system than to patch page by page later. W3C’s WCAG guidance applies to web content including text, images and interface components.

Test real mobile widths and keyboard navigation before launch. A redesign should reduce barriers, not introduce a more visually complex interface that is harder to use.

Reference: W3C: WCAG Overview ↗

4. Make performance and accessibility part of the design system.

A redesign is an opportunity to remove unnecessary complexity, but it can also introduce large videos, animation libraries, oversized images and third-party scripts. Set performance expectations early so visual ideas are evaluated alongside their cost.

Accessibility should be treated the same way. W3C’s WCAG guidance applies across desktop and mobile web experiences. Keyboard focus, contrast, text size, form labels and responsive behaviour are easier to build into reusable components than to patch later.

References: Google page-experience guidance ↗ · W3C WCAG overview ↗

Preserve forms, analytics and integrations.

Document contact forms, booking systems, CRM connections, ecommerce, analytics events, email delivery, consent tools and structured data before development. A redesign can look successful while quietly losing a business-critical integration.

Test the actions that create value. Submit forms, use booking flows, verify transactional email and compare analytics events before and after launch.

5. Build a launch checklist that reflects business risk.

Before launch, test more than the home page. Check navigation, mobile layouts, keyboard access, forms, email delivery, booking or checkout functions, analytics events, title tags, canonical URLs, robots settings, redirects, structured data and 404 behaviour. Confirm that staging protections such as noindex do not remain on production.

For high-value pages, compare the new version with the old one to ensure important content and internal links were not accidentally removed.

6. A redesign is not finished at launch.

After launch, monitor crawl errors, indexing, rankings, organic landing pages, conversions, PageSpeed and user feedback. Google notes that recrawling and reindexing can take time after changes, so the goal is not to panic at every daily fluctuation but to catch clear technical mistakes quickly.

Keep the pre-launch benchmark so you can tell whether the redesign is improving the metrics it was meant to change.

Create a pre-launch benchmark.

Before replacing the current site, save the information you will need to judge the new one. Record top organic landing pages, important query groups, lead or ecommerce conversion rates, Core Web Vitals, PageSpeed results, indexed URL counts and the performance of critical forms or booking paths.

Without a benchmark, teams can celebrate a new design without knowing whether search visibility, speed or conversions improved. The benchmark also makes post-launch troubleshooting more objective because you can distinguish an existing problem from a regression introduced by the redesign.

Use staging carefully.

A redesign should be built and tested away from the live site, but staging introduces its own SEO and content risks. Keep staging protected from indexing, verify that canonical tags and internal links are not pointing back to staging when production launches, and avoid leaving production forms or email integrations active where they could create duplicate notifications.

Before launch, run a specific “staging to production” checklist: domain references, robots directives, canonical URLs, analytics IDs, forms, cache/CDN settings, redirects, sitemap URLs and structured data.

Plan the content freeze and final migration.

When a site changes frequently, decide when content stops being edited on the old site and how the final changes will be moved into the new one. This is especially important for ecommerce, news-heavy sites and businesses that receive form submissions or bookings during the migration window.

Document the cutover sequence: final database/content sync, DNS or hosting changes, cache purge, redirect activation, form verification and post-launch crawl. A clear sequence reduces the risk that content created at the last minute disappears during launch.

Define a rollback threshold.

Before launch, decide what type of failure would trigger rollback or emergency remediation. A minor spacing issue can be fixed after launch; widespread 500 errors, broken checkout, missing redirects or an indexing mistake may justify more aggressive action.

Knowing the threshold in advance prevents launch-day decisions from being made under pressure.