Il y a deux ans, j’écrivais cet article : et si Google fermait mon compte ?
Ça faisait suite, dans une certaine mesure, à l’annonce d’Opera de fermer quelques mois plus tard leur service mail : je m’étais demandé quel impact pour moi aurait la fermeture d’autres services web que j’utilisais à l’époque, principalement Google.

Depuis la fermeture de My-Opera, j’ai effectivement pris quelques mesures. Je pense être devenu moins dépendant de services externes. Il faut dire que la fermeture de mon compte email principal m’a beaucoup fait chier, mais d’un autre côté ça m’a permis d’apprendre beaucoup de choses.

Voici mon retour d’analyse, deux ans après cet « incident », et la mise aupoint concernant ma dépendance vis à vis des autres « grands sites ».
Toujours la même notation : 0/5 correspond à « je m’en fous totalement » et 5/5 à « je suis vraiment dans la merde ».

Si Google fermait mon compte, en 2015 :

• Gmail. Je n’utilise plus GMail. Mes comptes utilisateurs sur les autres sites sont sur une adresse email chez moi. Note : 0/5.
• Google Plus. Note : 2/5. J’utilise G+ pour trouver des infos intéressantes plus qu’autre choses. Je pourrais m’en passer, même si ce serait dommage.
• Google Documents. Note : 0/5. J’utilise exclusivement Libre Office et je partage les fichiers qui sont à partager via mon site ou via email.
• Youtube. Mon compte Youtube est fermé depuis quelques temps. Je n’ai plus de compte Youtube. Note : 0/5.
• Android. Note : 1/5. Il faut un compte Google pour télécharger des applications sur Google Play et utiliser diverses fonctionnalités d’Android. J’ai appris à utiliser Android sans compte Google. Si mon compte était fermé, je mettrais ces connaissances à exécution (ce n’est pas le cas actuellement). Je ne sais pas en revanche ce que Google peut encore faire si on n’est pas connecté à son compte. D’où l’intérêt d’utiliser un téléphone avec un OS Libre, mais ce n’est pas gagné. Je pense que je verrais le moment venu, en espérant que ça arrive le plus tard possible. Mais quand ça arrivera je ne serais pas paniqué, c’est déjà ça.
• Google Maps, Google Search, Google Traduction : tout ça j’utilise parfois aussi. Mais il n’y a pas (encore) besoin de compte pour utiliser.

C’est tout pour Google.

Pour les autres sites :
Paypal, eBay, Amazon, ça me ferait un peu chier parce que j’achète régulièrement en ligne, mais je peux m’en passer : il y a d’autres sites et d’autres moyens.
Microsoft/Skype, Facebook, Yahoo : totalement rien à faire. Je n’utilise pas de XBox, et Facebook me sert un peu à rien. Mon compte Yahoo, je ne sais même plus ce que c’est…
Twitter : je l’utilise de temps à autre en version web pour interagir avec ceux qui suivent mon blog via Twitter (le RSS de mon blog est reposté sur Twitter). Ça serait dommage si ça vienne à être supprimé, mais bon, tant pis : ça m’empêchera pas de poster et ça n’empêchera personne de lire mon site quand même si elle le souhaite vraiment.
Tumblr : j’aime bien Tumblr, le site est sympa et on trouve pas mal de monde. Mon site n’est plus dupliqué sur Tumblr depuis un moment car je l’utilise pour d’autres raisons maintenant, plus orienté jeux-vidéos, manga, pokémon… Là aussi, ça m’embêterait que le site ferme où que mon compte soit fermé, mais ça ne sera pas la fin du monde non plus.

Je n’ai autrement pas de compte « Cloud » grand public, ni de compte d’écoute de musique en ligne (SoundCloud, LastFM, Deezer…).

Bref, je suis un peu partout sur Internet, mais mon point central c’est mon site, mes noms de domaines. Je n’ai pas encore de quoi m’auto-héberger (ou même devenir mon propre FAI) pour garantir une bonne et vraie indépendance, mais si ça venait à arriver pour des raisons politiques, je suppose que le web ne sera plus un lieu digne d’intérêt pour partager quoi que ce soit. Je serais alors passé sous Tor ou Freenet depuis longtemps.

Ce ne sont pas la fermeture de mes comptes sur les réseaux sociaux qui me font peur en tout cas.

