No code SEO: 10 of 42 no code home pages served a crawler zero words

What does no code SEO actually depend on?

The field calls it generative engine optimization, and it disagrees with ordinary search optimisation about plenty, but not about this step. The crawl is shared, and this site has already set out the four things that separate GEO from SEO: none of the four is the fetch. A request goes out, bytes come back, and something pulls text out of those bytes. Everything a ranking system or an answer engine does afterwards runs on the text that survived that extraction. If no text survived, there is nothing downstream to rank, summarise or quote.

That ordering is why structured data and llms.txt cannot rescue an empty response. Both describe a page. Neither is a substitute for one, and this site has measured what happens when markup and page disagree: 70 of 146 markup values were not present on the page they described. A description of prose that does not exist is not a smaller problem than no description at all.

So no code SEO depends on one thing before it depends on anything else, which is whether the words typed into the builder are present in the response or assembled afterwards by a script. This site calls the distance between those two states prose parity, and it decides whether an AI crawler has any material to work with. A page can be well organised, correctly marked up, fast, and still completely empty to a reader that does not execute JavaScript. The methodology behind the grade starts there for exactly this reason.

10 of 42 no code home pages served zero words

The corpus is the platform seed file committed to this repository, generated on 30 July 2026 and stratified by the platform a site is built on rather than by what the site sells. Its no code stratum holds 42 hostnames taken from published lists of sites built with Bubble, Carrd, Glide and Softr, together with one vendor's own customer stories. That provenance is also a limit, and it is worth stating plainly: the frame records what those sources said each site was built with when it was drawn, and this run did not re-verify that all 42 still run on the platform they were listed under.

All 42 answered HTTP 200 with HTML on 28 September 2026. 11 of them returned zero words. One of those 11, swapstack.co, answered with a Cloudflare interstitial titled "One moment, please..." rather than a page of its own, which is a bot challenge and not a rendering outcome, so it is counted separately and excluded from the finding. That leaves 10 hostnames that answered with a real page carrying no readable words at all.

Two more sat just above the line and are named rather than folded in. nocodemvp.com returned a body reading 403 Forbidden underneath an HTTP 200 status, which is a different defect and one this site has measured across a wider sample as a soft 404. dvassallo.com returned 36 words. Above those, the stratum recovers quickly: the median was 547 words, and the top of the range reached 3,737.

That median is the reason a single average would have hidden this entirely. 547 words is unremarkable, and it sits above Webflow at 355, above Wix and Squarespace at 327 and above static documentation sites at 302. The no code stratum does not have a general prose problem. It has a tail, and roughly a quarter of the sample is in it. A platform average is the wrong instrument for a failure mode that is total on the sites it touches and absent on the rest, which is a pattern this corpus keeps producing.

Stability was checked rather than assumed. Every zero word page in the whole corpus was requested a second time the same day. 26 of the 27 returned zero words again. The exception was carlsonduluth.com in the local media stratum, which returned 707 words on the second read and is therefore reported as one page that moved between two reads rather than as a finding. All 13 of the no code pages under 50 words returned the same count both times.

What the ten pages did send instead of words

None of the 10 was an empty file. Every one of them returned a complete HTML document with a title element that says what the business is, and the titles are not placeholders: estate planning, invoicing software for freelancers, a MarTech stack management platform, an AI article writer. The response knows what the site is for. It simply does not contain the page.

Two of them were very large. listr.pro returned 329,114 bytes and letterhunt.co returned 242,041 bytes, both yielding zero words. The material is in the response, in the sense that the bytes crossed the wire, but it is held in script payloads rather than in text nodes an extractor can reach. This site has measured the same shape before, where text in hydration JSON scored the same as no text at all. A crawler is not paid to guess which of several megabytes of JSON was meant to be the paragraph.

Not one of the 10 carried an h1. That matters more than it looks, because a missing h1 usually means the heading is created by script along with everything else, and headings are the structure an answer engine uses to decide what a page is about. This site has measured heading loss on its own pages before, where a heading existed in the markup and still counted as no h1 at all.

The clearest evidence that these sites already know is the noscript element. 6 of the 10 shipped one. Per MDN's reference, a noscript element defines a section of HTML to be inserted if a script type on the page is unsupported or if scripting is turned off in the browser, which describes a crawler that runs no JavaScript precisely. projectant.io's noscript says: You need to enable JavaScript to run this app. That is the site addressing this exact reader, in writing, and telling it to go away. It is worth noting that a noscript element is not itself a fix, and this site has published the fourteen noscript elements that held no text to make the point that the element is usually a warning rather than a fallback.

Robots.txt was not what stopped these crawlers

