Si vous attendez que Google exécute votre JavaScript par bonté d’âme, vous attendez trop longtemps. Ici, on va arrêter de supplier un robot et lui donner des preuves — HTML rendu, sitemaps propres, traces dans les logs — pour qu’il vienne, rende et indexe. Pas de morale : des méthodes pratiques, testables, et un peu violentes.
Diagnostiquer le silence de google
Arrêtez de deviner. Quand votre contenu JS ne ranke pas, il faut des preuves : logs, URL Inspection, render snapshots. Première étape : savoir si Google voit votre HTML ou juste un shell vide. Outils obligatoires : Search Console (URL Inspection), les logs serveur, et un rendu headless local (Puppeteer / Rendertron).
Ce qu’il faut vérifier en priorité
- Dans Search Console, lancez Inspecter l’URL → Test en direct. Regardez le HTML rendu et la capture d’écran. Si le texte critique est absent, Google n’a pas rendu.
- Logs serveur : cherchez les hits de Googlebot. Une requête de rendu (souvent un User-Agent Googlebot/2.1) devrait charger aussi les ressources JS (statuts 200). Exemples de commandes :
- grep « Googlebot » access.log | grep « GET » | wc -l
- awk ‘/Googlebot/ {print $1,$4,$7,$9}’ access.log | tail
- Temps de rendu : Google a un budget de rendu. Si votre JS met plus de 5–10s à hydrater, il risque d’abandonner. Surveillez les temps de première peinture interactible (TTI) et la durée de scripts longs.
Indices techniques d’échec
- Votre page renvoie 200 mais le HTML initial est vide : risque élevé que Google n’indexe rien.
- Beaucoup de 403/429 pour les ressources statiques quand Googlebot tente de rendre : vous ratez la passe de rendu.
- Redirections basées sur User-Agent ou géo : c’est du cloaking si le résultat diffère pour Google.
Anecdote : nous avons récupéré un client dont 40% des pages produit n’apparaissaient pas dans l’index — les logs ont montré que Googlebot n’avait jamais pu télécharger le bundle JS à cause d’un CDN mal configuré. Solution : mettre en place un fallback HTML et relancer le crawl. Résultat : +30% d’indexation en 72h.
Actions rapides (à faire dans l’heure)
- Tester une URL dans Search Console → prendre la capture de rendu.
- Grepper les logs pour Googlebot sur 7 jours. Identifiez erreurs 4xx/5xx.
- Vérifier que les ressources JS ne sont pas bloquées par robots.txt ou header anti-bot.
Conclusion de la piste : sans diagnostic précis, vous tirez à l’aveugle. Rassemblez ces preuves avant d’appliquer une solution. Google ne vous écoute que si vous lui servez du HTML lisible, servi vite, et prouvé.
Choisir la bonne arme : ssr, pré-render ou rendu dynamique
Vous avez trois familles d’armes. Choisissez en fonction du produit, du trafic et de la fréquence de mise à jour.
- Server-Side Rendering (SSR) — Pour les pages dynamiques, personnalisées ou constamment mises à jour :
- Avantage : Google reçoit directement l’HTML complet. Indexation rapide.
- Inconvénient : coûts serveurs, complexité backend, cache invalidation.
- Cas d’usage : e-commerce à gros catalogue avec filtres SEO, pages produit critiques.
- Static Site Generation (SSG) / Pré-render — Pour contenus stables ou mises à jour par lot :
- Avantage : HTML statique, rapide, scalable via CDN.
- Inconvénient : génération au build, pas idéal pour contenus très volatils.
- Cas d’usage : blogs, catégories, pages marketing.
- Rendu dynamique à la demande (On-Demand Rendering / ISR) — Mixte entre SSR et SSG :
- Avantage : génération à la première requête, cache court, évolutif.
- Inconvénient : complexité de purge et cohérence.
- Cas d’usage : pages avec trafic irrégulier mais besoin d’un HTML SEO-friendly.
Règles simples pour décider
- Si une page change moins d’une fois par jour : SSG ou pré-render.
- Si vous avez des millions d’URL et besoin d’un rendu à la demande : ISR/On-demand.
- Si le contenu est utilisateur-spécifique (auth) : ne l’indexez pas, ou proposez un rendu serveur d’une version publique.
Performance et budget de rendu
- Google ne vous rendra pas si l’exécution dépasse un certain temps. Visez un rendu client < 3s pour le contenu critique.
- Réduisez le bundle initial : code-splitting, lazy-loading, critical CSS inline.
- Utilisez des solutions Edge (Cloudflare Workers, Vercel Edge) pour diminuer la latence du SSR.
Exemples concrets
- Migrer un catalogue produit lourd en SSR chez un retailer a réduit le temps de rendu pour Google de 8s à 800ms, entraînant une augmentation de l’indexation des pages produit de 65% en deux semaines.
- Pour un blog tech, le passage à SSG + purge ciblée a réduit la latence et multiplié l’apparition dans les résultats enrichis.
Verdict rude : si vous voulez que Google « entende » votre JS, donnez-lui un HTML prêt à être lu. Choisissez l’architecture qui minimise le travail de rendu côté client, pas celle qui flatte vos développeurs.
Forcer le crawl : tactiques techniques immédiates
Quand Google fait la sourde oreille, on active les leviers qui attirent son robot comme du métal attire un aimant. Voici les méthodes testées et approuvées.
- Sitemaps propres et pings
- Générer un sitemap XML avec et diviser par 50k URLs si nécessaire.
- Soumettre via Search Console et pingez Google :
- Mettre à jour quand le contenu change. Google regarde ce signal.
- Priorité d’exploration via liens internes
- Ajoutez des liens internes depuis des pages fréquemment crawlées (homepage, catégories).
- Utilisez une structure en silo pour propager l’autorité et inciter au crawl.
- Evitez les liens JavaScript uniquement. Préférez HTML pour assurer la découverte.
- Request Indexing manuel et API (avec prudence)
- Search Console → Inspect URL → Request Indexing : utile pour pages critiques. C’est limité en volume mais rapide.
- Automatisation : l’API d’indexation est restreinte (jobPosting, livestream). Ne l’attendez pas pour tout.
- Alternative : automatiser la soumission des sitemaps via l’API Search Console (validée, moins risquée).
- Headers HTTP et entêtes robots
- Utilisez X-Robots-Tag pour contrôler l’indexation si nécessaire.
- Ne bloquez pas /static/ ou /js/ dans robots.txt. Google doit pouvoir accéder aux bundles.
- Push via CDN et cache-control
- Mettez un Cache-Control court pour pages mises à jour souvent ou purgez cache automatiquement après build.
- Configurez les règles CDN pour répondre vite aux requêtes de Googlebot.
- Routines de re-crawl
- Après une grosse mise à jour, touchez ces leviers : sitemap + internal links + Request Indexing.
- Pour grands sites, orchestrez une revalidation cascade : purge cache sur pages liées et ping sitemap.
Exemples pratiques (commande)
- Pinger sitemap :
- Rechercher Googlebot dans les logs et alerter si aucune visite en 7 jours :
- if [ $(grep -c « Googlebot » access.log) -lt 1 ]; then echo « Pas de Googlebot » | mail -s « Alerte » vous@exemple.com; fi
Caveat : ne spamez pas Request Indexing. Google a des limites et vous risquez d’être ignoré. Utilisez ces tactiques judicieusement : priorité aux pages à valeur SEO réelle.
Pré-rendering automatisé : scripts et architecture
Prerendering = servir du HTML prêt à lire. Vous pouvez industrialiser ça avec des outils headless. Voici un plan technique et des scripts pour automatiser.
Solutions connues
- Puppeteer / Playwright : scripts headless pour exécuter le JS et sauvegarder le HTML.
- Rendertron / Prerender.io : middlewares prêts à l’emploi pour détecter Googlebot et servir snapshots.
- CDN edge rendering (Workers) : rendre au plus proche de Googlebot.
Script Puppeteer minimal (pratique)
// prerender.js
const fs = require('fs');
const puppeteer = require('puppeteer');
(async () => {
const url = process.argv[2];
if (!url) throw 'Usage: node prerender.js <url>';
const browser = await puppeteer.launch({args:['--no-sandbox']});
const page = await browser.newPage();
await page.goto(url, {waitUntil: 'networkidle2', timeout: 30000});
const content = await page.content();
fs.writeFileSync(snapshots/${encodeURIComponent(url)}.html, content);
await browser.close();
})();
- Plan : lister vos URLs à pré-rendre, lancer en batch sur des workers cloud, stocker les snapshots dans un bucket CDN.
Nginx + detection User-Agent pour servir snapshot
map $httpuseragent $isbot {
default 0;
~Googlebot 1;
~Bingbot 1;
}
server {
location / {
if ($isbot) {
tryfiles /snapshots/$uri.html =404;
}
tryfiles $uri $uri/ /index.html;
}
}
- Avantage : pas de cloaking si le snapshot contient strictement le même contenu SEO que l’UI.
Cache et invalidation
- Stockez snapshots dans un bucket (S3/Cloud Storage). Purgez automatiquement après déploiement.
- Pour ISR : mettez un TTL. Si page demandée et snapshot absent → render on-demand.
Orchestration
- Queue (RabbitMQ, Redis) pour gérer le rendu en parallel.
- Fonction serverless pour rendre à la demande et stocker le snapshot.
- Monitoring : count d’échecs de rendu, réessais, alertes.
Coût et performance
- Puppeteer coûte : CPU + temps. Optimisez en limitant ressources (bloquer analytics tiers), timeout 30s.
- Edge rendering réduit latence mais complexifie le debugging.
Pratique : commencez par vos pages les plus stratégiques (top 1k), industrialisez, puis étendez. Mesurez l’indexation après chaque lot.
Surveillance, itération et pièges à éviter
Après l’implémentation, la guerre continue : on surveille, on itère, on évite les erreurs qui vous feront bannir.
Surveillance indispensable
- Logs : fréquence de visites de Googlebot, codes 200 vs 4xx/5xx, latence.
- Search Console : couverture, erreurs d’exploration, pages valides non indexées.
- Monitoring de rendu : script qui compare snapshot attendu vs HTML rendu par Google (via URL Inspection API si disponible).
- KPI : taux d’indexation sur pages traitées, temps moyen d’indexation, CTR organique.
Itération
- Si Google n’indexe pas malgré un snapshot : vérifiez la cohérence du contenu rendu (texte visible dans HTML), la canonicalisation, le noindex accidentel, ou des backlinks faibles.
- Expérimentez : une poignée de pages A/B testées avec SSR vs prerender pour voir l’impact sur l’indexation en 7–14 jours.
- Automatisez la purge et le rendu à chaque update critical (webhooks).
Pièges et avertissements
- Ne faites pas de cloaking. Si vous servez un HTML différent au bot et à l’utilisateur, vous prenez un risque de pénalité.
- Évitez d’inonder Google de Request Indexing ; vous perdrez du crédit.
- Faites attention aux pages personnalisées (auth) indexées par erreur.
- Vérifiez les balises hreflang et canonical : un mauvais canonical efface vos efforts de crawl.
Cas concret : un site média a servi des snapshots incomplets (scripts bloqués) pendant un mois. Résultat : perte de visibilité sur les pages news. Le correctif : rendre complètement le contenu, purger le CDN, et soumettre un sitemap révisé. Retour : indexation et visibilité restaurées en 48h.
Checklist opérationnelle (actionnable maintenant)
- S’assurer que le HTML initial contient le contenu SEO critique.
- Soumettre ou pinguer le sitemap pour pages modifiées.
- Mettre en place un prerender pour les 1 000 pages les plus stratégiques.
- Monitorer logs et Search Console quotidiennement la première semaine.
- Ne jamais servir un contenu différent pour Googlebot.
Conclusion tacite : Google n’est pas votre juge — c’est un exécuteur. Donnez-lui des preuves irréfutables (HTML rendu, sitemap, accès aux ressources) et il exécutera son travail. Si vous voulez des résultats, arrêtez d’espérer et commencez à rendre. Gagnez du terrain, ou regardez vos concurrents le prendre.