Exemple de rapide audit de site: pro.alexandrebaumann.com

En finissant mon guide pour réaliser un audit technique, je me suis dit qu’il serait intéressant que je l’applique à mon site me présentant professionnellement: pro.alexandrebaumann.com. En effet, il s’agissait de mon premier projet Nuxt.js (version statique ou avec rendu côté serveur de Vue.js) et on ne sait jamais qu’est-ce qui est géré automatiquement ou non.

Donc je fais mon crawl (avec Screaming Frog, vu que le site a très peu de pages), et là …. une vision d’horreur:

Vision d’horreur

Trois problèmes me sautent aux yeux:

  • Il n’y a pas de réécriture d’url, ce qui fait qu’on a des écrites avec et sans www qui se cotoient.
  • Il y a des redirections alors qu’il ne devrait pas y en avoir. Sans doute des url écrites sans /.
  • Il n’y a pas la plupart de mes projets de portfolio.

Ce sont des problèmes gravissimes. Pourtant, réparer les deux premiers me prendra quelques minutes. Le troisième demande de reprendre un composant et me prendra donc une petite heure.

La réécriture d’url

C’est le plus rapide, il suffit de créer un fichier .htaccess dont le contenu est :

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]
RewriteRule ^(.*)$ https://%1/$1 [R=301,L]

Ainsi,

Réparer les liens

Dans mes menus, mes liens étaient sans / à la fin. Ex:

<nuxt-link to="/contact" :class="{ active: $route.path === '/contact' }">

Or, le serveur mettait des / à la fin et redirigerait vers la version avec /. La résolution se fait en quelques secondes: il suffit de rajouter un / à la fin.

Dans la même logique, j’ai remarqué que mes url étaient notées « non indexables » par Screaming Frog. En fait, les liens d’url canoniques n’avaient pas non plus de / à la fin. Ce problème a été plus difficile à résoudre.

En effet, les métadonnées, dont, l’url canonique sont définies à partie d’un objet json. Exemple:

{
   "url": "/mentions-legales",
   "title": "Mention légales du site d'un développeur web et consultant SEO",
   "description": "Développeur et consultant SEO, je vous aide à améliorer votre visibilité sur le web."
},

On pourrait se dire qu’il suffirait de mettre un / à la fin de la valeur d' »url ». Cela répare le problème en local. Néanmoins, dans la version statique en ligne, cela aboutit à ce que l’url de la page ne soit plus identifée comme correspondant à celle de l’objet json. En effet, l’url de la page, définie par « this.$route.path », semble renvoyer une url sans / … sauf pour la page d’accueil … Il semblerait que la génération statique de Nuxt 2 mette un / à la fin des url du routeur.

Il faut donc, à la place, que j’ajoute un / à tous les composants où je renseigne une url interne (ex: le bouton contact en page d’accueil) …

Modifier la page portfolio

Le problème de la non identification de mes projets vient de la page portfolio et, surtout, de mon composant « Card », qui présentait le portfolio dans des cartes. Cliquer sur ces dernières ouvrait une fenêtre (« modale ») détaillant un peu plus leur contenu et permettant, d’ensuite accéder à la page complète.

Haut du portfolio
Modale ouverte

L’idée est de permettre à l’utilisateur de se faire une meilleure idée du projet, tout en restant sur la même page.

Néanmoins, si cette logique est pertinente pour l’utilisateur en page d’accueil, pour qu’il n’ait pas le sentiment d’être perdu dans une page de second niveau sans être passé par sa page parente, Portfolio, elle se justifie beaucoup moins pour l’utilisateur sur la page Portfolio.

Cela ouvre une autre question: est-ce qu’avoir deux éléments identiques qui se comportent différemment est une bonne chose ?

Injection des cartes en page d’accueil

La réponse est évidemment non. Devrais-je retirer ma modale ? …

Autres

J’ai identifié quelques autres problèmes.

  • Le lien « <a href= »www.discoverthegreentech.com »>Discoverthegreentech</a> » était compris comme une adresse relative :https://pro.alexandrebaumann.com/www.discoverthegreentech.com. Pour résoudre la problème, il fallait préciser le protocole: <a href= »https://www.discoverthegreentech.com »>.

Ensuite, il y a évidemment les en-têtes de sécurité (HSTS, Content-Security-Policy, etc.) qu’il faudrait rajouter. Ayant un serveur Apache, il me suffit d’ajouter ceci au .htaccess:

Header set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Header set Content-Security-Policy "script-src 'self'"
Header set X-Content-Type-Options "nosniff"
Header set X-Frame-Options "DENY"
Header set Referrer-Policy "no-referrer"

Conclusion

Ainsi, vous voyez que la plupart des rectifications absolument cruciales peuvent être faites en quelques minutes. En outre, on voit aussi que les différents frameworks de développements peuvent avoir des spécificités difficiles à anticiper et pouvant causer de gros problèmes si elles sont ignorées.