Faut-il vraiment conserver les anciens assets CSS/JS pour Googlebot ?

Pourquoi Googlebot a-t-il besoin d'anciens fichiers après un déploiement ?

Quand vous déployez une nouvelle version de votre site avec Rails Asset Pipeline (ou tout système similaire générant des noms de fichiers avec hash), vos nouveaux fichiers portent des noms différents — par exemple app-a3f2b1.css devient app-d8e9c4.css. Le HTML mis à jour pointe vers les nouveaux fichiers.

Le problème : Googlebot ne recrawle pas instantanément toutes vos pages. Il peut conserver en cache pendant plusieurs jours l'ancien HTML qui référence encore app-a3f2b1.css. Si vous supprimez ce fichier, le bot tente de le charger, obtient une 404, et le rendu échoue. Google voit alors une page cassée, sans styles ni scripts critiques pour afficher le contenu.

Qu'est-ce que le rendering cassé change pour l'indexation ?

Un rendu cassé signifie que Googlebot ne voit pas le contenu tel qu'un utilisateur le verrait. Si votre CSS masque du contenu non critique ou si votre JavaScript injecte des éléments structurants (navigation, liens internes, sections de texte), leur absence fausse la compréhension de la page.

Dans les cas extrêmes — sites Single Page Applications où tout le contenu dépend du JS — un script manquant = page blanche pour le bot. Même sur des sites classiques, des layouts cassés peuvent perturber la détection des zones de contenu principal versus publicité ou navigation.

Combien de temps faut-il conserver ces anciens fichiers ?

Google ne donne aucun chiffre précis — c'est le flou habituel. La durée dépend de la fréquence de crawl de vos pages : un site à fort trafic avec crawl quotidien peut se permettre 7-10 jours. Un site moins prioritaire pour Googlebot peut nécessiter 3-4 semaines.

Martin Splitt parle de « temporairement » sans définir de seuil. Sur le terrain, la plupart des pipelines d'assets modernes (Webpack, Vite, Sprockets) conservent par défaut 2-3 versions précédentes — c'est un bon compromis entre sécurité SEO et gestion du stockage.

• Conservez les anciens assets jusqu'à ce que Googlebot ait recrawlé les pages HTML mises à jour
• La durée varie selon la fréquence de crawl de votre site — surveillez vos logs serveur
• Les systèmes de versioning par hash (fingerprinting) créent ce problème en générant de nouveaux noms de fichiers à chaque build
• Un rendu cassé impacte la compréhension du contenu par Google, pas juste l'esthétique
• Cette recommandation s'applique aussi aux images critiques référencées dans l'ancien HTML

Cette recommandation est-elle cohérente avec ce qu'on observe sur le terrain ?

Oui, et c'est même un problème bien documenté depuis des années. Les plateformes e-commerce qui déploient plusieurs fois par jour ont appris à la dure que supprimer immédiatement les anciens bundles JavaScript provoque des pics d'erreurs 404 dans la Search Console, suivis de chutes temporaires de visibilité sur des pages pourtant inchangées au niveau contenu.

Ce qui est plus révélateur : Google admet implicitement que son infrastructure de cache HTML et de crawl des ressources n'est pas synchronisée. Le bot peut garder un snapshot HTML pendant que le service de rendu tente de fetcher des assets en temps réel. C'est une limite architecturale rarement avouée aussi clairement.

Quelles nuances faut-il apporter à cette directive ?

Premier point : cette recommandation concerne surtout les assets référencés directement dans le HTML (<link>, <script>, <img> critiques). Les ressources chargées dynamiquement en JavaScript après le rendu initial posent moins de problème — si le JS principal se charge, le reste suit.

Deuxième nuance : la gravité dépend de votre architecture de rendu. Un site avec Server-Side Rendering où le contenu textuel est présent dans le HTML initial peut survivre à un CSS manquant — Google verra du texte brut mais indexable. Un site client-side où React/Vue injecte tout via JS ? Catastrophe immédiate si le bundle principal 404.

[À vérifier] Google ne précise pas comment il gère les fallbacks modernes : si vous servez un CSS critique inline dans le <head> et que seul le CSS non-critique externe échoue, le rendu reste-t-il valide ? Les retours terrain suggèrent que oui, mais aucune confirmation officielle.

