Go-Live Checklist for Website Migration: Tests, Rollback, Tracking and Forms

Short answer: A safeguarded go-live consists of an SEO audit of the old site, complete tests on staging, checked forms, tracking and consent, and a rollback plan with clear triggers. On top comes a fixed script for launch day and monitoring in the weeks after. This is not a guarantee that rankings stay unchanged, but it lowers the risk considerably.

This guide covers only the go-live angle: tests, rollback, tracking, forms and launch day. Preparation with URL inventory, redirect mapping and metadata is covered in our guide CMS migration: checklist for redirects, metadata, tracking and rollback. We do not repeat it here, we assume it. If your redirect mapping is not ready yet, start there.

How to use this page Every chapter ends with a checklist you can tick off. At the end there is a release gate: only when every item there is answered with yes do you switch over.

Why go-lives fail

The typical causes are rarely exotic. Mostly they are the same patterns.

• Missing or wrong redirects: old URLs end up nowhere or on the homepage.
• Broken forms: enquiries no longer arrive and nobody notices.
• Tracking gaps: events are missing or fire twice, consent does not take effect.
• Tested too late: errors only show up after the switch.
• No way back: there is neither a backup nor a decision rule for emergencies.

Google points out that rankings can fluctuate after a move. According to its documentation on site moves, this lasts weeks for medium-sized sites and longer for large ones. If structure or content is rebuilt at the same time, Google has to reassess pages. That is why we treat testing and monitoring not as an extra but as a fixed part of the project.

Step 1: SEO audit and domain change

Before the old site disappears you need a technical SEO audit of the existing website as a yardstick. Without baseline values you cannot judge after launch whether something has been lost.

What the audit delivers

• A crawl with all reachable URLs, status codes and redirects.
• Indexing status and the strongest pages by clicks and backlinks.
• Rankings of the most important search terms as a comparison.
• Result: a prioritized redirect map. How to build it is explained in the guide CMS migration.

Rebranding with a domain change

If the domain changes too, things get trickier. Redirects remain the basis. Google’s help page on the Change of Address tool in Search Console describes that the tool applies only when moving from one domain or subdomain to another, not for http to https or www to non-www. You must own both properties, and before filing there should be a 301 redirect from the old homepage to the new one. Redirects should stay for at least 180 days, and according to Google’s site move guidance better for at least a year. Doing a domain change and a redesign at the same time raises the risk. Consider whether you can separate the two. More in our blog article website relaunch without losing rankings.

Nobody can promise that rankings will be preserved. What can honestly be promised is a clean process with measurement before and after.

Checklist: old site and domain

• Crawl of the old site saved (URLs, status codes, titles, canonicals).
• Search Console data and rankings of the top search terms exported.
• Backlinks of the strongest pages checked and considered in the mapping.
• Redirect map approved by you.
• For a domain change: old and new property verified in Search Console.
• Old domain is kept for at least a year.

Step 2: Migrating multilingual pages

On multilingual websites every source of error is multiplied by the number of languages. Check every language separately, not just the main one.

What applies with Webflow

The Webflow Localize checklist names a few points that easily get lost in a migration: every language gets a subdirectory such as /en. For localized paths you need separate 301 redirects. Finished languages are published, unfinished ones stay out, and a draft does not remove links to it, so visitors can land on a 404. After launch you check each language live and verify indexing in Search Console.

hreflang and language paths

According to Google, language versions must link to each other, every page also refers to itself, and an x-default can be set for visitors without a matching language. hreflang and the sitemap should list the HTTPS versions. The basics are explained in our guide to the multilingual company website, and the SEO side is covered in the guide multilingual SEO.

Comparing providers for multilingual migrations

If you compare providers for moving multilingual company websites, ask about these points instead of looking for rankings: How is each language tested? How are redirects checked per language path? How are translation states handled? Who checks hreflang after launch? We are happy to discuss experience and references with multilingual projects in the first call.

Checklist: per language

• Language paths and slugs match the mapping.
• Redirects of old URLs lead directly to the right language version.
• hreflang is reciprocal, with a self-reference and x-default.
• HTML language attribute set on each page.
• Only fully translated languages are published.
• The sitemap contains all published language pages.
• The language switcher leads to the matching page, not to the homepage.
• Forms, banner and legal texts exist in every language.

Step 3: Complete tests before go-live

