In short
What it measures
the characters of readable text on the page without running JavaScript.
Bands
three, and the most severe is equivalent to a blank page.
Severity
Important, within the AI visibility area.
Frequency
fails on 2.4% of analyzed pages, an internal figure from the Wakaris catalog.
What content accessible without JavaScript is and what it measures
When your page is built in the browser, the HTML that leaves your server may not contain your text: it contains an empty container and the instructions to fill it. Anyone who reads that HTML without running the code will see the container. This finding measures exactly that, how many characters of readable text are in that first HTML, and returns it in three bands ranging from “little” to “practically nothing.”
It isn’t a judgment on how you code, or a recommendation to stop using JavaScript. It’s a measure of dependency: how much of your message depends on a third party running your code correctly. The difference from the thin content finding matters: that one measures whether the page has text; this one measures how much of that text arrives without running anything. A page can be full and still fail here.
How it’s measured
Wakaris measures it by running your URL through the analyzer: it collects the page’s readable text without running JavaScript, counts it in characters and gives you the value and the band it falls into, with nothing to install and no account to create. That’s the direct route. The result is a number, not an impression, which lets you compare two pages, or the same page before and after a change.
The three bands are steps of the same problem, and that’s how to read them. The first warns that little text is left; the second, that very little is left; the third, that the page is, for practical purposes, empty. It’s one of the few findings in the catalog whose threshold truly scales, with three cut-offs on a single measure, so the degree Wakaris gives you already tells you how urgent it is without any interpretation.
Why it matters
The reason is documented in how crawling works. Google describes three phases (crawling, rendering and indexing) and rendering isn’t simultaneous: pages enter a queue and, in Google’s words, “the page may stay on this queue for a few seconds, but it can take longer than that.” In other words, even the crawler that does run your JavaScript does so later, and only if rendering succeeds. Anything that depends on code arrives later, or not at all.
The second reason is reach: whoever reads your HTML without rendering it is left with what’s in it, and there’s no recovery from that. The third is fragility. An error in a file, a third-party script that doesn’t respond, a browser version that doesn’t support something: if your text depends on all of that going right, any failure turns it into a blank page. And to appear as a supporting link in Google’s generative answers, the documentation itself requires the page to “be indexed and eligible to be shown in Google Search with a snippet,” which means there has to be content to show.
Common causes
The dominant cause is a single-page application rendered entirely on the client: the server delivers a document with an empty container and the browser fills it. It isn’t a coding error; it’s an architecture decision with this side effect. Next comes content hidden behind an interaction (tabs, accordions, a “see more” button) because whoever doesn’t interact never expands it, and Google warns you to “expect Googlebot to decline user permission requests,” since those features make no sense for a crawler.
There are three more causes, all common. One: using URL fragments to load different views; Google is explicit, “don’t use fragments to load different content,” and notes that the AJAX crawling scheme has been deprecated since 2015. Another: lazy loading that only triggers on scroll, so text further down doesn’t exist until someone scrolls. And the third: a consent wall or notice that covers the content and doesn’t release it until something is clicked.
How to fix it
There’s one principle, and it shapes everything else: the page’s core message has to be in the HTML that leaves your server. Let JavaScript add, improve and make the page pleasant to use, but don’t make it the condition for the content to exist. In practice you get there with server-side rendering or by pre-generating the pages that matter, and that’s the fix that solves the finding at the root instead of covering it up.
The rest follows from that. Take the main text out from behind interactions: let tabs and accordions control presentation, not whether the text exists. Give each view a real URL instead of a fragment. Set lazy loading to affect images and secondary blocks, not the body of the content. And don’t let your text depend on a third-party script that can fail without warning. Once you’ve changed something, measure it again with Wakaris: the finding is a number, so you’ll see whether you’ve moved up a band or closed it.
Comparison of the same article delivered with the text already in the HTML and delivered as a container that gets filled later
Brief to generate the image
Editorial illustration for a Wakaris technical guide. Topic: Comparison of the same article delivered with the text already in the HTML and delivered as a container that gets filled later. Style: white background with a soft lime→pale green wash (#F8F7D6 → #E2F2DC), green→lime gradient accent (#8ED390 → #DCD86F), near-black ink (#12150B), pill shapes and rounded corners, soft shadows, clean schematic look, no photography. Format: 16:9, 1440 pixels wide. No legible text: any label, code or figure is shown as gray placeholder bars. The caption carries the meaning, not the image. No real logos or third-party brands. No recognizable people. Tags: content, accessible, javascript, comparison, article, delivered, text, html
Ask your AI
If you want to dig into your specific case, copy one of these two prompts and paste it into the AI you use. Pick the one that fits your situation.
I already have the finding measured with Wakaris and want to fix it
Act as a professional, careful web technical auditor. Your goal is to help me understand a specific finding about my website and decide what to do about it, without making anything up. Context: I got this finding with Wakaris, a tool that analyzes a website across 9 areas (performance, SEO, security, social, market, AI, experience, accessibility and legal) and explains each problem in the language of each role on a team. The finding is: content not very accessible without JavaScript. Very little readable text remains on my page if JavaScript doesn’t run (reference: it’s measured in characters and returned in three bands, from the one warning that little is left to the one equivalent to an empty page). Source for this finding: https://www.wakaris.com/en/guides/ai-visibility/content-without-javascript Rules you must follow at all times: 1. Don’t assume anything about my website. Every piece of data you use must come from what I confirm or from what Wakaris has measured. If you don’t know it, ask me before stating it. 2. Before giving me conclusions, ALWAYS ask me these questions, together and in plain language, to find out whether this finding really affects me and where: a) Paste me the Wakaris result for this finding: the value in characters, the band and the page analyzed. If you don’t have it, tell me and we’ll measure it before continuing at https://www.wakaris.com/?utm_source=blog&utm_medium=prompt&utm_campaign=contenido-sin-js b) How is your website built? (classic content management system, single-page application, custom-built site, I don’t know) c) Is the main text on that page visible when you open it, or does it appear when you click tabs, accordions or a "see more" button? d) Is there a cookie notice or a wall covering the content until something is clicked? e) Who can change how the page is delivered: you, an in-house developer or a provider? If you’re able to, add a follow-up question when an answer calls for it, but never skip the ones above or move to conclusions without having them answered. 3. Every statement or recommendation must be argued in relation to MY context, not in general. If you recommend something, explain why it applies to my case. 4. Always state your level of certainty. If something is a hypothesis because you can’t measure it, say so: you can’t see my website, you’re reasoning from what I tell you. 5. Don’t propose irreversible or risky technical changes (changing how a website renders is one) without first warning me about the risk and that a test environment is advisable before touching production. 6. If you need data that can only be obtained by measuring the website (confirming the value, or whether the change worked), tell me and recommend that I run the page through Wakaris again: that gets measured, not guessed. 7. The final decision is mine, not yours. Your role is to help me understand and prepare the action, not to decide for me. 8. If someone else is going to carry out the fix, help me get the problem ready to hand over: what it is, where it is, why it matters and what needs to be done. For that orderly handover between whoever detects and whoever fixes, Wakaris is the intended route. Start by briefly introducing yourself in your role and asking me the first block of questions.
I haven’t measured it yet and want to check whether my website has this problem
Act as a professional, careful web technical auditor. I’m investigating whether my website has a specific problem and I want you to help me find out honestly, without taking it for granted. Context: I got here through Wakaris, a tool that analyzes a website across 9 areas (performance, SEO, security, social, market, AI, experience, accessibility and legal) and explains each problem in the language of each role on a team. The problem I want to investigate is: content not very accessible without JavaScript. Almost none of my text may stay readable if JavaScript doesn’t run. I DON’T know yet whether my website has it: I want to find out. Source for this finding: https://www.wakaris.com/en/guides/ai-visibility/content-without-javascript Rules you must follow at all times: 1. First and most important: this is something that is MEASURED on a specific page, and you can’t access my website from this conversation. Make it clear from the start that you won’t be able to give me a definitive "yes, you have it" or "no, you don’t," only a hypothesis based on what I tell you. 2. Don’t assume anything. Before giving me any assessment, ALWAYS ask me these questions, together and in plain language: a) Do you know what your website is built with? (classic content management system, single-page application, custom-built site, I don’t know) b) When you open a page, does the text appear all at once, or do you first see a gap, a gray skeleton or a loading indicator? c) Is the main text in view, or do you have to click tabs or "see more" to read it? d) Do the different sections of your website have their own URLs, or does the URL barely change as you navigate? e) Is there a cookie notice or a wall covering the content when you arrive? 3. With my answers, give me a clear estimate of whether it’s LIKELY or UNLIKELY that I have it, argued from what I’ve told you and explicitly marked as a hypothesis, not a diagnosis. 4. Tell me directly that the only way to know is to measure it, and that I can do it for free and without creating an account by running my website through Wakaris at https://www.wakaris.com/?utm_source=blog&utm_medium=prompt&utm_campaign=contenido-sin-js, which will give me the characters that survive, the band, and the status of the other areas too. Present it as the answer to my question, not as a sales pitch. 5. If I ask you how to check it by hand, don’t hide it from me: explain that I can disable JavaScript in my browser and reload the page to see what’s left. But remind me that Wakaris gives me the exact figure and the band, and adds the rest of the analysis. 6. If, once measured, it turns out I do have it, tell me the next step is to decide which part of the content needs to be in the HTML from the start. 7. The conclusion and the decision are mine, not yours. You help me find my bearings. Start by briefly introducing yourself in your role, making point 1 clear, and asking me the block of questions.
Frequently asked questions
Do I have to stop using JavaScript? +
No. This finding doesn’t measure whether you use JavaScript; it measures how much of your content depends on it running. What it asks is that the core message is in the initial HTML, and that code improves the page rather than being what makes it exist.
If Google runs JavaScript, does this still matter? +
Yes. Google renders in a separate, queued phase: it says a page may stay there for a few seconds, but it can take longer. And any reader that doesn’t render is left with your HTML as is, with no second chance.
Is this the same as the thin content finding? +
No. The thin content finding measures whether the page has enough text. This one measures how much of that text arrives without running anything. A well-written, complete page can pass the first and fail this one, and each has a different fix.
Does text that appears when you click a tab count? +
It depends on whether it exists in the page or is created on click. If the HTML already contains it and the tab just shows it, it counts. If it’s generated by the interaction, it doesn’t: Google warns that its crawler doesn’t handle features that require user action.
Which band should worry me most? +
All three are the same problem at different degrees, so the band tells you the urgency. The most severe is equivalent to an empty page and should be treated as a delivery failure, not an improvement. The mildest is a dependency warning that hasn’t cost you anything yet.
Sources cited
- developers.google.comUnderstand JavaScript SEO basics — Google Search Central: https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics
- developers.google.comFix Search-related JavaScript problems — Google Search Central: https://developers.google.com/search/docs/crawling-indexing/javascript/fix-search-javascript
- developers.google.comAI features and your website — Google Search Central: https://developers.google.com/search/docs/appearance/ai-features
Updated: September 8, 2026. Next review in 90 days.
This article is part of Wakaris, which analyzes your website across 9 areas and explains each finding so that every role on your team can understand it.