Guides
Pre-rendering guides - choose by symptom, bottleneck, and operating stage
Use this hub when the architecture is already plausible and the real question is operational. The issue is usually one of five things: crawlers are wasting budget, snapshots are stale, render cost is climbing, parity is breaking between cached HTML and the live app, or the URL set has grown past the point where defaults still work.
Start with crawl budget fundamentals when you still need the baseline diagnosis. Move to expand crawl budget when the problem is confirmed and you need sequencing. Use pre-render cache headers when freshness and invalidation are the real bottlenecks. Use large sites (100k+ pages) when scale itself is now the main constraint.
The advanced guides are for narrower cases such as hydration drift, paywalled content, shadow DOM, or headless-browser ownership. If you are still deciding what kind of site pattern you have, step back to use cases. If you are already choosing tooling, move forward to compare.
Explore Pre-rendering guides - choose by symptom, bottleneck, and operating stage
Choose the right pre-rendering guide by symptom: crawl waste, stale cache, render cost, parity drift, or large-site scale. April 2026.
Crawl budget fundamentals
Start here if the diagnosis itself is still fuzzy. Best for teams that know indexing is weaker than it should be but have not isolated whether crawl waste is the real cause.
Baseline diagnosisExpand your crawl budget
Use this when crawl-budget waste is already established and you need the next sequence of changes: canonical compression, sitemap structure, and template prioritization.
Fix sequenceFix the 80% crawl-budget loss
Best when pages exist but indexing still stalls. This guide is built around the classic render-queue and wasted-fetch pattern on JavaScript-heavy sites.
Specific failure modeLarge sites (100k+ URLs)
The right path when the site has already crossed into six-figure URL territory and selective rendering, shard logic, and economics matter more than defaults.
Scale operationsPre-render cache headers
Choose this when freshness, TTL design, purge triggers, and stale-snapshot risk are the operational bottlenecks rather than raw crawl discovery.
Freshness controlCrawl frequency signals
Useful when crawlers are not coming back quickly enough after updates and the team needs a clearer model for recrawl cues and false positives.
Recrawl modelJavaScript rendering cost
Use this when the main question is economic: what rendering actually costs at 10k, 100k, and 1M URLs, and where build-vs-buy math changes.
Cost modelAdvanced: paywalled content
Read this only when the crawler-visible surface sits behind subscription boundaries and parity or anti-cloaking risk needs careful control.
AdvancedAdvanced: hydration failures
The right guide when the pre-rendered snapshot and hydrated app disagree, especially after deploys, experiments, or partial component failures.
AdvancedAdvanced: headless browser overhead
Choose this when the problem is operational ownership itself: CPU, RAM, queue pressure, crash handling, and the threshold where buying beats building.
AdvancedAdvanced: shadow DOM and SEO
Useful for web-component heavy teams that need to know what crawlers can actually see and what pre-rendering can or cannot rescue.
Advanced
Pre-rendering guides - choose by symptom, bottleneck, and operating stage — common questions
Usually with [crawl budget fundamentals](/guides/crawl-budget). It gives the cleanest baseline model for diagnosis. If the site is obviously stale rather than undiscovered, start with [pre-render cache headers](/guides/prerender-cache-headers) instead.
Choose a guide when the problem is cross-vertical: crawl waste, stale cache, weak recrawl, render cost, or parity drift. Choose a [use-case page](/use-cases) when the problem is strongly tied to one inventory or URL pattern such as job expiry, route/date fanout, or seller-generated facet sprawl.
Only when the core operating model is already clear and the site is hitting a narrower edge case. Most teams should solve crawl budget, freshness, scaling, and cost before spending time on shadow DOM or paywalled-content edge cases.
Usually crawl behavior and crawler-facing HTML quality change first: faster recrawl, cleaner canonical sets, lower stale-snapshot rates, or better first HTML completeness. Ranking and traffic improvements usually follow after those technical signals stabilize.
Move to [compare](/compare) once the operational problem is clear and the team is deciding which vendor or build path can handle it. The guides tell you what has to be fixed. The compare pages tell you who is better equipped to do it.
Related silos
Use cases - diagnose by vertical failure pattern
Go here when the operational problem is tightly coupled to a specific industry or inventory model.
Compare - choose tooling after the ops model is clear
Use the comparison hub once you know which constraints the vendor has to handle.
Technology - how the rendering layer works
Read this if terms like crawler routing, snapshot cache, and invalidation still need a clearer mental model.
Editorial trust
Written by ostr.io engineering team · Engineering Team. We build and run pre-rendering infrastructure for more than 200 engineering teams, which is where the numbers and code samples on this page come from.
Last updated . Editorial scope and review policy: About prerender.info.