Monique Posté 10 Septembre 2003 Posté 10 Septembre 2003 Bonsoir, Je viens de découvrir ce validateur de robots.txt, en complément de plusieurs articles sur le fichier : exemples, erreurs fréquentes... Quand on sait combien ce fichier, plutôt léger, peut peser lourd dans la balance du référencement quand il est mal rédigé
Dan Posté 11 Septembre 2003 Posté 11 Septembre 2003 Bonjour Monique, Même si ce lien n'est pas tout récent, c'est une excellente idée de l'avoir posté ici. Tu m'as battu sur le fil, comme je rédigeais un petit résumé des liens utiles au webmaster. A ton lien j'ajouterai donc ceux-ci: Le visualiseur d'entêtes HTTP d'ApocalX, bien utile lorsqu'on a des redirections en place pour s'assurer que la bonne entête est retournée. Je suggère à tous de faire aussi l'essai avec un fichier inexistant, et de vérifier que l'entête retournée est bien 404. Le visualiseur de Leknor qui permet de voir si une page est "gzippée" sur le serveur avant envoi. Tous les sites hébergés en mutualisé chez OVH le sont, par exemple. C'est d'ailleurs pour cette raison que je n'ai pas activé le gzip sur le forum du Hub, car "gzipper" du gzip ne sert qu'à consommer du CPU En voici la démonstration ! Le validateur du W3C, indispensable ! Le validateur du Web Design Group, qui par rapport à celui du W3C, permet la validation d'un site "entier". Ils limitent tout de même à 100 pages pour le validateur en ligne. Le Web Design Group offre un validateur offline pour ceux qui souhaitent valider les sites en local. Dan
Perle d'Argent Posté 11 Septembre 2003 Posté 11 Septembre 2003 Le validateur du W3C, indispensable ! Le validateur du Web Design Group Merci pour cette liste de liens qu'il est bon d'avoir dans ses favoris Les deux liens ci-dessus sont en fait complémentaires, en ce sens que: Le premier ne permet de valider qu'une page à la fois, et refuse de s'intéresser aux pages en php, contrairement à WDG Le deuxième accepte le php (et là, bonjour les dégâts....) mais ne tient pas compte des caractères spéciaux.... Bref, merci Dan, grâce à toi, j'ai encore passé une journée à m'arracher les cheveux Mais bon, il faut le faire
Anonymus Posté 11 Septembre 2003 Posté 11 Septembre 2003 (modifié) C'est d'ailleurs pour cette raison que je n'ai pas activé le gzip sur le forum du Hub, car "gzipper" du gzip ne sert qu'à consommer du CPU En voici la démonstration ! Superbe démo, mais.... à quoi ca sert, de gzipper, dégeziper, etc ?? Anonymus... ps :Ne faudrait il pas faire une file de discussion spéciale 'liens utiles' ?? Modifié 11 Septembre 2003 par anonymus
Dan Posté 13 Septembre 2003 Posté 13 Septembre 2003 C'est d'ailleurs pour cette raison que je n'ai pas activé le gzip sur le forum du Hub, car "gzipper" du gzip ne sert qu'à consommer du CPU En voici la démonstration ! Superbe démo, mais.... à quoi ca sert, de gzipper, dégeziper, etc ?? Anonymus... ps :Ne faudrait il pas faire une file de discussion spéciale 'liens utiles' ?? anonymus, J'imagine que tu ne poses pas cette question pour toi, mais pour l'intérêt général comme tu connais vraisemblablement la réponse Tout le monde connaît les fichiers compressés au format Zip qui permettent une économie de place importante. Gzip (le programme de compression Zip du GNU) fait globalement la même chose que tous les utilitaires de compression que l'on trouve sur de nombreux PC: réduire la taille d'un fichier avec une compression dite "lossless" (sans perte). Cette compression "sans perte" permet de récupérer le fichier exact après décompression, sans aucune perte d'information. Une des particularités du protocole http est justement de permettre l'utilisation de pages compressées, pour gagner de la bande passante. On divise typiquement par 5 la taille d'une page lorsqu'on la compresse, et cela réduit donc les temps de transfert réseau dans les mêmes proportions.... très appréciable quand on n'a pas un accès rapide au net. Certains hébergeurs avisés, soucieux de leur bande passante réseau car c'est un des éléments les plus coûteux de leur métier, activent donc la compression gzip des pages sur leurs serveurs avant l'envoi vers le poste client. C'est notamment le cas d'OVH. Cette configuration se fait directement au niveau du serveur Apache. La compression, si elle fait gagner de la bande passante, consomme un peu de ressources CPU pour être effectuée. C'est donc un compromis à trouver pour l'hébergeur ou le propriétaire d'un serveur dédié. Tous les navigateurs récents décompressent ces pages "à la volée" de manière totalement transparente pour les utilisateurs. Les moteurs de recherche utilisant le protocole http pour scanner les pages du web décompressent les pages gzippées à l'identique (encore heureux ) Dan
Sujets conseillés
Veuillez vous connecter pour commenter
Vous pourrez laisser un commentaire après vous êtes connecté.
Connectez-vous maintenant