URL étrange pour un site hébergé par OVH : /~ [at] L11Ju~/

Gibus3133 · Avril 16, 2015, 18:53:20

Je vous soumet une chose étrange que peut être certains d'entre vous ont déjà rencontré mais qui pour moi reste un mystère.
Depuis quelque temps je constate sur un de mes sites internet une bizarrerie qui commence à devenir inquiétante. Précision qui peut être utile, le site en question est hébergé par OVH et est en html "classique" (pas un CMS, pas de Php, et même pas une petite base de données qui pourrait mettre la zone suite à une manip inappropriée).

Le problème : certaines URL comportent entre le nom de domaine et le nom de la page une partie avec des caractères "étranges" qui n'ont aucune raison d'être. Toujours les mêmes caractères d'ailleurs /~ [at] L11Ju~/

Précision, à la place de [at] dans la réalité s'est le signe arobase qui figure (c'est le forum qui traduit automatiquement arobase et le remplace par [at])

Pour être plus clair, si j'ai une page qui s'appelle : nom-de-domaine.com/nom-de-la-page.htm je me suis aperçu en consultant mes statistiques que de plus en plus d'Internautes arrivaient sur la page avec cette URL : nom-de-domaine.com/~ [at] L11Ju~/nom-de-la-page.htm

Bien sûr je n'ai sur mon site aucun dossier intermédiaire qui soit nomme /~ [at] L11Ju~/

Et l'url nouvelle en question permet bien d'accéder à la page.
Le côté le plus fâcheux c'est que Google référence maintenant bon nombre de pages avec les 2 URL, la vraie et la fictive.
J'avais déjà vu fleurir quelques fois ce type d'URL il y a 1 ou 2 ans mais c'était tellement rare que je l'avais oublié. Depuis quelques jours le problème a pris une vraie ampleur et j'ai des dizaines de pages qui sont concernées et pour certaines d'entre elles cela va jusqu'à 30% des visites reçues.

Je soupçonne une histoire de cache ou de renvoi interne au fonctionnement OVH (hébergement serveur mutualisé) mais avant de les contacter j'aurai aimé savoir si quelqu'un avait déjà connu ce phénomène et pourrait m'en dire un peu plus. Merci par avance pour vos retours !

GregP · Avril 17, 2015, 11:06:10

Je pense vraiment qu'il faut poster ceci sur le forum d'OVH et non ici....

Gibus3133 · Avril 17, 2015, 16:48:19

Citation de: GregP le Avril 17, 2015, 11:06:10
Je pense vraiment qu'il faut poster ceci sur le forum d'OVH et non ici....

Nous sommes bien dans la rubrique "Espace INTERNET & Multimédia", le souci évoqué concerne l'hébergement d'un site photo, et j'ai bien sûr déjà posé la question au support OVH qui me répondra sans doute à un moment ou à un autre.

Merci pour ton aide précieuse ...

Samoreen · Avril 17, 2015, 23:35:48

Bonsoir,

Si vous avez une réponse, je suis intéressé. Après une rapide enquête, je me rends compte que de nombreux sites, non nécessairement hébergés par OVH, ont des dossiers contenant le terme L11JU associé éventuellement à d'autres caractères (pour être précis, ont des pages dont l'URL contient ce type de dossier qui n'a pas l'air d'exister en réalité). Et à chaque fois, si on entre le même URL sans inclure ce dossier intermédiaire, on arrive sur la même page.

En fait, ce dossier invisible car inexistant doit servir de marqueur. Quand le serveur reçoit la requête et analyse l'URL, il doit effectuer une tâche particulière et ensuite rediriger vers la page réelle (dont l'URL ne contient pas le sous-dossier en question dans son chemin d'accès). C'est donc peut-être lié à une application que vous avez installée sur votre serveur. Pour que ça fonctionne, il faudrait donc que le navigateur insère le marqueur en question avant d'envoyer la requête.

Gibus3133 · Avril 18, 2015, 11:04:40

Merci pour cette vision des choses qui est assez proche de ce que je pense.

