Guide complet d’audit de site Web : SEO, lien en bio, portfolio, blogue, performance et plus

1. SEO technique : les moteurs de recherche peuvent-ils atteindre vos pages?

Commencez par les bases qu’un robot d’exploration voit avant de lire un seul mot.

• Une seule adresse par page. http://, https://, www. et le domaine nu devraient tous mener à une seule version, et les pages devraient utiliser (ou non) la barre oblique finale de façon constante.
• Liens canoniques. Chaque page devrait avoir un <link rel="canonical"> qui pointe vers son adresse privilégiée. Google le traite comme un indice fort de l’URL à afficher.
• Codes d’état. Les vraies pages renvoient 200, les pages déplacées 301, les pages manquantes un vrai 404 (pas une page « introuvable » qui renvoie 200). Évitez les chaînes de redirections.
• Une vraie page 404 qui aide les gens à retrouver leur chemin.
• Aucun `noindex` accidentel sur les pages que vous voulez voir dans les résultats.

Comment vérifier : lancez curl -I https://votresite.com/une-page/ pour voir les codes d’état et les redirections, affichez le code source pour trouver la balise canonique, et utilisez l’outil d’inspection d’URL de Google Search Console.

Sur mon propre site : aucun lien canonique nulle part, www.victorxai.com servait une copie complète du site au lieu de rediriger, et les pages manquantes affichaient la page d’erreur générique de mon hébergeur.

2. Contenu et métadonnées : chaque page se décrit-elle?

• Un titre unique sur chaque page, d’environ 50 à 60 caractères, avec les mots les plus importants au début. Google tronque les titres plus longs.
• Une méta-description unique, d’environ 150 à 160 caractères, qui dit aux gens ce qu’ils trouveront. Google la réécrit parfois, mais une bonne description est souvent reprise telle quelle.
• Un seul `<h1>` par page, qui correspond au sujet de la page, puis des <h2>/<h3> dans un ordre logique.
• Aperçus de partage : balises Open Graph et Twitter/X avec un titre, une description et une image de 1200×630. Utilisez du JPEG ou du PNG : certaines plateformes n’affichent pas toujours le WebP ou le SVG.

Comment vérifier : affichez le code source, utilisez une extension SEO pour navigateur, ou collez votre lien dans une messagerie pour voir l’aperçu.

Sur mon propre site : six pages partageaient exactement la même description, trois titres d’articles dépassaient 80 caractères, et le <h1> de chaque page était mon nom dans la barre latérale, pas le titre de la page. Les images de couverture de mon blogue étaient en WebP et en SVG, donc certaines plateformes n’affichaient aucune image d’aperçu.

3. Indexation et plan de site : dites-vous aux moteurs de recherche ce qui existe?

• robots.txt à la racine, qui autorise ce qui doit être exploré et pointe vers votre plan de site. robots.txt contrôle l’*exploration*, pas l’indexation : pour garder une page hors des résultats, utilisez plutôt une balise noindex.
• Un plan de site XML qui liste chaque page à indexer, avec seulement les adresses canoniques. Générez-le à partir de votre contenu pour que les nouveaux articles s’ajoutent automatiquement. Google utilise lastmod quand il est exact et ignore priority et changefreq.
• Pages utilitaires exclues : les pages de remerciement, les aperçus et les zones d’administration devraient être en noindex.
• Search Console et Bing Webmaster Tools : ajoutez votre site et soumettez le plan de site. C’est le seul moyen de voir ce qui est réellement indexé.

Sur mon propre site : /robots.txt et /sitemap.xml renvoyaient tous deux un 404, et la page de remerciement de mon formulaire pouvait être indexée.

4. Données structurées : aider les moteurs de recherche à comprendre qui et quoi

Les données structurées (JSON-LD) décrivent votre contenu dans un format que les machines lisent directement.

• Person (ou Organization) sur votre page d’accueil ou À propos : votre nom, les noms sous lesquels on vous connaît, votre titre et vos profils sociaux.
• BlogPosting sur chaque article : titre, date, image et auteur.
• BreadcrumbList sur les pages plus profondes : Accueil › Blogue › Article.

Ne décrivez que ce qui est visible sur la page. N’ajoutez jamais de fausses notes, de faux avis ou de fausses réalisations. Cela enfreint les consignes de Google et peut faire ignorer vos données structurées.

Comment vérifier : le test des résultats enrichis de Google et le Schema Markup Validator.

Sur mon propre site : aucune. Je les utilise maintenant pour relier mon nom complet, Okikioluwa Victor Olarewaju, à « Victor Okiki » et à VictorXAI, afin que les moteurs de recherche sachent qu’il s’agit de la même personne.

5. Performance et Core Web Vitals : le site charge-t-il vite pour de vraies personnes?

Les Core Web Vitals de Google, mesurés au 75e centile des visites réelles :

• LCP (Largest Contentful Paint) : 2,5 secondes ou moins.
• INP (Interaction to Next Paint) : 200 millisecondes ou moins.
• CLS (Cumulative Layout Shift) : 0,1 ou moins.

À vérifier :