Dans quels cas cette règle devient-elle secondaire ?

Si vous utilisez un système de versioning sémantique sans hash (ex: app.v2.css que vous ne supprimez jamais), le problème disparaît. Idem si vous servez toujours les mêmes noms de fichiers en écrasant leur contenu — pas de cassure de référence.

Pour les sites avec pré-rendering statique (Gatsby, Next.js static export) où Google crawle directement du HTML complet avec contenu inline ou minimal external assets, l'impact est négligeable. Le vrai risque concerne les architectures hybrides complexes avec multiples layers de cache et rendering dynamique.

Que faut-il faire concrètement lors d'un déploiement ?

Configurez votre pipeline de build pour conserver au minimum les 2-3 dernières versions d'assets. Webpack permet cela via le plugin clean-webpack-plugin avec l'option cleanOnceBeforeBuildPatterns paramétrée pour garder les fichiers récents. Rails Asset Pipeline offre config.assets.keep_versions.

Mettez en place un monitoring des 404 sur les assets via vos logs serveur ou votre CDN. Filtrez spécifiquement les requêtes venant de Googlebot (user-agent Googlebot) — si vous voyez des pics de 404 sur d'anciens fichiers CSS/JS après un déploiement, c'est le signal que le bot n'a pas encore recrawlé vos pages HTML.

Utilisez la Search Console pour vérifier le rendu : testez quelques URLs majeures avec l'outil « Inspection d'URL » > « Tester l'URL en ligne ». Comparez le screenshot de rendu Google avec votre site réel. Si Google affiche une page cassée alors que votre navigateur la voit correctement, vous avez probablement un problème d'assets obsolètes 404.

Quelles erreurs éviter absolument ?

Ne configurez jamais un script de déploiement qui purge automatiquement tous les anciens assets immédiatement après le push. C'est une pratique courante en développement classique (pour « nettoyer » le serveur) mais catastrophique pour le SEO. Ajoutez un délai ou une logique basée sur l'âge des fichiers.

Évitez les stratégies de cache HTTP trop agressives sur les assets avec des max-age très courts combinés à une suppression rapide des fichiers. Si Googlebot cache un HTML avec Cache-Control: max-age=86400 mais que vous supprimez les assets référencés au bout de 12h, vous créez une fenêtre de risque.

Ne vous fiez pas uniquement aux sitemaps pour forcer un recrawl rapide. Soumettre un sitemap après déploiement ne garantit pas que Google recrawle toutes les pages dans les heures qui suivent — la priorité de crawl reste déterminée par de multiples facteurs (popularité, fréquence de mise à jour historique, crawl budget).

Comment vérifier que mon infrastructure est conforme ?

Consultez vos logs serveur pour identifier la durée moyenne entre deux crawls Googlebot sur vos pages principales. Si c'est 5 jours, gardez vos assets au minimum 7-10 jours. Si c'est 48h, une semaine suffit. Adaptez la rétention en fonction de ces données réelles.

Testez un déploiement sur un environnement de staging accessible à Googlebot (via Search Console property séparée) : déployez, supprimez immédiatement les anciens assets, et observez les rapports de couverture et le rendu dans l'inspection d'URL. Si des erreurs apparaissent, vous avez la preuve du problème avant qu'il touche la production.

Automatisez des alertes sur les 404 assets via votre monitoring (Datadog, New Relic, logs Cloudflare) : si le taux de 404 sur /assets/* dépasse un seuil pendant plus de 24h, déclenchez une notification. Cela vous permet de réagir avant que l'impact SEO ne se matérialise dans les classements.

• Configurer la rétention d'au moins 2-3 versions d'assets dans votre build pipeline
• Monitorer les 404 sur assets filtrés par user-agent Googlebot
• Tester le rendu Google via Search Console après chaque déploiement majeur
• Mesurer la fréquence de crawl réelle de vos pages pour calibrer la durée de rétention
• Documenter la procédure de déploiement pour que toute l'équipe technique suive la même logique
• Éviter les purges CDN immédiates — préférer une invalidation progressive ou un grace period