Netflix, entre autres, qui utilise le codec H265 pour diffuser de la vidéo en Ultra-HD (4K), est ciblé par HEVC Advanced, pour leur faire payer des droits d’utilisation du codec.

Je me marre.


Bah comment dire : c’est bien fait et ça leur apprendra d’utiliser des technologies non libres ?

Parce que ça fait des années, même des décennies, qu’il existe de très bon codecs et conteneurs libres d’usage et de droits pour l’audio et la vidéo : Vorbis, Theora, WebM (reprise du Matroska, lui aussi libre), VP8/9, Opus.

Les formats ne sont pas ce qui manque. Et s’ils peuvent très bien ne pas être aussi bon que le H265, je pense que ça coûtera bien moins cher à Netflix et les autres d’investir dans l’évolution de ces codecs libres que de payer pour avoir le droit de se servir du H265. Et en prime, ces évolutions profiteront à tout le monde, comme ces codecs pourront profiter à eux, gratuitement.

Il faut croire que personne n’apprend jamais : ça fait des années que les ayants droits du H265/H264 et même aussi ceux du MP3 et avant cela ceux du format GIF font ce qu’ils peuvent pour imposer des royalties quand on utilise leur codecs.

En CSS, il y a les sélecteurs. Avec le CSS v3, il y a maintenant beaucoup de sélecteurs, et vous trouverez pas mal de ressources à ce sujet. En revanche, ce dont on n’entend pratiquement jamais parler, c’est la spécificité des sélecteurs. Même les sites de référence comme OpenClassRooms ne semble pas en parler dans son tutoriel sur le HTML/CSS.

La spécificité est pourtant importante, car elle intervient au moment où le navigateur doit appliquer les CSS à un élément de la page.

Spécificité ?

Considérons ce code :

HTML :

<body>
Mon texte
</body>

CSS:

body { color: red; }
body { color: green; }

Quelle sera la couleur de la page ?
La page sera évidemment verte, car le navigateur va prendre en compte la dernière déclaration effectuée.

Maintenant, plaçons des paragraphes dans la page avec un lien :

<body>
Mon texte
<p>Mon paragraphe</p>
<p>Mon paragraphe avec <a>un lien</a></p>
</body>

Avec le code ci-dessus, les paragraphes et le lien seront également en vert (en fait non pour les liens : les styles internes du navigateur font qu’ils sont bleus si on ne dit rien ; voir plus bas) : la couleur est en effet héritée de l’élément parent de <p> et de <a>.
Si on veut donner une couleur particulière aux éléments on fait ceci :

CSS:

body { color: red; }
p { color: green; }
a { color: blue; }

Ici, le texte sera bleu dans le lien, en vert dans le paragraphe et en rouge partout ailleurs dans le corps du document.
La couleur est bien héritée, mais elle est écrasée si on la déclare de nouveau dans un élement qui est plus proche (p est plus proche de a que le body).

Simple non ? Bien.


Maintenant, prenons le code CSS suivant :

CSS:

body p { color: red; }
p { color: green; }

Quelle sera la couleur du paragraphe ? Indice : ça n’est pas vert !
Ici, la première déclaration veut dire « tous les paragraphes dans le corps du document doivent être en rouge » et la seconde déclaration « tous les paragraphes doivent être en vert ».

Alors pourquoi le paragraphe est rouge et pas vert ?

Le paragraphe est rouge parce que le sélecteur « body p » est plus spécifique que le sélecteur « p » tout seul. Il est en effet plus précis de dire « tous les paragraphes dans le corps du document » que « tous les paragraphes ».
Or, pour le navigateur qui va afficher la page, la spécificité est prioritaire sur l’ordre des déclarations dans le code.


Sachant ceci, vous pouvez prédire quelle sera la couleur du paragraphe quand on lui applique ce code :

CSS:

body p { color: red; }
body p { color: blue; }
p { color: green; }
p { color: orange; }
p { color: fuchsia; }

Le paragraphe sera en bleu.
Les deux premiers sélecteurs sont plus spécifiques que les trois suivantes : elles sont donc prioritaires. La seconde est située après la première : c’est donc elle qui est retenue.

Spécificité de chaque sélecteur

Si on reprend ce CSS :

body p { color: red; }
p { color: green; }