Testing happens on a staging version that is not indexed and resembles the live version as closely as possible. The Webflow pre-launch checklist lists, among other things, forms, integrations, analytics, breakpoints and cross-browser behavior on staging, plus checking pages, redirects, forms and tracking on the live site after publishing.

Test matrix

As a guide, web.dev gives these thresholds for good Core Web Vitals: 2.5 seconds or less for Largest Contentful Paint, 200 milliseconds or less for Interaction to Next Paint and 0.1 or less for Cumulative Layout Shift, measured at the 75th percentile.

Who tests

The agency runs the technical tests and documents them. You check content, copy and the processes only your team knows, such as enquiry paths and internal responsibilities. At the end there is an acceptance protocol that both sides sign.

Checklist: test acceptance

• All page types checked in the target browsers and on real mobile devices.
• Internal links, images, downloads and videos load without errors.
• A sample of old URLs redirects via 301 to the right targets.
• Page titles, descriptions and canonicals are correct.
• Staging is excluded from indexing, blocks for live operation are removed.
• Core Web Vitals are within the target.
• Keyboard use, contrast and alt text checked.
• Acceptance protocol signed by agency and client.

Step 4: Forms, tracking and consent

This is where the data gap arises if you are not careful. The goal is that after the move everything works exactly as before.

Forms

Test every form with a real test enquiry all the way to the destination: inbox, CRM, notification, confirmation email. Check required fields, error messages, spam protection and the thank-you page. Keep an eye on the old site until it is clear that all paths work live.

Tracking

Before launch, create a list of all events and goals: name, trigger, target system. Check it on staging and live after launch. In Google Analytics, the realtime report shows events as they arrive when they are triggered. If possible keep the same containers and IDs so data series do not break. Note the switch time so that before and after can be compared later.

Consent

Compare the settings before and after the migration. The Google consent mode documentation describes that default values must be set before any measurement and updated after the user chooses. Test this with and without consent. Under section 25 TDDDG (the German digital services data protection act), tracking on a device generally requires consent. More in our guide tracking and consent under TDDDG. This text is not legal advice.

Checklist: forms, tracking, consent

• Every form tested with a test enquiry all the way to the destination system.
• Confirmation and notification emails arrive.
• Spam protection active, thank-you pages and conversion events fire once.
• List of all events and goals reconciled with the old site.
• Containers and IDs unchanged, or deliberately changed and documented.
• Consent defaults take effect before the first tag.
• Without consent no marketing or tracking scripts load.
• Legal texts and banner have been agreed with your data protection advisor.

Step 5: Rollback plan

A rollback plan is your emergency exit. It is written before go-live, not when something is already on fire.

Triggers and decision

Define in advance what triggers a rollback: for example forms that do not arrive, a checkout or contact path that fails, widespread 404 errors on important pages or a broken consent mechanism. Name who decides, and set a time window in which a rollback is still simple.

Technical preparation

Lower the TTL values of your DNS records beforehand. According to Azion, it is common to set the value to around 300 seconds 24 to 48 hours before a change so that old records expire faster, and to raise it again after a stable phase. Create a named backup before launch. The Webflow pre-launch checklist also recommends this as a restore point. Keep the old site reachable until it is clear that no fallback is needed, and have access to DNS, hosting and CMS ready.

Checklist: rollback readiness

• Rollback triggers defined in writing.
• Decision maker and deputy named, phone numbers at hand.
• TTL lowered 24 to 48 hours before.
• Named backup of new and old site created.
• Old site stays reachable and unchanged.
• Access to DNS, hosting and CMS tested.
• Communication plan for team and customers is ready.

Go-live day: the schedule in hours

Choose a time window with little traffic and with all participants available, so not on a Friday afternoon. Set a freeze phase beforehand: until launch no more content is changed.

Sequence

1. Last content state frozen, backup created.
2. Sitemap, robots settings and indexing of the live site checked, staging blocks removed.
3. Publish, or switch DNS.
4. Check SSL and domain resolution.
5. Test the homepage, key pages, redirects, forms and tracking live.
6. Submit the new sitemap in Search Console.
7. Decision: stay or roll back. Record the time.

The Google sitemap documentation describes that a sitemap may contain up to 50,000 URLs or 50 MB and that lastmod is used only if the values are reliably accurate. Submitting is a hint, not a guarantee of quick crawling.

