A Webflow migration needs an SEO plan before development starts. Identify the pages that matter to the business, decide which URLs will change, and agree how the team will check the live site. Keep that plan alongside the build so search requirements don’t become a last-minute cleanup.
The checklist below is a working process for a B2B marketing site. Give each item an owner and a place to record the result. “Checked” should mean someone tested it and can show what happened.
Before the build: establish what you need to preserve
Export the current URL list and combine it with search performance, analytics, and conversion data. Look beyond the most visited pages. A low-traffic integration page may bring in qualified inquiries, and an older article may have links you still want to preserve.
Save a dated baseline. Include organic landing pages, impressions and clicks, qualified inquiries where you can identify them, and the tracking setup behind those figures. Note campaigns or seasonal changes that could affect the comparison after launch.
Review the inventory with the marketing owner. For each page, choose whether to keep it, improve it, combine it with another page, or remove it. Record why. Content decisions made during implementation are much harder to review when the launch is already close.
| Inventory field | What to record |
|---|---|
| Current URL and destination | The existing address and the intended live address in Webflow |
| Page purpose | Who uses it, what it answers, and the action it supports |
| Business priority | Lead contribution, search visibility, valuable links, or another reason it matters |
| Content and assets | Copy, images, downloadable files, and anything being revised |
| Dependencies | Forms, CRM routing, scripts, localization, or other connected systems |
| Owner and test result | The person responsible and evidence that the destination works |
Set the URL plan before building the CMS
Keep useful existing URLs when the new structure supports them. If an address must change, map it to the closest relevant destination. Don’t send every removed page to the homepage. A visitor following a product link should reach the product information they expected.
Google’s site-move guidance recommends URL mapping, permanent redirects for moved pages, and monitoring after the change. It also advises separating major changes where practical. A CMS move does not, by itself, require a new domain or a complete change to the URL structure.
Ask the developer to flag routing constraints early. A proposed Collection structure can affect page addresses. Resolve those constraints before importing the full content library.
For a page you are retiring, decide whether a relevant replacement exists. If it doesn’t, removal may be the right outcome. Record that decision so an intentional removal isn’t confused with a broken migration.
During the build: test complete journeys
Pick representative pages from every template and include the highest-priority URLs. Check the rendered copy, headings, page titles, descriptions, images, downloads, and links. Compare against the inventory rather than relying on memory.
Review canonical URLs across the published templates. A canonical identifies the preferred version of a page; it should agree with the URLs you use in internal links and the sitemap. Google’s canonical guidance warns against sending conflicting signals through those methods.
Test the journey from arrival to submission. Does the demo button open the right form? Does a test lead reach the correct CRM destination? Does the thank-you state work? Are the intended analytics events recorded under the relevant consent settings?
Keep a record of expected behavior for each integration. A form appearing on the page is only one part of that check.
Agree the launch decision
Before launch day, decide who can approve the release and which failures would stop it. For example, a broken primary inquiry form should have a different priority from a minor spacing issue on an archived article.
Set a content freeze or a clear process for capturing late edits. If the old site stays active during the build, someone needs to carry those changes into Webflow. Otherwise, an article published the day before launch can disappear from the new site.
Prepare a fallback plan with the people who control hosting and DNS. Confirm what can be restored, how new submissions will be preserved, and who makes the call. The plan needs to fit the actual infrastructure.
On launch day: check the public site
- Verify the production domain and the agreed crawler and indexing settings.
- Test priority URLs directly, including old addresses that should redirect.
- Check the live sitemap, canonical URLs, and important internal links.
- Submit test inquiries and confirm their full route into the CRM.
- Check analytics collection and record the launch time in your reporting notes.
- Test key pages on mobile, including navigation, buttons, and forms.
Development settings need deliberate attention. Robots.txt controls crawling; it is not a reliable way to keep a page out of search results. Review access controls, robots rules, and noindex settings separately so the public site has the intended behavior.
After launch: investigate changes by page
Compare priority pages against the baseline and review reported indexing issues, broken destinations, and lead collection. Start with a frequent check while the team is resolving launch issues, then agree a regular reporting schedule.
If traffic falls, narrow the problem before making another broad change. Is the decline concentrated on one template? Did the URL change? Is tracking missing? Did the page lose useful content? Did demand or campaign activity change at the same time?
Google notes that rankings can fluctuate as a significant site move is processed. That makes a documented baseline and a change log useful. A careful migration reduces avoidable problems; it cannot promise unchanged rankings.
If you’re planning a move, bring Beqi your current site, priority pages, and integration list. We can use them to identify the work that needs to be settled before development starts.
Related reading
Written by
