CMS Migration Checklist: Redirects, Metadata, Tracking and Rollback

Short answer: A CMS migration avoids ranking loss when every old URL points to the matching new URL via a 301 redirect, titles, descriptions, headings and alt texts are carried over completely, tracking and forms are tested before go-live, and you actively monitor indexing, error pages and rankings after launch. Google itself expects temporary fluctuations lasting a few weeks. A rollback plan protects you in case the launch goes wrong.

The key points in brief:

• Without a complete redirect mapping, there is no safe migration.
• Measure the current state before the move: rankings, traffic, backlinks, indexing, conversions.
• Test tracking, consent and forms on the new site before the domain moves.
• Plan the way back: time window, decision criteria, DNS values, access to the old system.
• Keep redirects for at least one year. Google even recommends keeping them permanently, if possible.

Contents

• Phase 0: Measure the starting point
• Phase 1: URL inventory and redirect mapping
• Phase 2: Metadata, content and alt texts
• Phase 3: Technology, staging and backlinks
• Phase 4: Tracking and consent
• Phase 5: Forms and integrations
• Phase 6: Tests before go-live
• Phase 7: Go-live and rollback
• Phase 8: Monitoring after launch
• Common mistakes
• Short version to tick off
• Frequently asked questions

Why migrations cost rankings and how to prevent it

Rankings get lost in migrations because search engines evaluate addresses, not pages. If a URL changes without a redirect, the old address is gone for Google, and the new one is an unknown newcomer without backlinks, history or signals. That holds whether you are moving from WordPress, TYPO3, Wix, Jimdo, Squarespace or Framer, switching platforms, changing the domain or just reorganizing the structure.

Google describes the process in its documentation on site moves with URL changes and names the core steps: map all old URLs to the new ones, redirect server-side with 301 or 308, submit the new sitemap and then monitor. This checklist turns that into a sequence you can work through with your team or an agency.

For the choice of the target platform itself, you will find the decision criteria in our platform consulting. The blog explains the relaunch process in outline under Website relaunch without losing rankings and Website relaunch process.

Phase 0: Measure the starting point

Without measurements from before the migration, you cannot judge afterwards whether anything was lost. So record the current state before anything gets rebuilt.

1. Verify Search Console for all variants. Google names this as the first step: set up all variants of the old and new site: HTTP and HTTPS, with and without www, subdomains.
2. Export performance data. Clicks, impressions, click-through rate and position per page and per query, for at least the last 12 months. This is your baseline for comparison.
3. Record rankings for the most important keywords. A list of 30 to 100 terms that bring inquiries or revenue, with the current position and ranking URL.
4. Secure the analytics numbers. Sessions by channel, top landing pages, conversions and form submissions per month.
5. Document the indexing status. How many pages are indexed, and which errors and exclusions already exist? You will need this number later for the comparison.
6. Technical audit of the old site. Status codes, redirect chains, canonicals, noindex tags, hreflang, sitemap, load times. You should not carry the old site's errors over to the new one.
7. Export backlinks. Which pages have external links? More on this in Phase 3.

The result of this phase is a folder of exports and a document listing the pages that matter most to you. These pages get priority in every following step.

Phase 1: URL inventory and redirect mapping

The redirect mapping is the most important single task of the migration. It assigns the matching new URL to every old URL.

How to build the inventory

Google recommends starting with the sitemaps, the pages with the most traffic from log files and the Links report in Search Console. Add a crawl of the old site, plus images, videos, PDFs and the CSS and JavaScript files that might be linked externally. The table should have at least these columns:

Old URL	New URL	Type	Status	Traffic and backlinks	Note
/leistungen/seo-beratung	/leistungen/growth/seo	301	checked	high	Content merged
/blog/alter-artikel	(removed)	410	checked	low	No replacement
/produkte/modell-x	/produkte/modell-x	same	checked	medium	URL stays

Rules for the mapping

These rules come from the Google documentation and apply regardless of the system:

• Redirect server-side. 301 or 308. Client-side redirects only in an emergency.
• Straight to the final URL. Googlebot follows up to 10 hops. Ideally use 3 at most, and in any case fewer than 5.
• Not everything to the homepage. Sending many old URLs to an unrelated new page leads to soft-404 behavior and wastes relevance.
• 404 or 410 for content without a replacement. If you deliberately do not carry a page over, return the matching status code.
• Keep redirects for at least one year, permanently is better.

