Définition et périmètre
Avec le CSR, le serveur peut renvoyer une coque HTML légère, et le JavaScript récupère ou compose le contenu utile dans le navigateur. Cela peut convenir aux applications très interactives, mais cela crée une chaîne de dépendances : le HTML, les scripts, les API et la logique de rendu doivent tous fonctionner pour que le crawler et le visiteur reçoivent le même contenu important.
Démarche pratique
Partez de ce que l’utilisateur et le crawler doivent voir. Vérifiez si la balise title, le texte principal, la balise canonical, les directives robots, les liens internes, les images et les données structurées sont présents dans le HTML initial ou seulement après l’exécution du JavaScript. Si un contenu essentiel à la découverte arrive trop tard, choisissez une architecture qui le livre de façon fiable : rendu serveur, génération statique ou approche hybride testée.
Ce qu’il faut contrôler
Comparez un téléchargement brut du HTML avec une inspection après rendu, sur un échantillon représentatif de templates. Vérifiez que les ressources JavaScript ne sont pas bloquées, que les requêtes de données aboutissent sans session privée, que la balise canonical reste stable et que les états d’erreur ne remplacent pas le contenu principal. Google recommande de tester les applications JavaScript plutôt que de supposer qu’un nom de framework garantit la crawlabilité.
Limites et erreurs fréquentes
Ne qualifiez pas automatiquement le CSR de mauvais pour le SEO, et ne supposez pas qu’un crawler ne voit rien. La bonne question : le contenu et les métadonnées nécessaires sont-ils disponibles de façon constante après le parcours de rendu réel ? Évitez une version réservée aux robots, sauf si elle reste équivalente et maintenable.
Contrôles de rendu avec un exemple de route
Prenez une route comme /guides/rendering. Récupérez-la sans état de navigateur et enregistrez le corps de la réponse. Chargez ensuite la même route dans une session de navigateur vierge, puis inspectez le DOM rendu, la console et le panneau réseau. Les deux vues n’ont pas besoin d’être identiques octet par octet, mais la finalité de la route doit subsister : un title exploitable, un titre principal, le texte principal, la référence canonical, les liens crawlables et les données structurées importantes doivent apparaître sans appel API authentifié, sans course de temporisation ni exception côté client.
<a href="/guides/rendering">Rendering guide</a>\n<link rel="canonical" href="https://example.test/guides/rendering">Lors d’une défaillance de l’app-shell, le HTML initial peut ne contenir qu’un élément racine, tandis que la requête de données échoue avec 401, 403, 404 ou une exception JavaScript. Un internaute connecté peut voir une page en cache, alors qu’un rendu effectué dans une session vierge n’affiche qu’une coquille vide. La parade n’est pas de faire passer la route pour un succès 200 : il faut classer le chemin d’erreur, rendre disponibles les données publiques nécessaires à cette route, ou choisir un rendu serveur ou statique pour le contenu à livrer immédiatement.
Google décrit un pipeline de crawl, de rendu et d’indexation pour les pages JavaScript. Une réponse 200 peut entrer dans la file de rendu, mais les pages bloquées, ou les ressources JavaScript bloquées, ne sont pas rendues. Google recommande aussi l’Outil d’inspection d’URL ou le Test des résultats enrichis pour examiner les ressources chargées, les messages de la console, les exceptions et le DOM rendu. Utilisez ces outils comme preuves complémentaires, et comparez-les avec un test anonyme récent dans le navigateur : les analytics côté client ne reflètent pas totalement l’activité de rendu de Googlebot.
Évitez le rendu dynamique comme correctif architectural par défaut. Google le présente comme un contournement, et non comme une solution à long terme. Ne pratiquez pas le cloaking : le contenu livré à un crawler doit rester équivalent à celui que reçoit un utilisateur. Consignez la route, l’état de l’utilisateur, la réponse brute, le résultat rendu et le statut des ressources en échec, afin qu’une future mise à niveau du framework puisse être vérifiée sur les mêmes preuves.