See what crawlers get from your site.
Your users see a finished React, Vue, or Svelte app. Many crawlers receive the empty HTML shell.
Know the problem already? Start free
How it fits
Prove the crawler path before you commit to a frontend migration.
Use PageFlash for registered public SPA routes that need inspectable crawler HTML, cache state, and render evidence. Use SSR or SSG when the user experience itself needs server rendering. The same API can also produce screenshots, PDF, and Markdown for backend or internal workflows.
01
Register the host
Add the SPA hostname bots should see. Domain scoping rejects arbitrary third-party renders before a browser starts.
02
Keep the key server-side
Create a scoped key for edge, server, proxy, or job code. Do not ship PageFlash credentials in browser bundles.
03
Route the crawler user-agents you choose
Use your edge, server, or proxy integration to send selected crawler traffic through PageFlash. Normal visitors stay on your regular SPA route when that rule is in place.
04
Prewarm public URLs, then refresh
Eligible plans can queue sitemap URLs for warming. Pro and Enterprise can request background refreshes for changed paths after a publish or deploy.
if (isCrawler(req.headers['user-agent'])) {
return fetch('https://pageflash.io/render?url=' + encodeURIComponent(url), {
headers: { Authorization: 'Bearer PAGEFLASH_KEY' }
})
}
return serveYourSpa(req)Proof + pricing
Prove the crawler response first. Pay for capacity and freshness only when the job is real.
The decision stays grounded in what you can inspect: rendered HTML, cache state, scoped keys, and render activity. It does not depend on a ranking or traffic promise.
Runs on pageflash.io
This marketing site uses the same crawler path you can inspect before routing your own bots.
Domain-scoped keys
Registered domains reject arbitrary third-party renders before a browser starts.
Render activity
Status, cache state, latency, and history make crawler rendering observable after launch.
Pricing path
Start with proof. Choose a plan when the operating limits matter.
Compare plans by the public routes you operate, how fresh crawler output must be, and whether your team needs sitemap warming, push refresh, or SEO operations.
Free to inspect one public crawler path
Starter to warm the first production site
Growth for more domains, URLs, and freshness control
Pro for push refresh and SEO operations
FAQ
Questions to answer before routing production crawler traffic
What problem does PageFlash solve?
PageFlash renders registered public SPA routes into HTML that you can return to the crawler user-agents your integration selects. Your visitors stay on the normal SPA path when your edge, server, or proxy routes only crawler traffic through PageFlash.
Will this change what real users see?
Not by default. Configure your edge, server, or proxy to route the supported crawler user-agents you choose. PageFlash does not decide which traffic reaches the render endpoint for you.
Do I still need SSR?
Use SSR or SSG when the user experience itself needs server rendering. Use PageFlash when the immediate problem is verifying crawler visibility for public routes your SPA already ships.
Can I verify it before changing production traffic?
Yes. Add a domain, create a scoped key, and make a crawler-style request to inspect the exact HTML response before you route production bots.
How does sitemap warming help?
On eligible plans, PageFlash reads sitemap URLs and queues them for warming so known public pages can be rendered before a crawler request. It reduces cold-render risk but does not promise that every crawler request is already warm.
What counts as a render?
One fresh render is a request that needs the PageFlash browser. Cache hits do not consume render quota. Visitor page views do not count unless your integration intentionally routes them through PageFlash.
What if content changes often?
Starter uses a 1d default freshness window. Growth unlocks custom TTLs down to 1h. Pro adds push refresh so a CMS publish or deploy can queue changed paths for background refresh.
How do you limit key abuse?
Keys are scoped to registered domains, and unregistered hosts are rejected before rendering. Use separate keys for middleware, jobs, and environments so each one can be revoked safely.
Can I switch from prerender.io?
Yes. Register the domain, create a scoped key, validate the rendered HTML with a crawler-style request, then move selected crawler traffic gradually through your existing edge, server, or proxy integration.