The catch

A WordPress alternative in practice: how we built our site

Q: Is WordPress a bad choice?

No. WordPress builds pages on the server and so doesn't have the problem from this post. The difference is in maintenance: a database, a running programming language and usually about ten plugins, all of which get updates. If you have an editorial team publishing often and someone doing the upkeep, it's a fine choice. For fifteen pages that rarely change, it's more machine than needed.

Q: What does hosting a static site cost?

Nothing, in practice. Serving ready-made files falls within a free tier with several providers, even at normal visitor volumes. You only pay for your domain name. The cost shifts entirely from hosting to build hours, which is exactly where it belongs.

Q: Can someone without technical knowledge edit the text?

Not right now, and that's the honest drawback of this approach. A text change is a change in the code. A solution exists — having the text come from an environment with an editor while keeping the design in the code — and it's prepared on our side but not yet connected. Anyone who waves this drawback away is selling you a site that won't be updated in six months' time.

For a search engine without JavaScript, our own website was fifty-eight characters long. How we measured that, what the rebuild delivered, and why this is about visibility and not taste.

DD Saga • 9 June 2026 •5 min

← back to home

Pillar 02 // The catch

site.md

$ curl -s datadriftdigital.nl | wc -c

A WordPress alternative in practice: how we built our site

We rebuilt our site with Astro, a generator that converts pages into ready-made HTML during the build. The reason: for a search engine without JavaScript, our homepage was 58 characters long. Below is how we measured that, what the rebuild delivered, why it didn't become WordPress, and what we give up for it.

DD DataDrift Digital • 9 June 2026 • 6 min

A modern page builder often delivers an empty shell: a small piece of HTML with a reference to a JavaScript file that assembles the actual page in the visitor's browser.

For a visitor, that makes no difference. For anything that reads your page without a browser (search engines, share previews on social media, and the language models people now put their questions to) it makes the difference between a page and nothing.

So this isn't an aesthetic story. It's about whether you get found.

01 / the measurementWhat does a crawler see of our site?

Almost nothing. We measured it rather than assumed it.

The measurement is simple: fetch the page the way a search engine does, without executing JavaScript, and count the visible text. Six of our own addresses, measured on one day:

58The main site. 3,463 bytes of HTML, of which 58 characters were readable text.

0The quiz. Zero characters. For a search engine, that page doesn't exist.

36The course environment. 36 characters.

54The landing page. 54 characters.

584The checkout page. 584 characters, partly built on the server.

OKThe blog. Fully readable. The only surface that had already moved.

Four of the six were empty for a crawler. The only part that did work was the only one we'd already moved away from the page builder. That's not a coincidence, that's the conclusion.

02 / the rebuildWhat did the rebuild deliver?

A factor of eighteen on the only axis that counts.

We rebuilt the homepage with Astro: a generator that converts the pages into ready-made HTML during the build. After that, no program runs any more; a file sits ready. The whole build takes three-quarters of a second.

TEXT58 → 1,038 characters visible without JavaScript.

HTML3,463 → 9,595 bytes. More content, no heavier page for the visitor.

AIThe file for language models went from a stub of 211 bytes to 1,258 bytes, automatically generated with every build.

BASICSSitemap, canonical addresses, share previews and the language setting were completely missing. Now they're there, without anyone having to think about it.

That last line is more important than it sounds. These weren't settings that were set wrong: they didn't exist.

Hosting: €0 per month. Serving static files is free with several providers.

03 / why not WordPressWhat are you actually comparing?

Not the quality of WordPress. What you have to maintain.

WordPress solves the problem above perfectly well: it builds pages on the server, so a crawler simply sees text. That's not a point of criticism.

The difference comes after. WordPress is a program that runs, with a database, a programming language and usually about ten plugins. All of that gets updates, and updates you don't install are a common break-in route on the web. So you have a server to manage and a security responsibility on top.

A static site doesn't have that. There's no database, no programming language running, no login screen. There are files. There's almost nothing to break into.

The safest server is the server that runs nothing.

So: WordPress is a good choice if you have an editorial team that publishes daily and someone who does the maintenance. For a site of fifteen pages that changes once a month, you're buying a job you didn't need.

	WordPress	Static site (Astro)
What a crawler sees	Pages are built on the server, so a crawler simply sees text.	Ready-made HTML sits ready as a file; a crawler sees the full text.
Maintenance	A database, a programming language running, and usually about ten plugins, all of which get updates.	There are files. No database, no login screen, almost nothing to break into.
Editing text	Via an editor: click, type, save.	A change in the code; someone with technical access is needed.
Best for	An editorial team that publishes daily and someone who does the maintenance.	A site of fifteen pages that changes once a month.

04 / what we give upWho can still publish now?

I can. And that's a problem, not a side note.

A page builder has an editor: you click on the text, you type, you save. Astro doesn't have that. A text change is a change in the code, and that means someone with technical access is needed.

That's precisely why we ended up in a page builder in the first place. Anyone who waves away this drawback is selling you a site that won't be updated any more in six months' time, because it's too much hassle and whoever can do it is busy.

There's a way out: decoupling form and content, so the text comes from an environment with an editor while the design stays in the code. That's prepared on our end but not yet connected. As long as that's the case, this is an honest drawback, not a solved problem.

05 / the current stateIs this live yet?

No. At the time of writing, the new site is on a test address.

It's a build experiment with a proven outcome, not a launch. No domain name is connected, nothing on the existing site has been changed, and the blog hasn't been touched. Anyone going to our main address today still gets the old page with those 58 characters.

We're saying that because otherwise we'd be doing exactly what we accuse others of: presenting a result as if it's in production. The measurement holds, the rebuild works, and it isn't online yet.

What you can take from this, even without us: measure your own site before you hire an agency to improve your visibility. Turn off JavaScript in your browser and load your homepage. What you see then is roughly what a search engine sees.

Frequently asked questions

Why is a page "empty" for a search engine?+

Because some page builders only send a small piece of HTML with a reference to a JavaScript file that assembles the actual page in the browser. A visitor doesn't notice anything. A crawler that doesn't execute JavaScript only sees that empty shell. On our own homepage, that left 58 characters of readable text.

How do I measure this myself?+

Turn off JavaScript in your browser and reload your homepage. What you see then approximates what a search engine sees. If you want it more precise: fetch the page with a command-line tool that doesn't execute JavaScript and count the visible text. It takes five minutes and it's the cheapest check you can do on your site.

Is WordPress a bad choice?+

No. WordPress builds pages on the server, so it doesn't have the problem described in this post. The difference lies in the maintenance: a database, a programming language running, and usually about ten plugins, all of which get updates. If you have an editorial team that publishes often and someone who does the management, it's a fine choice. For fifteen pages that change once a month, it's more machine than needed.

What does hosting a static site cost?+

Only your domain name. Serving ready-made files sits within a free tier at several providers, even with normal visitor numbers. That shifts the cost entirely from hosting to build hours, which is exactly where it belongs.

Can someone without technical knowledge edit the text?+

Not at the moment, and that's the honest drawback of this approach. A text change is a change in the code. A solution exists (having the text come from an environment with an editor while keeping the design in the code) and that's prepared on our end but not yet connected. Anyone who waves away this drawback is selling you a site that won't be updated any more in six months' time.

30 minutes, free, no sales pitch

Want to know what a crawler sees of your site?

Book a call

We'll look at where your time is leaking away and tell you honestly whether we can do anything about it. Often the answer is: you can do this yourself. Then we say that, and you'll have spent thirty minutes on a clear answer.

→ Book a call (30 min)

This text was produced with AI assistance and checked and approved by a human before publication.