Does your site's JavaScript actually work?

What this is about

A WordPress site quickly runs a dozen JavaScript libraries: one for the slider, one for the lightbox, one for the scroll animations, one for the form. Each comes from a different plugin, and none of them knows about the others.

The interesting question is not whether they are loaded. It is whether they actually work. Loaded is not the same as working.

On top of that there is a second, quieter question: how many elements is the page built from at all, and how deeply are they nested inside each other?

Why it matters

There is a class of errors that are broken without anyone noticing. A script starts before the library it depends on exists — then it runs into nothing. A .js address returns an HTML error page instead of the file, which the browser silently accepts. A slider is fully prepared in the HTML, but the library that should set it in motion was never started — then all the slides stand below each other or not at all.

You rarely notice such errors yourself, because you usually look at the page in only one place and because your own browser has the files in its cache.

The second reason it matters has to do with visibility: AI systems do not execute JavaScript. Retrievers process what they read in — not what appears after an interaction. A text that is only loaded after clicking a tab does not exist for them.

On page complexity I want to be explicitly cautious, because it is regularly over-interpreted. Fewer elements do not make a page faster. The two values often move together in a rebuild, but only because both come from the same clean-up work. No connection between element count and loading time can be derived from that.

There is also no reliable general number for “too many elements” or “nested too deeply”. When a report names thresholds, they are Google's own warning points — hints, not rules. What such numbers are really worth only shows the second time: one measurement alone produces three boring numbers. Two measurements before and after a rebuild produce a before and after that a client understands without a vocabulary list.

One more thing that matters in the assessment: an optimisation plugin that holds scripts back until the first interaction looks, on a plain page load, exactly like a broken script. That is a case for a human, not for a verdict.

How to check it yourself

Open your page in a private window and then the developer tools (F12), “Console” tab. Reload.

Red lines are errors. The most common wordings: ... is not defined means a script used something that was not there yet. Uncaught SyntaxError on a .js file often means the file is not a JavaScript file at all, but an error page. 404 together with a .js address means the file is missing.

A note on this: not every red line is yours. Browser extensions and antivirus software also write into the console. If in doubt, check in a browser without extensions.

Then the practical part: click through the whole page once. Sliders, accordions, tabs, lightbox, the menu on the phone, the form. That takes five minutes and finds more than any tool.

And for the visibility question: switch off JavaScript in the browser and reload. What is still there is what search engines and AI systems reliably get.

What to do if it is missing

With console errors the first question is always: which plugin does this belong to? The file path in the error message usually gives it away. Often the cause is banal — a plugin that is no longer maintained, or two plugins that bring the same library in different versions.

If an optimisation plugin is involved, switch off its combining and delaying of JavaScript as a test. A large share of the script errors on WordPress sites only arise there — through merging files whose order tips over in the process.

For visibility: the main text belongs in the delivered HTML. If content sits in tabs or accordions, it should be present in the HTML and only visually collapsed — not loaded later by script.

And on complexity: the way there does not lead through an element count, but through less nesting in the build. Page builders create extra containers for every row and every column. A build that uses modern CSS layout instead gets by with a fraction. That is a question of how the site is built, not an optimisation step afterwards.

Sources

• Script runs before the library exists; .js address answers with an HTML error page; elements are prepared for a library that was never started; loaded is not working; console messages from antivirus software and browser extensions on the checking machine are filtered out before evaluation; an optimisation plugin that holds scripts back until the first interaction cannot be told apart from a broken script on a passive load and is kept as a case for a human to check; element count and nesting depth are a measure of complexity and not of performance, because fewer elements do not make a page faster; there is no reliable general number, the thresholds are Google's own warning points; the value arises on the second run as a before-and-after comparison -- @ctx:projects-tools-checky-workbench-docs-tech-specs-probe-catalog-experience@7
• RAG retrievers process what they parse, not what renders after an interaction; a main answer behind a JavaScript tab or accordion is missing from the first-paint HTML and therefore for retrievers; Etch FSE delivers static HTML server-side -- @ctx:atlas-seo-practice-2026@3
• Risk of client-side rendering, because Google often delays JavaScript processing; prefer server-side rendering or pre-rendering; test rendering through Search Console's URL inspection; find unused JavaScript and CSS through the developer tools' code coverage -- @ctx:atlas-seo-technical-audit@1
• AI crawlers do not execute JavaScript, which is why a page with script-dependent content is almost empty for them -- @ctx:atlas-seo-geo-scoring@1
• No superfluous JavaScript libraries; clean semantic HTML -- @ctx:projects-websites-dhs-cpt-checklisten-technisches-seo-content@2