Je vous ait dit que la première déclaration est plus spécifique. En fait, il y a deux sélecteurs d’éléments (body et p). La spécificité d’éléments est donc de 2. La seconde déclaration possède un seul sélecteur d’élément : sa spécificité d’éléments est 1 : la première est bien prioritaire.

Maintenant, donnons des classes à nos éléments :

<body>
Mon texte
<p class="in-blue">Mon paragraphe</p>
</body>

Et ajoutons le CSS suivant :

body p { color: red; }
p { color: green; }
p.in-blue { color: blue; }

Quelle sera la couleur du paragraphe ? Bleue, encore !

En CSS, le sélecteur de classe l’emporte sur les sélecteur d’éléments, même s’il y en a plusieurs ! Vous pouvez bien faire « html body div p span a { … } », si votre lien <a> possède une classe « foo », alors le code « .foo { … } » sera prioritaire.

C’est une question de hiérarchie : les classes sont plus fortes que les éléments, même si les éléments sont au nombre 315 et que la classe est toute seule : un sélecteur plus haut dans la hiérarchie sera toujours prioritaire pour imposer ses styles.

Comme les éléments et les classes, chaque type de sélecteur (ID, attributs…) possède sa place dans la hiérarchie.

Calcul de la spécificité

On a vu que la classe est prioritaire sur les éléments. Mais les ID sont prioritaires sur les classes. Et le CSS « inline » (attaché dans l’attribut style="…" d’un élément) est prioritaire sur les ID. Enfin, le flag « !important » est prioritaire sur tous les autres, quelque que soit sa place.

On a donc quelque chose comme ça :



Avec :

• Y : la présence du « !important »
• X : le CSS est Inline
• C : le sélecteur d’ID
• B : le sélecteur de classe (les pseudo-classe telles que « :nth-of-type() », ou « :hover » et d’attributs comme « [href="http://lehollandaisvolant.net/"] » vont également ici)
• A : le sélecteur d’élément (les sélecteurs de pseudo-éléments telles que « ::before » ou « ::first-line » vont ici)

Chaque lettre A, B, C, X, Y représente un nombre, où 0 est le défaut.

Voici quelques exemples :

* { color: green; }

Ceci donne un style vert à tous les éléments. Sa spécificité est cependant nulle : 0-0-0-0-0. Elle est supplantée par tous les autres sélecteurs, mais elle permet quand même d’être plus forte que les styles « par défaut » du navigateur (j’y reviendrai plus tard).

p { color: green; }

Pas de !important, ni de style en ligne, ni d’ID, ni de classe, mais un sélecteur d’élément : la spécificité est 0-0-0-0-1.

body p { color: red; }

Pas de !important, ni de style en ligne, ni d’ID, ni de classe, mais deux sélecteurs d’élément : la spécificité est 0-0-0-0-2.

p.in-blue { color: blue; }

Ici, on a une classe et un élément : la spécificité est 0-0-0-1-1.

body p.in-gray { color: gray; }

On a un élément (body), un autre élément (p) et une classe : la spécificité est 0-0-0-1-2.

body.home p.in-black { color: black; }

Ici, au total on deux éléments et deux classes : la spécificité est 0-0-0-2-2.

p.in-black.in-bold { color: black; font-weight: bold; }

Ici, au total on un élément et deux classes (sur le même élément, certes) : la spécificité est 0-0-0-2-1.

body#home p.in-black .link span { color: black; }

On a 3 éléments, 1 ID et deux classes : 0-0-1-3-2.

body#home table#data tbody tr td a .cool { color: black; }

6 éléments, deux ID et une classe : 0-0-2-1-6.

C’est assez simple non ?

Pour le « !important », il faut faire attention : ce dernier ne s’applique qu’à une seule propriété :

#home p {
    color: black;
    font-weight: bold;
}
p {
    color: red!important;
    font-weight: normal;
}

Ici, la couleur est mise en !important dans la seconde déclaration : la spécificité de la couleur est donc :

• 0-0-1-0-1 dans la première déclaration
• 1-0-0-0-1 dans la seconde

Mais la spécificité pour la graisse (texte en gras) est de :

• 0-0-1-0-1 dans la première déclaration
• 0-0-0-0-1 dans la seconde

