Prerender for bots
Search bots, social-share scrapers and legacy crawlers still choke on client-side rendering, and a blank div is worse than no page at all. The Prerender API loads your URL in a real browser context, waits for the app to finish rendering, and hands back the final HTML exactly as a human visitor would see it. Point your server or edge logic at it whenever a bot user-agent shows up, and stop guessing whether Googlebot actually saw your content.
Run it online
Run this on our servers with your account. Free tools run in your browser; this one bills your KIT balance per the price above.
The gap between what you built and what gets indexed
Single-page apps built with modern frameworks look perfect in a browser but frequently arrive at search engines and crawlers as an empty shell, because the HTML they request never runs the JavaScript that fills it in. This hits SPAs, heavily hydrated e-commerce catalogs, and any site where content depends on client-side data fetching. The Prerender API exists specifically for teams who cannot rewrite their whole front end into server-side rendering just to satisfy a handful of bots.
What actually happens on each call
You send a URL to POST /web/prerender, our infrastructure opens it in a real rendering engine, waits for network activity and key JavaScript execution to settle, and captures the resulting DOM as static HTML. That HTML is what gets returned, complete with meta tags, injected structured data, and any content that only appeared after an API call finished on the client. It behaves the same as a browser tab that was left open until everything loaded.
A short history of a persistent problem
Search engines have improved their JavaScript execution over the years, but rendering budgets remain limited, unevenly applied across crawlers, and largely invisible to site owners. Meanwhile social preview bots, link unfurlers, and many SEO auditing tools never evolved past reading raw HTML at all. Prerendering as a technique predates most modern frameworks precisely because this asymmetry between rendering-capable and rendering-blind clients has never fully closed.
Fitting it into a pipeline instead of a browser tab
Because the endpoint is asynchronous, you queue a request, get a task_id immediately, and receive the finished HTML by signed webhook or a link valid for 24 hours — no held-open connections, no polling loops baked into your critical path. Middleware that detects bot user-agents can call this endpoint on demand, or you can pre-warm a cache of your most important URLs on a schedule and serve from that cache instantly.
Where it stops being your problem
Once the rendered HTML is in your hands, what you do with it is entirely yours: cache it at the edge, store it as a static fallback, or feed it straight into another automated step like a meta-tag check or an SEO audit. We do not retain the page content beyond the retention window, and nothing rendered here is used to train anything.
What you can do with it
Serving Googlebot a complete page
Detect the crawler user-agent at your edge, call the Prerender API for that URL, and serve the rendered HTML instead of your empty app shell.
Fixing broken social previews
Link-unfurling bots on messaging apps often skip JavaScript entirely; prerendering guarantees your Open Graph tags and preview image are actually present in the HTML they read.
Feeding downstream SEO tools accurate HTML
Run a page through prerendering first, then pipe the result into a heading or meta-tag audit so the analysis reflects what a rendered page really contains.
Pre-warming a static cache overnight
Batch through your sitemap on a schedule, store the rendered HTML for each URL, and serve bots from that cache with zero rendering latency during the day.
FAQ
What does the Prerender API actually return?
The final, fully rendered HTML of the URL you submit, captured after JavaScript execution has settled — the same markup a browser would show, not the original source.
Is there a free tier for testing?
There's no free tier — free tiers get abused and slow everyone down. Access runs on a prepaid ForHosting KIT balance: top up from $10.00 (it never expires) and each request is charged at its published price, so a call with no balance returns HTTP 402. No subscription, no tokens, no invented credits, and a failed task is never charged.
How do I get the result back?
The call to POST /web/prerender is asynchronous and returns a task_id immediately; the finished HTML arrives via signed webhook or a signed link valid for 24 hours.
What happens if rendering fails?
The task retries automatically up to three times; if it still fails you get a clear error and you are never charged for a failed task.
How is this priced?
It's $0.040 per request plus $0.001 per URL, published and predictable so you can calculate a batch job's cost before you queue it.
Can I use it for pages behind authentication?
The endpoint renders whatever URL you submit, so any authentication needs to be handled via URL parameters, cookies, or headers your setup already supports.
Does prerendering help with page speed too?
Indirectly yes — serving pre-rendered HTML to bots and cached visitors removes client-side render time from their experience entirely.
Is my page content stored long-term?
No. Results are deleted after the retention window and are never used to train any model.
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, and soon from our app, email and Telegram.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/web/prerender \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"url":"https://ejemplo.com"}'const res = await fetch("https://api.kit.forhosting.com/web/prerender", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"url": "https://ejemplo.com"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/web/prerender",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"url": "https://ejemplo.com"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/web/prerender", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"url":"https://ejemplo.com"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"url":"https://ejemplo.com"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/web/prerender", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"url": "https://ejemplo.com"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "web.prerender",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Limits
timeout_sec | 30 |
max_crawl_pages | 25 |
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
422 | task_failed | The task failed after 3 retries. You are never charged for it. |