Ce qui est très dérangeant dans ce problème c'est que Google référence ces URL modifiées, et quand un internaute arrive sur ce type URL dès qu'il navigue il conserve (propage) le défaut à toutes les pages qu'il consulte. Lesquelles sont à leur tour référencées ... Snif !

Le site concerné par ce problème étant particulièrement simple, site classique en html, j'en viens à soupçonner les marqueurs de statistiques. J'utilise CLICKY et les pages contiennent aussi les marqueurs de Google Analytics que je ne consulte plus mais que j'avais laissé par habitude. Il est possible que j'utilise un code Google Analytics périmé (ceci dit je n'ai rien touché et ce problème ne se posait pas). Je remarque d'ailleurs que seul Google références les URL ainsi modifiées. J'avais cru à un moment que BING également mais a priori ce n'est pas le cas.

Ensuite, ce qui me fait dire que ce problème concerne tout de même OVH, c'est que sur n'importe quel site hébergé par OVH on intercale entre le nom de domaine et le nom de la page ce fameux code /~ [at] L11Ju~/ (ne pas oublier de remplacer [at] par le signe arobase) et bien on arrive toujours à accéder à la page en question. Si l'on fait la même chose sur un site qui n'est pas hébergé par OVH (je viens à l'instant de tester sur un site hébergé chez Online), fort logiquement on obtient une erreur 404.

Bon ayant posé la question à OVH un vendredi je pense que je n'obtiendrai une réponse que la semaine prochaine. Je ne manquerai pas d'en faire un retour ici.

Bien entendu si quelqu'un d'autre a déjà eu connaissance de ce phénomène et qu'il l'a résolu, la solution m'intéresse !!

Merci encore.

jesus · Avril 18, 2015, 11:09:30

Je pense à un problème de .htaccess, vérifie le tien.
Justement avec le .htaccess tu dois pouvoir créer une règle, qui supprime l'extension et le duplicate content !

GregP · Avril 18, 2015, 16:15:40

Citation de: Gibus3133 le Avril 16, 2015, 18:53:20
mais avant de les contacter j'aurai aimé savoir si quelqu'un avait déjà connu ce phénomène et pourrait m'en dire un peu plus. Merci par avance pour vos retours !

Citation de: Gibus3133 le Avril 17, 2015, 16:48:19
j'ai bien sûr déjà posé la question au support OVH qui me répondra sans doute à un moment ou à un autre.

No comment...

Gibus3133 · Avril 18, 2015, 19:22:01

Citation de: GregP le Avril 18, 2015, 16:15:40
No comment...

Je ne te connais pas mais sur ce coup tu peux obtenir la palme des interventions inutiles.

Première intervention pour dire qu'en gros ma demande n'a rien à faire sur ce forum alors que je suis justement dans la rubrique appropriée,
Deuxième intervention avec un montage tronqué de 2 de mes précédents messages ... ayant 24 heures d'intervalle (cela s'appelle de la manipulation) et un commentaire destiné à me faire passer pour ce que je ne suis pas.

Ne te crois surtout pas obligé de revenir.

Gibus3133 · Avril 18, 2015, 19:31:28

Citation de: jesus le Avril 18, 2015, 11:09:30
Je pense à un problème de .htaccess, vérifie le tien.
Justement avec le .htaccess tu dois pouvoir créer une règle, qui supprime l'extension et le duplicate content !

A priori le .htaccess est correct. Il est en ligne depuis plusieurs années et il n'a jamais posé de problème, je ne l'ai pas touché récemment.
Avant d'y toucher j'attendrai tout de même la réponse d'OVH car il n'est pas évident de créer une règle pour une URL qui fait référence à un dossier qui n'existe pas.

Comme le suggère Samoreen dans sa première réponse, il doit y avoir une requête qui coince quelque part et qui retourne ce marqueur. Si c'est le cas, comme le problème n'existait pas avant (le même site existe depuis 2008), il y sans doute eu des modifications récentes coté serveur qui pourraient expliquer la chose.

Merci en tout cas pour ta réponse, je garde tout de même ta suggestion au chaud.

Samoreen · Avril 18, 2015, 23:12:51

Si ça peut orienter les recherches, je note que les sites fonctionnant sous ASP .Net utilisent cette technique quand l'option "Session cookieless" est activée.

GregP · Avril 20, 2015, 09:48:50

Dans le monde UNIX, un chemin contenant un "~" référence un utilisateur.
Ainsi l'URL suivante <nom de domaine>/~test/index.html indique au serveur qu'il faut charger la page index.html à partir du répertoire du user "test".
Or ici, le user "test" n'existe pas. On peut aussi remplacer "test" par " [at] L11Ju~". On peut ramplacer par n'importe quoi qui commence par tilde.
Ces users n'existent évidemment pas et le serveur va charger la page demandée (index.html) depuis le répertoire racine (www).

Une solution pour ne pas indéxer de tels URLs est bien d'utiliser .htaccess afin de rediriger tout ce qui commence par un tilde vers le répertoire racine:

RedirectMatch ^/~(.*)/(.*) http://www.example.com/$2

Samoreen · Avril 20, 2015, 11:22:46

Citation de: GregP le Avril 20, 2015, 09:48:50
Dans le monde UNIX, un chemin contenant un "~" référence un utilisateur.

Voilà une info intéressante qui m'avait échappé (je n'ai pas touché à Unix depuis des lustres). Cependant, ça n'explique pas tout. Pourquoi OVH feraient-ils ça ? En profitent-ils pour exécuter quelque chose de particulier dans cette page index.html pour ensuite rediriger vers la page index "réelle" ?

