Un site JavaScript peut être visible dans Google. Avant de changer de technologie, vérifiez ce qui est réellement accessible sur les pages importantes : contenu, adresses, liens et instructions d’indexation. Le problème peut venir du rendu, mais aussi d’une page absente, d’une erreur serveur ou d’un réglage qui exclut la page.
Comment Google traite-t-il le JavaScript ?
Google décrit trois phases : exploration, affichage et indexation. Il peut exécuter JavaScript et utiliser le HTML rendu, mais les ressources nécessaires ne doivent pas être bloquées. Google recommande aussi le rendu côté serveur ou le pré-affichage, notamment parce que tous les robots n’exécutent pas JavaScript. Voir ses bases du SEO JavaScript.
Cela ne signifie pas qu’une migration garantit l’indexation. Je conseille de commencer par un échantillon de pages publiques : accueil, service ou catégorie, page de détail et adresse inexistante. Le but est d’identifier un défaut précis avant de reconstruire une application entière.
Quelles adresses faut-il tester en accès direct ?
Copiez l’adresse d’une page profonde et ouvrez-la dans une nouvelle fenêtre, sans passer par l’accueil. Rechargez-la. Notez si vous obtenez la bonne page, une erreur ou un écran vide. Faites aussi un essai avec une adresse inexistante : votre système doit permettre de distinguer cette erreur d’une vraie page.
Dans une application monopage, appelée SPA, la navigation peut fonctionner sans que l’accès direct soit correctement traité. Les liens entre pages doivent permettre de trouver les destinations. Google indique notamment d’utiliser des liens HTML avec un attribut href et de ne pas dépendre de fragments pour charger des contenus distincts. Une animation de navigation ne remplace pas ce contrôle.
Que comparer entre la réponse serveur et le rendu ?
Pour chaque page de l’échantillon, conservez l’adresse, la réponse reçue et le contenu après affichage. Comparez le titre, l’explication principale et les liens utiles. Relevez aussi les appels qui échouent : ressource absente, accès refusé ou contenu qui reste en chargement. Cette comparaison oriente le diagnostic ; elle ne reproduit pas à elle seule le traitement de Google.
Testez un parcours sans connexion pour les pages que vous souhaitez rendre publiques. Un espace client peut rester privé : son absence de la recherche n’est pas nécessairement un défaut SEO. Pour un projet SaaS, séparez les pages de présentation des écrans réservés aux utilisateurs.
Comment contrôler les instructions d’indexation ?
Vérifiez le statut HTTP, les directives pour les robots et l’URL canonique, dans la réponse et dans le rendu. Google recommande de ne pas remplacer par JavaScript une canonique déjà définie dans le HTML par une autre adresse. Une page techniquement accessible peut rester exclue de l’indexation par une consigne distincte.
Avec les accès autorisés à Search Console, examinez ensuite une page précise et le test en ligne disponible. Notez ce qui est observé, ainsi que la date du contrôle. Distinguez une page consultable maintenant d’une page déjà présente dans l’index. Ne présentez pas un résultat local de navigateur comme une preuve d’indexation.
Faut-il choisir un rendu serveur ou une génération statique ?
La décision dépend du contenu à présenter et de son entretien. Pour cadrer le développement, demandez quelles informations doivent être disponibles dès l’ouverture, lesquelles changent souvent et quelles interactions demandent réellement JavaScript. Le choix doit aussi tenir compte de l’exploitation : mise à jour, déploiement, cache et gestion des erreurs.
Je ne recommande pas un framework uniquement pour son étiquette SEO. Sur un site vitrine, un parcours simple et un contenu disponible sont prioritaires. Une application interactive peut demander une autre organisation. Faites valider le comportement attendu page par page, avant de chiffrer une migration.
Quelle preuve demander après une correction ?
- Les adresses testées et le défaut constaté avant intervention.
- La modification réalisée et les fichiers ou réglages concernés.
- Le contrôle d’accès direct, du contenu et des instructions après correction.
- Une vérification du parcours utilisateur sur mobile et ordinateur.
- Les limites du test et le suivi à poursuivre dans Search Console.
Ce cadre de recette est ma proposition de travail, pas une garantie de classement. Une mission SEO peut identifier les pages prioritaires et les contrôles à effectuer, sans supposer qu’un changement de technologie résout tous les problèmes.
