Laravel serves an empty #app with a 200 when the Inertia SSR process stops answering

The shim the developer put at the top of ssr.jsx imports route from ziggy-js and assigns it to global.route, with the config url read from process.env.APP_URL at run time ^[12]. The run-time read is deliberate. The post says taking the host from the value baked into ziggy.js at build time leaves the markup React hydrates against different from what the client would have produced ^[13].

Node has no global route(), and the @routes Blade directive only defines one in the browser, so twenty-two call sites threw route is not defined during server render ^[10]. Inertia handled a bundle that throws exactly as it handles a process that is not there, and fell back to the client ^[11]. One definition in ssr.jsx covers all twenty-two of those calls ^[19].

php artisan inertia:check-ssr opens a connection to the configured SSR URL, confirms something answers, and prints "Inertia SSR server is running." ^[14]. The post lists three ways to end up with an empty #app, and only one of them leaves the port silent: a process someone started by hand over SSH that died when the shell closed ^[9]. A bundle that throws at render time answers the port, and so does a process running the wrong build, so a connection test can detect one failure mode out of three ^[18]. The developer says they had a green check-ssr and an empty #app in production at the same time ^[15].

Uptime checks passed and every status code was 200 ^[8]. The screenshots were perfect too, because the failure exists only in the part of the response body that a browser immediately overwrites ^[8].

The check that would have caught it is an HTTP fetch with no JavaScript engine anywhere in it. The post's loop walks five paths, cuts each response at <div id="app">, strips the tags out of everything after it, and counts the characters left ^[16]. A server-rendered page has prose after that div; the fallback has a data-page attribute and nothing else ^[4].

What made the empty body expensive at Bunfolio rests on a claim about Google, and it is the author's reading rather than a measurement: Google does render JavaScript, but rendering is queued and budgeted separately from crawling, and on a new site with essentially no inbound links you should assume that budget is close to zero ^[7]. For the indexing damage to transfer, your site needs to be in that same position ^[7]. On a domain with crawl history the rendering queue may well reach the pages, and the body served is still an empty div with the props in an attribute ^[4]. The clients that never recover are the ones with no JavaScript engine at all, including link unfurlers and anything reading the page with an HTTP library ^[6].