En plus des traditionnels « favicon.png » ou « robots.txt », qu’on doit mettre à la racine de son site, il y a une ribambelle d’autres fichiers qu’il est possible (parfois recommandés, même) d’avoir sur son site.

En voici une petite liste.

Commençons par les fichiers très connus et très utilisés. Vous trouverez beaucoup de ressources à leur propos.

La favicon

Pour que votre site affiche une icône sur toutes les pages, le minimum est de mettre un fichier favicon à la racine de votre site :

/favicon.ico

Le format est spécifique, mais généralement, utiliser un fichier BMP renommé en .ICO fonctionne très bien. La favicon est traditionnellement carrée et de taille 16x16, 32x32 ou 48x48.
Une seule favicon à la racine de votre site suffit pour toutes les pages de votre site, quelque soit leur arborescence (sous-dossiers, etc.). Les navigateurs viendront automatiquement la chercher.

Vous avez la possibilité (en plus du fichier favicon.ico à la racine du site) de spécifier une autre icône dans le code source HTML, grâce à une balise <meta>. Dans ce cas, le format de fichier peut être PNG, SVG ou ce que vous voulez.

De plus, vous pouvez aussi pointer le chemin vers un autre chemin, comme un dossier spécial pour toutes les autres icônes.

Les autres icônes

Chrome, Safari, Edge, Windows 10, Android ou Mac OS peuvent parfois avoir besoin d’une icône spécifique.

Voici quelques exemples :

• Android utilise une icône dédiée quand on met un lien vers un site sur l’écran principal.
• Idem pour iOS.
• Edge utilise une icône spécifique pour quand le site est épinglé.
• Safari sur Mac OS utilise une icône spéciale dans les onglets épinglés aussi.
• Windows 10 a aussi son format d’image pour quand votre site apparaît dans le menu démarrer.

Il y en a tout un tas, et à chaque fois les formats et les dimensions varient (il n’y a pas encore de standard bien défini pour ça).

Chrome et Windows 10 utilisent aussi des fichiers .manifest en XML pour avoir d’autres informations sur le raccourcis que vous cherchez à faire : nom du raccourcis, couleur principale, quel application doit l’ouvrir, etc.

Créer toutes es icônes à la main est fastidieux. Aussi, le mieux est d’utiliser le site Real Favicon Generator pour cela. Vous lui donnez une seule icône (en PNG ou SVG) et il va vous donner un ZIP avec tous les fichiers. C’est très pratique.

robots.txt

Pour les moteurs de recherche, il faut spécifier un fichier destinés aux ordinateurs robots qui analyse les pages web du monde entier. Ce fichier permet de dire aux moteurs de recherche si oui ou non vous voulez apparaître dans les résultats de recherche. Et si oui, sous quels conditions, quels fichiers, etc.

C’est un petit fichier texte à placer à la racine du site également :

/robots.txt

La syntaxe est décrite ici : robots-txt.com.

Sachez seulement que même si les moteurs de recherche prennent généralement en compte ce fichier, rien ne les y oblige. Je vous conseille donc, si vous ne voulez absolument pas que vos fichiers ne se retrouvent en ligne, de ne pas les publier ou bien d’en protéger l’accès. C’est à vous, le détenteur d’un site, de faire en sorte que vos fichiers soient protégés.

/humans.txt

Si robots.txt est destiné aux robots, le fichier humans.txt est destiné aux… humains !
Rares sont les sites qui le mettent, mais il permet de donner un peu d’information supplémentaire sur le site ou l’auteur.

Là aussi, c’est à la racine qu’il faut le mettre :

/humans.txt

Il n’y a pas vraiment de syntaxe standard : le fichier humans.txt est fait pour des humains et par des humains.

Une idée de syntaxe est proposé sur le site humanstxt.org, mais vous pouvez y mettre tout ce que vous jugerez utile à transmettre aux visiteurs curieux sur votre site.

Mes site disposent de ce fichier aussi. N’hésitez pas à y jeter un œil.

Un sitemap

Ce fichier est une carte de votre site : il contient les différents liens des pages de votre site. À nouveau, il est à la racine de votre site site :

/sitemap.xml

L’idée est là aussi que les moteurs de recherche découvrent ce fichier et voient toutes les pages de votre site d’un seul coup.

Google ou Bing proposent des outils pour leur soumettre vos sitemap (DDG et Qwant n’ont pas d’outils dédiés) : ça leur permet d’enregistrer votre site dans leurs indexes et de savoir par où commencer.

La syntaxe est spécifique et bien décrite sur Wikipedia.

Un fichier manifeste

/manifest.xml

Il n’est pas obligé de le mettre à la racine du site, car il est lié dans une balise méta dans la page, vous pouvez donc le mettre où vous voulez tant que vous liez son chemin dans la balise méta.

Il s’agit d’un fichier qui contient quelques informations supplémentaires pour le navigateur, en particulier mobile : quand vous faites un raccourcis sur votre bureau Android, ce fichier peut être appelé. Par exemple, il permet d’afficher le site avec ou sans la barre de tâches Android, ou même avec ou sans les boutons du navigateur, avec ou sans une icône spécifique, faisant apparaître votre page web comme une application native.

C’est le début de l’intégration d’une application-web progressive (PWA). Ici l’app aura toujours besoin d’une connexion internet pour fonctionner, mais l’affichage se fera en (quasi-)plein-écran sur mobile, sans la barre d’adresse et l’interface du navigateur.

