Should you block Googlebot on the slow pages of your site?

Why does Google insist on crawling all your pages, even the slowest ones?

The logic is simple: Googlebot wants to access the same content that your users see. Blocking certain pages on the grounds that they are slow creates a discrepancy between what the bot sees and what your visitors can access. This inconsistency can harm your indexing and may even be interpreted as an attempt at cloaking if the blocked pages contain substantial content.

Google specifies that only one in a hundred requests is influenced by the speed factor in ranking. This figure, officially published, puts into perspective some SEO experts' obsession with every millisecond gained. Speed does matter, but its direct weight in the ranking algorithm remains marginal for most sites.

What does Google consider an 'excessive' loading time?

Google deliberately remains vague on this threshold. The expression 'particularly slow to the extreme' is not accompanied by any quantified metrics. There's no 'beyond X seconds, you are penalized'. This vagueness is typical of Google's communication: it's impossible to draw a clear red line.

One could reasonably consider that a site with loading times exceeding 5-7 seconds on mobile falls into this category. However, even then, Google's recommendation is not to block pages, but to improve performance for user experience, not for crawling. This is a crucial distinction.

Does crawl budget come into play with slow pages?

This is the real question posed by this statement in a roundabout way. If Googlebot spends time on your slow pages, it will have less time to explore your strategic content. For sites with fewer than a few thousand pages, crawl budget is generally not an issue. Google has repeated this: this concept concerns only a minority of very large sites.

However, on an e-commerce site with 50,000 product listings, of which 20,000 are slow and little relevant variations, the calculation changes. There, blocking these pages can free up crawl budget for content that matters. But this is a global architectural decision, not a cosmetic patch.

• Googlebot wants to explore what your users see: blocking accessible pages creates a risky inconsistency.
• Only 1 request out of 100 is affected by speed: the direct impact on ranking is less than one might think.
• ‘Excessively slow’ remains undefined: Google provides no specific threshold, making the application of this advice subjective.
• Crawl budget is only an issue for very large sites: for the majority of projects, it is not a limiting factor.
• Optimization should focus on UX before SEO: speed mainly affects conversion and engagement, not directly the ranking for most sites.

Is this statement consistent with practical observations?

Yes, overall. The myth of speed as a dominant ranking factor has persisted since the Speed Update announcement, but A/B testing on hundreds of sites shows that the impact remains modest. Improving LCP from 3.5s to 2.0s does not mechanically propel a site from page 3 to page 1. The observed gains are often indirect: improved click-through rate, reduced bounce rate, positive user signals.

However, Google obscures part of the picture. Speed influences Core Web Vitals, which themselves are part of the Page Experience. Saying that one request out of a hundred is affected by 'the speed factor' does not clarify whether this figure includes or excludes the impact of CWV as a signal. [To be verified]: this wording leaves uncertainty about the counting methodology.

In what cases does blocking slow pages remain relevant?

Contrary to what Google suggests, there are scenarios where blocking certain pages makes sense. On a legacy site with thousands of heavy administrative pages, accessible but without SEO value (multi-step forms, internal tools exposed by mistake), excluding them from crawling frees up resources. It is not cloaking if these pages were never meant to be indexed.

Another case: infinite filter pages on an e-commerce site. If each combination of filters (red color + size M + price 50-100€) generates a slow and nearly duplicated URL, blocking them via robots.txt or setting them to noindex improves the overall health of the site. But again, the decision is made at the architectural level, not page by page.

What nuances does Google deliberately omit?

Google does not mention that speed indirectly affects SEO through behavioral metrics. A slow site tends to have a higher bounce rate, reduced visit time, and fewer pages viewed per session. These signals likely feed into ranking models, even if Google refuses to admit it explicitly.

Additionally, speed plays a role in mobile-first indexing. On mobile, connections are less stable, and processors are less powerful. A site that takes 8 seconds to load on 3G is objectively penalized in UX, thus in business performance, and consequently in indirect signals. Reducing this impact to 'one request out of a hundred' is a careful communication strategy, not total transparency. [To be verified]: no public data allows quantifying the indirect effect via user metrics.

What should you do if your pages are slow?

Let’s be clear: optimize for your users, not for Googlebot. Focus on the metrics that impact conversion: LCP (Largest Contentful Paint), INP (Interaction to Next Paint), CLS (Cumulative Layout Shift). These indicators reflect the real experience and, incidentally, send positive signals to Google through user behavior.

Don’t waste time blocking slow pages in robots.txt hoping for an SEO gain. If a page is useful for your visitors, it should be crawlable. If it isn’t, question its relevance in your structure, not its speed. Architecture takes precedence over superficial optimization.

What mistakes should you absolutely avoid?

First mistake: believing that improving speed by 10% will double your organic traffic. Direct SEO gains are marginal for most sites. Business gains (conversion, average order value, recurrence) are measurable and substantial. Don’t confuse the two.

Second mistake: blocking entire categories of pages on the pretext that they load slowly. You risk creating crawl orphans, indexing inconsistencies, or even negative signals if Google detects a discrepancy between what the bot sees and what the user accesses. Unintentional cloaking is more common than one might think.

How can you check that you're on the right track?

Use Google Search Console to identify indexed pages with Core Web Vital issues. Cross-reference this data with your analytics: which slow pages are generating traffic and conversions? These should be your optimization priorities. Slow pages without traffic can be deindexed (noindex), but should not be blocked from crawling if they remain accessible.

Test your optimizations on a sample: isolate 10-20 strategic slow pages, improve them (lazy loading, image compression, CDN, code splitting), and measure the impact on bounce rate and session time. If these metrics improve, deploy on a larger scale. SEO will follow suit as a result.

• Audit your Core Web Vitals in Search Console and prioritize slow strategic pages.
• Never block pages accessible to users, even if they are slow.
• Optimize for UX (LCP, INP, CLS), not for a hypothetical direct ranking gain.
• Deindex (noindex) pages without SEO value, but do not block them if they remain useful for internal navigation.
• Test the impact on behavioral metrics (bounce, session duration) before widespread deployment.
• Use a CDN and compression for quick wins, before reworking the technical architecture.