Implementing redirects in Webflow, WordPress and TYPO3

How you enter the list depends on the target system:

• Webflow: Rules are in the site settings under Publishing. According to the Webflow help center, there is no hard limit, but no more than 1,000 rules are recommended, because each one is factored into delivery. Wildcards with capture groups (for example (.*) in the old path and %1 in the target) cover whole folders. For sites with tens of thousands of URLs, this is a planning limit: move the logic into wildcards, deliberately set worthless mini-URLs to 410, or handle parts at the server level.
• WordPress: Redirects run through a plugin or the server configuration (for example Apache or Nginx). Server rules are faster and practically unlimited, but need server access.
• TYPO3: Redirects can be managed in the system or handled at the server level. With version jumps, URL schemes sometimes change, so check this early.

After entering them, you check every rule. For this, Google names the URL Inspection tool for individual pages and a crawler or a script for large lists. The goal: no hop chains, no loops, and every row returns the expected status code.

Industry note: For IT and software, feature and integration pages often rank individually. For industry and engineering, product and series pages carry the long-tail traffic. These URLs get a clean mapping first.

Phase 2: Metadata, content and alt texts

Metadata and content are the second point of loss. In migrations they get lost because fields have different names in the target system or are not mapped during import.

Check for every important page:

1. Title tag and meta description. Carry them over word for word as long as they rank well. Optimizations come later, not at the same time as the move, otherwise you will not know what triggered the change.
2. H1 to H3. The heading structure and the main message of the page should be preserved.
3. Body text. Carry over text, tables, lists and internal links completely and without formatting breaks. Check tables and embedded content in particular.
4. Alt texts and file names of images. Alt texts often drop out during import. Reconcile them via an export.
5. Canonical tags. Every page points to itself, unless there is a deliberate different canonical version. Google recommends self-referencing canonicals on the new URLs.
6. Open Graph and social images. They determine how links appear on social media and in messengers.
7. Structured data. Organization, article, product, FAQ, or whatever was in use before. The markup must match the visible content, according to Google's introduction to structured data. JSON-LD is the recommended format.
8. hreflang for multilingual sites. Every language version points to all others and to itself, the references must be reciprocal, and the x-default is set. Details are in the Google documentation on localized versions.
9. Internal links. Update internal links to the new URLs instead of relying on redirects. Google advises adjusting links right away.

The move changes as little as possible. If you also plan a rebrand, separate the steps or document the changes precisely, otherwise causes cannot be traced later.

Phase 3: Technology, staging and backlinks

Securing the staging system properly

The new site is first built on a test address. This test address must not end up in the index. Set noindex or access protection on the test environment and remove both before launch. Google states this explicitly: migration-related noindex tags and robots.txt blocks must disappear. This is one of the most common mistakes of all, which is why the item is also on the go-live list.

Other technical points

• robots.txt and sitemap. The new sitemap contains only indexable pages with status code 200. You can keep the old sitemap for a while to follow the switch in Search Console.
• HTTPS and domain variants. All variants redirect to the preferred address.
• Page speed. Check the Core Web Vitals of the new site against the old one. The thresholds according to web.dev: largest content load time at most 2.5 seconds, interaction at most 200 milliseconds, layout shift at most 0.1, each at the 75th percentile.
• JavaScript dependency. Important content and links must be in the delivered HTML. Google renders JavaScript but still recommends server-side rendering or pre-rendering, see JavaScript SEO basics.

Checking backlinks

Backlinks are endorsements from other sites, and they are attached to old URLs. Proceed like this:

1. Export external links by target page, using a backlink tool and Search Console.
2. Sort by number and quality of the referring domains.
3. Check that every heavily linked page gets a redirect to a topically matching new page.
4. For important references such as industry directories, partners and press, ask for an update to the new URL. Google recommends updating especially relevant external links directly.
5. After launch, check whether backlinks lead to 404 pages (broken backlinks) and add redirects.

Domain change

If the domain changes too, the Change of Address tool in Search Console comes into play. Google requires it for all verified variants of the old domain. For a pure platform switch with the same domain, this step does not apply.

Phase 4: Tracking and consent

After the move, tracking should keep running without a data gap. For that you need to do more than transfer tags: you also need to re-check the legal basis.

What to check

