A website redesign SEO checklist belongs at the beginning of the project, not the night before launch. By then, decisions about page removal, navigation, URLs, and content structure may already be difficult to reverse. Search visibility is easier to protect when the migration is part of the brief.
The aim is not to freeze an outdated website. It is to understand which existing assets matter and make deliberate changes. Better navigation, clearer service pages, and faster templates can be worthwhile, but a visual refresh does not automatically compensate for missing content or broken destinations.
Before design: inventory the current site
Collect current URLs from the sitemap, a crawl, analytics, Search Console, and known campaign links. Include downloadable resources and older project URLs that may not appear in the current menu. Record each page's purpose, traffic evidence, meaningful backlinks if available, and proposed future destination.
Do not preserve a page solely because it exists, but do not delete it solely because it looks old. A plain service explanation may answer a valuable question. A neglected campaign page may still receive enquiries. Decide whether to retain, improve, merge, or retire each important URL.
Map URLs before changing navigation
Keep a working URL when there is no strong reason to change it. When a page moves, map it directly to the closest genuinely equivalent destination. Avoid sending every old page to the homepage: that may be convenient technically but unhelpful to the person following a specific link.
Google's site-move documentation recommends preparing URL mapping, implementing permanent redirects, and monitoring the move. Redirects do not make an unrelated replacement equivalent. If no replacement exists, a correct missing-page response may be more honest than a misleading redirect.
Preserve meaning, not just metadata
Copying the old title into a new template is not enough if the visible page no longer explains the service. Review the main heading, supporting details, images, internal links, and call to action together. Keep the information a qualified visitor needs to decide what to do next.
For example, replacing several detailed service pages with one short “What we do” section may simplify the design while removing useful answers. A better solution can be a concise overview that still links to distinct service pages. See the difference between interface polish and user experience when evaluating that trade-off.
Test staging as a complete product
Protect unfinished staging with appropriate access controls. Before launch, test navigation, forms, page metadata, redirects, media, and structured data. Confirm that generated canonical URLs do not point to the staging host or incorrectly point every page to the homepage.
Use a written launch checklist rather than relying on memory. An owner should sign off the content, a developer should verify behavior, and someone should check the mobile journey. Automated checks are valuable, but they should accompany an actual enquiry-flow test.
Launch with a recovery route
Back up the application, assets, and database using a method suitable for the hosting environment. Know which release can be restored and whether rolling back code would conflict with database changes. Separate deployment from publishing content so a rushed release does not overwrite live enquiries or editorial updates.
After deployment, check the real public URLs rather than only the origin server. Reverse proxies, caches, HTTPS rules, and domain redirects can behave differently in production. Verify representative old URLs, attribution parameters, sitemap destinations, and the contact form.
Monitor pages, not just the traffic total
Compare indexed pages, queries, landing pages, and successful enquiries over a meaningful period. Allow for reporting delays and normal variation. A traffic change might reflect seasonality, changed demand, or a tracking issue rather than the redesign alone.
Keep the URL map after launch and use it to investigate specific losses. If one service page loses visibility, inspect its content, canonical, links, and response before replacing the entire design. A controlled investigation is more useful than repeated site-wide changes.
Common questions
Will a redesign guarantee more organic traffic?
No. A redesign can remove technical and usability problems, but demand, content quality, competition, and execution still matter. No responsible checklist can promise a ranking.
Should I change the platform and all URLs together?
Only when the project requires it. Combining many changes increases the number of things to verify and makes causes harder to isolate.
Use the broader technical SEO checklist alongside this plan. For a redesign with content and migration considered together, explore website redesign services or share your current site and goals.