How to move a Webflow website while keeping useful URLs

Moving a website away from Webflow starts with the pages and journeys that already matter. Before changing the platform, record the existing URLs, the useful content on those pages and the actions visitors take. That inventory becomes the reference for deciding what the new site must preserve.

The platform change and the URL change are separate decisions. You can rebuild the site while keeping many of its public addresses. Where an address needs to change, plan the destination and verify the redirect as part of the launch rather than leaving it for search engines or customers to discover.

A successful move gives people a usable new site and keeps a clear path from old links to the appropriate content. The technical cutover, the content transfer and the customer enquiry flow all need to be reviewed together.

Record the useful existing pages

Collect the published URLs and identify the pages that receive traffic, links or enquiries. Include service pages, articles, project pages and practical destinations such as contact and careers. A visually modest page may still be an important entry point into the business.

Record the title, main heading and purpose of each page. This helps the new team preserve the meaning of the destination even if the design and content structure change. A URL alone does not explain why someone arrives there or what they expect to find.

Keep a recoverable copy of the existing content and media before beginning the move. Record the assets that belong to each page and any permission or publication status that affects their use. Preserving the source gives the team a reference when something looks incomplete in the new build.

Decide which addresses can stay

Keep useful addresses where the new structure can support them. A new content system does not inherently require a new public path for every article or project. Stable addresses can reduce the number of changes visitors and external links need to navigate.

Where a change is necessary, map the old address to the closest relevant destination. Google's site-move guidance explains the importance of URL mapping and suitable redirects. Use the mapping as a testable list, with an explicit decision for each affected page.

Separate equivalent destinations from pages that genuinely have no replacement. A general homepage is often an unhelpful landing point for a very specific old article or service. Review the information need behind the original page before choosing where the old link should lead.

Rebuild the content with its meaning intact

Move article bodies, project descriptions and service information into the new system carefully. Check headings, lists, internal links and special characters. Imported content can carry layout markup from the old editor that needs cleaning without changing the underlying meaning.

Preserve publication history accurately where it is known. A visual refresh does not make every old article newly written. If a piece is substantially updated, record that separately from its original publication date. Readers and editors should be able to understand the difference.

For Bricks' own site, the move beyond Webflow retained existing article and service routes while the presentation and work catalogue developed. The current work catalogue brings cases and collections into one browsing experience without requiring every established project address to disappear.

Test the customer actions as real journeys

Open the important landing pages directly, then follow their main actions. Check contact, enquiries, application destinations and any external business tools the site uses. A page rendering correctly does not establish that its form or next step still works.

Keep customer-facing fields understandable while preserving the backend contract that handles the enquiry. Bricks' later contact update hid internal routing choices and added a project brief. That was a separate interface improvement, and its existing submission destination needed to remain compatible.

For a Kuwait website, review Arabic and English journeys where both are provided. Check names, addresses, language switching and the relevant contact details. Do not assume that moving the English pages correctly has also preserved the Arabic version or its linked destinations.

Review discovery and launch configuration

Check the new pages' titles, descriptions, canonical destinations and crawl access before cutover. Test the sitemap against the pages that actually exist. A preview environment may deliberately block indexing, and that setting needs a clear production review before the public launch.

Google's sitemap guidance describes submission and discovery routes. After publication, make the current sitemap available and submit it through the site's verified Search Console property. Submission helps discovery, but it does not guarantee an indexing outcome or timetable.

Keep the old-to-new URL checks beside the release record. The team should know which redirects passed and which pages need further attention. This makes the cutover review concrete instead of reducing it to whether the homepage looks correct on one device.

Keep the move recoverable and monitor the result

Use a release process that can recover the previous working version if the new one has a serious issue. Keep the content sources and the redirect plan. A recoverable deployment is particularly useful when several systems or external destinations are involved in the same launch.

After cutover, open the site through its public domain and repeat the important journeys. Check old links as well as new navigation. Review actual failures with their URLs and response details so the team can distinguish a missing page from a temporary network or caching problem.

Watch the site and Search Console for meaningful changes after the move. Search visibility can fluctuate while pages are processed. Interpret that alongside the technical checks and actual customer journeys, rather than assume that one day's ranking change proves the migration succeeded or failed.

A contained migration check before launch

Select an old service URL, an article URL, a project URL and the contact destination. For each, record the expected public result on the new site. Open the address directly and follow the next step a visitor is likely to take. Include an old link that needs a redirect so the mapping is tested as part of the journey.

Keep this representative check separate from the complete URL audit. The small set helps the team see practical issues quickly, while the full audit checks coverage. Repeat both through the public domain after cutover, where caching, redirects and external destinations can behave differently from the preview. The guide to website enquiry forms covers the receiving information that should survive a platform or interface change.

Frequently asked questions

Does leaving Webflow require new URLs?

No. The public URL structure can often be preserved in the new implementation. Decide which addresses need to change based on the site's structure and content, not simply the choice of platform.

Can every old page redirect to the homepage?

That rarely gives a clear equivalent for specific content. Map useful old pages to relevant destinations and make explicit decisions for pages that do not have a suitable replacement.

Does submitting the new sitemap finish the move?

It is one discovery step. The team also needs to verify pages, redirects, enquiry journeys and live behaviour, then review any indexing or traffic issues that appear afterwards.

Bricks' website and product work treats migration as a content and customer-journey project as well as a technical move. The practical starting point is the existing URL inventory and the decisions behind it.