No-code SEO: 10 of 40 home pages served a crawler zero words, and our own detector could not name the builder on 20

What this measured, and what it did not

The population is not a sample of no-code sites in general. It is the 42 hostnames a previous commit put in a stratum named bubble-nocode, chosen to represent builder-hosted sites inside a corpus that also covers Shopify storefronts, Webflow marketing sites, WordPress small business sites and documentation hosts. Treating it as a census of the no-code web would be wrong, and nothing here is extrapolated beyond those 42. What it can support is a statement about those 42 hostnames on one date, and a statement about how this product's own code behaved when pointed at them, which is the part that generalises.

Two of the 42 produced no page to read. bettersheets.co answered 403 with a Cloudflare interstitial carrying the challenge-platform markers and the words Just a moment, so the refusal came from a network edge rather than from the site's own configuration. saashook.com answered 404 for both its home page and its robots.txt, which is a host that resolves and serves nothing. Those two are excluded from the 40 that follow, and the exclusion is stated rather than folded into a round number.

The run was repeated to check that the figures were stable, and one host moved. swapstack.co returned a holding page titled One moment, please on the first pass, which the extractor correctly read as zero words, and returned its real page carrying 753 words on the second. Every other host produced identical status codes, word counts and platform labels across both passes. The figures reported here are the second pass, and swapstack.co is therefore counted as a page with words rather than one without. A single host flipping between an interstitial and its content is worth stating plainly: a one-shot measurement of any site can catch a bot defence instead of the site, and this one did.

Three things were not measured and no claim is made about them. No browser was used, so this post does not say what any of these pages contain once JavaScript has run, and the rendered half of that comparison belongs to a separate measurement. No crawler logs were read, so nothing here observes GPTBot, ClaudeBot or any other token fetching, reading or skipping these sites. And no builder's documentation was treated as evidence of what its pages do: where Bubble is named below, it is named because the HTML a server sent referenced bubble.io, not because a vendor page was quoted. The user agent this scan sends is documented at the bot page.

Does no-code SEO reach a crawler that runs no JavaScript?

On 10 of the 40 pages it does not reach it at all. The shipped extractor read zero words from beelango.com, byword.ai, incomee.co, letterhunt.co, lifelegacy.io, listr.pro, martechbase.com, nanny.network, projectant.io and yep.so. Those are not empty sites. Every one of the 10 served a title element, and every one served a meta description, so the head of the document is populated exactly as the builder's settings panel promises while the body carries nothing a parser can quote. That combination is the specific failure worth naming, because it is invisible to every check that looks at metadata: the fields a site owner is told to fill in are full, and the sentences an answer engine would need to cite are absent.

The distribution across the other 30 is wide rather than uniformly bad. In total the extractor read 24,704 words across the 40 pages. 12 pages returned under 50 words and 15 returned under 100, so the under-100 group is a little over a third of the set. At the other end userloop.io returned 3,737 words, icelandbyannie.com 2,391 and abstractlab.co 1,870, which are ordinary content pages by any standard. The builder is therefore not the determining factor on its own. Something about how each of these particular sites was assembled is, and the two extremes sit in the same stratum.

Page weight makes the point sharper than word count alone. listr.pro served 329,180 bytes of HTML containing no readable words, and letterhunt.co served 242,480 bytes containing none either. Those are large documents by the standards of this corpus, and all of that weight is markup, inline data and script references rather than prose. yep.so carried 60 script tags and beelango.com 59, again with nothing readable between them. A crawler that fetches one of these pages pays the full transfer cost and extracts nothing, which is the worst of both arrangements. Prose parity is the measure that captures this, and it is the sub-score that dominated the losses when this corpus was graded end to end.

Two of the 10 silent pages carried structured data while carrying no prose. lifelegacy.io and projectant.io each served one JSON-LD block in the document the server sent, so a parser reading those two pages receives machine-readable claims about the business and not one sentence of the text those claims are supposed to summarise. Across all 40 pages 29 carried no JSON-LD block at all and 11 carried one or more. Separately, 14 of the 40 declared no h1 and 11 declared no heading of any level, and the 11 with no heading are the 10 silent pages plus consciencecart.com, which served words with no heading structure over them.

