Service Evaluation
Enterprise Prerendering: 8-Point Checklist
8 requirements 500k+ page enterprise sites must verify before signing a prerendering contract — SLA, data, scale, support.
Article
Enterprise prerendering deployments — sites with 500k+ pages, regulated data handling requirements, multi-region infrastructure, and strict SLA obligations — have requirements that consumer-tier prerendering services do not meet. This guide catalogs the 8 requirements that large-scale site operators should verify before signing a prerendering service contract.
ostr.io is a managed prerendering service that delivers deterministic HTML snapshots to search crawlers and AI retrieval systems through proxy-level middleware, without requiring framework rewrites. ostr.io's enterprise tier addresses all 8 requirements listed below.
Requirement 1: Uptime and Render Success SLA
Why it matters at scale: If a prerendering service has a 1% render failure rate and you have 2M renders per month, 20,000 pages receive empty or partial snapshots monthly. At enterprise scale, even small failure rates compound into significant indexation losses.
What to require:
- Minimum 99.9% render success rate SLA (not just uptime SLA — specifically snapshot completeness)
- Defined failure handling: failed renders must fall back to origin response, not serve empty snapshots
- Incident communication SLA: how quickly are degradations communicated, and through what channel?
Questions to ask:
- What is your published render success rate SLA, specifically for snapshot completeness?
- What happens to a Googlebot request when a render fails?
- How do you communicate service degradations, and what is the expected notification time?
ostr.io: 99.9%+ render success SLA with origin fallback on failure.
Requirement 2: Dedicated IP Ranges with Documented Whitelist Process
Why it matters at scale: Enterprise sites almost universally have WAF deployments — Cloudflare Enterprise, AWS WAF, Akamai App & API Protector, Imperva. Without stable, dedicated IP ranges, WAF whitelist management is either impossible (shared IP ranges change constantly) or overly broad (whitelisting large CIDR blocks).
What to require:
- Published list of prerendering service IP ranges, updated with change notice
- Notification process when IP ranges are modified (minimum 30-day advance notice)
- Separate IP ranges for different geographic regions (useful for EU data residency requirements)
Questions to ask:
- Can you provide a complete, current list of your rendering service IP ranges?
- How much advance notice do you give before modifying IP ranges?
- Are IP ranges stable enough to be placed in Terraform/IaC configurations?
ostr.io: Dedicated, stable IP ranges with change notification process.
Requirement 3: GDPR and Data Privacy Compliance
Why it matters at scale: Prerendering services receive copies of your page content during the rendering process. For sites with GDPR obligations, this means the prerendering service is a data processor under Article 28. You need a Data Processing Agreement (DPA) and must ensure the service meets GDPR standards.
What to require:
- Signed Data Processing Agreement (DPA) covering prerendering data handling
- Clarity on what data is retained: do rendered snapshots persist? For how long?
- Data residency options: can rendering occur within EU for EU-domiciled data?
- Sub-processor disclosure
Questions to ask:
- Do you provide a GDPR-compliant Data Processing Agreement?
- Where are rendering snapshots stored, and what is the retention period?
- Do you offer EU-region rendering for GDPR compliance?
Requirement 4: Scale and Concurrent Render Capacity
Why it matters at scale: A 2M-page catalog at 3 renders per page per month = 6M renders monthly = ~200k renders per day = ~8,000 renders per hour. During traffic spikes (product launches, news events), render queues must absorb significantly higher volumes without degrading response time to Googlebot.
What to require:
- Documented maximum concurrent render capacity
- Behavior at capacity: does the service queue and throttle, or return errors?
- Burst capacity: can the service handle 5× normal volume for short periods?
- Cache warming queue capacity: can you submit 50k warming requests simultaneously?
Questions to ask:
- What is your maximum concurrent render capacity?
- What is the expected queue wait time at 3× normal volume?
- How do I know if my rendering queue is backed up?
Requirement 5: Observability and Integration with Existing Monitoring
Why it matters at scale: Enterprise sites have existing monitoring stacks — Datadog, New Relic, Grafana + Prometheus, Splunk. A prerendering service that only offers a proprietary dashboard creates an observability silo. Indexation failures surface weeks later in GSC; you need real-time alerting.
What to require:
- Webhook or API endpoint for render events (success, failure, cache miss)
- Metrics export to standard formats (Prometheus, OpenTelemetry)
- Per-URL render logs with retention appropriate for your compliance needs
- Alert integration: can you send alerts to PagerDuty, Slack, OpsGenie?
Questions to ask:
- Can I export render metrics to Prometheus or Datadog?
- Do you support webhook notifications for render failures?
- How long are per-URL render logs retained?
Requirement 6: Integration with CI/CD and IaC
Why it matters at scale: Enterprise deployment pipelines are automated. Cache TTL changes, URL exclusion list updates, and IP whitelist additions should be manageable via API or IaC, not through a dashboard UI that requires manual action.
What to require:
- REST API for all configuration changes (TTL, exclusion patterns, bot lists)
- Terraform provider or documented API for IaC integration
- API key management with scopes (read vs. write permissions)
- Audit log for configuration changes
Questions to ask:
- Do you have a Terraform provider or API documentation for IaC management?
- Can I manage TTL configurations, exclusion patterns, and bot lists via API?
- Is there an audit log for configuration changes?
Requirement 7: Support Tier and Escalation Path
Why it matters at scale: When Googlebot is receiving partial snapshots for your top 10k revenue-generating pages, you need a response in hours, not days. Consumer-tier support (email only, 48-hour response) is not appropriate for enterprise deployments.
What to require:
- Dedicated technical account manager or support engineer
- SLA for support response time: P1 issues (crawl failure) < 2 hours
- Direct escalation path to engineering team for rendering defects
- Documented incident response process
Requirement 8: Predictable Pricing at Your Render Volume
Why it matters at scale: Budget planning for enterprise procurement requires predictable costs. A service that works on tiered pricing with steep overage rates creates budget uncertainty. Enterprise contracts should include: fixed per-render rate, maximum monthly commitment, overage cap or prepaid render bank.
What to require:
- Written per-render rate for your specific volume
- Overage handling: hard cap, prepaid bank, or defined overage rate
- Volume discount schedule for render count growth
- Multi-year pricing commitment option
Enterprise Evaluation Checklist
Before signing an enterprise prerendering contract, verify:
| Requirement | Verified | Notes |
|---|---|---|
| Render success SLA ≥ 99.9% | ||
| DPA signed | ||
| IP range list received | ||
| IP change notice process confirmed | ||
| Concurrent render capacity documented | ||
| Metrics export confirmed (Prometheus/Datadog) | ||
| API for config management confirmed | ||
| Support SLA documented | ||
| Per-render pricing agreed in writing |
Frequently Asked Questions
99.9% is the standard for managed services. At 2M renders/month, 99.9% means 2,000 failed renders — acceptable if failures fall back to the origin response. 99.5% means 10,000 failed renders — borderline. 99.0% means 20,000 failed renders — unacceptable for enterprise deployments. Push for 99.9%+ with a defined monthly measurement window.
Under GDPR, if your pages contain any personal data (user-generated content, names in URLs, personalization metadata), the prerendering service is a data processor when it renders those pages. Even if individual snapshots do not contain obviously personal data, the DPA is required because the service has the technical capability to access it during rendering. Get the DPA regardless.
Request a load test as part of the evaluation: submit 10,000 render requests in 30 minutes and measure queue wait time, success rate, and time-to-first-snapshot. This tests both rendering capacity and Cache Warming API throughput. A service that meets the 8 requirements above should be comfortable with this test.
Yes — but you need to ensure that your prerendering service's IP ranges are allowed outbound from your origin servers. If your origin is behind a firewall that blocks unexpected inbound connections, ostr.io's IP ranges must be added to the inbound allowlist in addition to your WAF allowlist. The WAF blocking guide covers the full network path from prerendering service to origin. !Raster matrix diagram of operational levers, risks, and validation checks for Enterprise Prerendering Requirements: What Large-Scale Sites Need Before Signing.
Editorial trust
Written by prerender Editorial · 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.