• des images dimensionnées selon leur affichage, dans des formats modernes, chargées en différé sous la ligne de flottaison, avec width et height définis;
• l’image ou le titre principal au-dessus de la ligne de flottaison qui se charge en premier;
• le JavaScript inutile, les scripts tiers et les bibliothèques lourdes;
• un chargement efficace des polices;
• la compression et les en-têtes de cache.

Comment vérifier : PageSpeed Insights montre à la fois les résultats de labo (Lighthouse) et les données réelles des utilisateurs de Chrome, si votre site a assez de trafic. Prenez les scores de labo comme un guide et les données réelles comme la vérité.

Sur mon propre site : les icônes des technologies de ma page d’accueil faisaient jusqu’à 2560 pixels de large pour des emplacements de 40 pixels, soit environ 750 Ko téléchargés pour rien. Les ramener à 120 pixels a réduit chacune à environ 5 à 12 Ko.

6. L’essentiel du lien en bio : votre carrefour doit être rapide et fiable

Une page de liens en bio est souvent la première chose que les gens voient depuis vos profils sociaux.

• Une identité claire : votre photo, votre nom et ce que vous faites, en un coup d’œil.
• Les liens les plus importants en premier, regroupés logiquement (en vedette, entreprises, écrits, contact).
• Chaque lien testé. Des liens morts sur une page carrefour font négligé. Masquez ce qui est hors service.
• Rapide et pensée d’abord pour le mobile, avec de grandes zones tactiles et sans animations lourdes.
• Un bel aperçu de partage, parce que le lien lui-même est partagé.
• Une seule adresse officielle. Si la même page existe sur deux domaines, définissez comme canonique celle que vous promouvez.

Sur mon propre site : ma page de liens existait à la fois sur victorxai.com/links/ et sur builtbyvic.com, ce que les moteurs de recherche voient comme du contenu en double. builtbyvic.com est maintenant l’adresse canonique. Le lien vers le site d’un partenaire était aussi hors service; je l’ai signalé.

7. Portfolio et blogue : rendre votre travail trouvable et crédible

Les pages de projet devraient expliquer le problème, votre rôle, l’approche, les technologies et des résultats vérifiés. Indiquez clairement ce qui est en ligne, en cours ou confidentiel, et mentionnez vos collaborateurs.

Les articles de blogue devraient avoir :

• des URL permanentes et lisibles;
• une date et un auteur visibles;
• des blocs de code lisibles et des images avec texte de remplacement;
• des liens vers des articles et des projets connexes;
• un fil RSS pour les lecteurs qui suivent les blogues de cette façon;
• un seul endroit pour définir les détails SEO, pour que publier n’oblige pas à modifier les métadonnées dans plusieurs fichiers.

Sur mon propre site : les articles n’avaient aucun auteur visible, il n’y avait pas de fil RSS, et les détails SEO étaient définis différemment sur chaque page. Je les ai regroupés dans un utilitaire commun, pour que chaque nouvel article reçoive automatiquement son lien canonique, son aperçu de partage et ses données structurées.

8. Sécurité et vie privée : fermer les portes que vous ne saviez pas ouvertes

Même un site statique a une surface d’attaque.

• Aucun secret dans le front-end ni dans git. Vérifiez la version compilée et l’historique, pas seulement les fichiers actuels.
• En-têtes de sécurité : HSTS, X-Content-Type-Options: nosniff, une Referrer-Policy, une protection contre l’intégration (X-Frame-Options ou frame-ancestors de la CSP) et une Permissions-Policy.
• Listage des répertoires désactivé. Visitez /images/ ou /assets/ sur votre propre site.
• Aucune source map, page de débogage ni route de test exposée en production.
• Protection anti-pourriel des formulaires, comme un champ piège, une limite de débit ou un CAPTCHA au besoin.
• Vie privée : une politique de confidentialité qui correspond à ce que vous recueillez, et le consentement quand il est requis.

Comment vérifier : securityheaders.com, curl -I, et en parcourant vos propres dossiers.

Sur mon propre site : c’était le constat le plus grave. Le listage des répertoires était activé : n’importe qui pouvait parcourir mes dossiers /images/, /cv/ et /_next/ comme des listes de fichiers. Il n’y avait aucun en-tête de sécurité, et mes formulaires n’avaient aucun piège à pourriel.

9. Accessibilité : tout le monde peut-il l’utiliser?

Visez les WCAG 2.2, niveau AA :

• Clavier : chaque contrôle est accessible avec Tab et affiche un style de focus visible.
• Noms : chaque bouton, lien et champ de formulaire a un nom clair (texte visible ou aria-label).
• Contraste : 4,5:1 pour le texte normal et 3:1 pour le grand texte et les contrôles.
• Zones tactiles : au moins 24×24 pixels.
• Texte de remplacement : décrivez les images significatives et utilisez alt="" pour les images décoratives.
• Formulaires : des étiquettes et des messages d’erreur clairs.
• Mobile : aucun défilement horizontal, peu importe la largeur.

Sur mon propre site : les icônes sociales de ma barre latérale étaient des zones tactiles de 18 pixels; elles en font maintenant 32. Le titre de ma page de liens en bio était dessiné comme une forme sans texte lisible; j’ai donc ajouté du texte pour les lecteurs d’écran et les moteurs de recherche.