1. Tag inventory of the old site. Which scripts are running: analytics, tag manager, ad pixels, heatmaps, chat, appointment booking, maps, fonts? List them all.
2. Containers and IDs. If possible, use the same tag manager container and the same measurement IDs so time series do not break.
3. Events and conversions. Form submissions, clicks on phone and email, downloads, appointment bookings. Every event must fire on the new site. Check the event names, because even small deviations ruin comparisons.
4. UTM parameters and redirects. Check that campaign parameters are preserved through a redirect. Otherwise sources get lost.
5. Thank-you pages or events. If target pages change, goals in analytics and in the ad accounts must be adjusted.
6. Internal search and filters. If present, their parameters must be carried over as well.

Consent and legal basis

Under § 25 TDDDG (German Telecommunications Digital Services Data Protection Act), storing information on the end device and reading it out generally requires consent based on clear and comprehensive information. Exceptions apply if the access is strictly necessary to provide a service the user has expressly requested. This is the same on every system. In practice, for the move this means:

• The consent tool must run on the new site and load scripts only after consent.
• Texts, categories and services in the banner must match the new tag setup.
• New embeds (maps, videos, third-party fonts) usually require consent.
• The privacy policy is reconciled with the new site.

The topic is covered in depth in the guide Tracking and consent under the TDDDG and on the blog under Cookie banners under GDPR (DSGVO). The glossary has a definition under Tracking. This does not replace legal advice: clarify the details with your data protection officer or advisor.

How to test

• Open the new site in a fresh browser window without stored consent and check in the network tab that no non-essential scripts load before consent.
• Accept and check that analytics events arrive, for example with the real-time view or the tag manager preview.
• Decline and check that nothing unauthorized is loaded.

Phase 5: Forms and integrations

Forms are the point where migrations get most expensive if they go wrong: inquiries do not arrive, and nobody notices.

Forms checklist

1. Inventory of all forms. Contact, newsletter, quote, application, download, appointment request.
2. Fields and required fields. Same fields, same validation, same privacy checkbox with a link to the current policy.
3. Recipients and data forwarding. Target addresses, notification emails, connection to CRM, newsletter tool or ticketing system. Check webhooks, API keys and Zapier or Make connections.
4. Spam protection. Honeypot, captcha or other measures work on the new site without locking out users. Here too, consent requirements for external services apply.
5. Confirmation and thank-you page. The user sees a confirmation, and the conversion event fires.
6. Email delivery. Sender address, SPF, DKIM and DMARC stay correct. Otherwise notifications end up in spam.
7. Storage of submissions. Where is the data, for how long, who has access? For Webflow, the site plans count according to the pricing page: the free Starter plan allows 50 submissions per site, while the paid Basic and Premium plans list unlimited submissions (as of October 31, 2026).
8. Legacy data. Export earlier submissions and newsletter subscribers before the old system is shut down, and reconcile retention with data protection.

Appointment booking, chat, maps, shop integration or login areas each get a row in the test list with an owner and a result.

Phase 6: Tests before go-live

On the staging version, test what a visitor would do, not just whether pages open.

Test area	What is checked	Tools
Browsers	Current versions of Chrome, Safari, Firefox, Edge	Own devices, browser testing services
Devices	Smartphone, tablet, desktop, common widths	Real devices, developer tools
Content	Missing images, line breaks, tables, special characters	Spot checks by page type
Links	Broken internal and external links	Crawler
Redirects	Status code, target, no chains	Crawler or script with the redirect list
Metadata	Title, description, canonical, robots, hreflang	Crawler, page source
Schema	Validity and match with the content	Rich Results Test, Schema.org Validator
Speed	Core Web Vitals and total load time	PageSpeed Insights, Search Console after launch
Accessibility	Contrast, keyboard operation, form labels	Testing tools plus manual tests
Forms and tracking	See Phase 4 and 5	Test submissions, tag preview
Security	HTTPS, headers, access, default passwords	Security check, role review

If you are migrating a multilingual site, also test each language individually, the language switcher, hreflang and what happens if a page is missing in one language. Whether the site must be accessible by law depends on your offering, for example for e-commerce services under § 1 BFSG (Accessibility Strengthening Act). An overview is on the blog under BFSG and your website.

Document errors with a priority (blocking, important, cosmetic). Blocking errors postpone the date.

Phase 7: Go-live and rollback

Choosing the timing

Google advises scheduling the move for a period with little traffic. Large sites can launch in sections. Avoid campaign peaks, trade shows and seasonal peaks, and make sure someone is reachable in the first hours.

Rollback plan

