Website builder or custom code: when a site is worth moving

A question usually asked at the wrong moment

Website builder or custom development is a question almost everyone asks twice. The first time at the start, when there is no site yet and every answer sounds equally convincing. The second time about eighteen months later, when the site exists, works, and something in it has stopped being possible.

The first time there is nothing real to answer with. No traffic, no enquiries, no sense of which pages will turn out to matter. At that point a builder is almost always the right call, and there is nothing to argue about.

The second time the answer is already in your data — but you have to look at the specific tasks that stopped getting done, not at the platform. That is what this is about.

We made this move ourselves and know what both sides cost, including the part of the bill that articles usually leave out.

What a builder genuinely solves

Start with an honest list of what builders deserve credit for, because this conversation is usually led by people who profit from selling development.

Speed. From idea to a working page in an evening. No agency will be faster, because an agency has a brief, an approval round and a queue.

Predictable cost. A subscription costs the same in March and in September, and does not need its own line in the budget.

No technical debt on your side. Updates, security, certificates, backups — the platform's problem. That is real work, and on your own site it costs either money or nerves.

The ability to change text without involving anyone. This is underrated. A site whose owner cannot make an edit themselves ages faster than any other.

If your site is ten or twenty pages that change once a quarter, a builder covers the job completely and you do not need to move.

Where a builder runs out, and it is not design

A common misconception: people leave builders because they want something prettier. Almost never. Modern templates look decent, and bad design happens on custom code just as often.

People run out in three other places.

First, data. As soon as the site contains something that lives in a table — a catalogue with filters, a schedule, a property database, prices that move — a builder starts demanding manual labour that grows linearly. A hundred items can still be handled by hand. A thousand cannot.

Second, integrations. An enquiry has to reach the CRM, a payment has to clear the right gateway, the warehouse has to report stock. On a builder every link in that chain runs through an intermediary service, and a four-link chain breaks where you cannot see it.

Third, control over what is served to search engines. Response headers, canonical addresses, structured data, the sitemap, load speed. On a builder you control these exactly as far as the platform decided to let you, and you find the limit precisely when you hit it.

Five signs you have hit the ceiling

None of these alone is a reason to move. Three at once is a conversation.

You regularly pay for third-party services to work around a platform limitation. Count those subscriptions as part of the cost of the builder — they usually double it.

The same edit takes hours because it is made by hand across twenty pages. This is not about convenience: it means the data structure does not match the job.

You cannot answer why one specific page loads slowly. Not know-but-cannot-fix — literally cannot look.

A developer you hired for an improvement begins their sentence with on this platform you cannot, but we could try.

The site makes money and the cost of downtime exceeds the cost of development. That is not about platform capability; it is about keeping a revenue-critical asset under your own control.

What a move actually costs: 673 addresses

Now the bill nobody shows you. Building the new site is the smaller half of a migration. The larger half is what happens to the old addresses.

Our site moved off its previous platform, and over the years the search engine had learned hundreds of addresses. After the change of engine they stopped existing. In the Search Console report that reads as 673 addresses returning not found.

Each of those is either a page somebody still links to, or a search position you are giving up, or both. Working through them cannot be fully automated, because the decision on each address is editorial: is there a page on the new site that answers the same question?

Hence the practical rule: the map between old and new addresses is drawn before development, not after launch. Take the inventory from the old platform and from Search Console separately, because the two lists will not match — the search engine knows addresses you have forgotten.

And separately, what not to do: redirect every old address to the home page. It looks like a solution and is not one — search engines read such redirects as a soft error, decline to index, and you lose the data about what people were looking for.

Why traffic falls even after a careful migration

Worth knowing in advance, so you do not mistake a normal process for a failure.

After a move the search engine has to re-crawl the whole site, match old addresses to new ones, and carry across the signals you accumulated. That takes weeks, sometimes months, and positions fluctuate meanwhile.

A twenty to thirty per cent dip in the first weeks is ordinary for a correctly executed migration. The warning sign is different: traffic that does not recover within two or three months, or a fall concentrated in one section rather than spread across the site.

Which is why migrations are not scheduled at the peak of a season. If December makes half your annual revenue, move in February.

Search visibility on builders, without the myths

The claim that sites built on builders cannot rank is false, and it is repeated most often by people selling development.

A search engine does not ask what a page was made with. It looks at what the page serves: content, speed, structure, markup. A builder page with good text will beat a custom-coded page with bad text, every time.

The real difference is the ceiling and the response time. When you need to change something the platform gives you no access to, on custom code that is half an hour; on a builder it is a support ticket with an unknown outcome.

And load speed. Builders ship a universal bundle of scripts because they cannot know in advance what you will need. Custom code ships only what is used. The difference is usually not catastrophic, but it is visible on mobile traffic — and Core Web Vitals are measured on real visits.

When you definitely should not move

Three situations in which development will not pay for itself, however convincingly it is sold.

The site brings no enquiries and you hope a new one will. It will not. If the problem is that nobody finds you or the offer does not convince, the platform has nothing to do with it, and after the move you will have the same zero enquiries at greater expense.

You do not like how the site looks. Design on a builder changes in a week and costs a fraction of development.

Somebody told you there is no SEO on builders. Before believing it, ask them to show which specific change is impossible. If no answer comes, it is not an argument.

The hybrid that is often the right answer

Between everything on a builder and everything custom sits a middle option that is oddly rarely offered.

The part of the site that lives on data and makes money — the catalogue, the account area, a price calculator — is built on custom code. The rest — the blog, the about pages, campaign landings — stays where the owner edits text themselves.

Technically this is one domain split by path. To a visitor and to a search engine it is a single site.

The gain is that development is paid for only where it returns something, and an editor does not queue to fix a comma. The cost is having to keep both halves looking like one site.

For most businesses whose site already works and already earns, this is a saner step than rewriting everything.

Export: check it before you need it

One thing worth establishing in your first month on any platform, rather than on the day you decide to leave.

Exactly what you can take with you. Text — nearly always. Images at original size — not always: some platforms only return compressed versions prepared for their template. A catalogue structure with attributes — rarely in usable shape. A list of page addresses — almost never without pulling it from a search console.

This takes fifteen minutes to check: find the export in settings, run it, open the file. If it contains markup tangled with text and images referenced on somebody else's domain, you now know the price of a future move.

Images deserve their own note. Links to files stored on the platform's side stop working once the subscription ends. A site that moved with those links intact loses every illustration on the day the paid period runs out.

None of this is an argument against builders. It is an argument for keeping your own source text and images from day one, whatever the site is built on.

How to decide in one evening

Take the list of things you wanted to do to the site over the past six months and did not do. Wanted and did not do — not it would be nice.

Next to each, write the reason: the platform will not let me, too expensive, no time, never figured it out.

If more than half come down to the platform will not let me, a move is justified. If they come down to no time and never figured it out, moving changes nothing, and the money is better spent on somebody who will finish the tasks.

It is a crude test, but it works better than comparing feature tables, because it rests on what you actually need rather than on what somebody decided was important.

One last word on the phrasing. Website builder or custom development is a badly posed question, because it implies a choice made forever. In practice it is a choice for the next two years, and the right answer changes as the job the site has to do changes.

What we would do differently

Two things that cost us time.

The inventory of old addresses should have been taken before development, not after launch. Some pages would then have been designed with something to inherit, and 673 addresses would not have become a separate job after the fact.

And we should have launched in parts. We shipped the new site whole, and when something went wrong there was no way to tell which part was responsible. Section by section is slower, but every step is verifiable.

Neither is about choosing a platform. Both are about treating a migration as a project with its own risks rather than as a change of design agency.