Puisque cette partie du chemin n'existe pas quand on accède au site par l'URL normal, à quel moment est-elle donc insérée ? Si Google référence cet URL modifié, c'est bien que quelqu'un quelque part prend l'initiative de le créer...

Gibus3133 · Avril 20, 2015, 13:32:24

Citation de: GregP le Avril 20, 2015, 09:48:50
Dans le monde UNIX, un chemin contenant un "~" référence un utilisateur.
Ainsi l'URL suivante <nom de domaine>/~test/index.html indique au serveur qu'il faut charger la page index.html à partir du répertoire du user "test".
Or ici, le user "test" n'existe pas. On peut aussi remplacer "test" par " [at] L11Ju~". On peut ramplacer par n'importe quoi qui commence par tilde.
Ces users n'existent évidemment pas et le serveur va charger la page demandée (index.html) depuis le répertoire racine (www).

Une solution pour ne pas indéxer de tels URLs est bien d'utiliser .htaccess afin de rediriger tout ce qui commence par un tilde vers le répertoire racine:

RedirectMatch ^/~(.*)/(.*) http://www.example.com/$2

Avant tout, merci pour cette réponse constructive et intéressante.

Je ne connais pas l'univers UNIX et donc je découvre cette fonction du signe "~". Ce que tu en décris correspond effectivement à ce qui doit se passer dans le cas que je soulève.

Maintenant, avant d'agir sur le .htaccess j'essaie de comprendre ou de trouver quel est l'élément déclencheur, qui le met en œuvre et à quel niveau cela se passe. Car j'avais déjà vu ce phénomène il y a 2 ou 3 ans de façon très marginale pour un autre site hébergé chez OVH. Ce qui me permet de penser qu'OVH a dans ce cas précis un rôle spécifique c'est que si l'on insère entre le nom de domaine la fameuse suite de caractères, systématiquement pour un site hébergé chez OVH la page est accessible (qu'il s'agisse de site en PHP ou en HTML) alors que ce n'est jamais le cas avec d'autres hébergeurs testés.

Après, ce qui me fait temporiser un peu le fait de toucher au .htaccess c'est que le site concerné a des centaines de pages avec des contenus bien différents et que qu'aujourd'hui un Internaute qui arrive par un moteur de recherche arrive directement sur la bonne page. Vu le nombre de pages concernées je n'aurai d'autre choix effectivement pour faire simple de le rediriger vers la page d'accueil et c'est tout de même largement moins bien.

En attendant de recevoir la réponse des services OVH, j'essaie d'identifier ce qui a pu déclencher ces derniers jours ce phénomène sur un site qui a 7 ans d'existence.