A rollback plan sets in advance when and how you go back:

1. Decision criteria. For example: forms do not work, redirects return errors on important pages, homepage unreachable, tracking missing entirely. Define who decides and by when.
2. Time window. How long does the way back stay open? The old system keeps running at least until the most important tests have passed in live operation.
3. DNS preparation. Lower the TTL values of the DNS records a few days before launch so that a switch back takes effect quickly. Document all old records (A, CNAME, MX, TXT).
4. Access and backup. Full backup of the old site, including database and media. Access to hosting, domain and the old system stays secured.
5. Communication. Who is informed in case of a rollback: team, management, support, campaign owners.

For smaller errors such as individual redirects, fixing is faster than a rollback. The plan helps you decide calmly.

Sequence on launch day

1. Content freeze: no more content changes on the old site.
2. Final sync: transfer new content or submissions since the test.
3. Remove noindex and access protection on the new site, check robots.txt.
4. Switch the domain or DNS to the new system, check the SSL certificate.
5. Activate redirects and spot-check them.
6. Submit the sitemap in Search Console. For a domain change, trigger the change of address.
7. Submit forms, check events, test the consent banner.
8. Switch internal links, social profiles, ad accounts, email signatures and directory listings to the new URLs.

Phase 8: Monitoring after launch

Google writes that for mid-sized sites it can take a few weeks or more for new URLs to appear, and longer for larger ones. There is no fixed crawl schedule. So you monitor in a targeted way.

What Google shows you

• Sitemaps report. The number of indexed pages from the new sitemap should rise, and the number from the old one should fall toward zero. Redirect notices on the old sitemap are normal.
• Page indexing. Watch for error spikes, excluded pages and blocks.
• Crawl stats and server logs. They show which status codes Googlebot sees and whether unexpected errors occur.

Monitoring schedule

The following points in time are a recommendation from practice, not a requirement from Google:

When	Tasks
Day 1	Status codes of the top 100 URLs, forms, real-time tracking, error pages, robots.txt, sitemap
Week 1	Check Search Console daily for errors, evaluate the 404 list, add missing redirects, check server logs
Weeks 2 to 4	Compare indexing status with the baseline number, measure rankings of key terms, check backlinks to 404s, compare conversions with the previous year and previous month
Weeks 6 to 8	Evaluate rankings and traffic by page type, analyze outliers, refine redirect targets
Week 12	Final report against the measurements from Phase 0, close open items, plan optimizations

When is a loss normal, and when is it an alarm?

According to Google, fluctuations in the first weeks are to be expected. Warning signs, on the other hand, are:

• Important pages return 404 or 5xx.
• The new sitemap shows hardly any growth in indexing over weeks.
• Rankings drop on several top pages and do not recover.
• Conversions collapse even though traffic stays stable (a sign of a form or tracking problem).
• Pages are noindex or blocked by robots.txt.

Then you proceed in this order: check the technology (status codes, noindex, canonical), check the redirects, compare the content of the affected pages with the old version, and only then examine competition and other causes such as a parallel Google update.

More on the technical basics is on the blog under Technical SEO, and on linking under Internal linking.

Common mistakes

Mistake	Consequence	Countermeasure
All old URLs redirected to the homepage	Relevance is lost, soft-404 behavior	One-to-one mapping by content
Redirect chains	Slower, signals are lost	Straight to the final URL, 3 hops at most
noindex or password protection of the test environment stays active	Site disappears from the index	Its own item on the go-live list
Metadata not carried over	Snippets change, click-through rate drops	Metadata export and crawl comparison
Tracking and forms without a test	Data gap, lost inquiries	Real-time test and test submissions before go-live
Redesign, new copy and platform switch at the same time	Causes cannot be separated	Stagger the changes or document them precisely
No rollback plan	Panic when problems occur	Set the plan down in writing beforehand

When you can do it without an agency

Small sites with few subpages, no multilingual setup and no complex integrations can be moved yourself with the checklist. The prerequisite: you have access to the old and new systems, can enter redirects and have time for the monitoring afterwards. With many URLs, several languages, shop functions, CRM integrations or important organic traffic, a second pair of eyes on the mapping and the tests is worth it.

Migrations between specific systems

The checklist applies to every switch. Specifics by source and target are on the pages for the individual migrations:

• WordPress to Webflow
• TYPO3 to Webflow
• Wix to Webflow
• Jimdo to Webflow
• Squarespace to Webflow
• Webflow to WordPress
• Framer to Webflow

