A website builder can move your pages and still leave your search traffic behind. The usual problem isn’t the new design. It’s that an article once found at /blog/roof-repair-costs now lives at /articles/roof-repair-costs, while the old address leads nowhere. Images may still load from the old account, or a setting used to hide the unfinished site may remain switched on after launch.
Treat the switch as a move of URLs, content, and services—not a template change. If you can keep the same domain and page addresses, do it. When addresses must change, map each important old URL to its new home and test the move before canceling anything.
1. Decide what will change before choosing a launch date
Write down three separate decisions: Are you changing the builder, the domain name, or the page URL structure? A builder switch does not require a new domain. It may not require new page paths, either, if the destination platform lets you set them.
Keeping addresses stable removes a major source of migration work. Google distinguishes between moves that change URLs and infrastructure moves that leave visible URLs unchanged. If you can avoid combining a domain change, a new URL structure, and a full content rewrite, you’ll have fewer variables to troubleshoot if traffic falls.
Before committing to the new builder, test the tasks your site needs: Can you set page and blog slugs? Add redirects for changed paths? Edit titles, descriptions, and canonical URLs? Connect your domain? Export content if you leave again? A polished editor won’t compensate for missing controls on a site that depends on search traffic.
Set a quieter launch window if your business has predictable peaks. Keep access to the old builder, domain registrar, DNS settings, analytics, and Google Search Console throughout the move. Assign one person to approve the final URL list and another, if possible, to check the launched site against it.
2. Build an inventory of the site you have
Don’t start rebuilding from the navigation menu. Menus often omit articles, campaign pages, downloadable PDFs, and older URLs that still receive visits or links.
Export your sitemap and a list of URLs from your analytics and Search Console. Crawl the live site if you can. Put the results in a spreadsheet, one old URL per row, and note each page’s type, title, traffic, and planned destination. Include images and files that people link to directly. Mark high-traffic and business-critical pages so they get checked first.
Then capture what a URL list cannot tell you:
- Page copy, blog posts, product descriptions, categories, and author details
- Page titles, meta descriptions, headings, and image alt text
- Images, videos, PDFs, and their locations in the content
- Forms, bookings, store functions, menus, and other features that need rebuilding
- Analytics tags and any structured data or multilingual page settings you use
Save a separate backup before editing the original. An export file is not necessarily a complete website backup. For example, a WordPress.com content export contains posts, pages, and comments, but not the theme, plugins, or the media files themselves. Knowing exactly what you have in hand prevents an unpleasant discovery after the old site is gone.
3. Export content and media, then test the import
Export the content in the format the old platform provides, and import a small sample into the new builder before moving everything. Choose a typical article, an image-heavy page, and a page with unusual formatting. Check the published result, not just the editor preview: headings, tables, links, captions, and embedded elements can change during import.
Platform exports differ enough that “export complete” should never mean “migration complete.” Webflow CMS Collections can be exported as CSV files, but image and file fields in those exports can contain URLs pointing back to the original Webflow site. Move the assets you need and confirm the new pages use their intended locations. Wix lets site owners download uploaded media from its Media Manager, though its help documentation distinguishes those uploads from free Wix and Shutterstock media.
For each imported page, compare the new version with the original. Look for missing paragraphs, altered dates, broken internal links, images served from an account you plan to close, and files that did not transfer. Recreate important image alt text; the W3C’s image guidance calls for text alternatives that convey an informative image’s purpose or content.
Keep the old site accessible while imports are being checked. Some import methods retrieve media from the live original site rather than from the content export file. Rebuild forms and other interactive features separately, then submit test entries to make sure they reach the right inbox or system.
4. Map every changed URL to a useful destination
Add a “new URL” column to your inventory. For each old address, choose one of three outcomes:
| Old page status | What to do |
|---|---|
| The same page exists at the same address | Keep the URL; no path redirect is needed. |
| The page has a new address or a close replacement | Redirect the old URL to that specific page. |
| The page is gone with no relevant replacement | Return a genuine 404 or 410 response. |
For example, if /blog/roof-repair-costs becomes /guides/roof-repair-costs, the old article should send visitors straight to that guide—not to the homepage. If two old articles have genuinely been combined into one useful new article, both can point to it. Don’t send every retired URL to a vaguely related category page simply to avoid errors. Google’s crawl-error guidance distinguishes a moved page with a clear replacement from one that has been removed without one.
Preserve existing slugs where practical. Check trailing slashes, uppercase letters, blog prefixes, and www versus non-www addresses: small differences can create URLs you hadn’t planned for. If the old site already has redirects, include their original URLs in your inventory and point them directly to the final destinations rather than creating another hop.
5. Prepare redirects and test the new site before switching DNS
For pages that move, use permanent server-side redirects—commonly 301 redirects—where your setup allows them. Test whether the new builder can handle your old URL paths before launch. Webflow, for instance, supports CSV imports of 301 redirect rules, but its imported rules take effect after publishing. Other builders have different controls.
Where a redirect must live depends on what is changing. If the domain stays the same, requests will reach the new platform after the DNS switch; that platform or a service in front of it must handle the old paths. If the domain changes, the old domain must continue answering requests and sending visitors to the new one. Check this arrangement before ending your old hosting plan.
On the new site, update internal links to point directly to final URLs. Check page titles and headings against the originals, particularly on pages that bring in search traffic. Make sure canonical tags identify the intended new addresses. If you used a password, noindex setting, or crawl block to keep the unfinished site out of search results, plan exactly when to remove it. Preview settings left in place can make a successful launch look like a traffic emergency.
Run through the site on a phone as well as a desktop. Test navigation, search, forms, checkout if applicable, and a representative set of articles and downloads. Check that your analytics tag records visits before relying on its post-launch reports.
6. Connect the domain without disrupting email
A domain name, its registration, its DNS records, and its website hosting are related but separate. You can move the website without necessarily transferring the domain registration. Find out who controls each part before making changes.
If you’re keeping the same domain, follow the new builder’s connection instructions and change the appropriate DNS records when the new site is ready. Google’s guidance for moves without URL changes recommends preparing and testing the new infrastructure, then monitoring traffic to both old and new hosting after the DNS update. Don’t shut off the old site the moment you make the change.
Record your DNS settings first, especially if you’re changing nameservers rather than just the website records. Email may depend on MX and other DNS records; Cloudflare’s email-record documentation shows why mail settings need separate attention. After the switch, check that the site loads securely at the addresses you intend to use and that email still sends and arrives.
If you’re changing domains, keep control of the old one so its redirects continue to work. Once the move and redirects are live, use Search Console’s Change of Address tool for an eligible domain or subdomain move. It is not for a builder switch that keeps the same addresses, or for changing paths within one domain.
7. Audit the launch, then watch the pages that matter
On launch day, test more than the homepage. Visit a sample of old article URLs, product pages, image or PDF links, and any addresses that previously had redirects. Each should reach the right destination without looping or landing on an error. Crawl the new site to find broken internal links and unexpected redirect chains. Check that pages meant to appear in search are accessible, indexable, and listed at their final URLs in the new sitemap.
Submit that sitemap in Search Console and inspect a few priority pages. Use its performance and indexing reports alongside analytics to compare search clicks, impressions, and landing pages with your pre-move baseline. Watch for sudden drops tied to particular sections rather than judging the whole migration by one day of traffic.
Review the site closely during the first few days, then keep checking over the following weeks. Fix missing pages, wrong redirect targets, blocked URLs, and broken assets as you find them. Some movement in search visibility is expected while Google discovers the new setup; a sustained decline concentrated on pages that moved is a reason to inspect their mappings and rendered content.
Finally, keep the redirect arrangement in place. Google recommends retaining redirects for at least a year, and longer where practical. The work is finished when old addresses reliably lead people to the right content, the new pages function properly, and you can see how search traffic is settling—not when the new design first goes live.