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?
For me the evidence was the server logs, filtering by user agent. my main page is basically a canvas game, so the html has almost nothing for a crawler, and I was surprised to see googlebot not only rendering it but opening the SSE stream like a real player (I noticed because bots were showing up as online players lol). what actually got indexed were the plain server rendered pages I made for each thing worth sharing, with title, og image and json-ld, listed in the sitemap. so I didn’t change the app rendering, I just gave crawlers simpler pages to read.