Aujourd’hui, Google me notifie d’une hausse énorme des erreurs 404 (introuvable) sur mon site :


erreurs 404 de mon site

Google me signale ça au moyen de son outil Google Webmaster Tools, qui permet de garder un œil sur l’état du référencement, mais également qui pointe où, l’état du site (up/down), le nombre d’erreurs rencontrés, la vitesse d’exploration, le temps de chargement des pages. C’est un outil assez pratique, et on y trouve parfois des surprises.

Concernant tous les 404, on dirait que Google fait remonter toutes les erreurs, y compris anciennes, qu’il a en mémoire : quand je regarde les pages 404 et les pages qui pointent vers les fichiers 404, beaucoup sont des erreurs de la part de Google : les liens sont bien corrects, aucun soucis donc… Pas plus que d’habitude en fait.


Ceci est tout de même l’occasion de donner quelques astuces sur la maintenance d’un site web au fil du temps.


Astuce de base : une bonne URL ne change pas


Une bonne URL ne change pas. Quand vous créez une page, quelqu’un sera emmené à la partager sur un site ou un forum. À partir de ce moment là, il sera trop tard : si vous voulez modifier l’emplacement du fichier, le lien sur l’autre site ne fonctionnera plus.

Évidemment, ne pas changer de place des fichiers, ce n’est pas toujours possible : un site évolue, c’est normal.
Dans ce cas là, on peut s’en sortir avec une redirection, mais c’est seulement en dernier recourt.


Corriger avec .htaccess

f

Une page web, par exemple « http://lehollandaisvolant.net/tuto/index.php » est accessible depuis plusieurs adresses différentes :


Tôt ou tard, ce genre de liens finiront par se retrouver dans la nature, et dans certains cas, ça créera des problèmes, dont des erreurs 404. Pour ça, on peut utiliser la réécriture d’URL avec le fichier « .htaccess » qui se trouve à la racine de votre site.

Perso, j’utilise plusieurs formes de réécritures. Parmi toutes les URL ci-dessus, celle que je veux pour mon site et mes pages, c’est la plus courte :


Pas de « www », pas de multiples slashs, pas de « index.php » (ce dernier est implicitement utilisé par le serveur, mais ça dépend de votre configuration et le mieux est de tester sur votre site).

Voilà les codes à placer dans le fichier .htaccess (après chaque ajout, testez votre site : une erreur 500 indique une erreur dans le .htaccess, et il faudra annuler la dernière opération effectuée dans ce fichier).

Déjà, placez ceci tout en haut et s’il n’y est pas, pour activer la réécriture :

RewriteEngine on
RewriteBase /


Pour supprimer le « www. » :

RewriteCond %{HTTP_HOST} ^www.lehollandaisvolant.net [NC]
RewriteRule ^(.*)$ http://lehollandaisvolant.net/$1 [R=301,L]

Pour supprimer les « index.php » inutiles :

