The reason we run on Hado is what it does at the edge for crawlers, and it solves a problem most hosts pretend does not exist.
Our sites are JavaScript single-page apps. On a normal host, when a crawler that does not execute JavaScript well requests a page, it gets a near-empty shell and a script bundle. Googlebot can usually render its way through that eventually, but the AI crawlers (GPTBot, ClaudeBot, PerplexityBot) and a lot of the long tail do not, or they weight rendered content lower. That is pages full of work going invisible to exactly the engines we care about.
Hado fixes it by prerendering at the edge and serving fully formed HTML to bots. I can verify it rather than take it on faith: curl the same URL with a normal browser agent and you get the app shell, curl it with a GPTBot or Bingbot user agent and you get the complete server-rendered DOM with the JSON-LD structured data already inlined in the response, not injected client-side after hydration. That distinction is the whole game now. Article and BlogPosting, FAQPage, BreadcrumbList and Organization schema all land in the raw HTML the crawler actually parses, so the structured data is doing its job at first byte instead of waiting on a render pass that may never happen.
A few other things that earn their keep day to day:
Edge host rewriting. Hado rewrites the preview host to the production host at the edge, so canonical tags, Open Graph URLs and the sitemap all resolve to the live domain. No duplicate-host indexing mess, no canonical pointing at a staging URL, which is a classic way SPAs leak ranking signal.
The analytics export. The JSON API gives per-bot attribution, so I can see GPTBot versus ClaudeBot versus Bingbot hit frequency at the URL level. That is genuinely rare. It lets me confirm which pages are being crawled, spot ones that are being missed, and watch crawl frequency as a leading indicator before anything shows up in a search console. I have built an automated daily pull on top of that endpoint that feeds our own reporting, and it has been stable enough to run unattended on a schedule, which is the bar I needed before I would trust it.
Edge performance. Because the render and the cache both live at the edge, time to first byte stays low for crawlers wherever they hit from. For crawl budget and for Core Web Vitals that matters more than people give it credit for.
Net effect: it collapses what would otherwise be a CDN plus a separate prerender service plus a log-analytics tool into one platform, and the per-bot data closes the loop so I can actually measure whether the rendering work is paying off. Review collected by and hosted on G2.com.
Honestly very little, and what did come up has already been dealt with. The one real gap was that the analytics endpoint did not accept an arbitrary from/to date range, so pulling a specific historical window took extra work. I raised it and the fix is shipping in the next release, which is the pattern with them: I flag something, it gets understood and actioned fast. If I am reaching, slightly deeper docs on the edge caching and server-function behaviour would have shortened my early learning curve, but once it clicked it stopped being a thing.
The support is the standout. Quick, technical, and they clearly understand their own product, which is rarer than it should be at this price. For us it has been faultless. Review collected by and hosted on G2.com.
