What changes when you own your site's code
We rebuilt leal.st from a site builder into our own code and measured the same 16 pages before and after. HTML per page fell from 254 KB to 59 KB, unique meta descriptions went from 1 to 16, H1 headings from 0 to 16, structured data blocks from 0 to 32, and 1,406 near-invisible elements went to zero. The builder was not slow: it painted faster and shipped fewer bytes. What it could not do was let us add the things agents read, like an llms.txt, a markdown mirror of every article and structured data we control. Owning the code is what turned each of those from impossible into an afternoon.
Published · 5 min read
In short
- The builder painted faster and shipped fewer bytes, and still scored 70 against 100. The entire gap was 1,490 ms of blocked main thread.
- Zero of 15 inner pages had an H1 and 16 of 17 shared one meta description. Those are platform defaults, not somebody being careless.
- Headlines were served as 1,406 elements at opacity 0.001. Crawlers that do not run JavaScript read them as invisible letters.
- Leave a builder when what you need stops being expressable by it, which today usually means the agent-facing layer. Not for speed.
We rebuilt this site. It used to run on a site builder and now runs on our own code, on the same 16 URLs, without a single redirect. Before switching we measured both versions the same way, so this is not an opinion about tools. It is a before and after.
What the builder did well
It served real HTML. Googlebot never needed to run JavaScript to read a page, and that is the single most important thing a platform can get right. It was also fast to paint: first contentful paint at 0.3 s against our 0.4 s, and largest contentful paint at 0.3 s against our 0.6 s. It even shipped fewer bytes in total, 377 KB against our 411 KB.
We are stating that first because it is true, and because most comparisons like this one quietly omit the parts where the old thing won.
What we measured
Same 16 indexed URLs, fetched with a plain HTTP request on both sides, no JavaScript, on 10 August 2026.
- HTML per page: 254.4 KB on the builder, 58.8 KB on the rebuild. The builder repeats the same copy in three breakpoint variants inside one document, so most of that weight is the same sentence written three times.
- Unique meta descriptions: 1 across 17 pages, against 16 across 16. Sixteen pages were competing in search with the same description.
- Pages with an H1: 0 of 15 inner pages, against 16 of 16.
- Structured data blocks: 0, against 32 across nine types.
- Images without alt text: 75 of 85, against 0 of 70.
- Elements rendered at opacity 0.001 in the served HTML: 1,406, against 0.
That last number is the one that matters most
The builder animates headlines by splitting them into one span per character, and it does that in the HTML it serves, before any JavaScript runs. Each span carries opacity 0.001. A browser fixes this in milliseconds. A crawler that does not execute JavaScript does not: it reads the headline as a pile of invisible letters.
Google runs JavaScript, so this rarely shows up as a ranking problem. GPTBot, ClaudeBot and PerplexityBot mostly do not. In 2026 that is no longer an edge case, and it is exactly the traffic a studio wants.
The score that looks wrong until you read it
PageSpeed Insights, desktop, same day: 70 for the builder and 100 for the rebuild. But the builder painted faster and weighed less. The entire gap is one metric, total blocking time: 1,490 ms against 0 ms.
It is not weight, it is work. The builder delivers static HTML quickly and then spends a second and a half on the main thread hydrating components and splitting text into spans. Nothing is downloading during that time. The page is simply not answering.
Why agents changed the calculation
Two years ago this article would have ended at the SEO numbers. It does not, because how people arrive has changed. More and more teams now work through agents that read sites directly, summarise them, compare vendors and hand back a shortlist. That reader does not scroll, does not wait for hydration and does not care about your hover states. It reads text and structure.
Serving that reader well is not one feature. It is a handful of small things that have to be true at the same time:
- An llms.txt, so an agent finds the map instead of guessing it. The builder served 0 bytes there because the file cannot exist on it. This site serves 3,099 bytes, plus 10,543 in llms-full.txt.
- A plain markdown mirror of every article, at a predictable address, marked noindex so it never competes with the page it mirrors.
- Structured data you write on purpose, describing who you are and what each page is, instead of whatever the platform emits.
- Text that is complete in the served HTML, which is the same requirement as the opacity problem above, arriving from a different direction.
What owning the code actually bought
None of the four items above is hard. Each is an afternoon. What owning the code changes is that they become possible at all. On a closed platform you can file a feature request and wait; you cannot add a route that serves markdown, or decide what your JSON-LD says, or move your tag cache to a different store because you measured that the old one was on the wrong continent.
That last one is not hypothetical. Our first version of this site answered in 142 ms because a cache lookup crossed from São Paulo to North America on every request. Finding that took an afternoon. Fixing it took one line. Neither would have been available to us before.
What the rebuild did not fix
Raw time to first byte is still worse than the builder. It serves static HTML from a CDN at 19 ms; we run a worker and answer in 49 ms, down from 142 ms after the fix above. That is fast enough that nobody notices, and it is honest to say we did not win that one.
The word count that a bot sees also went down, from 3,368 to 2,230. That sounds like a loss and is not: the difference is the same sentences repeated across breakpoint variants. Distinct vocabulary went up.
So should you leave your builder?
Not because of SEO. Almost everything on the list above can be fixed inside a builder, and we said so in the article about whether Framer is good for search. Leave when the things you need stop being things the platform can express, which today most often means the agent-facing layer. That is a real reason. Speed alone is not.
What we measured
- Average HTML weight per page, on the builder
- 254.4 KB
- Fetched the same 16 indexed URLs on both sites with a plain HTTP request, no JavaScript, and measured the served HTML without assets. The rebuild averaged 58.8 KB. Most of the difference is the same copy repeated in three breakpoint variants inside one document. · n=16
- Elements served at opacity 0.001 across the site
- 1406 elements
- Counted elements carrying opacity 0.001 in the raw HTML of the 16 indexed pages on the builder, before any JavaScript ran. The rebuild serves zero: text is split by line only after hydration. · n=16
- Total blocking time on the home page, desktop
- 1490 ms
- PageSpeed Insights, desktop profile, both sites on the same day. The rebuild measured 0 ms. First contentful paint favoured the builder, 0.3 s against 0.4 s, and so did total bytes, 377 KB against 411 KB.
- Bytes served at /llms.txt by the builder
- 0 bytes
- Requested /llms.txt and /llms-full.txt on both sites. The builder returned nothing for either, because the file cannot be added to it. The rebuild serves 3,099 and 10,543 bytes.
- Time to first byte, after moving the tag cache
- 49 ms
- Six requests over one reused connection, so the handshake is paid once and excluded from the rest. It was 142 ms before, because the tag cache lived in North America while the worker runs in São Paulo. The builder still wins this one at 19 ms, serving static HTML from a CDN.
Questions
- Is a site builder bad for SEO?
- No. Measured side by side, the builder served real HTML, painted faster and shipped fewer bytes. Its weak points were defaults that can be changed inside it: one meta description across every page, no H1 on inner pages, and no structured data.
- What is llms.txt and does it actually matter?
- It is a plain text map of a site, written for models rather than browsers. It is a proposal, not a standard, and no engine promises to read it. It costs an hour to generate from content you already have, and it is one of the few things a closed platform cannot let you add.
- Do I have to leave my builder to fix any of this?
- For most of the list, no. Descriptions, headings, alt text and structured data are all editable inside a builder. The agent-facing layer is where it stops: an llms.txt, a markdown mirror at a route you control, and JSON-LD you write yourself.
- Did the rebuild make everything faster?
- No. Time to first byte is still 49 ms against the builder 19 ms, and total transferred bytes went up. What changed is that the page stops blocking: 0 ms of blocked main thread against 1,490 ms.
Sources
- PageSpeed Insights · Google
- The /llms.txt file · llmstxt.org
- JavaScript SEO basics · Google Search Central
Work behind this
- Glass · Shaped by nature, crafted in Brazil.
- Ligga Telecom – ESG Annual Report · Translating technical data into a refined visual system.