RewriteCond %{THE_REQUEST} ^GET.*index\.php [NC]
RewriteRule (.*?)index\.php/*(.*) /$1$2 [R=301,NE,L]

Pour supprimer les multiples slashs :

RewriteCond %{REQUEST_URI} ^(.*)//+(.*)$
RewriteRule . %1/%2 [R=301,L]

Pour supprimer le slash final sur un lien en « .php ».
Il faut savoir que sur Linux, Unix et d’autres, un dossier est un fichier, et l’ouvrir constitue une « exécution » du fichier. Son adresse se termine par un slash « / ».
Donc si au lieu de faire « dossier/fichier.php » vous mettez « dossier/fichier.php/ », l’ordinateur pensera que « fichier.php » est un dossier (avec les problèmes de liens relatifs/absolus que ça entraîne : ça fait un sous-niveau supplémentaire) et en exécutant le contenu du fichier quand même. Perso je préfère éviter cela, car ça peut donner des erreur 404.
Je supprime dont le slash final quand il suit un « .php ». Mais attention à ce qu’aucun dossier sur votre site comporte « .php » à la fin, sinon il sera inaccessible aussi.

RewriteCond %{REQUEST_URI} ^(.*)\.php/$
RewriteRule . %1.php [R=301,L]


Le fichier .htaccess permet de faire plein de choses, mais ne le rendez pas trop obèse parce que ce fichier est appelé à chaque requête sur votre site.


Le fichier robots.txt


Google m’indique toutes ces erreurs parce qu’il analyse mon site. Il est possible de lui bloquer l’accès à certaines pages. Du moins, les pages bloquées ne seront pas retournés dans les résultats de recherche : visiblement, Google les explore quand même (certains 404 ne sont issues que de pages bloquées).

Le fichier robots.txt est un fichier à la racine du site, et c’est là dedans qu’on va indiquer quels sont les dossiers et fichiers que les robots ne doivent pas indexer.

Pour interdire l’indexation du dossier « /dossier/ » à tous les robots, utilisez ça :

User-agent: *
Disallow: /dossier/

Vous pouvez mettre plusieurs dossiers, chacun sur une ligne !

User-agent: *
Disallow: /dossier1/
Disallow: /dossier2/

Vous pouvez aussi bloquer juste un moteur de recherche avec son nom :

User-agent: nsa
Disallow: /

Ce code à l’efficacité que je pense fortement douteuse va bloquer l’indexation de tout mon site par la NSA. Le nom des différents moteurs de recherche sont donnés ici : robots-txt.com/ressources.


Le fichier humans.txt


En plus du fichier robots.txt, une initiative a été lancée pour faire un fichier à destination des humains : le fichier « humans.txt ».
Il s’agit un peu d’une page « à propos » de votre site, qui s’affiche en texte simple et dans lequel vous pouvez mettre des infos sur le site, l’auteur…

Selon moi c’est un peu inutile, plutôt humoristique, mais ça peut être sympa si assez de monde le fait : ça ne coûte rien du tout, c’est totalement gratuit et ça ajoute comme les erreurs « 404 » personnalisées, une touche de finesse et de détails à votre site.

J’en ai un sur mon site aussi, je vous laisse le trouver à la racine du site.

14 commentaires

gravatar
Ikario a dit :

Intéressant l'initiative humans.txt...

Je te conseille de commencer à plancher sur l'intégration schema.org > un balisage simple à employer est celui du format JSON (et notamment via la norme JSON-LD) bien plus que les microformat/data...

Google n'en prend en compte que certaines uniquement pour le moment, mais sémantiquement, c'est extrêmement powerfull! Et puis Google n'est qu'un crawler parmi d'autre après tout...

Schema.org est blindé d'objet/type différents donc cela implique une réflexion sémantique en amont par contre :)

http://schema.org/
http://json-ld.org/
https://developers.google.com/structured-data/
https://developers.google.com/structured-data/testing-tool/

Enjoy :D

gravatar
chantoine a dit :

Bonjour,
J'ai bien aimé votre humans.txt (la partie owner... and another) et me suis permis de la pomper lamentablement (avec un (c) ) pour le mien.
J'espère que ça ne me coûtera pas trop cher en droits d'auteur :-)
Merci pour vos articles
Christophe

gravatar
Freegos a dit :

Au passage, c'est assez accessoire, mais pour ceux qui le peuvent (en général ceux qui ont accès à leur propre serveur dédié), il faut éviter à tout prix les htaccess, c'est vraiment super lourd à gérer pour apache par rapport à un simple virtualhost avec des données de rewrite&co dedans.

Maintenant, ce n'est pas toujours possible et les htaccess nous aident bien :p .

gravatar
Le Hollandais Volant a dit :

@chantoine : c’est gratuit :p
Par contre, là on dirait que c’est le site qui est (c)moi. Tu n’es pas obligé de le mettre le crédit, mais si tu insistes, à la place j’aurais mis quelque chose comme une section (en bas) « THIS FILE » puis mon nom.

gravatar
Pierre a dit :

Merci pour le partage. Tant qu'à faire, tu pourrais ajouter un petit paragraphe sur le sitemap

PS: petite faute à corriger dans l'article: celle que je veut -> veux

gravatar
Titi_Alone a dit :

Je signale juste une petite faute de frappe, après l'énumération des liens du Hollandais Volant dans la partie "Corriger avec .htaccess", il est écrit : "Pour ça, on peut utiliser la réécriture d’URL avec le fichier « .hraccess »", je crois que c'est un "t".

gravatar
inwebo a dit :

Bonjour Timo,

en passant,

Une page web, par exemple « http://lehollandaisvolant.net/tuto/index.php » est accessible depuis plusieurs adresses différentes.

Ne serais ce pas une erreur ? Une ressource ne devrait elle pas être accessible de façon unique ?

Pour ma part je désactive ce genre de redirection (omission du www).

http://lehollandaisvolant.net/tuto/index.php
http://www.lehollandaisvolant.net/tuto/index.php

Par contre je conserve l'appelle implicite qui est le comportement par défaut des serveurs wen pour :

http://lehollandaisvolant.net/tuto/
http://lehollandaisvolant.net/tuto/index.php

MAIS ceci :

http://lehollandaisvolant.net////tuto////index.php
http://www.lehollandaisvolant.net////tuto////index.php

Devrait retourner des 404. Car les urls ne désignent aucunes ressource.

Qu'en penses-tu ?

Bonne journée

gravatar
Le Hollandais Volant a dit :

@inwebo :

Ne serais ce pas une erreur ? Une ressource ne devrait elle pas être accessible de façon unique ?

Non, si tu as des redirections et tout, plusieurs URL peut pointer sur le même fichier.
Le but ici de mes redirections c’est de rediriger toutes ces URL sur la même URL.

Pour le WWW, je ne vois pas l’intérêt personnellement : c’est un sous domaine comme les autres. J’aurais pu le conserver, mais je trouve plus joli sans le WWW.

Le fait de tout rediriger au même endroit c’est mieux pour les moteurs de recherche : ça évite les doublons. C’est également mieux pour le référencement : si 4 liens pointant vers la même ressource sont partagés 10 fois chacun, pour le moteur de recherche ça fait 4 pages. En faisant pointer tout au même endroit, ça fait une seule page partagée 40 fois : c’est mieux (à mon avis).

Pour les 404, il faudrait voir ce que dit les spécifications Unix en matière de ressources. Tu as sûrement raison.
Mais dans ce cas, j’aurais pu prendre l’exemple de ça : http://lehollandaisvolant.net/tuto/../tuto/../tuto/index.php
Qui équivaut à dire « j’entre dans le dossier "tuto", je sors, je rentre, je ressors, je rentre et je prends le fichier "index.php" ». Ce chemin est bien valide, même pour Unix.


@Pierre :
@Titi_Alone :
J’ai rectifié, merci !

@Pierre : bonne idée pour le Sitemap, je n’y pensais plus.

gravatar
inwebo a dit :

Re Timo,

Alors

var_dump(filter_var('http://www.lehollandaisvolant.net////tuto////index.php', FILTER_VALIDATE_URL)); Est tout à fait valide.

Pointer plusieurs fois sur la même ressource: http://www.w3.org/DesignIssues/Axioms.html#nonunique

Tu as tout compris pour le référencement ! C'est pourquoi j'essaye de n'avoir que des URL uniques ! Plus simple à maintenir, plus simple à faire évoluer, plus simple à rediriger avec une arborescence sans doublon.

Ce n'est que mon point de vue.

Bonne journée

gravatar
Manu a dit :

Bonjour Timo

N'aurais-tu pas par hasard endormi "ton proxy" aux alentours du 8 juillet.
Je m'en servais de tps en tps et là je me suis moi aussi pris une 404.

Il va revenir le proxy? Hein, dis?

Les commentaires sont fermés pour cet article