Le double encodage d'URLs tue-t-il vraiment votre crawl budget ?

Qu'est-ce que le double encodage percent exactement ?

L'encodage percent (ou URL encoding) consiste à remplacer des caractères spéciaux par leur représentation hexadécimale précédée d'un %. Par exemple, un espace devient %20, une esperluette & devient %26.

Le double encodage, c'est quand on applique ce processus deux fois de suite. Un espace devient %20, qui est à son tour encodé en %2520. Le % lui-même est transformé en %25. C'est souvent une erreur de développement — un script qui encode une URL déjà encodée par un CMS, par exemple.

Pourquoi Google ne décode-t-il qu'une seule fois ?

Google applique une logique simple : il décode une fois l'URL qu'il reçoit, puis tente de la requêter auprès du serveur. Si l'URL a été encodée deux fois, après ce décodage unique, elle reste partiellement encodée — et donc incorrecte.

Votre serveur ne reconnaît pas cette URL malformée. Il renvoie une 404 ou une erreur, même si la page existe bel et bien sous sa forme correcte. Googlebot considère alors que la ressource est introuvable.

Combien de sites sont réellement concernés ?

Gary Illyes mentionne que ce problème représente environ 2% des cas de crawl défaillant. Ce n'est pas négligeable sur des sites volumineux : 2% de milliers de pages, ça fait des centaines d'URLs orphelines.

Les plateformes à risque sont celles qui chaînent plusieurs couches techniques : CMS + proxy + CDN + redirections dynamiques. Chaque maillon peut encoder sans vérifier si c'est déjà fait en amont.

• Le double encodage percent transforme %20 en %2520, rendant l'URL illisible pour le serveur
• Google ne décode qu'une seule fois — pas de rétropédalage possible
• Cela concerne environ 2% des problèmes de crawl, surtout sur des architectures complexes
• Les URLs concernées deviennent orphelines dans l'index, même si elles existent

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

Oui, complètement. On observe régulièrement des cas de double encodage dans les logs de crawl, particulièrement sur des sites e-commerce avec paramètres de filtres ou URL rewriting mal configuré. Les URLs touchées génèrent des 404 en série dans la Search Console.

Le chiffre de 2% peut sembler faible, mais il est concentré sur certains types de sites. Si vous gérez un blog WordPress simple, vous ne verrez jamais ce problème. En revanche, sur une marketplace avec URLs dynamiques et plusieurs langues, c'est un classique.

Quels sont les cas limites non couverts par cette déclaration ?

Gary Illyes ne précise pas si Google tente un second décodage en cas d'échec du premier. [À vérifier] : certains crawlers tiers appliquent un décodage récursif jusqu'à obtenir une URL stable. Google semble plus strict — un seul passage.

Autre zone grise : que se passe-t-il si une URL est partiellement double-encodée ? Imaginons /produit/%2520shoes/basket — Google décode et obtient /produit/%20shoes/basket. Est-ce qu'il comprend que c'est un espace ou laisse-t-il le %20 tel quel ? La déclaration ne tranche pas.

Faut-il vraiment s'inquiéter si on n'a jamais vu ce problème ?

Non. Si votre Search Console ne montre pas de pics d'erreurs 404 inexplicables sur des URLs qui existent, vous n'êtes probablement pas concerné. Ce n'est pas un bug silencieux qui ronge l'index sans symptôme.

En revanche, si vous constatez des pages valides qui n'apparaissent jamais dans l'index malgré un sitemap propre et des liens internes, vérifiez l'encodage. C'est un diagnostic à avoir dans votre checklist avant de chercher des causes plus ésotériques comme le contenu dupliqué ou la cannibalisation.

Comment détecter le double encodage sur mon site ?

Comparez les URLs crawlées par Google (Search Console → Couverture → Exclues) avec celles présentes dans vos logs serveur. Si vous voyez des URLs avec %25 suivies de codes hexa (ex: %2520, %253D), vous avez un double encodage.

Autre signal : des 404 en masse dans la Search Console sur des URLs qui, une fois décodées manuellement, correspondent à des pages existantes. Utilisez un outil de décodage en ligne pour vérifier.

• Auditez les URLs de la Search Console marquées comme 404 ou Non trouvées
• Cherchez les occurrences de %25 dans vos logs de crawl — c'est le signe du % encodé lui-même
• Testez manuellement les URLs suspectes en les décodant deux fois et en vérifiant si elles deviennent valides
• Passez en revue les scripts de génération d'URLs : CMS, plugins, redirections .htaccess, middlewares
• Vérifiez les URLs issues de filtres dynamiques (facettes e-commerce, paramètres UTM complexes)

Quelles actions correctives mettre en place immédiatement ?

Identifiez la couche technique responsable du double encodage : CMS, serveur web, CDN, application tierce. Souvent, c'est un plugin ou un module mal configuré qui encode par défaut sans vérifier l'état de l'URL entrante.

Corrigez à la source en désactivant l'encodage automatique dans la couche fautive. Si ce n'est pas possible (dépendance externe), mettez en place une règle de réécriture côté serveur pour décoder une fois avant traitement.

• Désactivez l'encodage automatique dans les modules suspects (URL rewriting, plugins SEO, proxies)
• Implémentez une règle .htaccess ou nginx pour décoder les URLs entrantes si nécessaire
• Soumettez à nouveau les URLs corrigées via la Search Console pour forcer un recrawl
• Surveillez les logs pendant 2-3 semaines pour vérifier que le problème ne se reproduit pas

Que faire si le problème persiste malgré les correctifs ?

Certains cas de double encodage sont générés dynamiquement par des scripts côté client (JavaScript) qui modifient les URLs avant soumission. Auditez vos event listeners, vos fonctions de routing, vos appels AJAX.

Si l'architecture est trop complexe ou les couches techniques multiples, ce type de diagnostic peut rapidement devenir chronophage. Faire appel à une agence SEO technique permet d'obtenir un audit approfondi des logs de crawl, une cartographie précise des points d'encodage et une correction pérenne sans risque de régression.