Le paragraphe a donc une couleur rouge (grâce au !important) mais un texte en gras, à cause de spécificité du sélecteur dans la première déclaration.

Vous arrivez à suivre ?
Continuons.

p.foo a[href] {…}

La spécificité du sélecteur d’attribut est la même que celle des classes. On a donc l’équivalent de deux classes et deux éléments : 0-0-0-2-2.

p.foo > a{…}

p.foo a{…}

Ici, les liens a ont la même spécificité : les combinateurs comme >, ~, + n’ont pas de spécificité particulière et ne sont pas prioritaires.

Ce qui suit est plus tordu :
HTML:

<body id="home><p><a>coucou!</a></p></body>

#home p { color: red!important }  /* 1-0-1-0-1 */
a{ color: green }  /* 0-0-0-0-1 */

Le lien sera… Vert !
En effet, bien que la spécificité de la première déclaration l’emporte sur la seconde, la couleur de la première s’applique au paragraphe et non au lien !
L’héritage existe, mais la seconde déclaration s’applique directement aux liens : elle est donc plus forte que l’héritage. L’ordre n’aurait pas non plus importé et le lien aurait été vert même dans le cas suivant :

a{ color: green }
#home p { color: red }

Si on avait voulu forcer la couleur rouge des liens, il aurait fallu faire ça :

#home p a { color: red }  /* 0-0-1-0-1 */
a{ color: green }  /* 0-0-0-0-1 */

Ici alors les deux sélecteurs s’adressent aux liens directement, et c’est la spécificité qu’il faut regarder.

La même remarque compte pour les pseudo-éléments :

#home a::before{ color: green }  /* 0-0-1-0-2 */
#home p a { color: red }  /* 0-0-1-0-2 */

La spécificité de la couleur est de 0-0-1-0-2 dans les deux cas, mais la première s’applique directement au ::before du lien, qui est un pseudo-élement : il est donc prioritaire sur l’héritage ainsi que sur l’ordre de la déclaration.

En revanche, les pseudo-classes restent des classes (ce ne sont pas des éléments particuliers) et ont la même spécificités que les classes.
Du coup, le code suivant :

#top a { color: red; } /* 0-0-1-0-1 */
a:hover {color: green} /* 0-0-0-1-1 */

Donnera un lien rouge même quand on passera la souris dessus ! Les deux sélecteurs s’appliquent directement au lien (pas de problème d’héritage) mais le « #top » de la première déclaration est plus spécifique que le « :hover », qui ne compte que pour une classe.

Pour faire passer l’effet lors du passage de la souris, il faut utiliser une des méthodes suivantes :

#top a:hover {color: green} /* 0-0-1-1-1 */

a:hover {color: green!important} /* 1-0-0-1-1 */

Ou bien utiliser JavaScript, dans ce genre là :

<a onmouseover="this.style.color='green'">