Même si je ne vois pas bien à quel niveau cela pourrait s'être produit, le fait que Google soit le seul moteur à référencer ces URL fictives m'interpelle.

Gibus3133 · Avril 20, 2015, 13:45:09

Citation de: Samoreen le Avril 20, 2015, 11:22:46

... Pourquoi OVH feraient-ils ça ?
En profitent-ils pour exécuter quelque chose de particulier dans cette page index.html pour ensuite rediriger vers la page index "réelle" ?

Puisque cette partie du chemin n'existe pas quand on accède au site par l'URL normal, à quel moment est-elle donc insérée ? Si Google référence cet URL modifié, c'est bien que quelqu'un quelque part prend l'initiative de le créer...

C'est tout à fait les questions que je me pose. Qui pourquoi et à quel moment.
Précision utile, malheureusement cela ne concerne pas que la page index, mais bien toutes les pages du site. Et ce qui est fâcheux c'est que si un Internaute arrive sur une page (n'importe laquelle) de mon site avec cette suite de caractères, quand il clique sur un lien vers une autre page il conserve systématiquement cette chaine de caractères pour touts les pages de sa navigation.

Je trouve également surprenant que Bing, Ask, Yahoo et les autres moteurs ne référencent aucune page avec cette suite de caractères comme le fait Google.
Comme je le disais plus haut, j'utilisais à l'origine du site (7 ans donc) Google Analytics en même temps que Clicky. Depuis j'ai définitivement adopté Clicky et je ne me suis donc jamais plus soucié du code de Google qui depuis doit largement être obsolète. Je ne vois pas à quel niveau, mais j'ai pensé (à tort ou à raison) que cela pouvait être devenu un élément perturbant au moment d'accéder aux pages. Ma première action consiste donc à progressivement supprimer ce marqueur Google.

