Website Builder Lock-In: What Happens When You Want to Leave

When you leave a hosted website builder, you can usually take your domain, your text and your images, but often not the design, the layout or anything that ran on the builder's servers, such as forms, member accounts or a store. Your search rankings survive the move only if you keep your URLs or redirect every old one to its closest new page. The cheapest exit is the one you plan before you need it, or the one you avoid by owning your site's code from the start.

What lock-in really is

Lock-in is rarely a contract. Nobody stops you from leaving. It is the cost of leaving: the hours spent rebuilding what you cannot export, the features you have to replace, and the risk to search traffic you spent years earning. A builder can be pleasant to use and still expensive to leave, and you usually find out which only when you try.

The trigger is rarely your choice, either. It tends to be a price rise, a plan change that removes a feature you rely on, an editor redesign, an acquisition, or a new developer who wants the site in the company's codebase. The alternative is to start with an AI website builder that exports your code, so leaving is a change of tools rather than a rebuild. If you are already on a hosted platform, here is what to expect.

What you can usually take with you

Every platform is different, so check yours, but the general pattern looks like this.

What	Usually portable?	Why
Domain name	Yes, if it is registered in your name	Domains are designed to move between registrars
Text	Yes	You can copy it, or export it where an export exists
Images	Usually	Download the originals; do not rely on the builder's image links
Blog or CMS posts	Sometimes	Some platforms offer a file export; others mean copy and paste
Design and layout	Often not	The design is stored in the builder's own format and drawn by its own software
Forms	The submissions, maybe; the form, no	The inbox behind the form is the builder's service
Store, bookings, members	Rarely as they are	Product lists may export, but checkout, accounts and passwords do not move
URLs	Yes, if you plan for it	Paths are just text, and you can recreate them on the new site
Search rankings	Yes, if URLs are kept or redirected	Rankings follow content and addresses, not the platform

The pattern: content is portable, while presentation and services are not. The design is the part people underestimate, because it feels like theirs too. In many hosted builders it exists only inside the builder.

The dependencies people forget

Before you plan anything, find the ties you do not notice day to day.

• Where the domain is registered. If you bought it through the builder, it may sit in the builder's registrar account. Find out who the registrant is and how a transfer works.
• Email on your domain. Your mail runs on MX records in the same DNS as the website. A careless DNS switch can stop email, which hurts more than a broken page.
• Image links elsewhere. If newsletters, partner sites or directory listings point at images hosted by the builder, they break when your account closes.
• Integrations. Analytics, chat widgets and tracking pixels may have been added through the builder's settings rather than through your own accounts. Move them to accounts you control.
• The builder's URL patterns. Some platforms add a fixed prefix to blog or product URLs. Your new site may not use the same pattern, which means more redirects.

How to plan an exit

Work in this order. Most of it can happen while the old site stays live.

1. List every URL. Start from the old site's sitemap.xml, add any page Search Console shows getting impressions, and put them all in a spreadsheet. This list is the backbone of the move.
2. Export and download everything you can. Text, posts, form submissions, product data and original images. Keep them somewhere that is not the builder.
3. Secure the domain. Confirm you are the registrant and write down the current DNS records, especially MX for email. If you are moving registrars, remove the transfer lock and request the transfer code.
4. Rebuild the design. If the builder cannot export it, use your current site as the reference for the new one. An AI builder can take your current site's look from its URL, meaning its grid, type, colors and spacing rather than a section-by-section copy, and you then put your own words and images back in.
5. Replace the services. Choose a form tool, a booking tool or a store for anything that ran on the builder's servers, and link to them from the new pages.
6. Map old URLs to new ones. Keep the same paths wherever you can. For each URL that changes, plan a 301 redirect to its closest new equivalent. Our redirect map guide walks through building that list.
7. Carry the SEO over. Copy each page's title, description and headings across, and update internal links to point at the new paths directly instead of leaning on redirects.
8. Switch DNS at a quiet time, and keep the old site reachable until you have checked the new one.
9. Check after launch. Test a sample of old URLs, submit the new sitemap in Search Console, and watch for not-found errors for a few weeks.

Google's guide to moving a site with URL changes is the reference for steps 6 to 9.

Redirects: the part that protects your traffic

A 301 redirect tells browsers and search engines that a page has moved permanently. Google treats a permanent redirect as a strong signal that the new address should replace the old one in its results, as its documentation on redirects and Google Search explains. Three rules keep them working for you:

• One to one, not all to the homepage. Send /services/kitchen-remodeling to the new kitchen page, not to the homepage. Pointing many old pages at one unrelated page throws away the match between what people searched for and what they land on.
• No chains. Go from the old URL to the new URL in one hop, not through a series of intermediate pages.
• Keep them for good. Old links in emails, bookmarks and other people's sites keep arriving for years.

Where you set redirects depends on the host. Static hosts usually let you list them in a file or a dashboard setting; Cloudflare Pages, for example, reads a plain _redirects file placed with the site's files.

Owning the code from day one

The way to make an exit cheap is to never be all the way inside. That means a site whose source lives in your own GitHub repository or on your own computer, in a standard format, deployed to a host you chose.

It changes the math of leaving. If you stop using the tool that made the site, the site keeps running, and the next person edits the code or brings it into another tool. You lose the convenience of that tool's editor, but you do not lose the site, its URLs or its rankings.

Owning code is not magic, and it comes with duties. Someone has to make changes, either in a builder that exports again or by editing the code directly. Forms, bookings and stores still come from separate services. The upside is that those services are independent too, so you can swap any one of them without touching the others.

Before you commit to any builder, ask it these questions:

• Can I export the site as code that runs without your scripts?
• Are my images included in the export?
• If I move, can I keep my existing page addresses?
• Is the domain registered in my name, with a registrar I can leave?
• What happens to my live site if I stop paying?

Our ten-step test for any builder's code export shows how to check the first two answers yourself, before you build anything real.

How FNJ avoids lock-in

FNJ's AI builder does not host your site at all. It exports a Next.js App Router project or static HTML, or pushes the code to a branch of your own GitHub repository, with your images copied into the project and no FNJ runtime, script or badge in the code, so the site keeps working if you stop using FNJ. You host it on Cloudflare Pages, Vercel, Netlify or any static host you like. See what the export includes in FNJ's AI website builder with code you own.

Frequently asked questions

What can I take with me when I leave a website builder?

Usually your domain (if it is registered in your name), your text and your original images. The design, forms, store checkout and member accounts often stay behind, because they depend on the builder's own software and servers.

Will I lose my Google rankings if I switch website builders?

Not for long if you keep the same URLs or 301-redirect each old URL to its closest new page, and carry over titles, descriptions and headings; rankings can fluctuate for a while after any move. Rankings follow content and addresses, so the lasting risk comes from missing or broken redirects.

Can I move my domain away from a website builder?

In most cases, yes, if you are the registrant. Remove the transfer lock, get the transfer code from the current registrar and start the transfer at the new one, keeping your email's MX records in place.

How do I avoid website builder lock-in?

Choose a tool that exports standard code you can host anywhere, keep that code in your own GitHub repository, register your domain in your own name, and use separate services for forms, bookings and payments. Then leaving any one tool is a small change rather than a rebuild.