-5
A 200 response can still be a loading screen: what do you check before calling it a rendering problem? (programming.dev)
submitted 2 days ago by to c/webdev@programming.dev
1 comment fedilink hide all child comments
 

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?

1 comment

sorted by: hot top controversial new old
[–] 1 point 2 days ago

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.

  • permalink
  • fedilink
  • source
    •