Erreurs d'exploration 404 étranges dans les outils pour les webmasters de Google
Si quelqu'un peut aider, je vous en serais très reconnaissant! Nous rencontrons des domaines étranges dans les outils pour les webmasters de Google. Ils semblent se reproduire. Quand je regarde d'où viennent les liens, c'est soit:
- pages inexistantes sur notre site Web (généralement) ou
- une autre URL du site
Je vais donner quelques exemples:
- hechenghai/article/inquiry/frmenquiry.aspx
- sql-server-reporting-services-training/~/ms-project/~/procédures-stockées/~/inquiry/frmenquiry.aspx
- blogs/BradSchacht/ssis/blog/blog/enquête/frmenquiry.aspx
Je suis sûr que Brad Schacht est un type formidable et hechenghai un lieu génial, mais je n'avais jamais entendu parler de l'un d'eux avant qu'ils apparaissent dans les outils Google. Ils ne figurent certainement pas sur notre site Web.
Quelques choses pour aider:
- J'ai un plan de site simple que Google connaît et que j'ai vérifié.
- Nous n'utilisons pas de fichier htaccess (tout est sous Windows)
- nous n'utilisons aucune technique illicite ou noire
- nous générons le site à partir d'un système .NET qui écrit les pages HTML
Vous pouvez voir le site à http://www.wiseowl.co.uk
Analysons vos exemples. Tous trois ont en commun: /enquiry/frmenquiry.aspx. Cela vaut la peine de googler pour. L'un des résultats est cette question, mais il y en a plusieurs autres, dont quelques-uns affichent réellement le code source HTML au lieu du code HTML rendu. C'est un vecteur d'attaque classique pour compromettre des sites Web.
Je suppose que votre site ressent les effets d'une analyse de vulnérabilité mal configurée. Il semble que le scanner possède un certain nombre d’URL et il échange simplement le domaine, puis les recherche. Et depuis que Google les a trouvés, les liens eux-mêmes doivent avoir été disponibles quelque part, parfois, peut-être sur le site Web du scanner.
Avez-vous trouvé l'une de ces 404 occurrences dans votre journal des erreurs? Ils devraient fournir des informations supplémentaires pour savoir quand et où cet événement a commencé.
C’est le cas de masquage d’URL , votre site a été attaqué avec des codes malicieux, votre site affiche donc l’url des autres sites de votre url.
Vous devez faire la nouvelle installation de votre site.
La meilleure façon de procéder consiste à effectuer une sauvegarde de votre base de données, puis à procéder à la nouvelle installation.
Remarque: Essayez de ne pas utiliser de fichiers de code du système précédemment installé autre que des images, car les codes malveillants sont souvent cachés dans les fichiers de code.
Moi aussi j'ai été confronté au même problème. Pour plus d'informations, consultez le lien ci-dessous, cela pourrait aider
http://www.willmaster.com/library/web-development/URL-masking.php
OK, je pense que nous avons peut-être trouvé la réponse. Google signalait des centaines de pages ASPX comme des erreurs 404 et nous avons supposé que c'était ce qui n'allait pas. En fait, c'était ce qui se passait bien. Le vrai problème était que, lorsque quiconque accédait à une page HTML, IIS était configuré pour afficher une page différente, ce qui renvoyait une erreur 200.
Ainsi, si un lien suspect existait à l'extérieur vers une page Wise Owl qui n'existait pas, cette page liée serait alors considérée comme authentique par Google, de même que toutes les pages liées à cette page. Le nombre de pages indexées par Google mais non existantes aurait donc augmenté de manière exponentielle avec le temps, ce qui a finalement conduit à notre pénalisation.
Toujours pas sûr si cela est correct, mais cela semble plausible. Nous avons maintenant supprimé la page 404 d’IIS et nous verrons ce qui se passe!