Should you block title modifications via JavaScript to prevent unwanted indexing?

Why does Google sometimes index a title modified by JavaScript?

Google executes the JavaScript of pages during crawling and indexing. If a script modifies the content of the tag during page rendering — before any user interaction — the engine may interpret this dynamic version as the final title.

The issue arises when this modification was not intended for indexing. Some websites use JS to customize display based on context (geolocation, time, A/B testing) without anticipating that Googlebot will see and index this variant. The result: the title that appears in the SERPs does not match what the SEO intended.

What does it mean to

Cette recommandation est-elle cohérente avec les observations terrain ?

Oui, et c'est même une confirmation attendue. Les tests de rendu via Search Console (outil d'inspection d'URL) montrent depuis des années que Googlebot exécute le JS et capture l'état du DOM après rendu. Si un script modifie le titre avant que ce snapshot soit pris, Google l'indexe.

Ce qui est nouveau ici, c'est la solution explicite : isoler ces modifications derrière une interaction. Martin Splitt aurait pu dire « désactivez le JS côté serveur » ou « utilisez un SSR propre », mais il propose une approche plus nuancée qui respecte les besoins UX. Reste que cette consigne suppose un audit JS minutieux — combien de sites savent précisément quel script touche au et quand ?

Quelles limites faut-il signaler ?

Premier point : Google ne garantit jamais qu'il utilisera le que vous lui fournissez. Même si vous suivez ce conseil à la lettre, le moteur peut réécrire votre titre en fonction du contexte de la requête, du contenu de la page ou de ses propres heuristiques. Cette directive limite les modifications accidentelles, pas les réécritures algorithmiques.

Deuxième point : [À vérifier] Aucune donnée publique ne quantifie l'impact réel d'un titre mal indexé sur le ranking ou le CTR. On sait que Google privilégie la cohérence sémantique entre titre, H1 et contenu, mais l'ampleur de la pénalité (si pénalité il y a) reste floue. Cette recommandation relève surtout du contrôle qualité : vous voulez maîtriser ce qui apparaît dans les SERP, point.

Dans quels cas cette règle est-elle difficile à appliquer ?

Les applications monopages (SPA) posent un défi particulier. Dans une SPA React ou Vue, le titre change souvent à chaque navigation client-side via un router. Techniquement, ces changements surviennent après interaction (clic sur un lien interne), donc Google ne devrait pas les indexer sur la page d'origine. Mais quid des URL pushState/replaceState ? Si Google crawle directement une de ces URLs, il verra le titre correspondant — et c'est voulu.

Autre cas épineux : les tests A/B côté client. Si vous testez des variantes de titre via JS pour mesurer le CTR organique, vous risquez que Google indexe une version non représentative. La solution ? Soit passer par un A/B serveur (mais c'est coûteux en dev), soit accepter le risque et surveiller de près les données d'indexation. Pas de solution miracle ici — c'est un arbitrage entre rigueur SEO et agilité produit.

Que faut-il auditer en priorité sur son site ?

Commencez par lister tous les scripts qui touchent à document.title ou à l'élément <title> du DOM. Un grep dans votre codebase sur « document.title = » ou « .textContent » appliqué à title révèle souvent des surprises : librairies analytics, chats tiers, widgets de notification.

Ensuite, testez le rendu via Search Console (Inspection d'URL > Afficher la page explorée). Comparez le titre HTML source avec celui capturé après rendu. Si les deux diffèrent et que ce n'était pas intentionnel, vous avez un candidat à corriger. Répétez l'opération sur un échantillon représentatif de templates — homepage, fiches produit, articles, landing pages.

Comment implémenter la protection par interaction utilisateur ?

Plutôt que d'exécuter votre script de modification de titre au load ou au DOMContentLoaded, attachez-le à un événement utilisateur. Par exemple, si vous affichez un compteur de temps passé dans le titre, déclenchez-le au premier scroll ou au premier clic dans la page.

Côté code : remplacez window.addEventListener('load', modifyTitle) par document.addEventListener('click', modifyTitle, { once: true }). Le flag { once: true } garantit que le listener ne se déclenche qu'une fois, évitant les répétitions. Alternative : déclenchez au premier mousemove si vous avez besoin que ça se lance plus tôt, mais gardez en tête que Googlebot ne simule aucun de ces événements.

Quelles erreurs éviter absolument ?

Ne confondez pas « derrière interaction » avec « en différé ». Utiliser un setTimeout() de 3 secondes ne protège pas votre titre : Googlebot attend souvent plusieurs secondes pour que le JS finisse de s'exécuter, et votre script tournera quand même. Seule une interaction humaine authentique (clic, touch, keypress) est ignorée par le bot.

Autre piège : oublier les dépendances tierces. Les scripts de chat, de personnalisation, de tracking peuvent modifier le titre sans que vous le sachiez. Auditez vos tag managers et vos scripts async. Si vous ne contrôlez pas directement le code, passez par une politique CSP (Content Security Policy) pour restreindre les modifications du DOM, ou encapsulez ces scripts dans un contexte isolé.

• Lister tous les scripts qui modifient document.title (grep codebase + audit tag manager)
• Tester le rendu via Search Console sur un échantillon de templates représentatifs
• Remplacer les listeners load/DOMContentLoaded par des événements utilisateur (click, scroll, mousemove)
• Vérifier que les scripts tiers (chat, analytics) ne modifient pas le titre au chargement
• Documenter les exceptions volontaires (titres dynamiques destinés à l'indexation)
• Monitorer les changements de titre indexé via les rapports de couverture et les logs de crawl