Moving off a page builder

Check what you own first

The domain, the content and the customer data should all be yours. Confirm the domain registration is in your name and under your control before anything else happens.

Domains registered by a provider on your behalf are the single most common obstacle to leaving one. Sorting it out while you are still a customer is far easier than afterward.

Then check what the export actually produces. Some platforms export clean content, some produce markup nobody can reuse, and finding out early changes how much work the move is.

Record every address

List every page address on the current site before touching anything. That list is what protects the links other sites have built to you and the positions your pages currently hold.

Keeping the same addresses removes the problem entirely. Where the structure genuinely improves, map each old address to its closest new one with nothing left unmapped.

Then redirect permanently, in one hop. Our page on redirects covers the difference between the two kinds and why chains cost you on every request.

What gets lost in a move

Form submissions and their destinations. A contact form that silently stops delivering is the most damaging migration failure, and it is invisible until somebody mentions they never heard back.

Alt text, which frequently lives in a platform field rather than in the exported content. So do page titles and descriptions on some platforms.

And any redirect the old platform was handling for you. Those disappear with the account, which means addresses that were working stop working with no warning at all.

Custom code snippets are another. Tracking tags, booking widgets and anything a previous developer pasted into a platform field rarely appear in an export, and their absence is only noticed when a report stops filling in.

The migration checklist

Working in this order means the irreversible steps come last, and the old site stays available until the new one is proven.

• Confirm the domain is registered in your name
• Export content and record every page address
• Save images at full size, with their alt text
• List every form and where its submissions go
• List every existing redirect
• Build and test the new site before switching
• Switch, then check every old address resolves

Testing before the switch

Build the new site somewhere it can be viewed without being indexed, then check it against the old one page by page. Reading the list of addresses is not the same as opening them.

Submit every form and confirm the message arrives where it should. Do it from a phone as well as a desktop, since form failures are often specific to one of them.

And run a structural check before you switch rather than after. A check that runs before anything publishes is worth more than an audit afterward. Our site check reports heading order, alt text and link problems across the whole site in one pass.

Check the site on a phone as well as a desktop before switching. Layout problems that only appear on a narrow screen are common after a move, and most visitors to a small business site arrive on a phone.

After the switch

Check that every old address resolves to something sensible, and check all of them rather than a sample. Missed addresses cluster in the parts of a site nobody thought about.

Submit the new sitemap and watch coverage for a fortnight. Our page on the coverage report covers what an ordinary settling period looks like.

Expect some movement and do not react to the first week. Changing things again before anything stabilizes is how a clean migration turns into a confusing one.

When not to move

When the current site works, performs and is maintained. Platform dissatisfaction is a poor reason on its own, and a migration always costs more than the estimate.

When you are in a busy season. Migrations produce a week of small problems, and the week to have them is not the week your phone should be ringing.

And when the real problem is the content. A site that does not work because its pages are thin will not work better elsewhere. Our page on thin content covers that diagnosis.

And when nobody has time to test. A migration needs somebody to open every page, submit every form and read every address list. Without that, the move will appear to work and fail quietly in the parts nobody opened.