Ahosting Logo
Knowledge Base

How to Move from a Website Builder to Your Own Hosting

What comes with you and what does notComes with you· content and images· product data· the domain· your search rankings, if URLs matchDoes not· the design: templates are specific to that platform· built-in features you were using· anything the builder did for you automaticallyWhat becomes yoursUpdates, backups and security. The builder was doing these invisibly, and now nobody is unlessyou arrange it.

Moving from a hosted website builder to your own hosting is mostly a content migration with two hard parts: the builder's platform does not export a website, and the addresses of your pages will change unless you plan for it.

Everything below is about those two.

What you can and cannot take with you

You can take your content (text, images, product data) and your domain, if you registered it or can transfer it.

You cannot take the design. Builder templates are specific to that platform, and the site will be rebuilt on a new theme rather than moved.

You also cannot take anything the platform provided as a feature: their forms, their booking system, their analytics. Each of those becomes a plugin or a service you choose, and that list is worth writing down before you start, because it is where the work actually is.

Get an inventory first

Before touching anything, list every page with its URL.

That list is what you will redirect from later, and it is far easier to collect while the old site is live. Note which pages get traffic. Those are the ones that must not break.

Then export what the platform allows. Most offer some export: content as a file, products as CSV, sometimes a full archive. Take everything offered, including images at full resolution.

Build on a temporary address

Set up the new hosting and build the site there while the old one stays live. Your host can give you a temporary address, or use a subdomain you control.

Two rules while you do that. Keep the site out of search results until it launches, and remember to turn that off at launch, because the setting travels with the site and is the most common launch mistake there is. The launch checklist deals with checking for it.

And do not point the domain at the new site until it is genuinely finished. There is no benefit to switching early and there is a cost.

Match the URLs where you can

The decision that determines how much traffic survives.

If the old site had /services/consulting, create the same path on the new one. Every matching path is a redirect you do not have to write and an inbound link that keeps working.

Builders often use particular patterns. A blog under a fixed prefix, for instance, and reproducing those in WordPress is usually a permalink setting rather than a compromise. Permalinks and .htaccess sets out the structure.

Where you cannot match, plan a redirect from each old path to the closest new page.

Redirects, from the list you made

Every old URL that does not exist on the new site needs a redirect to its equivalent.

Send each to the matching page, not the homepage. Sending everything to the homepage is treated as pages that vanished rather than moved, and a visitor following a link to a specific article lands somewhere they have to start over. For writing them, see redirecting a domain or page.

Keep them permanently. Links on other sites are never updated.

The domain and the email

Check where the domain is registered before anything else. If the builder registered it as part of your subscription, you need it transferred to your own registrar account, and that takes days, so start early. Getting an EPP code has the detail.

Then check mail. If your email came with the builder, it stops when the subscription does, and moving mail is a separate project from moving the site.

Create the mailboxes on the new host, copy the messages across, and change the MX records only when both are ready. Nothing about the website move handles this for you. Migrating email walks through the sequence.

Images need re-doing

Builders serve images through their own processing, resized and compressed on the fly. Exported originals are frequently the full-size uploads.

Dropping those into a new site produces pages several times heavier than the old ones, and the site feels slower than the thing you left.

Resize before uploading and serve WebP. There is more on the order that works in optimizing images.

What the builder was doing for you

Worth being honest about, because it is the real trade.

Updates, security patching, backups and uptime were somebody else's job. On your own hosting they become yours, or somebody's you pay.

Decide which before you launch rather than discovering it eighteen months later through a compromise. Automatic updates, a backup that you have restored once, and monitoring that alerts you cover most of it. Keeping WordPress updated walks through the maintenance.

In exchange you get to move hosts, change themes, export everything and add anything, which is why people do this. But it is an exchange, not an upgrade in every direction.

Switch, then check the list

Point the domain at the new site, then work through the inventory: load every old URL and confirm it either resolves or redirects.

Check search console for crawl errors over the following weeks, which surfaces the paths you missed while there is still time for it to matter. There is more on getting that set up before you need it in verifying your site and setting up analytics.

Keep the builder subscription for a month. It is the only remaining copy of anything you did not export.

Before rebuilding, it is worth deciding what to rebuild as, since the options differ mainly in what happens later. How to Choose Between a Site Builder, a CMS and a Static Site sets out the choice.