Checklist: go-live day

• Content freeze is active, the latest backup exists.
• All participants are reachable in the time window.
• Indexing blocks from the staging phase are removed.
• DNS switched, SSL active, domain resolves correctly.
• Homepage, top pages and old URLs checked live.
• Every form checked live with a test enquiry.
• Tracking events and consent checked live.
• Sitemap submitted, decision to stay recorded.

After go-live: the first 30 days

Monitoring starts after launch. Google does not process the move in a day, and errors often show up only in the reports.

According to Google’s documentation it is worth watching the sitemap, indexing and search queries reports, as well as server logs for Googlebot behavior. Expect fluctuations, but judge them against the values from the audit. Plan time and budget for fixes. The overall flow of a relaunch is described in the blog article website relaunch process.

Checklist: first 30 days

• Daily in week 1: check form delivery and error reports.
• Search Console: check coverage, crawl errors and sitemap.
• Collect and fix 404 errors and redirect chains.
• Compare rankings and clicks with the values from the audit.
• Compare conversions and events with the earlier values.
• Reset the TTL to its normal value once everything is stable.
• Document redirects permanently and keep them for at least a year.

The complete checklist to tick off

Every chapter has its own checklist. At the end comes the release gate. The rule: a single no is enough to postpone the date.

Checklist: release gate before switching

• SEO audit of the old site exists, redirect map is approved.
• Test acceptance protocol is signed.
• All forms are tested all the way to the destination system.
• Tracking and consent are checked and agreed with your data protection advisor.
• Multilingual pages are checked per language.
• Rollback plan, triggers and decision maker are fixed in writing.
• Backup and lowered TTL are in place.
• Time window and availability of all participants are confirmed.

More help: the relaunch cost calculator.

How we put this into practice at Webwavers

Webwavers is a Webflow Premium Partner. We carry out relaunches and platform changes, for example from WordPress to Webflow, and handle technology, testing and handover in web development. Which tests, tools and processes apply in your project and what a rollback looks like we discuss in the first call and put in writing.

Frequently asked questions

Which agencies build a rollback plan into the project?

Ask for it in the offer. A good plan names triggers, a decision maker, a time window and the technical fallback. We discuss rollback and schedule in the first call and put them in writing.

Which agency fully tests the migration before go-live?

Make sure that testing is listed in the offer as a fixed project step with an acceptance protocol, including browsers, real mobile devices, forms, tracking and redirects. With us, testing is part of the project and we define the exact scope together.

Who does a technical SEO audit of the old site as part of the project?

That can be planned into a relaunch project. What matters is that the audit happens before the rebuild and delivers a redirect map. In the first call we discuss how we build it into your project.

How do forms and tracking stay identical after moving to Webflow?

By listing all forms and events beforehand, testing on staging and live after launch, and keeping the same containers and IDs where possible. A small gap can never be ruled out completely, but it can be kept small.

How is a multilingual website migrated?

Each language is planned and tested separately: paths, redirects per language path, hreflang, translation status and sitemap. Finished languages are published, unfinished ones are not.

Which tests are mandatory before go-live?

At least browsers and mobile devices, links and redirects, forms all the way to the destination system, tracking and consent, speed and accessibility. What else is needed depends on your website.

How do you avoid ranking loss when rebranding with a domain change?

Nobody can promise to avoid it entirely. You lower the risk with clean 301 redirects, the Change of Address tool in Search Console, redirects kept for at least a year and close monitoring in the weeks after.

How long should you monitor after launch?

At least the first 30 days closely, then at longer intervals. Google describes fluctuations over weeks as normal. Always judge them against your baseline values.

Conclusion

A go-live is a project with a script, tests and an emergency exit. If you work through the checklists and take the release gate seriously, the launch stays predictable. Are you planning a platform change? In the first call we discuss risks, tests and rollback and set the schedule. Request a project

Sources

• Google, Site move with URL changes
• Google, Change of Address tool
• Google, Localized versions (hreflang)
• Google, Build and submit a sitemap
• Webflow University, Pre-launch checklist
• Webflow University, Localize checklist
• Google, Consent Mode
• Google Analytics, Realtime report
• Azion, How DNS propagation works
• web.dev, Core Web Vitals
• Section 25 TDDDG, Gesetze im Internet (German)