Why does Google crawl your JS/CSS files but never indexes them?

What is the concrete difference between crawling, rendering, and indexing?

Martin Splitt describes a three-step distinct process, and this is where many practitioners still confuse the terms. Crawling is the basic HTTP request that retrieves the source code — raw HTML, JavaScript, CSS, images, everything that makes up the resource.

Rendering then occurs to execute the JavaScript in a headless browser. This step transforms the initial code into actually visible content. Indexing, on the other hand, only stores content deemed relevant for the end user — not the technical files used solely to construct the page.

Why does Google crawl JS/CSS files if it doesn’t index them?

Because without these resources, the engine cannot render the page correctly. A JavaScript file can completely modify the DOM, add textual content, reshape the navigation. Without executing it, Google would see an empty or incomplete HTML skeleton.

CSS also impacts visual rendering and can hide or show content using display:none or other rules. Therefore, Google must retrieve these files to understand what the user truly sees — but that doesn’t mean it’s going to index app.js or styles.css as standalone pages.

Does this technical distinction impact the crawl budget?

Absolutely. Every HTTP request consumes crawl budget, whether for an HTML page, a 500 KB JavaScript file, or a stylesheet. If your JS/CSS resources are heavy, fragmented across dozens of files, or poorly cached, you're wasting budget that Googlebot could allocate to your actual pages.

Splitt doesn’t say it explicitly here, but the implication is clear: optimize the weight and number of your technical resources. Minify, bundle, and enable aggressive HTTP caching. The less time Googlebot spends crawling your assets, the more it crawls your strategic content.

• Crawl = an HTTP request that retrieves the raw source code (HTML, JS, CSS, images)
• Rendering = executing JavaScript in a browser to produce the final visible content
• Indexing = selective storage of content deemed relevant for users, not technical files
• JS/CSS files are crawled and rendered out of technical necessity but are never indexed as pages
• Each crawled resource consumes crawl budget — optimizing their weight and caching frees up resources for real pages

Is this crawl/rendering/indexing distinction consistent with real-world observations?

Yes, and it’s indeed one of the rare statements from Google that faithfully reflects the internal mechanics. In practice, we do observe that .js and .css files never appear in the SERPs as organic results — except in cases of extreme misconfiguration (forced indexing via XML sitemap, for example).

However, Splitt simplifies: he doesn’t mention that Google can crawl the same file multiple times if it changes frequently, nor that certain bots (AdSense, AdsBot) behave differently when crawling resources. The reality is a bit more complex than this linear diagram.

What nuances should be made regarding JavaScript rendering?

Splitt refers to "rendering" as a singular step, but in practice, the delay between crawling and rendering can reach several days on some low-authority sites. Google prioritizes rendering based on opaque criteria — crawl budget, page popularity, content freshness.

Second nuance: Google’s rendering does not execute all JavaScript the same way a real browser does. Certain events (infinite scroll, complex user interactions, long timers) may not always be triggered. If your critical content relies on a setTimeout of 5 seconds, it might never be seen. [To be checked] systematically using the URL inspection tool in Search Console.

In what cases can the 'no indexing of JS/CSS' rule pose a problem?

If you block your JS/CSS files via robots.txt, Google can still crawl the HTML page, but it won’t be able to render it correctly. The result: it indexes a stripped-down version, without the dynamically generated content. This is a classic mistake inherited from old SEO practices.

Another edge case: Progressive Web Apps (PWAs) that load all content in pure JavaScript. If the initial HTML is an empty shell and the JS takes 3 seconds to load, Google might see just a skeleton. The solution remains Server-Side Rendering or static pre-rendering — no miracles here.

What should you prioritize checking on your site?

Systematically test your main pages using the "URL Inspection" tool in Google Search Console. Compare the raw HTML code ("More info" tab > "Crawled HTML") with the rendered version ("Rendered HTML"). If strategic content only appears in the rendered HTML, you rely on JavaScript — which is acceptable, but provided the rendering works.

Next, make sure your JS/CSS files are accessible and not blocked. A 403, a 500, or a robots.txt blockage prevents Google from retrieving them, thus unable to render the page. Use server logs to track errors on these resources.

How to optimize the crawling of technical resources?

Consolidate your JavaScript and CSS files into optimized bundles instead of serving 50 small files. Each HTTP request has a cost in crawl budget. Minify with modern tools (Terser, cssnano), enable Brotli or Gzip compression, and configure aggressive cache headers (Cache-Control: max-age=31536000 for versioned assets).

If you use a CDN, ensure that Googlebot can access it without rate-limiting. Some CDNs block or slow down bots — explicitly whitelist Googlebot’s IPs (check the official IPs) if necessary.

What SEO mistakes should you absolutely avoid?

Never block JS/CSS via robots.txt — we’ve mentioned it, but it’s worth repeating. Some sites still do it "to save crawl budget," which is counterproductive: Google still crawls the HTML page but cannot render it.

Also, avoid loading critical content only after user interaction (click, scroll). Google does not interact with your pages like a human. If a "See more" button must be clicked to display indexable text, that text will never be seen. Prefer native lazy-loading (loading="lazy") for images, not for text.

• Test each strategic page with the "URL Inspection" tool in Search Console (Crawled HTML vs Rendered HTML)
• Check that all JS/CSS files are accessible (status 200) and not blocked by robots.txt
• Minify and bundle JavaScript and CSS resources to reduce the number of HTTP requests
• Enable Brotli/Gzip compression and aggressive cache headers (max-age=31536000 for versioned assets)
• Whitelist official Googlebot IPs on the CDN if rate-limiting is active
• Never condition the display of indexable content on user interaction (click, event scroll)