We read your pages the way a browser does, and publish a readable markdown twin at your edge — so an assistant that never runs your JavaScript still gets your real content.
Your site is not broken and your rankings may be fine — search engines run JavaScript. This is about the other readers: the ones that ask your server for a page and use what comes back.
We fetch your page without running any JavaScript, because that is what we can actually measure. On a JavaScript app, what comes back is an empty container and a script tag. We are not claiming to know what happens inside anybody's crawler — we can't see in there, and we won't pretend to. What we can say is the part we measure: if a reader does not execute your bundle, an empty container is everything it has. You can check this one yourself in a terminal: curl -s https://yoursite.com/ | wc -c.
<!doctype html>
<html lang="en">
<head>
<title>Aurora Fleet — route planning</title>
<meta name="description" content="Route planning for mid-size fleets.">
</head>
<body>
<div id="root"></div>
<script type="module" src="/assets/index-8f21c0.js"></script>
</body>
</html>
# Aurora Fleet Route planning for mid-size fleets. Aurora Fleet builds each day's driver routes from your depot list, vehicle constraints and delivery windows, and re-plans when a stop is added mid-shift. ## How it works 1. Import depots, vehicles and delivery windows. 2. Aurora solves the day's routes against your constraints. 3. Drivers get turn-by-turn stops; dispatch sees live progress. ## Who it's for Fleets of 10–200 vehicles running their own deliveries.
This works because of where we sit, not because of anything clever. You point one DNS record at us, and we serve your site — so we can answer a request for the readable copy ourselves, without your origin changing at all.
Once, not on every request. A real headless browser loads the page, waits for it to settle, and hands back the DOM your visitors see. No screenshots, no clicking, no interaction with your site.
Rendering swaps the input HTML and nothing else. Deterministic extraction still decides what the page says, the model only formats it, and the claim guard still checks the result against the extraction. You approve it, exactly as you approve the rest.
The twin lives at /your-page.md and in your llms.txt index. Your origin stays exactly the JavaScript app it was — the readable copy is served by the part of your site we already run.
Reading a customer's page with a browser is the most invasive thing this product does. These are the rules it operates under, and they are in the code rather than in a policy document.
Findings, facts and "what AI sees" stay a plain fetch, always. A page that serves nothing without JavaScript keeps that finding after we build a twin for it, because the finding is about your origin and the twin is a separate thing we serve. Rendering never launders a JS-shell site into a healthy audit — there are tests whose job is to fail if it ever does.
A rendered twin lands as a draft, next to the empty plain-fetch view of the same page, and goes live only when you approve it — the same gate every markdown twin has always passed through. The before/after is the review screen.
It carries a provenance label in your dashboard and in the twin's own record: built from the rendered page, because the raw page had no readable text. You always know which of your twins we had to use a browser to read.
If your page renders to an empty screen — an infinite spinner, a hard auth wall, a client-side error — we do not invent content for it. You get the same honest refusal, now with the stronger version of it: even a browser found nothing readable here.
Rendering a page in a real browser costs us money every time, so it is metered rather than unlimited, and the meter is visible in your account rather than discovered in an invoice.
1,000 browser renders a month on Studio, pooled across every site on the account — plenty to build and keep a real twin set current. Free and Pro include none: they can still see the finding, and the twin pipeline still works on pages that serve readable HTML.
Automatic rebuilds — the hourly pass that catches a redeployed JavaScript app — are capped at 50 renders per site per day, so a loose redeploy loop can't spend a month's allowance in an afternoon behind your back. A bulk build you start yourself isn't held to that daily number — it draws straight from the monthly pool, paced by your own queue. At the pool we refuse the render and say so — there is no render overage rate, because we would rather stop than bill you past a number you agreed to.
There is no checkout today, so there is nothing to buy on this page and we are not going to pretend otherwise. The free tier is real and works now — it will show you, on your own pages, whether you have this problem at all, which is the part worth knowing first. We will email you the day paid plans open.
Add a site free and we will tell you, per page, whether it serves any readable text without JavaScript. No card, and the answer is the same whether or not you ever buy anything.
start freeThe crawl, the rules, the twin pipeline and the edge injector are MIT-licensed and public. Weighing us against something else? See how we compare.
read the source