Search Engine Optimization

SEO checklist for a website relaunch: before, during and after the switch

Updated 10 min readBy Davinder Kumar Meen

Orange and white blocks forming a grid of crossing lines on a dark navy background

A relaunch keeps its search traffic when every page that mattered on the old site still exists on the new one, at the same address or behind one permanent redirect to its closest equivalent, with its title, canonical, structured data and internal links intact, and when nothing left over from staging (a noindex, a robots.txt block, a password) reaches the live site. Check that in three passes: an inventory and URL map before you build, a scripted comparison on staging, and eight weeks of monitoring in Search Console after launch. Google's own guidance is to "expect temporary fluctuation in site ranking during the move" when URLs change, so the safest relaunch is the one that changes the fewest URLs.

Key takeaways

  • Build the URL inventory from three sources (the sitemap, the CMS and a full crawl), mark every URL keep, redirect or retire, and save it. Google recommends permanent redirects (301 or 308) "for as long as possible, generally at least 1 year".
  • Do not redirect many old URLs to the home page. Google says redirecting to an unrelated page "can confuse users and might be treated as a soft 404 error".
  • Protect staging with a password, not with robots.txt or noindex; then you have nothing to forget on launch day.
  • After launch, Google "will temporarily crawl your new site more heavily than usual", and for a small or medium site "it can take a few weeks for most pages to move". Watch Search Console weekly for at least eight weeks.

What usually goes wrong in a relaunch?

Most traffic losses after a redesign or platform move come from a short list of mistakes, none of them about design:

  • URLs changed with no redirects, or with redirects that all point to the home page.
  • A noindex tag or a Disallow: / line copied from staging to the live site.
  • Canonical tags still pointing at the staging domain or at old URLs.
  • Titles, meta descriptions and structured data dropped because the new templates do not output them.
  • Internal links still pointing at old URLs, so every click goes through a redirect.
  • Analytics, tag manager and consent missing for the first weeks, so nobody can see the drop.
  • Forms that work on staging but fail on the live domain.

Before you build: what should we capture?

An inventory you can compare against later. This is the step people skip, and it is the one that makes everything else checkable.

  1. Every public URL. Combine the XML sitemap, an export from the CMS (pages, posts, products, categories, tags, media) and a full crawl. Each source finds URLs the others miss.
  2. The SEO head of every URL: title, meta description, canonical, robots meta, Open Graph tags, hreflang if you use it, and every block of JSON-LD structured data.
  3. Existing redirects, from the server, the CMS and any redirect plugin. They have to survive the move too.
  4. A baseline from Search Console and analytics: clicks, impressions and top queries by page for the last three to six months, and sessions and key events by landing page. Export them; this is what you compare against after launch. Our Search Console guide explains which reports to export.
  5. Pages that earn links. Google's site-move guidance suggests saving "a list of sites linking to your old URLs" so you can ask the most important ones to update.
  6. Everything that is not a page: forms, feeds, search, downloads, tracking tags, consent banner, third-party scripts, integrations.

Then build the URL map: one row per old URL, with a decision.

Decision When What happens
Keep The page still has a purpose Same URL on the new site; title, canonical and structured data carried over
Redirect The content moves or merges One permanent redirect straight to the closest equivalent page, never through a chain
Retire The page has no equivalent and no value Return 404 or 410; do not redirect it to the home page

Keeping URLs is the cheapest choice. When we moved our own site from WordPress to Astro on AWS in October 2026, all 693 public URLs kept their address, title, canonical and structured data, and 23 old URLs became permanent redirects; the full account is in what we learned moving our site.

On staging: what should we check before launch?

Check with scripts, page by page, against the inventory. Spot-checking ten pages by eye does not find the template that dropped the canonical on 200 product pages.

  • Routes. Every "keep" URL returns 200 on staging; every "redirect" URL returns one 301 or 308 to its mapped target; nothing extra appears that you did not plan.
  • SEO head parity. Compare title, description, canonical, robots and structured data for every URL, old against new. Write down each intentional difference.
  • Canonicals and absolute links point at the production domain, not the staging one.
  • Internal links point at final URLs, not at URLs that redirect. Google advises "redirecting to the final destination directly" and updating internal links to the new URLs.
  • Sitemaps list only indexable 200 URLs on the new site.
  • robots.txt for production says what you mean it to say, written and reviewed before launch day.
  • Speed and mobile. Test the main templates at phone width; heavy new templates undo SEO work.
  • Forms, analytics and consent. Send a real enquiry from each form; check that tags fire only as your consent settings allow.

