Google n'indexe pas les URL après une redirection qui ne diffère que par le pourcentage d'encodage / décodage?
Le robot d'exploration de Google refusera-t-il de suivre les redirections lorsque la différence entre les URL redirigées de et redirigées est uniquement le fait que des caractères spécifiques soient codés en pourcentage ou non? Par exemple:
- www.splunkbase.com/apps/All/4.x/Add-On/app:PDF+Report+Server+%28install_on+on+Linux+only%29
- www.splunkbase.com/apps/All/4.x/Add-On/app:PDF+Report+Server+(install+on+Linux+only)
Selon les spécifications HTTP, les deux sont des adresses URI valides et équivalentes, mais le code de notre site est toujours redirigé vers une URL "canonique" pour chaque page de contenu - qui est dans ce cas la première URL répertoriée.
Il est clair que Google n'indexe pas cette page (dans les variantes d'URL). Aucune des URL ci-dessus n'apparaît lorsque je recherche "PDF Report Server (installation sur Linux uniquement)" .
Les outils pour les webmasters de Google signalent une "erreur de redirection" pour la variante "décodée" de l'URL: www.splunkbase.com/apps/All/4.x/Add-On/app:PDF+Report+Server+(install+on+Linux + seulement)
Un autre problème est que nous utilisons actuellement une redirection 302 au lieu d'une redirection 301 pour gérer la canonisation; nous basculons bientôt vers la version 301 pour les redirections canonisées.
Mais je me demandais si le problème 302 contre 301 pouvait sembler être un fouillis rouge: le problème sous-jacent réel pourrait bien être que, aux yeux de Google, nous redirigeons une URL sur lui-même car, selon les spécifications HTTP, un perecent- Les adresses URL encodées et non encodées en pourcentage doivent être traitées de la même manière par les clients et les serveurs.
J'ai trouvé un fil connexe ici . Ce n'est pas le même problème - dans leur cas, la seule différence entre les URL redirigées était les majuscules/minuscules des valeurs hexadécimales codées en pourcentage. Mais cela ressemble étrangement à notre problème.
Enfin, ma question est la suivante: Quelqu'un at-il rencontré ce problème de pourcentage d'encodage plus redirection et, dans l'affirmative, pouvez-vous expliquer comment vous avez résolu ce problème? Le passage à un 301 a-t-il corrigé le problème ou était-il plus nécessaire?
Pour les solutions de contournement au-delà de 301-ing, nous examinons diverses options, dont l'utilisation de REL = CANONICAL et la désactivation de la redirection dans ce cas, ainsi que la modification de notre échappement pour désactiver l'échappement d'apostrophes, de parenthèses et d'autres paramètres peu courants. personnages échappés.
Pour les solutions à long terme, nous examinons:
- comme ce site le fait, en utilisant un identifiant numérique comme clé, en ajoutant REL = CANONICAL pour gérer les modifications du texte de référencement après le titre, sans aucune redirection
- comme de nombreux blogs, continuant à utiliser le titre en tant qu'URL canonique, poursuivez la redirection, mais changez tous les caractères problématiques avec des tirets afin que nous n'ayons pas à nous préoccuper du codage/décodage.
Ces URL étant théoriquement équivalentes, une redirection est probablement considérée comme une redirection vers elle-même, ce qui peut expliquer une erreur d'analyse. En général, si tel est le cas (et je suppose que tel est le cas), alors je vous recommande de ne pas essayer de canoniser l'URL à ce niveau, je ne redirigerais pas une URL vers une autre représentation de la même URL.
De même, il n'est pas nécessaire d'utiliser l'élément de lien rel = canonique pour ces deux URL. Il est conseillé de l'utiliser s'il existe d'autres versions, telles que des majuscules différentes dans les paramètres de chemin ou d'URL, mais cela n'aura aucun effet pour ces deux URL.
Pour ce qui en vaut la peine, un moyen simple de tester la façon dont Google considère les URL de ce type consiste à utiliser la fonction Extraire en tant que Googlebot dans les Outils pour les webmasters. Il ne suivra pas les redirections, vous devriez donc pouvoir voir exactement quelles URL sont extraites, ce qui vous permet d'essayer les différentes variantes et de voir comment elles réagissent.
Dans une note connexe, l'utilisation d'URL telles que celle que vous avez mentionnée me semble un peu problématique, car il peut être difficile pour les utilisateurs de créer des liens vers des URL utilisant des espaces (par exemple, lors du copier-coller d'une URL dans un forum). Avec un lien approprié, Google pourra le suivre, mais si le logiciel côté serveur ne reconnaît pas l'URL complète, ce lien risque alors d'être rompu.
Tout d’abord, le fait que Google n’ait indexé aucune des variantes d’URL n’indique aucun problème avec l’URL elle-même. C'est probablement une raison différente, par exemple Googlebot n'a pas encore exploré cette page ou ne pense pas qu'elle est suffisamment intéressante.
Je suggérerais quelques étapes:
- Supprimer complètement la redirection. Comme vous le dites, les URL sont traitées de la même manière. En fait, Google Chrome convertit automatiquement
%28en(. Vous trouverez peut-être que certains navigateurs font le contraire -(en%28- ce qui peut poser des problèmes. - Lien vers la version 'canonique'. En d'autres termes, assurez-vous que tous les liens sous votre contrôle pointent vers la version correcte, entre parenthèses.
- Mettez la version canonique dans votre sitemap. Si vous ne possédez pas déjà de sitemap XML, créez-en un et envoyez-le à Google Webmaster Tools.
- tilisez rel = canonical pour définir l'URL correcte. Si vous mettez la version entre parenthèses, Google devrait l'indiquer dans les résultats de recherche plutôt que dans l'autre.
Une dernière suggestion serait de supprimer les caractères spéciaux des URL lorsque cela est possible. Vos URL semblent être basées sur des noms de fichiers. Lorsque vous téléchargez un fichier, générez peut-être un "slug" à utiliser sur le site Web, par exemple. pdf-report-server-install-on-linux-only et utilisez-le plutôt dans l'URL.
Si vous utilisez Apache, je vous recommande vivement d'utiliser mod_rewrite afin qu'il puisse gérer les URL canoniques en servant simplement la page demandée plutôt qu'en envoyant une redirection.
Votre problème fondamental réside dans le fait que vous utilisez des URL sur votre site Web qui nécessitent un codage UTF-8. Bien que la limitation de votre jeu de caractères ne soit peut-être pas tout à fait aussi jolie au point d’être originale, elle vous aidera beaucoup plus tard lorsque les autres sites commenceront à créer des liens vers le vôtre. Il est fort probable que d'autres sites finissent par réencoder l'URL et, avant même que vous le sachiez, les moteurs de recherche tenteront d'accéder au lien canonisé.
Ma meilleure solution consiste à changer le lien en un lien sans caractères UTF-8, puis à envoyer une réponse 410 GONE ou 404 NOT FOUND et à ajouter une redirection de 5 secondes dans l'en-tête de l'URL corrigée. Attendez quelques semaines et ça va se corriger tout seul.
Bien sûr, si la page est plus ancienne (plus d'un an), cela peut ne jamais être corrigé.
(edit tidbit: 410 GONE semblait mieux fonctionner sur des URL qui n'auraient absolument pas dû être traitées. Par exemple, les fichiers temporaires et les URL contenant des données de session dans $ _GET.)