VanThunder Journal
Redesign 12 min read

Website redesign without guesswork: the SEO, content and launch checklist

A practical redesign plan from URL inventory to post-launch monitoring, with clear ownership, permanent redirects and measurable quality.

Marvin Schubert Author · strategy, development and SEO
Read the article ↓ 5 primary sources
Abstract 3D migration system connecting an old fragmented interface to a clean new system
AI-assisted editorial illustration, art-directed and reviewed by VanThunder · stored and served locally

Key takeaways

  • Inventory comes before visual design: URLs, search visibility, conversions, content and dependencies.
  • Every relevant replaced URL needs a deliberate destination and usually a permanent server-side redirect.
  • Launch is a controlled period of testing, rollout and monitoring—not a single calendar event.

01

Phase 1: keep, improve or intentionally retire

A redesign does not begin with a mood board. It begins with a list of existing URLs and the value each one currently provides. Export the sitemap, internal links, Search Console data, analytics entry pages and meaningful backlinks. Add the content type, owner and a decision for every URL: keep, consolidate, replace or remove.

Rankings are not the only criterion. A low-traffic page may support a high-value sales conversation; a popular page may be outdated and provide no useful next step. Review search demand, commercial relevance, accuracy and the intended journey together.

Sources: Google Search Central,

02

Phase 2: treat the redirect map as a product deliverable

When URLs change, Google recommends permanent server-side redirects such as 301 or 308. The destination should be meaningfully equivalent. Redirecting every old page to the home page is not useful to visitors and may be treated as a soft 404. Build an explicit old-to-new map and test every row automatically, with browser spot checks.

Avoid chains. If A used to redirect to B and B has been replaced by C, point A straight to C. Update internal links, canonicals, hreflang references and the sitemap to the final URLs. Google recommends keeping site-move redirects in place for at least a year.

  • Test status code and final destination
  • Eliminate redirect loops and avoidable chains
  • Point internal links directly at the new URL
  • Use only final URLs in canonicals, hreflang and sitemaps

Sources: Google Search Central,Google Search Central,Google Search Central

03

Phase 3: prove quality before launch

Build a launch matrix rather than a loose list. Test content, metadata, forms, analytics, consent, keyboard access, responsive behaviour and performance for every page type. Critical paths—enquiry, purchase, application or booking—need real end-to-end tests on narrow screens and modest hardware, not only a designer’s desktop.

Explicit performance thresholds are more useful than intuition. Core Web Vitals classifies a good experience as LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less at the 75th percentile of real visits. Lab tests are valuable before launch; field data shows what people actually experience.

Sources: web.dev,

04

Phase 4: actively manage the first 30 days

Immediately after rollout, re-check indexability, robots.txt, sitemap, canonicals and structured data. Watch server errors, 404 requests, redirect destinations and form events daily, then weekly. In Search Console, movements by page, query and indexing reason matter more than one daily total.

Keep the old crawl, redirect map and baseline metrics. When something changes, you can then distinguish a missing URL from broken analytics or shifting demand. A redesign is complete when the new system can be measured and operated—not when DNS changes.

Sources: Google Search Central,Google Search Central

Conclusion

The safest redesign gives every important URL, conversion path and measurement signal an owner. Strong visual design creates value only when the technical and editorial transition is controlled.

Editorial responsibility

Written by
Marvin Schubert
Professionally reviewed by
Marvin Schubert
Published
Last substantive update
Sources checked through
29 July 2026
Read the full editorial standards →

AI disclosure

Researched and structured with AI assistance; professionally reviewed and editorially revised by Marvin Schubert, then verified against the linked primary sources.

Change history

· Initial publication; arguments, recommendations and sources reviewed before release.

Apply the article to a real project.

We turn the principles into a clear scope, design system and measurable implementation.

Discuss your project