631-612-6976
Mon to Fri, 9:00 AM to 5:00 PM
4.9 from 71 Google reviews
Since 2012
Google will read your JavaScript eventually. AI crawlers never will. That one difference should change how you build every page, and it explains why the prettiest sites are often the most invisible.
There is a version of this advice floating around that says Google cannot read JavaScript. That is not true, and if you build your strategy on it you will make the wrong decisions. The real situation is more specific, and for any business that wants to show up in AI answers it is more urgent.
Googlebot does run JavaScript. It just does it in two passes: it crawls your raw HTML first, then queues the page for rendering when resources free up, which can lag anywhere from minutes to days. Your content usually gets indexed. It is simply slower and has more ways to fail, which we walked through in how Google indexing and ranking works.
The AI crawlers are a different story entirely, and this is the part almost nobody has adjusted for.
Google reads your JavaScript eventually. AI never sees it at all.
Vercel and MERJ ran a joint server-log analysis covering more than 500 million GPTBot fetches. They found zero evidence of JavaScript execution. Not slow execution, not partial execution. None.
The detail that removes any argument: GPTBot downloaded JavaScript files roughly 11.5 percent of the time, and ClaudeBot about 23.8 percent. They fetched the files and never ran them. The same pattern held for PerplexityBot, Meta's crawler, Bytespider, and CCBot. Only Google's own infrastructure renders, because it inherits the indexing pipeline Googlebot already uses.
Based on the Vercel and MERJ server-log analysis. Crawler behavior can change, so treat this as the current state rather than a permanent law.
So when someone asks ChatGPT for the best HVAC company in their town, and your services, your reviews, and your phone number are all assembled by JavaScript after the page loads, you are not competing badly in that answer. You are not in the running. We covered what it takes to be named in those answers in how to get cited in AI search results, and every bit of it assumes a machine can read your page in the first place.
You do not need a developer or a tool for this. Open your website, right-click, and choose View Page Source. That shows the raw HTML your server sent, before any JavaScript ran. It is exactly what an AI crawler sees. Then hit Ctrl+F or Command+F and search for a sentence from your page.
If your headline, your service descriptions, and your phone number are in there, you are fine. If the search comes up empty, your content is being built after delivery. Here is what each outcome looks like.
The useful question is not which platform is best in the abstract. It is how much of your real content arrives in that first HTML response. Here is the honest ranking.
Everything is in the file. Nothing to render, nothing to wait for, nothing to break. Fastest for people and machines alike. The tradeoff is that updates need a developer or a build step, which is why most businesses do not run this way.
Next.js, Laravel, Django and similar setups assemble the page on the server and send finished HTML. You get dynamic features with none of the blindness, as long as server-side rendering is actually turned on and not quietly bypassed.
PHP renders the page on the server, so your words land in the HTML. This is the practical sweet spot for most businesses: full control, easy editing, machine-readable output. The caveat is everything you bolt onto it.
Your text usually still lands in the HTML, which is why builders are not the villain people claim. The costs are bloat and fragility: large script and stylesheet payloads, enormous DOM sizes, and widgets that pull content in after load. Manageable with discipline.
A React or Vue app with no server rendering sends an empty shell and a script bundle. Google will figure it out on the second pass. AI crawlers receive a blank page and move on. This is the setup that silently costs the most, and it is a frequent cause of the ranking problems people blame on everything else.
Notice that WordPress sits high on that list when it is built carefully. We build everything on WordPress for exactly this reason, including the work we describe as custom HTML, and we went into the control argument in depth in why website builders cap your SEO. The platform is rarely the problem. What gets layered on top usually is.
This is where real sites go wrong, and it is almost never the whole site at once. It is specific elements quietly removing themselves from what machines can read. Tap through the common ones.
The pattern across all of them is the same. If the content exists in the HTML and JavaScript is only controlling whether a human can see it, you are fine. If JavaScript is what puts the content there, it does not exist as far as an AI crawler is concerned.
None of this requires rebuilding your site. For most businesses it is a handful of targeted fixes.
If you remember nothing else from this, remember the test. Right-click, view source, search for your own words. That one habit tells you more about whether your site can be found than any audit tool, and it takes half a minute.
Build pages where the content is genuinely in the page. Use JavaScript to make things nicer for humans, never to deliver the substance. Do that and you are readable by Google on the first pass, readable by every AI system that comes along, and faster for the customer who is actually trying to reach you. That is not three strategies. It is one, and it has been the right answer the entire time.
Yes, but on a delay. Googlebot crawls your raw HTML first, then queues the page for rendering, where it runs the JavaScript to see the finished result. That second pass happens when rendering resources are available, which can lag from minutes to days. So JavaScript content usually does get indexed, it just takes longer and has more points of failure than content already present in the HTML.
No. A joint analysis by Vercel and MERJ of more than 500 million GPTBot fetches found zero evidence of JavaScript execution. GPTBot downloaded JavaScript files roughly 11.5 percent of the time and ClaudeBot about 23.8 percent, but neither ran them. The same held for PerplexityBot and other major AI crawlers. If your content is built by JavaScript, those systems see an empty shell.
Serve your real content in the initial HTML response, on a platform where you control the output. That means static HTML, a server-rendered setup, or WordPress on a lightweight theme without a heavy page builder doing the rendering. The test is simple: view the page source and search for your headline. If it is there, machines can read it. If it is not, your content is being assembled after the fact.
Not inherently. Most page builders do output your text in the HTML, so the content is readable. The real costs are bloat and fragility: heavy script and stylesheet loads, enormous DOM sizes, and widgets that fetch content after page load. Tabs, accordions, sliders, and popups that pull their content in with JavaScript are the ones that cause trouble. Used carefully, a builder is fine. Used as a widget playground, it buries your content.
We will run the test across your important pages and tell you exactly which parts of your site are readable, which are hidden behind JavaScript, and what it would take to fix. No rebuild pitch unless you genuinely need one. Tell us about your site below, or see our web design work and success stories.
