I’m the founder of Prerender Buddy, and this is our Apache-2.0 CLI for inspecting what a public URL returns over HTTP. The CLI runs locally without an account, telemetry or calls to the hosted PB API. The commercial hosted service is separate.

Source: https://github.com/kopachlager/prerenderbuddy-cli

One part I’d like feedback on is the application-shell heuristic. It looks at readable text, empty mount points, loading text and script markers. That can flag a page worth investigating, but a deliberately minimal static page or a canvas app can need a different interpretation.

There’s a loading-placeholder fixture in the repo. From a local checkout, npm run demo:fixture passes that static fixture through the normal check and formatting functions. It lets you inspect the warning without relying on a live site that might change tomorrow.

For a public site you control, with Node.js 20 or newer:

npx @prerenderbuddy/cli check https://example.com/ --user-agent googlebot
npx @prerenderbuddy/cli compare https://example.com/ --user-agent gptbot
npx @prerenderbuddy/cli files https://example.com/

Both sides of the comparison are HTTP fetches. Neither runs JavaScript, and a user-agent string does not reproduce a crawler’s verified network origin. The output is diagnostic evidence, not proof of a crawler failure or a prediction of rankings or AI recommendations.

What fixtures would you add to keep this kind of heuristic honest? Small static sites, cookie banners and canvas apps are already covered, but reproducible false positives would be useful.

When a page looks fine in a browser but its discoverability is unclear, I’d separate three checks:

• Does the original HTML contain the page’s main content and useful navigation?
• Does the content appear only after JavaScript runs?
• Is the response different when you change the user agent, or is an access rule getting in the way?

Those are different problems. A 200 status alone doesn’t settle any of them, and a missing mention in an AI answer doesn’t prove a rendering problem either.

Disclosure: I’m the founder of Prerender Buddy. Our open-source CLI checks returned HTML and discovery files: https://github.com/kopachlager/prerenderbuddy-cli. It flags things worth inspecting; it doesn’t run a browser or prove that a real crawler failed.

If a rendering gap is confirmed, the fix could be in the app’s rendering approach or a managed prerendering layer. PB offers the latter, alongside monitoring: https://prerenderbuddy.com/. If the site already returns complete HTML, extra prerendering may not be needed.

What evidence do you normally collect before choosing between changing the app and adding a rendering service?

A coding assistant can explain SEO and still miss what the server actually sends back. The useful starting point is the response, before interpreting why a page might be hard to discover.

I’m the founder of Prerender Buddy. Our open-source MCP exposes public crawler diagnostics to an assistant: returned HTML, metadata, readable-text counts and discovery-file checks. Those public tools run without a PB account. The source and setup are here: https://github.com/kopachlager/prerenderbuddy-mcp

An example question to try on a site you control: “Compare the standard and GPTBot HTTP responses for my pricing page, and show the evidence behind any differences.”

There’s an important limit: both requests are HTTP fetches. Neither executes JavaScript, and changing a user agent does not reproduce a verified crawler’s network origin. A difference is something to inspect, not proof of cloaking or lost rankings.

For ongoing monitoring and account evidence, the separate PB platform is at https://prerenderbuddy.com/. The public diagnostics remain usable on their own.

What would make these findings useful in your development workflow: CI failures, a short evidence summary, or something else?