10. Tests et maintenabilité : le site restera-t-il fonctionnel?

• Vérification des types, analyse du code et compilation de production sans erreur.
• Vérification des liens brisés internes et externes.
• Console du navigateur sans erreur sur chaque page.
• Formulaires testés de bout en bout, y compris les cas d’échec.
• Dépendances à jour, sans rien d’inutilisé.
• Travail versionné dans le contrôle de version, pour pouvoir revenir en arrière.

Sur mon propre site : les vérifications et la compilation passaient, et il n’y avait aucun lien interne brisé. Mais des semaines de travail n’étaient toujours pas versionnées dans git, un risque de perte à corriger avant que quoi que ce soit d’autre tourne mal.

Faire faire cet audit par l’IA

Un assistant de code IA peut faire la majeure partie de l’inspection. Demandez-lui de regarder avant de changer quoi que ce soit, d’appuyer chaque constat sur des preuves et d’être honnête sur ce qu’il n’a pas pu vérifier, comme la vitesse réelle ou ce que Google a indexé.

Copiez cette requête dans Claude Code, Cursor ou un autre assistant de code IA ouvert dans votre projet.

Agis comme ingénieur Web principal, spécialiste du SEO technique, réviseur de sécurité et auditeur d’accessibilité. Fais l’audit du code de ce site. Inspecte avant de changer quoi que ce soit.

À propos de mon site (à remplir) :
- Type de site (portfolio, blogue, lien en bio, site d’entreprise, boutique) :
- Domaine(s) :
- Hébergement et façon de déployer :
- Tout ce qui est privé et doit rester hors des moteurs de recherche :

1. Explore d’abord : détermine le vrai framework, le routage, le rendu, la compilation et le déploiement à partir du dépôt. Lance la vérification des types, l’analyse du code et la compilation de production s’il y a lieu. Ne présume pas de la pile.
2. SEO technique : un seul nom d’hôte et protocole, barre oblique finale constante, liens canoniques, codes d’état et redirections, vraie page 404, noindex accidentels.
3. Contenu et métadonnées : titres uniques (environ 60 caractères) et descriptions (environ 155), un seul h1 par page, ordre des titres, balises Open Graph et Twitter avec une image JPEG/PNG de 1200x630.
4. Indexation : robots.txt, plan de site XML généré à partir du contenu avec seulement les URL canoniques, noindex sur les pages utilitaires, URL en double sur plusieurs domaines.
5. Données structurées : JSON-LD Person/Organization, BlogPosting et BreadcrumbList qui correspond au contenu visible. N’invente jamais d’avis, de notes ni de faits.
6. Performance : taille des images par rapport à leur affichage, formats, chargement différé, width/height, scripts bloquants et tiers, taille des paquets, polices, cache et compression. Sépare les résultats de labo des données réelles des utilisateurs; n’invente pas de scores.
7. Lien en bio (s’il y a lieu) : identité claire, ordre et regroupement des liens, chaque lien fonctionnel, aperçu de partage, une seule adresse canonique.
8. Portfolio et blogue : les pages de projet expliquent le problème, le rôle, l’approche et les résultats; les articles ont une date, un auteur, des liens connexes, un fil RSS, et le SEO défini à un seul endroit.
9. Sécurité et vie privée : secrets exposés (masque les valeurs dans ton rapport), en-têtes de sécurité, listage des répertoires, source maps ou routes de débogage en production, protection anti-pourriel des formulaires, mentions de confidentialité.
10. Accessibilité : clavier et focus, noms accessibles, contraste, zones tactiles d’au moins 24 px, texte de remplacement, étiquettes de formulaire, aucun défilement horizontal.
11. Tests et maintenance : liens brisés, erreurs de console, parcours des formulaires, santé des dépendances, travail non versionné.

Livre, dans l’ordre :
A. Un résumé court et honnête de l’état du site et de ses plus grands risques.
B. Un tableau des constats : ID, gravité (Critique/Élevée/Moyenne/Faible/Info), catégorie, fichier et ligne, preuve, impact, correction, effort, comment vérifier.
C. Un plan priorisé : bloquants de sécurité, bloquants d’indexation, SEO à fort impact, performance et accessibilité, puis croissance du contenu.
D. Les fichiers exacts à modifier et pourquoi.

Règles :
- Ne signale que ce que tu as confirmé dans le code ou en exécutant quelque chose. Liste le reste comme « à vérifier ».
- N’affirme pas que le site se classe bien, est indexé, est sécuritaire ou réussit les Core Web Vitals sans preuve.
- Préserve le design et les fonctions qui marchent, et évite les réécritures et les nouvelles dépendances quand une petite correction suffit.

Après le rapport, attends mon approbation, puis corrige les points les plus prioritaires par petits lots et relance les vérifications.

Après les corrections, déployez, puis testez le site en ligne : en-têtes, redirections, page 404, plan de site, et vos pages dans le test des résultats enrichis de Google et PageSpeed Insights. Soumettez ensuite votre plan de site dans Search Console et laissez passer quelques semaines.