The reason a document matters this much is that rendering is a separate step rather than part of fetching. Google's JavaScript SEO basics documentation, carrying Last updated 2026-03-04 UTC, states that Google processes JavaScript web apps in three main phases, that Googlebot queues pages for both crawling and rendering, and that once Google's resources allow, a headless Chromium renders the page and executes the JavaScript. The same page says Google can only see content that is visible in the rendered HTML, and that if the content is not visible there it will not be indexed. That is Googlebot, which does render, and the queue is the point: rendering is a later phase with its own resource limits, not something guaranteed to happen the moment a page is fetched. What other operators do varies and is mostly undocumented, which this blog measured separately when it found that 2 of 9 operators state whether their crawler executes JavaScript. The rendered comparison for a similar population, run with a real browser on and off, is in the finding that 11 of 271 home pages returned no words until the bundle ran.

The builder our own detector cannot name

The second finding is about this product rather than about the sites, and it is the more awkward of the two. Lantad stores a platform id on every scan so the report can tailor its advice to the stack a page is built with. On these 40 pages that detector returned no match on 20 of them. On the 20 it did name, it said Webflow 5 times, Next.js 4, WordPress 3, Squarespace 3, Framer twice, a generic JavaScript single-page app twice, and Astro once. Several of those are correct and useful. What it never said, on any page, was Bubble.

It never said Bubble because it cannot. The detector in core/src/platform.ts carries 15 signals, for Next.js, Nuxt, Gatsby, SvelteKit, Remix, Astro, Shopify, WordPress, Wix, Squarespace, Webflow, Framer, Hugo, Jekyll and a catch-all single-page app shell, and none of them tests for Bubble. The stratum these 42 hostnames sit in is named bubble-nocode in a file this repository commits, so the corpus is deliberately stratified on a platform the classifier has no way of seeing. That mismatch sat in the codebase unremarked, which is the sort of thing worth publishing rather than quietly patching: a stratum name is a claim about what is being sampled, and the tool reading the sample could not confirm it.

The evidence that Bubble is actually present is in the documents themselves. 5 of the 40 pages referenced bubble.io in the HTML the server sent: beelango.com, betterlegal.com, incomee.co, martechbase.com and yep.so. Four of those five, being beelango.com, incomee.co, martechbase.com and yep.so, also carried a window.bubble object and a bubble_page_load reference, which is a running application's own hook rather than an incidental mention. betterlegal.com referenced bubble.io 158 times without those hooks. The detector returned no match on all five. Four of the five returned zero words. Bubble's own site is at bubble.io, written here as plain text because this site does not link hosts it has not registered a link policy for.

The practical consequence is that the one stratum most likely to produce an empty document is also the one the report can say least about. By contrast the site ships a per-stack guide for Lovable, another builder in the same general category, and one for Framer, which the detector does recognise and which appeared twice in this run. There is no equivalent for Bubble, in the detector or in the guides. When the whole corpus was graded, 972 of 1,419 sites produced a score and prose parity accounted for 60.7 percent of every point lost, so the defect class these sites exhibit is the dominant one across the index, not a niche concern.

Why the label decides the advice

An unrecognised platform would be harmless if the label were only a statistic. It is not. The same module that holds the detector holds PLATFORM_FIX_HINTS, a map from platform id to the wording the report uses when it tells a reader how to fix a rendering or schema defect on their particular stack. It is keyed by exactly the ids the detector emits, which means an id the detector never emits can never be reached, and a page the detector cannot classify gets whatever the generic path produces. The module's own comment says as much: only the cases where the stack changes the advice are filled, and the generic summary stands elsewhere.

The map carries 12 keys, for Next.js, Nuxt, Gatsby, SvelteKit, Remix, the generic single-page app, Shopify, WordPress, Webflow, Wix, Squarespace and Framer. Three platforms the detector can recognise have no entry, those being Astro, Hugo and Jekyll, which matters less because all three produce server-rendered HTML by default and are unlikely to trip a rendering defect. Bubble appears in neither list, so on the 5 pages that referenced it the report had no tailored wording available and no id to look one up with.

The nearest hint that does exist is the one for the generic single-page app, and reading it next to this population shows why a missing entry is not a cosmetic gap. It says the app is client-rendered so crawlers get an empty shell, and to add server-side rendering or prerendering, naming Next.js, a prerender service or static generation as the options. Every word of that is correct for a React application a developer controls. For somebody who chose a no-code builder specifically so they would not be writing or deploying code, adopting Next.js is not an available action, and neither is swapping in a React rendering strategy. Two of the 40 pages were classified as that generic shell, byword.ai and projectant.io, and both returned zero words, so those two pages are the ones that would reach that wording. This run called the detector and the extractor directly rather than generating a report, so no report text was produced here and none is quoted; what is quoted is the hint the id maps to in the module.