Voir là : Progressive Web App (PWA) — Le fichier Web App Manifest

Un fichier openSearch.xml

Idem : vous pouvez le mettre où vous voulez tant que vous liez son chemin dans la balise méta.

Vous avez déjà vu un site qui propose d’installer un moteur de recherche ? Et ben vous pouvez faire ça également. Notez que cette implémentation est passive : c’est le navigateur qui proposera d’installer le moteur de recherche lorsqu’il le détecte sur votre site, un peu comme quand un site propose un flux RSS et que votre navigateur vous en propose l’abonnement via l’affichage d’une petite icône.

Cela peut être un petit plus pour votre site et c’est très simple à mettre en plus : une simple balise meta et un tout petit fichier XML statique à la base du site. C’est tout. Cela suffit pour que votre site propose un moteur de recherche :

/opensearch.xml

Les explications se trouvent sur Alsacréations. Essayez de regarder dans les options de mon site, par exemple :).

À noter que ceci ne fonctionne que si votre site est doté d’une fonction de recherche (ce que font les moteurs de blog, généralement). On pourrait l’adapter pour qu’il renvoie sur un moteur de recherche existant comme Google ou DDG, avec le paramètre « site: » dans la requête.

Une page security.txt

Il s’agit d’une page indiquant à quelqu’un qui découvre une faille dans votre site comment vous en faire part.
En pratique, il faut utiliser le répertoire .well-known et y mettre le fichier :

/.well-known/security.txt

La syntaxe est décrite sur le site dédié de l’initiative : securitytxt.org.

/ads.txt

Pour les sites qui diffusent de la publicité, il peut être nécessaire de spécifier quels annonceurs sont vos partenaires. Il y a un fichier pour ça : /ads.txt. Il s’agit simplement de la liste des annonceurs présents sur votre site et ce qu’ils y font (vente directe, annonces, etc.). Le standard a été établi pour des questions de sécurité et de lutte contre la fraude dans le domaine de la publicité en ligne.

En soit, le visiteur lambda s’en fiche, mais les annonceurs disposent d’outils pour analyser le fichier /ads.txt :

/ads.txt

La syntaxe et le projet sont décrites là : IAB Tech Labads.txt Specification Version 1.0.2.

Pour ma part, mes sites ne diffusent pas de publicité via des annonceurs. Seuls quelques liens sur mes blogs sont effectivement des liens affiliés (Amazon, ou eBay, ainsi que le lien vers mon hébergeur, dans le pied de page), mais cela reste de simples liens qui n’ont aucune possibilité d’afficher quoi que ce soit ici.

Mon fichier /ads.txt est donc vide.

Des fichiers que je recommande

Ces fichiers là ne sont pas forcément standard, néanmoins je conseille de les avoir.

Votre clé Publique GPG

Pour ceux qui utilisent GPG pour chiffrer les e-mails, vous devriez mettre votre clé Publique GPG sur votre site, en particulier si vous utilisez une adresse e-mail sur votre propre domaine.
Je propose l’un des deux formats suivants :

/pubkey.txt

/pubkey.asc

Je propose de le mettre à la racine du site car c’est là qu’un utilisateur peut commencer à chercher et surtout de le mettre dans un format texte, en ascii.

Vous pouvez également utiliser le fichier humans.txt pour y spécifier votre fichier GPG (c’est ce que je fais personnellement).

Des pages courantes

Selon moi, certaines pages devraient se retrouver sur tous les sites personnels : une page « à propos » par exemple, ou une page de contact.
Dans ce cas, vous pouvez configurer votre serveur pour qu’il affiche des pages sur les chemins /contact ou /about

Les fichiers d’erreurs

Quand vos visiteurs tentent d’accéder à une page qui n’existe pas, le site renvoie une erreur : 404 Not Found. Si la page demandée produit une erreur au niveau du serveur, c’est l’erreur 500 Internal Server Error
Il y a toute une liste d’erreurs comme ça. Les serveurs sont configurés pour afficher une page relativement épurée en cas d’erreurs, mais il est possible de la personnaliser.

Ainsi, si un visiteur cherche un fichier inexistant, vous pouvez afficher une page à vous avec un message personnalisé et un lien de retour vers la page d’accueil.

Rien n’est obligatoire ici, mais c’est toujours sympa d’avoir un site personnalisé jusqu’au bout. Mon site, par exemple, dispose d’une page personnalisée pour l’erreur 404.

Il y a juste une chose à avoir en tête : en cas d’erreur, le serveur ne fonctionne plus normalement. Il faut donc faire une page HTML simple et tout mettre dans cette page (y compris les images, les scripts…), si possible en Base64 : comme ça, le serveur (en erreur) n’a que le fichier d’erreur à envoyer et pas de requêtes supplémentaire, qui pourraient produire des erreurs supplémentaires et possiblement tout planter (voir ici pour convertir en Base64).

Pour conclure

En fait, l’idée derrière ce genre de petits fichiers est d’être trouvables facilement, d’avoir un chemin d’accès identique sur tous les sites, et de contenir des informations utiles.

Avoir un nom identique sur tous les sites, par exemple « /humans.txt », permet à quelqu’un de commencer à chercher même s’il ne sait pas que le fichier est là. Il cherche, mais si le fichier est là, il trouve, c’est tout bénéfique. Un peu comme une page « à propos », ou une page de contact.