Le pire type de panne est celle que personne ne signale
Un site qui affiche une erreur est un problème visible. Un site qui charge parfaitement mais dont toutes les pages disparaissent progressivement de Google est autrement plus traître. C'est exactement le scénario que décrit Your Inertia SSR server is down and your site still returns 200 : une panne sans exception, sans log d'erreur, sans alerte, et pourtant désastreuse pour le référencement.
Comment fonctionne le rendu côté serveur avec Inertia
Dans une stack Laravel + Inertia.js + React avec SSR activé, le fonctionnement est le suivant. Au démarrage, la commande php artisan inertia:start-ssr lance un petit processus Node.js qui écoute sur le port 13714. À chaque requête HTTP entrante, Laravel envoie les données de la page à ce processus Node, qui retourne du HTML déjà rendu. Ce HTML est ensuite injecté dans la directive Blade @inertia, à l'intérieur d'un <div id="app">.
Le résultat : les moteurs de recherche reçoivent une page complète, avec tout le contenu textuel lisible directement dans la réponse HTTP. C'est le comportement attendu et la raison pour laquelle on active le SSR en premier lieu.
Le fallback silencieux qui piège le SEO
Le problème survient quand le processus Node s'arrête, sans forcément planter avec une erreur. Laravel ne considère pas cela comme une erreur fatale. Il bascule automatiquement en rendu côté client (CSR) et retourne quand même une réponse HTTP 200.
Concrètement, le HTML renvoyé ressemble alors à ceci :
<div id="app" data-page="{...}"></div>
Le <div> est vide. Les données de la page sont sérialisées dans l'attribut data-page, mais le contenu textuel est absent du HTML. Le navigateur reçoit ensuite les fichiers JavaScript, lit cet attribut, et rend l'interface normalement. L'utilisateur ne voit rien d'anormal.
Googlebot, lui, voit une page vide. Il peut exécuter du JavaScript, mais son comportement dans ce contexte est imprévisible et bien moins fiable qu'un HTML complet reçu d'emblée. Le résultat observé dans l'article source est parlant : sur plusieurs dizaines d'articles publiés, seuls deux avaient été indexés par Search Console. Tous les autres étaient en statut "Discovered, currently not indexed".
Ce que ça implique en pratique pour la supervision
Ce mode de défaillance pose un problème de détection sérieux. Les outils classiques de monitoring qui vérifient le code HTTP de retour d'une page ne détecteront rien : la réponse est 200, le serveur PHP fonctionne, Laravel répond. Seul le contenu HTML réel permet de distinguer un rendu SSR valide d'un fallback CSR silencieux.
Plusieurs approches permettent de surveiller correctement cet état :
- Vérifier que le processus Node écoute bien sur le port 13714, par exemple avec un check TCP dans Supervisor, systemd ou un outil de monitoring comme UptimeRobot ou Prometheus.
- Inspecter le contenu HTML d'une page rendue : si
<div id="app"> est vide, le SSR ne fonctionne pas, quel que soit le code HTTP.
- Configurer Supervisor (ou systemd) pour redémarrer automatiquement
inertia:start-ssr en cas d'arrêt, et envoyer une alerte si le redémarrage échoue plusieurs fois de suite.
- Surveiller les métriques Search Console, notamment le ratio de pages "Discovered" vs "Indexed" : une dégradation soudaine peut signaler une défaillance SSR même si aucune erreur n'est visible en surface.
La dernière option est la plus lente à détecter le problème, puisque les crawls Google s'espacent souvent de plusieurs jours. Elle reste utile comme signal de recoupement, mais ne remplace pas une supervision technique directe.
Ce qui rend ce bug particulièrement difficile à diagnostiquer
La difficulté tient au fait que les deux sources d'information les plus naturelles, les logs applicatifs et le monitoring HTTP, sont toutes les deux muettes. Laravel ne logue pas le fallback CSR comme une erreur. Le processus Node ne génère pas forcément de stack trace avant de s'arrêter. Et les utilisateurs, qui voient le rendu client fonctionner normalement dans leur navigateur, ne signalent rien.
Le seul signal disponible est indirect et retardé : une baisse d'indexation dans Search Console, observable au bout de plusieurs jours ou semaines. C'est précisément ce qui rend ce type de panne coûteux : le dommage SEO s'accumule en silence bien avant que quiconque s'en aperçoive.
Si vous utilisez Inertia avec SSR dans une application Laravel dont le référencement est important, le processus Node mérite le même niveau de supervision que le processus PHP-FPM ou le serveur web. Il fait partie du chemin critique de rendu, même si son absence ne provoque aucune erreur visible.
Conclusion
Le fallback automatique d'Inertia vers le rendu client est une décision de conception qui favorise la disponibilité perçue plutôt que la cohérence du comportement. Pour un utilisateur connecté, c'est acceptable. Pour un bot d'indexation, c'est rédhibitoire. La supervision du processus SSR doit donc être explicite, indépendante du monitoring HTTP classique, et capable de déclencher une alerte avant que Google ait eu le temps de dégrader le positionnement des pages concernées.