What a no-code owner can actually do is narrower and worth stating accurately rather than optimistically. Most builders expose some control over whether a given page is published as static output, whether key text sits in native elements or inside a custom code embed, and what the head of the document declares. Those levers are real and they are the ones that move the document a crawler receives. What is not available is replacing the rendering model, which is the advice the generic hint gives. Writing a hint that says so, honestly and per builder, is the fix this measurement argues for, and it costs a map entry rather than a new feature. The scan itself, and what it reports per page, is described on the pricing page.

What the robots.txt files said

Access is the other half of whether a crawler reads a site, and on this stratum access was mostly open. 39 of the 42 hostnames served a robots.txt as text. Three answered 404, those being consciencecart.com, nanny.network and saashook.com. A 404 is not a gap in the measurement but a defined outcome: RFC 9309, the Robots Exclusion Protocol, published September 2022, states in its section on an unavailable status that status codes in the 400 to 499 range mean the crawler may access any resources on the server. So those three hosts are fully open by the standard's own rule, and the parser this product ships treats them that way rather than guessing.

Of the 39 files served, 8 named at least one of the five AI crawler tokens evaluated here, which were GPTBot, ClaudeBot, PerplexityBot, Google-Extended and CCBot. The eight are byword.ai, cuure.com, giglaw.co, lakeshorewindows.ca, lifelegacy.io, messly.com, swapstack.co and wearetheboard.co. Naming a token is not the same as blocking it, and the gap between the two is the usual finding: of those 8, only messly.com and swapstack.co actually disallowed the named tokens at the root. The other 6 named crawlers in a group that left the root allowed, which is a file written by somebody who thought about AI crawlers and decided to let them in, or who copied a template without changing the rule. LantadBot was allowed by all 42, so no figure in this post is depressed by a rule aimed at this scanner.

The overlap with the prose finding is where it gets useful. byword.ai and lifelegacy.io both appear in the list of 8 sites that named AI crawler tokens, and both appear in the list of 10 pages that served zero words. Those two sites configured their robots.txt to admit crawlers that are then handed a document with nothing in it. That is the honest shape of the problem on this stratum: the access layer is not what is stopping anything. 2 of 39 files restrict an AI crawler at the root, while 10 of 40 pages give one nothing to read whether it is allowed in or not. A robots.txt tester resolves the first question in a few seconds, and the tokens this scanner evaluates are listed on the AI crawlers page.

Nothing in this run touched llms.txt, and the omission is deliberate rather than an oversight. A separate measurement on this blog found no evidence that serving one changes what any engine does, so adding a count of it here would pad the post with a number that carries no consequence. The definition and the current state of the proposal are on the llms.txt page for a reader who wants it.

What a no-code owner can check today

The check that matters takes one request and no tooling. Ask for your own page the way a crawler does, without a browser, and read what comes back. On a site built with a visual builder the result is one of two things: a document containing your sentences, or a document containing a head, a pile of script tags and no sentences at all. There is no middle state to interpret and no score to argue with. If the words are missing from that response, then every downstream claim about structured data, headings or internal linking is being made about content that is not in the document yet. What GPTBot sees on a given URL can be checked directly rather than inferred.

If the words are there, the next checks are the ordinary ones and this corpus failed several of them. 14 of the 40 pages declared no h1, which is a document with no stated subject, and 11 declared no heading at all, so there is no structure for an extractor to follow. That pattern is not confined to no-code sites: across the wider corpus this blog found that 379 of 1,066 home pages declared no main landmark, and 29 of these 40 pages carried no JSON-LD block, which is in line with the rest of the index rather than worse than it. Fixing a heading inside a visual builder is usually a matter of using the native heading element instead of a styled text block, which is a change the owner can make.

Where the honest answer is less comfortable is the rendering itself. If the document comes back without words, the fix is at the platform level, and on most no-code builders the owner cannot change the rendering model. What they can sometimes do is publish the page through whatever static or SEO option the builder exposes, move the important text out of custom code embeds and third-party widgets into native elements, and accept that some pages will be assembled in the browser whatever they do. This post makes no claim about what any specific builder offers today or plans to offer, because it read servers rather than roadmaps, and a feature claim about a product this measurement did not test would be exactly the kind of sentence this blog does not publish.

The broader context is worth keeping in proportion. An empty document is not a no-code problem, it is a client-rendering problem that no-code builders happen to produce often, and it is widespread: across the full committed corpus, 418 of 1,419 sites gave a crawler no words on an earlier run. Meanwhile 10 of the 40 pages here served nothing while their title and description fields were filled in correctly, which is the detail a settings-panel view of generative engine optimization cannot see. The number to watch is not whether the metadata is complete. It is how many words come back when nothing runs.