SEO JavaScript : faire explorer une application monopage

« Notre site est invisible sur Google » est rarement un problème de contenu quand l’application est rendue côté client. C’est presque toujours un problème de ce qui existe au moment où on regarde.

Le malentendu de départ

Une requête HTTP vers votre page renvoie du HTML. Sur une application monopage, ce HTML contient un conteneur vide et une balise de script. Tout le contenu apparaît ensuite, quand le navigateur exécute le JavaScript.

Trois catégories d’outils lisent cela différemment :

• Un crawler qui ne rend pas voit le conteneur vide. Il conclut que la page n’a ni titre utile, ni texte, ni liens, et il a raison, du point de vue du document qu’il a reçu.
• Un moteur de recherche moderne rend, mais dans une file séparée du crawl initial. Le délai est variable et non contractuel.
• Un moteur de réponse IA dépend de son propre robot ; tous ne rendent pas le JavaScript.

Conclusion pratique : ce que votre visiteur voit n’est pas ce que la moitié de vos lecteurs automatiques reçoit.

Vérifier, en trois contrôles

1. Le HTML brut

curl -s https://votre-domaine/une-page | wc -c
curl -s https://votre-domaine/une-page | grep -o '<title>[^<]*</title>'

Si le corps fait deux kilo-octets et que le titre est celui de l’application entière plutôt que celui de la page, vous avez votre réponse.

2. Le rendu

Rendez la même page avec un navigateur sans interface, puis comparez la quantité de texte et le nombre de liens avec le HTML brut. L’écart est exactement ce que perd un lecteur qui ne rend pas.

3. Les journaux serveur

C’est le contrôle que personne ne fait, et c’est le plus concluant. Regardez si les robots demandent vos routes applicatives ou seulement la racine. Si vous ne voyez que la racine, vos routes ne sont pas découvrables : le problème est en amont du rendu.

Les cinq défauts les plus fréquents

1. Des liens qui ne sont pas des liens

Une navigation construite avec onClick et un routeur JavaScript ne produit aucun <a href>. Un moteur ne clique pas : il suit des liens. La règle est simple et sans exception : toute route atteignable doit l’être par une balise <a> portant un href réel. Le routeur peut intercepter le clic ensuite ; l’attribut doit exister.

2. Des métadonnées identiques partout

Le titre et la description sont posés dans le gabarit de l’application et jamais mis à jour à la navigation, ou mis à jour trop tard. Résultat : toutes vos pages portent le même titre. Sur un rendu différé, seul l’état initial compte.

3. Des codes de statut faux

Une route inexistante affiche un composant « page introuvable »… en répondant 200. Pour un moteur, ce sont des milliers de pages valides au contenu identique. Une page introuvable doit répondre 404, et une redirection doit être une redirection HTTP, pas un remplacement d’écran.

4. Du contenu derrière une interaction

Les onglets, accordéons et boutons « voir plus » qui ne chargent leur contenu qu’au clic rendent ce contenu invisible pour tout lecteur automatique. S’il compte pour votre visibilité, il doit être dans le document rendu, quitte à être masqué en CSS.

5. Une hydratation qui échoue en silence

Le cas le plus désagréable, parce qu’il ne se voit pas en développement. Une erreur JavaScript sur une page particulière (un jeu de données inhabituel, une locale non gérée) interrompt le rendu. Le visiteur voit une page à moitié construite ; le lecteur automatique voit un conteneur vide. Sans surveillance des erreurs en production, cela peut durer des mois.

Ce qu’il faut décider

Il n’y a pas une bonne architecture, il y en a trois, et le choix se fait sur le contenu :

Rendu serveur. Le serveur produit le HTML complet. C’est le plus sûr et le plus coûteux à maintenir. Recommandé dès que le contenu est votre canal d’acquisition.

Génération statique. Les pages sont produites à la construction. Idéal pour de la documentation ou un catalogue qui change peu. Inadapté à ce qui dépend de l’utilisateur.

Rendu client seul. Acceptable pour une application derrière authentification, où rien n’a vocation à être indexé. C’est le seul cas où le SEO JavaScript ne se pose pas, parce qu’il n’y a rien à explorer.

Le cas coûteux est l’intermédiaire : une application publique en rendu client, dont on veut la visibilité d’un site rendu au serveur. Les contournements existent, ils ajoutent tous une pièce mobile de plus.

Vérifier après correction

Trois contrôles, dans cet ordre :

1. Le HTML brut porte le titre, la description et les liens de la page, pas ceux de l’application.
2. Un crawl avec rendu et un crawl sans rendu trouvent le même nombre de liens. Si l’écart persiste, il reste des liens produits en JavaScript.
3. Les journaux montrent des robots demandant vos routes, pas seulement la racine. C’est la seule preuve que la découverte fonctionne.

Le troisième contrôle est le seul qui parle du monde réel. Les deux premiers disent ce qu’un moteur pourrait voir ; celui-là dit ce qu’il a effectivement demandé.