Standard crawl budget guides explain that Google has a limited number of pages it will crawl per day and that you should prioritise important pages and block low-value ones. This is correct but incomplete for JavaScript-heavy sites, which face a second, separate crawl budget constraint that most teams never audit: the rendering queue.

Two Separate Crawl Budget Systems

For JavaScript sites, Googlebot operates on two distinct budget systems that are often confused:

Wave 1 budget — HTML fetch and discovery. This is the standard crawl budget: the number of HTTP requests Googlebot makes to fetch your HTML responses. Every page load, including the initial SPA shell load, consumes Wave 1 budget. This is what standard crawl budget guides cover.

Wave 2 budget — JavaScript rendering queue. This is the separate system where Googlebot queues pages for JavaScript execution and full rendering. The rendering queue is shared across all websites Google processes — it is a finite resource that your site competes for against every other JavaScript-dependent site. A page can be fetched in Wave 1 immediately but not rendered until days later if the rendering queue is congested.

As we covered in our guide to JavaScript SEO, this two-wave system is why content only visible after JavaScript execution may not be indexed for days or weeks after publication on lower-authority sites where rendering queue priority is low.

What Determines Your Rendering Queue Priority

Google allocates rendering queue priority based on your domain's overall authority and trust signals. High-authority sites (major publishers, established brands) get faster rendering queue access. New or low-authority sites wait longer. This is why the same JavaScript content that gets indexed within hours for a major publication may take weeks for a new site.

The practical implication: for low-authority JavaScript sites, the rendering queue delay is not a bug you can fix — it is a priority allocation that improves as your domain authority grows. The mitigation is ensuring critical content does not depend on the rendering queue at all.

Auditing Your Rendering Queue Dependency

To identify which pages have rendering queue dependency, compare two crawl outputs:

Crawl 1 — JavaScript disabled. Use Screaming Frog with JavaScript rendering off. Record what content exists in the HTML response for each URL.

Crawl 2 — JavaScript enabled. Run a second crawl with JavaScript rendering on. Record what content exists after rendering.

The difference between the two outputs is your rendering queue dependency. Any content, links, or metadata present in Crawl 2 but absent from Crawl 1 requires the Wave 2 rendering queue. For important content, this is a risk that needs addressing.

Use our site scanner to identify pages returning thin content responses — these often indicate pages where the initial HTML shell provides minimal content for Wave 1 indexing while all substantive content loads via JavaScript in Wave 2.

Reducing Rendering Queue Dependency

Move critical content to server-side rendering. As covered in our guide to SPA SEO, SSR ensures that critical content exists in the HTML response and does not require the rendering queue at all. The HTML fetch in Wave 1 contains everything Google needs to index the page.

Identify and fix the highest-value rendering dependencies first. Not all rendering queue dependencies are equal. Your homepage, key category pages, and most important content pages deserve SSR treatment. Lower-value pages can accept rendering queue delays without significant SEO impact.

Reduce JavaScript bundle size. Smaller JavaScript bundles execute faster in the rendering queue. A page that renders in 200ms gets through the queue faster than one that takes 3 seconds to render. As we covered in our guide to advanced speed optimisation, code splitting and lazy loading reduce the rendering burden for each individual page.

Monitoring Rendering Queue Health

In Google Search Console, the Coverage report's "Crawled — currently not indexed" status sometimes indicates rendering queue backlog — Google fetched the page but has not yet rendered it for indexing. If you see this status on recently published important pages, check whether the pages render fully without JavaScript. If they do not, the rendering queue is the likely indexing bottleneck.

Summary

JavaScript sites face two separate crawl budget constraints: Wave 1 HTML fetch budget (standard) and Wave 2 rendering queue (often overlooked). Rendering queue priority is determined by domain authority. Audit dependency with parallel crawls (JS on vs off). Reduce dependency by moving critical content to SSR and reducing bundle sizes. Monitor with Search Console's Crawled but not indexed status on important pages.

Continue reading: Keyword Research by Intent Type: Different Metrics for Different Queries