(Les styles ajoutées en JS avec onmouseover/onblur équivalent à ajouter des styles directement sur l’élément, et la spécificité sera de 0-1-0-0-0, bien au dessus d’un sélecteur d’ID ou de classe.

Enfin, un petit mot sur la pseudo-classe « :not() » : elle n’ajoute pas de spécificité particulière, mais il faut quand même compter tout ce qui se trouve à l’intérieur :

#top a:not(.links) {color: green} /* 0-0-1-1-1 */

On se retrouve avec un ID, un élément ainsi qu’une classe : elle se trouve dans le :not(), il faut la compter comme une classe. Si le :not() contenait un ID, il faudrait le compter comme un ID.

Styles navigateur, auteur, utilisateur

On a vu tout ce qui concerne la spécificité des sélecteurs, mais il reste un dernier point à aborder.
Pour le moment, on a parlé du CSS dans une page web. Ce ne sont pourtant pas les seules styles qui sont utilisées sur une page.

Par exemple, quelle est le style d’un lien sur une page qui n’a aucun CSS ? Le lien est bleu dans pratiquement tous les navigateurs (il est même violet quand le lien est visité). Pareil, certains éléments sont stylisés de façon particulières : les formulaires ont des bordures et tous les éléments sont blancs.
Les styles ici sont produites par le navigateur lui-même : ce sont les styles navigateur.

Parallèlement, un utilisateur peut forcer l’application de styles : il veut par exemple mettre tous les liens en orange, et toute la page en Comic Sans MS. Les navigateurs disposent d’une feuille de style utilisateur prévu pour que l’utilisateur puisse ajouter ce qu’il veut. Ceci inclut les styles introduites par les modules complémentaires, comme les bloqueurs de publicité.

On se retrouve donc avec 3 sources de CSS :

• le style navigateur : appliqué par défaut si la page ne prévoit aucun code CSS ;
• le style utilisateur : inclus par l’utilisateur.
• le style auteur : inclus dans la page par l’auteur de la page ou du site ;

En général, les navigateurs appliquent les styles dans l’ordre ci-dessus. C’est donc l’auteur de la page qui a le dernier mot.

Il y a une exception cependant : le « !important » dans les styles utilisateur. Ce sélecteur, le plus puissant de tous, devient encore plus puissant quand il est utilisé dans les styles utilisateurs.
Les navigateurs laissent donc le dernier mot à l’utilisateur et c’est bien normal.

Pour Firefox, le fichier des styles utilisateurs se trouve dans le dossier chrome du profil de Firefox : ~/.mozilla/firefox/*.default/chrome/userContent.css (sous GNU/Linux).
Vous pouvez essayer dans ce fichier : ajoutez simplement ceci :
a { color: green!important; }

Enregistrez, puis redémarrez Firefox et vous verrez que tous les liens seront en vert, même si l’auteur a utilisé un sélecteur beaucoup plus puissant, avec à la fois !important et un ID, par exemple.

(Pour remettre les liens normalement, supprimez le ligne du fichier userContent.css, enregistrez, puis relancez Firefox.)

Les autres navigateurs doivent également proposer des styles utilisateurs quelque part.
Ceci est essentiel pour les personnes malvoyantes ou dyslexiques, qui ont besoin de polices de caractères spéciales, en grand et avec un contraste élevé.

Ressources

Comme j’ai dit en intro, il y a peu de documentation à propos de la spécificité en CSS, mais on trouve quand même ceci :

• Le poids des sélecteurs CSS
• Comprendre le poids des règles CSS - THE BLOWG (avec une jolie représentation avec des poissons :p)
• Calculating a selector's specificity (la doc officielle)
• Cascade CSS et priorité des sélecteurs

Pour conclure, je pense avoir fait le tour de la question, et j’espère que ça vous permettra de déboguer votre CSS un peu plus facilement.
Je dirais une nouvelle fois que ça me surprends de ne pas trouver plus de documentation à propos de la spécificité, alors que si on regarde d’autres choses, comme les nouveaux sélecteurs CSS3 ou les couleurs HTML, tout le monde en parle et les connaît.

Le conseil constitutionnel a validé la loi du renseignement, qui légalise une « NSA » made in France.
Allez, dites merci à Cazeneuve, Valls et tonton Hollande : grâce à ces compères, tous les français sont maintenant sur écoute h24 : les SMS, les appels, les emails, les comptes en banque, les achats en ligne et toute votre activité en ligne : tout est enregistré, logué et analysé.

Il faut bien ça pour nous protéger des terroristes.
Ouais… Et il faut bien un VPN aussi pour nous protéger du gouvernement.


Je rappelle que le terrorisme c’est faire usage de la peur pour faire passer des lois et des mesures liberticides et disproportionnées.
Quand on se rend compte qu’en plus, aux USA la police tue plus de citoyens américains que ne le fait la guerre en Irak (src) et qu’en France en 2014 au moins 10 personnes sont tuées par la police (src — environ une centaine depuis 2005), on se demande qui sont les vrai terroristes.


Bref, je fais court. Korben en écrit plus ici si vous voulez : Big Cazeneuve est maintenant une réalité, et la Quadrature aussi.

Aujourd’hui, Google me notifie d’une hausse énorme des erreurs 404 (introuvable) sur 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 :

• http://lehollandaisvolant.net/tuto/index.php
• http://www.lehollandaisvolant.net/tuto/index.php
• http://lehollandaisvolant.net/tuto//index.php
• http://lehollandaisvolant.net/tuto/
• http://lehollandaisvolant.net////tuto////index.php
• http://www.lehollandaisvolant.net////tuto////index.php
• http://lehollandaisvolant.net/tuto//index.php/ (en émettant des erreurs)

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 :

• http://lehollandaisvolant.net/tuto/

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.