The reflex when a site is missing from an answer engine is to open robots.txt, and on this sample that reflex would have found nothing wrong. 40 of the 42 no code hostnames returned a robots.txt that parsed on 28 September 2026, served with HTTP 200 and a plain text content type. The other two returned HTTP 404, which RFC 9309 section 2.3.1.3 treats as unavailable, meaning a crawler may access any resource on the server.

Of the 40 that parsed, 6 named at least one of the seven AI crawler tokens this scanner checks, and none of the 40 disallowed GPTBot at the site root. Evaluated with the scanner's own parser, GPTBot was permitted to fetch the home page on every one of the 40 files that parsed, and the two hostnames answering 404 permit it by absence. So on all 10 of the sites that returned nothing, the access control said yes and the page said nothing. The rule everyone tunes was not the binding constraint.

This is the opposite failure from the one the platform posts usually surface. On Webflow, 20 of 40 robots.txt files held no rule at all, and on Wix not one of 69 files named an AI crawler. Those are files that fail to express an intention. Here the files are fine and the page behind them is empty, which no robots.txt tester will ever report, because a robots.txt tester answers a question about permission and this is a question about content.

It is worth being exact about what robots.txt governs, because the confusion is common enough to be costly. Google's robots.txt specification, carrying Last updated 2026-08-31 UTC, describes status handling and rule matching for access. Nothing in it concerns whether the fetched document contains text. A file can be flawless and still sit in front of a page that has none, and this site has separately measured that 232 of 1,059 robots.txt files carried a defect a validator can name. Permission and content are two independent checks, and passing the first tells you nothing about the second.

What the crawler operators actually commit to about JavaScript

A fair objection to all of this is that crawlers might render the page anyway. The honest answer is that it depends entirely on which crawler, and that the companies behind the AI crawlers have mostly declined to say.

Google is the one that has written it down. Google's JavaScript SEO basics, carrying Last updated 2026-03-04 UTC, states that Google processes JavaScript web apps in three main phases, crawling, rendering and indexing, and that once Google's resources allow, a headless Chromium renders the page and executes the JavaScript. That is a commitment a site owner can plan against, with a documented queue and a documented engine.

For the crawlers that feed AI answers there is no equivalent. OpenAI's bots documentation describes GPTBot, OAI-SearchBot and ChatGPT-User, explains that each robots.txt setting is independent of the others, and publishes IP ranges for them. Read on 28 September 2026, that page contains the string JavaScript zero times and the string render zero times. It is not that OpenAI says it does not render. It is that the question is not addressed, so nothing on that page lets a site owner conclude either way. This site put the same question to every vendor it tracks and found that 2 of 9 operators say either way.

That silence is the whole risk calculation for a no code site. A page whose words exist only after a bundle runs is betting that every engine it cares about renders, and the documentation supporting that bet currently covers one engine. If you want to see the shape of the bet on your own pages, what GPTBot sees fetches them the way a non rendering client would, which is the same fetch this measurement made.

What this measurement does not establish

This run measured one page per site, on one day, from one network location, with one user agent. It did not run a browser, so it cannot say what any of these pages look like once the script has finished, and it cannot report a rendered word count to set against the raw one. This site has done that comparison separately, with a real browser on the same corpus, and found that JavaScript supplied 7.6 percent of the prose and 11 of 271 pages returned nothing readable until the bundle ran. Today's figure is the unrendered half of that comparison on a different day, not a replacement for it.

It also did not test whether any AI crawler in fact failed to retrieve these sites, because that would require the operators' logs rather than a scanner. The claim here is narrow and it is a supply side claim: on 28 September 2026 these 10 pages served no words to a client that did not execute JavaScript, and their robots.txt files permitted that client to ask. What any given engine then did is not in this dataset.

Nor is this a claim that no code platforms cannot serve prose. 29 of the 42 sites in the stratum served 50 words or more, several of them generously, and the stratum median beat four other platforms. The finding is about a tail, and the tail is where the platform default and the site owner's inattention meet. A builder that renders on the client by default will produce this outcome for anyone who never checks, which is precisely the population a no code tool is sold to.

The fix is not exotic and it is not a Lantad product. It is server rendering, or prerendering, or static export, whichever the builder offers, and the site's own client rendered and server rendered canary pages exist so the difference can be inspected rather than argued about. Where a site has outgrown the builder, the stack guides for React, Next.js and sites generated by an AI app builder cover the same fix in the frameworks people migrate to. The check that matters comes first though, and it costs nothing: fetch your own home page without JavaScript and read what comes back. AI visibility is downstream of that, and on 10 of these 42 sites there was nothing downstream to have.