How We Built Our Own Site — and Why Not With WordPress

DD Pim van den Boomen • 9 June 2026 •5 min

Pillar 02 // The catch

site.md

$ curl -s datadriftdigital.nl | wc -c

How We Built Our Own Site — and Why Not With WordPress

For a search engine without JavaScript, our own website was 58 characters long. Not 58 lines — fifty-eight characters, shorter than this sentence. The rest was only built after the visitor had loaded the page. Below is how we measured that, what the rebuild delivered, and why it didn't become WordPress. Including what we give up in return.

DD DataDrift Digital • June 9, 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 everything that reads your page without a browser — search engines, share previews on social media, and the language models people now ask their questions to — it's 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 instead of assuming 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 out of six were empty to a crawler. The one part that did work was the one thing we'd already removed 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 turns pages into ready-made HTML during the build. Afterward, no program is running; there's just a file, ready to go. The whole build takes three-quarters of a second.

TEXT58 → 1,038 characters visible without JavaScript.

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

AIThe file for language models went from a stub of 211 bytes to 1,258 bytes, generated automatically on 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 matters more than it sounds. These weren't settings that were configured 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 just fine: it builds pages on the server, so a crawler simply sees text. That's not a point of criticism.

The difference comes after that. 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 the most-used break-in route on the web. So you have a server to manage and a security responsibility that comes with it.

A static site doesn't have that. There's no database, no programming language running, no login screen. There are just 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 publishing daily and someone doing maintenance. For a fifteen-page site that changes once a month, you're buying a job you didn't need.

04 / what we give upWho can still publish now?

I can. And that's a problem, not a footnote.

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, which means someone with technical access has to be involved.

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

There is a way out: decoupling form and content, so that the text comes from an environment with an editor while the design stays in the code. That's prepared on our side 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 already?

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 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 this because otherwise we'd be doing exactly what we criticize others for: presenting a result as if it were production. The measurement holds, the rebuild works, and it isn't live yet.

What you can take from this, even without us: measure your own site before hiring an agency to improve your findability. 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 notices nothing of this. A crawler that doesn't execute JavaScript only sees that empty shell. For 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. For a more precise check: 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 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.

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.

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.

30 minutes, free, no sales pitch

Want to know what a crawler sees of your site?

Plan a conversation

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

→ Plan a conversation (30 min)

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