Staging access. Google says private content needs to be password protected "to ensure only authorized users can access it". A password on staging keeps it out of search without any noindex or robots.txt block that could follow the code to production.

On launch day: what is the order of work?

  1. Deploy the new site and the redirect rules together.
  2. Remove the staging password and confirm there is no noindex and no blanket Disallow in production. Google's checklist is explicit: "remove any noindex or robots.txt blocks that were only needed for the migration".
  3. Test the top 50 URLs by traffic and a sample of redirects from outside your network. Google suggests the URL Inspection tool for individual URLs and scripts for large numbers.
  4. Submit the new sitemap in Search Console. Google also suggests submitting the old URL sitemap you saved, so you can watch old URLs drop out as new ones are indexed.
  5. If the domain changed, verify both properties and use Search Console's Change of Address tool. Google says the tool is only for moves "from one domain or subdomain to another", not for HTTPS, www or path changes.
  6. Check analytics in real time, submit each form once more on the live domain, and confirm the emails arrive.

After launch: what should we watch, and for how long?

Weekly for the first eight weeks, then monthly until traffic is stable.

Week Check Where
1 404s from old URLs you missed; redirect errors; server errors under the heavier crawl Search Console Page indexing report, server or CDN logs
1 to 2 New sitemap indexing starting; old sitemap URLs reported as redirects Search Console Sitemaps report
2 to 8 Clicks and impressions by page against your baseline Search Console Performance report, compared with your export
2 to 8 Organic landing pages, key events, form submissions Google Analytics 4
Ongoing Links from important external sites updated to new URLs Your saved list of linking sites

Expect movement. Google says to "expect temporary fluctuation in site ranking during the move" and that new URLs may take "a few weeks or more" to appear for a medium-sized site. A fall on a handful of pages points to a mapping or template problem on those pages; a fall everywhere points to something sitewide, such as robots rules, canonicals or a domain issue. Keep the redirects for at least a year, and longer if old URLs still receive traffic.

What did our own relaunch teach us?

Three practical lessons from moving impingesolutions.com in October 2026, in a few working days from first capture to cutover:

  • Scripts beat eyes. Routes, SEO heads, page text, internal links and sitemaps were compared old against new by script before launch. That is what made it safe to keep every URL.
  • Integrations break on launch day, not on staging. What failed for us was outside SEO: a missing email-sending permission for forms with attachments, the newsletter provider's double opt-in (since resolved with the provider), and a few minutes of errors on the form API while a new configuration propagated. Test forms on the live domain.
  • Redirects belong at the edge. Our redirects run in the CDN on every request, in one hop, which keeps them fast and in one place. Our article on 301 redirects covers the options.

If the relaunch is also a move off an old platform, our website modernisation service follows this checklist end to end.

FAQ

Will a redesign hurt our Google rankings?

Not necessarily. Rankings are at risk when URLs, content, titles or structured data change, or when something blocks crawling. If every important URL is kept or permanently redirected to its closest equivalent, the SEO head is carried over and no staging block reaches production, the main risk is the temporary fluctuation Google warns about when URLs change.

Should we redirect old pages we are deleting to the home page?

No. Google advises against redirecting many old URLs to one irrelevant destination such as the home page and says this "might be treated as a soft 404 error". Redirect each URL to its closest equivalent; if there is none and the page has no value, let it return 404 or 410.

How long should we keep redirects after a relaunch?

Google's site-move guidance says to keep redirects "for as long as possible, generally at least 1 year", and notes users benefit from keeping them indefinitely. For a domain change, Search Console's Change of Address tool works over 180 days, but the redirects should stay well beyond that if old URLs still get visits.

Do we need the Change of Address tool?

Only if the domain or subdomain changes, for example from an old brand domain to a new one. Google says it is not needed for a move to HTTPS, a switch between www and non-www, or pages moving to new paths within the same site. In those cases redirects, updated internal links and a new sitemap do the job.

How do we keep the staging site out of Google?

Put it behind a password. Google says content that should not be public needs password protection so only authorised users can access it. That avoids relying on noindex tags or robots.txt rules, which are easy to copy to the live site by accident on launch day.

When is it safe to say the relaunch worked?

When, after about eight weeks, the Page indexing and Sitemaps reports show the new URLs indexed and the old ones as redirects, clicks by page are back in line with your pre-launch baseline allowing for seasonality, and forms and key events are recording normally. If one group of pages lags, check its mapping and templates first.

Planning a redesign or platform move? Our digital marketing and SEO team runs this checklist for relaunches, and website modernisation covers moves off old platforms. Run our free website audit on your current site before the URLs change.

Sources (5 links)
Share this article