How we implement this

A migration typically runs the way this checklist describes: measure the starting point, plan redirects, reconcile content and metadata, test tracking and forms, go live and monitor afterwards. Webwavers carries out migrations with redirects and SEO preservation. We are one of seven Webflow Premium Partners in Germany and also work with WordPress, TYPO3 and headless setups. Which target platform fits your project, we clarify beforehand in platform consulting. For SEO support after the move, there is the SEO service page.

Short version to tick off

Preparation

• ☐ Search Console set up for all variants
• ☐ Performance data, rankings, analytics and indexing status secured
• ☐ Technical audit of the old site done
• ☐ Backlinks exported, top targets marked

Mapping and content

• ☐ URL inventory complete (sitemap, crawl, log files, Search Console)
• ☐ Every old URL has a target, 301 or 410
• ☐ No chains, no loops, no catch-all target to the homepage
• ☐ Title, description, H1, canonical, Open Graph carried over
• ☐ Alt texts, schema and hreflang checked
• ☐ Internal links adjusted to the new URLs

Technology, tracking, forms

• ☐ Staging with noindex or access protection, removed before launch
• ☐ Sitemap, robots.txt, HTTPS, domain variants checked
• ☐ Core Web Vitals of the new site tested
• ☐ Tag inventory transferred, events and conversions tested
• ☐ Consent banner configured and tested under the TDDDG
• ☐ All forms checked with a test submission, including CRM and notification

Go-live

• ☐ Time with little traffic, owners reachable
• ☐ Rollback criteria, time window, DNS values and backup documented
• ☐ Sitemap submitted, change of address triggered for a domain change
• ☐ External links and profiles updated

Monitoring

• ☐ Day 1, week 1, weeks 2 to 4, weeks 6 to 8, week 12 completed
• ☐ Redirects active for at least one year

Frequently asked questions

Which agencies can handle a relaunch without ranking loss?

Nobody can guarantee it, because Google itself calls temporary fluctuations normal. Make sure an agency names redirect mapping, metadata reconciliation, tracking tests, a rollback plan and ranking monitoring as a fixed part of the project and shows you the results, such as the mapping table and the measurement plan.

How long do I have to keep redirects?

At least one year, according to Google's recommendation. It is better to keep them permanently, as long as old URLs still have backlinks or bookmarks. You should only remove them once the logs and Search Console no longer show relevant traffic.

Are metadata and alt texts carried over automatically during the move?

Not reliably. Depending on the import method, fields get lost or end up in the wrong place. Export titles, descriptions, headings and alt texts beforehand, and after the import reconcile them with the old site via a crawl.

How do I make sure tracking and forms run without a gap after go-live?

Test both on the staging version: check events in the tag manager, send test submissions to all recipients and systems, and verify consent behavior with and without consent. Use the same containers and measurement IDs if possible so time series do not break.

Do I need new cookie consent for the migration?

You need a working consent tool on the new site. Existing consent cannot be transferred automatically if tools, services or the domain change. The basis is § 25 TDDDG. Clarify the details with your data protection advisor.

How long does it take for rankings to stabilize after a migration?

For mid-sized sites, Google names a few weeks or more, and longer for larger sites, and gives no fixed number. So plan the monitoring over at least 12 weeks and compare with the values from the starting point.

Conclusion

A migration succeeds when you run it as a project with measurements, mapping, tests and follow-up checks. Most losses come from missing redirects, forgotten metadata, an open noindex and unchecked tracking. Plan the way back, test before launch and monitor for at least twelve weeks afterwards.

Support with your migration: If you do not want to handle redirects, tests and monitoring on your own, we can help. For a first overview, see the page on platform consulting.

Published on October 31, 2026 by Edip Kilinc, founder of Webwavers. Last updated on October 31, 2026. Information on Webflow plans: as of October 31, 2026.

Sources

• Google: Seitenumzug mit URL-Änderungen (Site moves with URL changes)
• Google: Lokalisierte Versionen und hreflang (Localized versions and hreflang)
• Google: Einführung in strukturierte Daten (Introduction to structured data)
• Google: JavaScript SEO Basics
• web.dev: Core Web Vitals
• Webflow Hilfe: 301-Weiterleitungen (Webflow Help: 301 redirects)
• Webflow: Pricing
• Gesetze im Internet: § 25 TDDDG
• Gesetze im Internet: § 1 BFSG