How do I allowlist Prerender.io's IP addresses?
Allow Prerender.io's IP ranges so your firewall, WAF, or CDN does not block rendered pages from reaching AI crawlers and search engines.
TL;DR
Prerender.io renders your pages from a fleet of public IPs in two CIDR blocks — 103.207.40.0/22 and 104.224.12.0/22. The Sitemap Crawler uses a separate ingress range, 5.161.0.0/16. If your site sits behind a firewall, WAF, or CDN that filters by IP, allow these ranges so Prerender is not blocked at the network boundary. The canonical, always-current list lives at ipranges.prerender.io/ipranges-all.txt — script your allowlist against that file rather than copying static values.
Next up: How do I manage domains in Prerender.io? — add, monitor, and remove domains using your shared Prerender token.
Why this matters
To keep your pages visible to AI crawlers and search engines, Prerender has to reach your origin server, fetch each page, and render it. If your firewall, web application firewall (WAF), or CDN filters traffic by IP, and Prerender's IPs are not on the allowlist, those requests are blocked before they ever reach your origin.
When that happens, the affected URLs stop updating. Your SEO Score and cache go stale, and crawlers eventually receive an older snapshot or a non-200 response for those pages. Allowlisting Prerender's IP ranges keeps the render flow open end to end.
There are two sets of addresses to allow: the egress IPs the rendering fleet uses to fetch your pages, and the ingress range the Sitemap Crawler uses. The steps below cover both.
Step 1 : Confirm your site filters traffic by IP
Check whether your origin sits behind a firewall, WAF, or CDN that restricts access at the network level — Cloudflare, AWS WAF, Akamai, or similar. If nothing filters inbound traffic by IP, you have nothing to allowlist and can skip ahead to verification.
If something does filter by IP, note which product it is and where you manage its allowlist. You will add every range below in that same place.
Step 2: Allow the rendering IP ranges (egress)
These are the egress IPs the rendering cluster uses when it fetches pages from your origin, and they are used exclusively by Prerender's rendering fleet. Add both CIDR blocks to your firewall or CDN allowlist:
103.207.40.0/22
104.224.12.0/22
Some firewalls and CDNs do not accept wide CIDR blocks like /22. If you are limited to /8, /16, or /24 blocks only, use these narrower equivalents instead — they cover the same address space, split across eight /24 entries:
104.224.12.0/24
104.224.13.0/24
104.224.14.0/24
104.224.15.0/24
103.207.40.0/24
103.207.41.0/24
103.207.42.0/24
103.207.43.0/24
Step 3: Allow the Sitemap Crawler range (ingress)
The rendering ranges above do not cover the Sitemap Crawler, which uses a separate ingress range. If you use sitemap-based recaching or crawl support, add this range as well:
5.161.0.0/16
You can also identify the Sitemap Crawler by its User-Agent string and allow it that way, instead of or in addition to allowing it by IP:
Prerender (+https://github.com/prerender/prerender)
⚠️ Allow the rendering egress IPs and the Sitemap Crawler together. Allowing only the egress IPs leaves the Sitemap Crawler blocked, and allowing only the crawler leaves your renders blocked.
Step 4: Keep your allowlist current
The static blocks above are a starting point, not the complete fleet. The IP list updates from time to time as the rendering fleet grows or rotates, and the live file contains many more individual addresses than the static blocks shown here.
The canonical source is ipranges.prerender.io/ipranges-all.txt, updated whenever the fleet changes. To avoid drift, script a fetch against that file and rebuild your allowlist from it — at least once a month, or on a schedule.
ℹ️ If you have a strict allowlist that drops anything outside the static CIDR blocks, you may still see some legitimate Prerender traffic blocked. Fetching the live list on a schedule and rebuilding from it is the simplest fix.
Step 5: Verify Prerender can reach your origin
Once the ranges are in place, confirm renders are getting through. Trigger a render for one of the affected URLs — for example, request the page with a crawler User-Agent, or recache it from your dashboard — then check your firewall or CDN logs for a source IP inside the ranges above and an accepted, 200-level response.
✅ Your allowlist is working when requests from the Prerender ranges reach your origin, return a 200 response, and the affected URLs start updating in your dashboard again.
If requests are still blocked, review the pitfalls below, then contact support with a sample blocked request.
Common pitfalls
- Allowing only the egress IPs. This leaves the Sitemap Crawler blocked. Allow both the rendering ranges and the Sitemap Crawler User-Agent.
- Rejecting the
/22blocks. If your firewall or CDN will not accept wide CIDR blocks, use the eight/24ranges from Step 2 — they cover the same address space. - Treating this article as the full list. The static ranges here are a starting point. The live
ipranges-all.txtfile is the source of truth — re-sync against it periodically.
Traffic origin and server regions
Prerender runs its rendering infrastructure across US and EU regions. If you need to restrict traffic to a single region — for example, to keep all rendering traffic inside the US — paid customers can request a US-only configuration through support.
Related articles
- Status codes
- Rendering queues
- How does Prerender.io work?
- How do I add AI crawlers and bots to my integration?
If you have allowlisted the IPs and the User-Agent and still see Prerender requests getting blocked, our support team can dig into the firewall logs with you. Include which firewall, WAF, or CDN you use, whether your allowlist uses the
/22 blocks or the /24 narrow ranges, and a sample blocked request — source IP, destination URL, response code, and approximate timestamp.→ Contact us at support@prerender.io