The safest website redesign is not the one that keeps every old page forever. It is the one that makes deliberate choices about the pages, links, content, and customer journeys that still matter. A visual refresh with unchanged URLs needs less migration work than a new domain or site structure, but both deserve a clear plan.

This checklist is for business owners, marketing teams, and the people building the new site. Treat the target queries as planning assumptions, not a promise of traffic or ranking gains. Google’s site-move guidance recommends preparing a URL map, using permanent redirects when URLs change, testing them, and monitoring the move.

Before the redesign: set a baseline

Start before the new navigation and page list are final. A baseline helps the team distinguish an intentional content change from a page or measurement path that was accidentally lost.

  1. Collect the current URLs. Export or crawl the live pages, including important service pages, articles, location pages, campaign landing pages, and files that receive links. Include URLs from the current sitemap, Search Console, analytics landing-page reports, and any backlink list you already maintain. No single source is a complete inventory.
  2. Mark what each page does. Note its purpose, audience, calls to action, and whether it supports enquiries, bookings, sales, or an important customer question. Flag pages with organic impressions or clicks, conversions, useful links from other sites, or links from within your own site.
  3. Save a measurement snapshot. Where the data is available, record a representative period of search queries, landing pages, organic visits, and lead actions. Include the date range and any seasonal context. Save key technical settings too: canonicals, indexability, analytics events, forms, and the current sitemap.

Do not use traffic alone as the keep-or-delete test. A page may have low visits but still answer a decision-stage question, receive a valuable referral, or help a customer complete a task.

Plan the page and URL changes

Keep an existing URL when it still serves the same purpose and there is no strong reason to change it. When the page or URL must change, write the destination down before the new site goes live. A simple spreadsheet can prevent last-minute redirect guesses.

  • Keep: the page stays useful; preserve its URL and carry over the important content, links, and search settings.
  • Move: the page has a clear equivalent at a new URL; map the old URL directly to that destination with a permanent server-side redirect.
  • Combine: two pages now serve one stronger page; map each old URL to the most relevant new page and preserve the useful information customers came for.
  • Retire: the page is genuinely obsolete and has no suitable replacement; serve an honest not-found response instead of sending every retired URL to the homepage.

For each URL, record the old address, chosen action, new destination if there is one, redirect owner, and test result. Avoid redirect chains that send an old URL through a temporary URL before reaching the new one. Make sure redirects lead to relevant pages. Update navigation, body links, canonical tags, and other internal references to use the final destination directly.

Protect useful content and page meaning

A new design system can tempt a team to shorten every page or combine sections before understanding what they contribute. Review the substance page by page: service details, product names, customer questions, locations served, useful examples, and the next step a visitor needs. If content is out of date, improve it; do not remove useful information just because it does not fit the first visual draft.

Give every important new page a clear purpose and a distinct title, main heading, description, and internal links. Carry over accurate image descriptions and relevant structured data, then validate that structured data describes the new visible page rather than the old layout. Keep one preferred canonical URL for each indexable page.

For an example of a storefront organized around product collections and the brand story, see the Sugar Plum Scrubs project. It illustrates content and design decisions; it does not claim a measured search result.

For the practical site-care work that continues after launch, see the small-business website maintenance checklist. If the redesign also raises questions about who owns updates, hosting, and handover, the managed website services guide outlines what to clarify.

Check the new site before it is public

Use a staging environment that is not open to public indexing. Password protection is usually a clearer safeguard than relying only on crawler instructions. Before launch, make a short list of what must change when the production site replaces staging.

  • Confirm staging pages are not intended to be indexed, and that production pages will not inherit a staging-only block or noindex directive.
  • Check that important pages return the expected response, have the intended canonical URL, and can be reached through normal internal links.
  • Review titles, descriptions, headings, navigation labels, mobile content, image text, and structured data on the actual templates as well as in the design file.
  • Test search, menus, forms, booking or checkout, confirmation messages, and the destination where enquiries are received.
  • Check analytics and conversion events in a safe test flow. Record which events you expect and verify they still fire after the new templates and consent settings load.
  • Ask someone unfamiliar with the build to complete the main customer task on a phone and desktop. Note confusing steps, not just visual polish.

Where Google Search Console is available, verify the relevant site properties and use the URL Inspection tool to check important URLs. It reports what Google knows about an individual URL; it is not a substitute for testing the full URL list.

Launch-day website redesign SEO checklist

Choose an owner for the launch checks and keep the old-to-new URL map open while testing. For a larger move, split the work across development, content, analytics, and whoever can approve rollback.

  1. Publish the approved production site and confirm that important pages load over the preferred HTTPS host.
  2. Remove staging-only password restrictions and search blocking from the public version; check that production is not accidentally set to noindex.
  3. Turn on permanent redirects for changed URLs and test representative examples from every page type, plus the highest-priority individual URLs.
  4. Open each redirect destination. It should load successfully, match the old page’s intent, and not create a redirect loop or a second hop.
  5. Submit a fresh XML sitemap containing only canonical, indexable URLs that return successfully. Google notes that a sitemap helps it discover URLs but does not guarantee indexing; see its sitemap guidance.
  6. Test internal links, contact and purchase paths, analytics events, and important mobile layouts on the live host.

If the project changes the domain, plan it as a domain move and follow Google’s specific Search Console steps for the old and new properties. A visual redesign or a move between paths on the same domain is not, by itself, a reason to use a domain-change tool.

Monitor the site after launch

Keep the redirect map and baseline for the follow-up period. Check the site immediately after release, then review it again over the following days and weeks. Search engines need time to recrawl changed pages, so avoid reacting to one short-term fluctuation without checking for a concrete technical problem.

  • Test the priority redirects again and look for unexpected 404s, server errors, loops, or destinations that no longer match the page.
  • Review Search Console indexing and crawl reports, URL Inspection results for key pages, and organic query or landing-page trends against the saved baseline.
  • Check that enquiries, bookings, or sales still arrive and that analytics records the intended conversion actions.
  • Update remaining internal links, business profiles, paid campaigns, email templates, and high-value external links when their URLs have changed.
  • Keep redirects in place. Google recommends maintaining them for at least a year after a site move; users with old bookmarks or links may need them longer.

When a redesign needs migration planning

Give the SEO work a named owner if the project changes the domain, URL structure, CMS, navigation, or a large set of pages. The same applies to stores, booking sites, multi-location businesses, and sites with substantial search or referral traffic. The owner does not have to do every technical task, but should know who is responsible for the content map, redirects, testing, analytics, and post-launch fixes.

Neon Media’s SEO service covers technical foundations, content priorities, and search measurement; the managed websites service describes ongoing site ownership. If you are planning a redesign, talk with Neon Media before the page structure is locked so the URL and launch checks can fit the actual project scope.

Quick checklist to copy into your project

  • Baseline recorded: priority pages, search/analytics data, technical settings, and key conversions.
  • Every old URL has a keep, move, combine, or retire decision.
  • Changed URLs have a relevant final destination and a tested permanent redirect where appropriate.
  • Important content, titles, canonicals, internal links, and conversion paths are preserved or intentionally improved.
  • Staging protections and production indexing settings are checked in both environments.
  • Live sitemap, analytics events, forms, redirects, and priority mobile journeys are tested.
  • An owner is assigned to review search visibility, errors, and enquiries after launch.

References