Je ne manquerai pas de revenir ici pour indiquer la réponse de OVH (mais rien encore pour l'instant).

GregP · Avril 20, 2015, 13:59:23

Concernant la duplication de contenu, Google recommande le "301 redirect" via le .htaccess:
https://support.google.com/webmasters/answer/66359?hl=en

En modifiant le .htaccess comme déjà indiqué, la page:
http://www.example.com/~test/blabla.html
sera redirigé vers:
http://www.example.com/blabla.html

Ce qui solutionne bien le problème, ce n'est pas une redirection systèmatique vers la home page.

Mais sinon, tu peux aussi laisser comme ça, Google "comprend" assez bien la duplication de page et l'article recommande même de na pas interdire l'accés aux pages dupliquées via robot.txt, afin de pouvoir "comprendre".

Quid: pourquoi, comment une telle URL a été indexée? Aucune idée, il peut suffir que quelqu'un poste cette URL dans un forum par exemple.

Gibus3133 · Avril 20, 2015, 20:02:11

Citation de: GregP le Avril 20, 2015, 13:59:23
Concernant la duplication de contenu, Google recommande le "301 redirect" via le .htaccess:

... Mais sinon, tu peux aussi laisser comme ça, Google "comprend" assez bien la duplication de page et l'article recommande même de na pas interdire l'accés aux pages dupliquées via robot.txt, afin de pouvoir "comprendre".

Quid: pourquoi, comment une telle URL a été indexée? Aucune idée, il peut suffir que quelqu'un poste cette URL dans un forum par exemple.

Oui je pensais bien à une 301 redirection c'était il y a quelques années déjà une suggestion de Matt Cutts (dont la parole n'était pas toujours d'évangile restons réalistes). Et comme tu le dis normalement Google a un algorithme suffisamment performant pout détecter le contenu dupliqué. Comme dans mon cas il s'agit d'URL qui n'ont pas d'existence "en dur", je pense que cela devrait progressivement rentrer dans l'ordre.

Il me semble d'ailleurs que le nombre de pages incriminées semble s'être réduit par rapport à la fin de semaine dernière (je reste prudent). Par contre 3 ou 4 pages très génératrices de visites sont encore concernées.

Après, effectivement comment la première URL de ce type s'est elles trouvée indexée c'est un mystère (comme d'ailleurs ce qui a été l'élément déclencheur pour que cette URL arrive).

Ce n'est en tout cas pas de mon fait car lorsque j'ai abordé le sujet sur le net j'ai volontairement exclu de citer le nom de domaine en question. D'une part c'était le meilleur moyen pour que d'autres moteurs s'y intéressent et d'autre part croyant bien faire des intervenants auraient aussi pu diffuser l'URL sur d'autres forums.

Pour l'instant toujours pas de réponse de la part du support OVH.

Affaire à suivre ...

Gibus3133 · Avril 21, 2015, 14:31:03

Bon j'ai une réponse d'OVH, elle est super pertinente et utile : circulez ce n'est pas notre problème.

La phrase qui résume tout :

> Votre souci concerne la programmation et cela est de votre ressort.

Bon je tente de relancer en étant je l'espère une peu plus clair.

A suivre toujours ...

jesus · Avril 22, 2015, 12:12:50

Ce n'est pas étonnant de la part d'OVH, tu a déjà eu une réponse c'est bien !
La règle à implémenter est assez basique tu n'as plus qu'à !
Google détecte bien le duplicate, mais pour le sanctionner

Gibus3133 · Avril 25, 2015, 11:11:03

La suite du feuilleton ... aujourd'hui le problème subsiste mais OVH le prend en compte.

Suite à la réponse qui m'avait moyennement plu, j'avais relancé ma demande en la reformulant et en me montrant plus directif.

J'ai constaté le lendemain que j'avais des visites avec la fameuse chaine de caractères, mais aussi avec d'autres variantes genre /~nimportequoi/ ou autres formulations et que ces visites venaient de chez OVH. Et effectivement dans les heures suivantes j'ai reçu confirmation qu'ils basculaient le problème aux services techniques (je suppose niveau supérieur au précédent) et qu'un ticket d'incident avait été ouvert.

Ce matin nouveau mail du service technique en question qui me confirme qu'ils examinent le problème et qu'ils tentent de le résoudre au plus tôt.

Je ne sais pas quelle sera l'issue, mais je trouve encourageant que le problème soit pris en compte et qu'il y ait un véritable suivi.

Je vous tiendrais bien sûr au courant car le cas que je soulève ici peut demain concerner tous ceux qui ont leur site hébergé chez OVH.

Gibus3133 · Mai 06, 2015, 14:04:10

Comme promis, un mois après les premiers symptômes, la suite de l'histoire.

La bonne nouvelle étant que progressivement les choses rentrent dans l'ordre. Aujourd'hui je ne vois plus ces URL dans le top 10 des pages les plus consultées alors qu'il y a une quinzaine de jours elles en occupaient 8 sur 10.

Côté OVH je n'ai aucune idée de ce qu'ils ont fait ou pas fait. Je sais qu'ils ont concrètement examiné le problème car j'ai repéré plusieurs visites en provenance de chez eux avec des déclinaisons du problème. Le ticket d'incident est toujours ouvert et je n'ai plus eu de nouvelles depuis son ouverture.

De mon côté les actions que j'ai menées "à tout hasard" tout en n'ayant aucune idée si elles ont pu avoir une quelconque utilité dans le fait que la situation se rétablisse. Ce qui est sûr c'est que désormais Google référence les pages normales comme c'était le cas auparavant et s'abstient de référencer les URL polluées.

- En première action j'ai commencé à retirer les marqueurs de Google Analytics qui n'étaient sans doute pas à jour, et qui venaient peut être en conflit avec ceux de Clicky.
- Mise à jour des marqueurs Clicky qui eux aussi ont légèrement évolué.
- Création d'un nouveau Sitemap, mis en ligne ... et informé les moteurs de recherche de sa présence.

Je ne sais donc toujours pas ce qui a été la cause déclenchante de ces URL, ni comment et pourquoi Google (et seulement Google) les a référencées. Au final, pas de chute du nombre de visiteurs ce qui était tout de même le risque numéro 1.

Si l'un d'entre vous rencontre un jour avec son site hébergé chez OVH, il pensera à ce fil ... Merci en tout cas à ceux qui ont tenté de m'apporter une aide sur ce problème semble-t-il inédit.