Overview
Whether you're rebranding, targeting new audiences, or simply restructuring your content, splitting your existing Webflow site into multiple projects can be a significant but manageable task. This resource will guide you through the process to help you achieve a smooth transition for your website and visitors.
Note: This resource is tailored for existing/live Webflow sites with standard hosting setups where your domain is pointed to Webflow servers using our DNS records, and assumes that a single enterprise site is being split into two live domains (e.g., domainA.com and domainB.com). The decoupling process for alternative setups (such as those with a reverse proxy or those that will result in more than two sites) may entail some of these steps and/or additional configurations (e.g., in external servers or in additional projects).
Disclaimers
Before making the decision to split your projects, it’s important to understand how doing so can potentially impact your site performance and team’s workflows.
- Splitting a website into two domains can have short-term negative effects on SEO due to changes in domain authority, backlink distribution, etc. When you split your site, that SEO equity built up by the original site will need to be redistributed between the two new domains. This can impact the search visibility of both domains, particularly if the original site had a strong SEO presence. However, negative effects can be mitigated, and the SEO performance of both domains can recover over time.
- Managing multiple Webflow sites can affect your team’s workflows, particularly if any design elements (such as classes, styles, or components) or content are shared between both sites. Although Webflow is working toward the release of Workspace Libraries that will streamline this process, it isn’t yet available; in the interim, you would instead copy/paste content between sites or develop custom integrations to sync data between them, each of which may introduce inefficiencies or additional complexities.
Planning
Before beginning the split, it's essential to plan thoroughly.
General considerations
- Choose and purchase a new domain: If you don’t yet own the new domain or subdomain for your new project, you can purchase a domain from any domain name provider, or you can plan to buy a domain and connect it to your site automatically through Webflow (from IONOS).
- Choose and purchase a new site plan: If your Webflow subscription doesn’t yet include an additional hosting/site plan for your new project, contact your Webflow account team (i.e., your Account Executive or Customer Success Manager) for more information. A site plan is required to bypass some of the Designer limits during development, as well as for hosting your new site when you’re ready to launch.
- SEO considerations: Assess the SEO impact of the split and plan strategies to measure or minimize any potential negative effects on your search engine rankings.
- Content audit: Review your existing site's structure and content. Identify which elements will be included in the new project; this is a great opportunity to also identify any outdated content that can be refreshed or removed.
- Note: If duplicated content is shared between
domainA.com and domainB.com, identify any needs for canonical tags; these indicate the preferred version of the content to search engines and helps you avoid potential SEO penalties for duplicate content. Ensure that each domain has unique, high-quality content to avoid issues with duplicate content penalties.
- 301 redirect mapping: Some of the content in your current site will be migrated and subject to URL changes (particularly for its new top-level domain, potentially along with updated slugs and subdirectories). Create a comprehensive list of old URLs and map them to their corresponding new URLs.
- Note: For ease of uploading your 301 redirects into your current Webflow site during a later step, create this list as a CSV file with two columns. The left column should contain old URLs as a relative path (the slug or subdirectory only, excluding the top-level domain of the current project) and the right column should contain the new target URLs (these will likely be absolute URLs including the new domain for your new project, but may contain updated relative paths as well).
Development environments and workflows
A major part of the planning process, you’ll need to decide on your upcoming development environments and workflows. Generally, you will take either one of the following approaches, each of which has different considerations.
Existing project + new project
In this approach, you will continue to use the current Webflow project that your live site is hosted on (e.g., domainA.com). You will duplicate that existing project, and the copy will be used for making the changes that will be served on your new site (e.g., domainB.com).
Advantages:
- Does not incur any downtime for the current live site (at the time of launching the new site) since there will be no changes to its domain
- Minimizes the number of surface areas to update when changes are made to the current live site during your development cycle
- Decreases disruption to API integrations or Apps that can continue to use existing authentication methods and IDs (e.g., site ID or CMS item IDs) — Note: Some changes will be required anyway if integrations are also required for the new site
- The historic data (such as Site Activity log events, backups, and form submissions) for your current live site will be retained within that project (but it will not carry over into the project copy for the new domain)
Disadvantages:
- Although updates to your live page content and page settings can be isolated and staged on page branches, Webflow does not currently support the ability to schedule unpublish events for static pages or CMS items (for the content being migrated out of domainA → into domainB). Neither can updates to your Site settings be branched. These sorts of changes must occur shortly before the split goes live, or during a freeze to reduce the risk of changes being unintentionally pushed to production.
- When you hold staged changes in your staging environment, your staging domain and production domains will be out of sync, which blocks single-item CMS publishing or scheduling (and API requests to those related endpoints).
Two new projects
In this approach, you will duplicate your current Webflow project twice. One of the copies will be used to stage the changes for your current site (domainA, for which the domain will be transferred to the copied project at a later step) and the other copy will be used for making the changes that will be served on your new site (domainB).
Advantages:
- Changes to both projects are independent of and isolated from your production site. This significantly reduces any risk of changes accidentally going live and eliminates any potential blockers to CMS publishing or scheduling and API requests in production.
Disadvantages:
- May incur a brief moment of downtime for the current live site at launch since your domain (
domainA.com) must be transferred from the current project to the new copy (depending on whether you manually transfer the domain or automatically transfer the site plan) - Any existing API integrations or Apps will need to be re-authenticated and pointed to new IDs (e.g., site ID or CMS items IDs) for both sites
- If any changes are made to your current live site after it’s been duplicated, you’ll need to re-do that change in the copied project(s) as well
- The new copy (for your current live site on
domainA.com) will not have any of the historic data from the original project
Disclaimers about duplication
Each approach listed above will involve some level of duplicating your Webflow project. When you duplicate a site, some content and settings are copied by default and some are not carried over at all, whereas you have the option to select some others. Please be aware of the following behaviors.
- Duplicated by default: Styles, pages, assets, CMS Collections and items, Ecommerce products and categories, secondary locales (excluding their publishing statuses), custom code, custom fonts, favicon, and web clip
- Selectable for duplication: Hosting (301 redirects, Advanced Publishing settings, custom security headers), SEO (indexing and sitemap settings), and native integrations (e.g., Google Analytics and Meta Pixel IDs)
- Not duplicated: Form notification settings, form submissions, form settings, reCAPTCHA keys, backup versions, site members (those with site-specific access and content editors using the legacy web Editor), API keys, site plan, and publishing statuses of secondary locales
Learn more in Duplicate a site.
Preparing your sites
Prepare your Webflow sites by checking for and implementing any necessary changes.
Both sites
- Delete content or change their statuses to Draft: In each project, identify the content that belongs to the other. You may need to delete it or change its page or item status to Draft, which will ensure it’s not published to the project that it has been split from.
- Note: As indicated in the workflow considerations above, be careful about deleting or drafting content in your main project if it’s still being used for your live production site.
- Update internal links: Update any internal links that direct visitors to pages getting split into a separate project. This will be especially relevant for relative paths, Page type links, or Collection page type links that may otherwise result in a 404 error; these links will likely require new absolute page URLs for the migrated content.
- All other settings: Be sure to check all the Site settings for your duplicated site(s) and make any other adjustments as needed (e.g., form settings, integrations, site members, etc.).
New site (domainB.com)
- Update custom code: If you have any custom code snippets or integrations (e.g., analytics, experimentation, or cookie consent tools) that are tied to the original domain, update them accordingly to avoid disruption of services or expected functionality for the new site.
- SSL certificate for new site:
- If you have Webflow’s standard SSL enabled, no action is needed since Webflow will automatically generate a new SSL certificate for your new domain.
- If you plan to use a custom SSL certificate for your new site, you must upload new SSL certificates for your new domains (even if it is the same custom certificate being used for the original site), including the www and non-www versions of your new domain.
- Security headers: If you have enabled any custom security headers and copied them into the project for your new site, check for directives that reference the old domain and update them accordingly to prevent unexpected behavior, such as critical resources getting blocked.
- Canonical tag: In the project for your new site, update the canonical tags with your new domain so that search engines can understand it is now the primary or preferred version to display in search results. If your Global Canonical Tag URL is set in Webflow, you can update this globally from your Site settings.
- Sitemap: In the project for your new site, auto-generate a sitemap or add/update a custom sitemap that reflects the new domain.
Original site (domainA.com)
- 301 redirects: As previously noted, some of the content in your current site will be split and migrated to your new project, undergoing URL changes to its top-level domain. You may have also updated the slugs and subdirectories for pages and CMS items. At this point, you can upload your 301 redirects in your original project to ensure those redirects take effect upon launch, routing users to their new URLs on your new domain.
- Note: To redirect an existing static page on your Webflow site to a new URL, you’ll need to first delete or save the page as a draft, or change its slug before setting the redirect. To redirect an existing Collection item page on your Webflow site to a new URL, you’ll need to archive, delete, or unpublish the item, save it as a draft, or change its slug before setting the redirect.
Connecting your domain(s)
When it's time to launch your newly separated sites, follow these steps to deploy the changes to the live domains.
IMPORTANT: Connecting a custom domain and publishing your Webflow site requires a hosting plan for each hosted project. If you have not yet obtained the site plan(s) from your account team, be sure to do so now to prevent any potential delays with your launch or extended periods of site downtime during the cutover process.
Original site (domainA.com)
Existing project + new project
If you followed the first approach (Existing project + new project) that was mentioned earlier, you will not need to make any changes to the domain settings for your original site. You’ll just need to publish all your staged changes into your production environment to go live!
Two new projects
However, if you went with the second approach (Two new projects), you will now need to transfer your domain from the original Webflow project to the duplicated one with all of your staged changes. You can do so in one of two ways.
Manually transferring your domain
If you choose to manually transfer your domain, you must first remove the domain from the original project (via the Site settings > Publishing page). This will unpublish your live site and begin to incur downtime.
As quickly as you can — it helps to readily have the new project’s Site settings up in another tab — you should follow the steps below to reconnect your domain to the project and get your site back online again.
- Add the domain: In the new project for your first domain (e.g.,
domainA.com), go to its Site settings > Publishing page, and add your new domain as a custom domain under the Production section. - Update your DNS records: Through your DNS provider, create or update the DNS records provided by Webflow on your Site settings page. Your A records and CNAME records should be the same as your current DNS records, unless you’ve made a change to your SSL setup. However, you may have to add a new TXT record for domain verification (depending on when it was last verified).
- If possible, verify your domain ahead of time (with the TXT record provided by Webflow), as you won’t be able to publish to your new domain until the verification process is complete.
- Note: Consider reducing the time to live (TTL) values for relevant records, at least a few days prior to the anticipated DNS change. This will reduce the DNS propagation time, making the switch to Webflow faster and decreasing the potential length of downtime. Once DNS has propagated, TTL can be restored to normal levels.
- It may take some time for your DNS records to propagate. Once you’ve confirmed your domain is pointing to Webflow (through the “Check status” step), you can move on to the next step.
- Set your default domain: Once your DNS records have propagated, set your domain as the new default domain for your site.
- Note: Most DNS providers will only allow you to use the 'www' version of your site as the default. Using the root domain as your default may not be supported by your DNS provider, which can then result in redirect errors.
- Publish changes: Publish your Webflow project to use it as your new live site.
Transferring your site plan
If you choose to automatically transfer your hosting plan between sites, you can transfer your site plan and domain without incurring any downtime. However, you’ll need to first ensure that the new project does not already have a hosting plan connected to it.
Note: Only Workspace Owners and Admins can transfer Site plans between sites in a Workspace. Site plans can only be transferred between sites in the same Workspace.
When you transfer your site plan from the original project to the new one:
- The original project is downgraded to a Starter site plan and it remains published to the custom domain (
domainA.com) until the new site is published to it - The new project inherits the Enterprise site plan from the original, including its custom domains and default domain setting. It does not inherit other Site settings, such as form settings, Apps, and integrations. It is not automatically published to the transferred custom domain, so the new site must be published in order for the changes to take effect.
To transfer a Site plan from one site to another:
- In the original project, open its Site settings > Billing tab
- Click Transfer plan and choose the site to which you want to transfer your Site plan (the new project)
- Click Continue
- Review the summary of the transfer
- Click Transfer plan to confirm
Once the transfer is complete, you can go to the Site settings > Publishing tab of the new site to publish it to your custom domain, which will push the changes live.
New site (domainB.com)
- Add your new domain: For the new site (e.g.,
domainB.com), go to its Site settings > Publishing page, and add your new domain as a custom domain under the Production section. - Update your DNS records: Through your DNS provider, create or update the DNS records provided by Webflow on your Site settings page.
- Be sure to verify your domain ahead of time (with the TXT record provided by Webflow), as you won’t be able to publish to your new domain until the verification process is complete.
- Note: Consider reducing the time to live (TTL) values for relevant records, at least a few days prior to the anticipated DNS change. This will reduce the DNS propagation time, making the switch to Webflow faster and decreasing the potential length of downtime. Once DNS has propagated, TTL can be restored to normal levels.
- It may take some time for your DNS records to propagate. Once you’ve confirmed your domain is pointing to Webflow (through the “Check status” step), you can move on to the next step.
- Set your new default domain: Once your DNS records have propagated, you can set your new domain as the new default domain for your site.
- Note: Most DNS providers will only allow you to use the 'www' version of your site as the default. Using the root domain as your default may not be supported by your DNS provider, which can then result in redirect errors.
- Publish changes: Publish your Webflow site with the new domain for it to go live.
Post-launch tasks
After launching the newly split sites, don’t forget these crucial tasks.
- Inform search engines:
- For the original site, ask search engines (e.g., via Google Search Console) to recrawl and index the new changes to your site.
- For the new site, submit its sitemap to Google and other search engines.
- Monitor for 404 errors: Continuously monitor for any 404 errors and promptly set up redirects for any broken URLs.
- Update external links: Update any external links pointing to your websites to reflect the appropriate domains.
- Communicate with users: Inform your audience (e.g., site visitors, customers, directory partners, media partners, etc.) about the new site via email, social media, or website notifications to avoid confusion.
Summary
By following these steps, you can successfully split your Webflow site into two projects on separate domains while ensuring a seamless transition for your audience. Whether you're embarking on a rebranding journey or refining your content strategy, this guide will help you navigate the process with confidence.