Blog On-site SEO Technique

Guide détaillé de l’audit technique d’un site web

Alexis Rylko

Alexis Rylko

Consultant SEO & Directeur technique SEO chez iProspect France

Ça fait longtemps que je n’ai pas écrit dans le blog, d’un côté pour des raisons personnelles, car je souhaitais consacrer plus de temps à ma femme et à mes amis, d’un autre à cause du travail qui en cette période a été particulièrement intense.

Et ça fait encore plus longtemps que j’avais projeté de rédiger un grand article complet (ou presque) sur un sujet lié au référencement de sites. Aujourd’hui il est enfin terminé et j’ai le plaisir de vous présenter mon Guide détaillé de l’audit technique d’un site web. Je vous remercie d’avance pour vos commentaires et remarques, en espérant que cet article vous sera utile.

Aide-mémoire de l’audit technique d’un site

1. Nom de domaine

  • 1.1. Prolongation
  • 1.2. Age et histoire du nom de domaine

2. Serveur

  • 2.1. Temps de réponse du serveur
  • 2.2. Traitement du statut 404
  • 2.3. Redirection 301 depuis les miroirs

3. Sitemap

  • 3.1. Présence de la carte du site au format XML
  • 3.2. Indication de la sitemap XML dans Google Webmasters Tools
  • 3.3. Présence de la carte du site au format HTML

4. Robots.txt

  • 4.1. Présence du fichier robots.txt
  • 4.2. Interdiction d’indexer des pages inutiles
  • 4.3. Indication de la sitemap XML
  • 4.4. Indication du host (miroir principal)

5. Région ciblée

6. Systèmes de statistiques

7. Hyperliens

  • 7.1. Liens cassés
  • 7.2. Liens sortants
  • 7.3. Correction du code des liens

8. Images

  • 8.1. Taille des images
  • 8.2. Images uniques et dupliquées
  • 8.3. Attributs alt et title
  • 8.4. Logo cliquable menant à la page d’accueil
  • 8.5. Présence d’un favicon

9. URL

  • 9.1. Pages statiques/dynamiques
  • 9.2. Sessions
  • 9.3. SEO friendly URL

10. Qualité du code source

  • 11.1. Encodage des caractères
  • 11.2. CSS dans le code source
  • 11.3. Javascript dans le code source
  • 11.4. Validité chez W3 (HTML & CSS)
  • 11.5. Balises META remplies et correctes

11. Contenu (du point de vue technique)

  • 11.1. Pages dupliquées
  • 11.2. Contenu unique et répété au sein du site
  • 11.3. Balises <title> différentes
  • 11.4. Fenêtres pop-up
  • 11.5. Durée de chargement des pages
  • 11.6. Correction de l’en-tête <H1>

12. Indexation

  • 12.1. Permission d’indexer la page dans le robots.txt
  • 12.2. Permission d’indexer la page dans la balise META robots
  • 12.3. Nombre de pages dans l’index principal et supplémentaire de Google
  • 12.4. Correspondance de la page réelle et celle dans le cache de Google
  • 12.5. Structure du site et profondeur des pages importantes

Audit technique detaillé

1. Nom de domaine

1.1. Prolongation

Afin de ne pas avoir d’ennuis à cause de l’oubli de payer le nom de domaine, il vaut mieux aller voir la date de son expiration sur Whois d’avance.

Les données présentées par Whois du nom de domaine Twitter.com:

Exemple des données présentées par Whois

1.2. Age et histoire du nom de domaine

Souvent pour évaluer l’état d’un site web, il est utile de jeter un œil sur l’histoire de son nom de domaine. Pour y arriver, on recourt à un outil très pratique qu’est le Web Archive ou Internet Archive Wayback Machine. Le Web Archive crawle constamment la Toile et sauvegarde les copies des pages vues. Une fois que le nom de domaine souhaité est saisi dans le champ du service, il suffit de patienter un peu pour voir quelques instants après l’année et le mois de sa première indexation, et ensuite «la vie», si vous voulez, du site. S’il existe des années vides dans le calendrier, alors pour des raisons quelconques le site n’a pas été disponible (site abandonné, nom domaine pas prolongé et repris ensuite par quelqu’un d’autre etc.)

La page d’accueil de l’Internet Archive Wayback Machine:

NB. Whois VS Web Archive

Quand il s’agit d’apprendre l’histoire d’un site web, on se souvient d’habitude à deux services: Whois et Web Archive. Le Whois est très utile pour apprendre la date de la création et de l’expiration du nom de domaine donné, certains renseignements de son propriétaire (s’ils ne sont pas protégés) et son hébérgeur tandis que le Web Archive permet d’apprendre la date approximative de la première indexation, ce qui nous est plus intéressant en tant que référenceurs, car c’est la où débute son histoire pour les moteurs de recherche. Moi personnellement, je suis habitué à considérer comme l’âge du site celui qui est dans le Web Archive. Et de même, la possibilité de suivre l’histoire du site le rend irremplaçable.

2. Serveur

2.1. Temps de réponse du serveur

Du côté technique, quand vous visitez un site web, il se passe un échange de salutations entre votre ordinateur et le serveur hébergeant le site. L’ordinateur envoie au serveur l’adresse de la page du site, et celui-ci, en réponse, lui envoie un code (si la page en question y présente). Par exemple, si le code est «200 OK», le serveur approuve la présence de la page et débute son chargement. Ou bien, sûrement, vous avez rencontré le code «404 Not Found» – dans ce cas-là, le serveur n’a pas trouvé la page demandée et fait une redirection à la page 404.php ou 404.html.

Ainsi,  le temps de réponse du serveur est le temps depensé par un paquet d’informations envoyé par votre navigateur internet au serveur web et à l’inverse. Cette valeur est mesurée en millisecondes ou secondes ce qui varie en fonction du service utilisé. Pour tester le temps de réponse de votre serveur vous pouvez utiliser le service WebsitePulse.

La page des résultats de WebsitePulse:

Test du temps de réponse du serveur

2.2. Traitement du statut 404

Le traitement correct du statut 404 est nécessaire pour indiquer les pages inexistantes.

La page des résultats de vérification du traitement du statut 404:

2.3. Redirection 301 depuis les miroirs

Chaque site créé a des miroirs – les pages qui affichent le même contenu sur des adresses différentes. Quoique Google détermine bien le miroir principal, il vaut mieux faire une redirection 301 pour éviter des ennuis quand même possibles.

Exemples de miroirs de la page d’accueil :

  • http://monsite.com
  • http://monsite.com/
  • http://www.monsite.com/
  • http://www.monsite.com/index.php

3. Sitemap

3.1. Présence de la carte du site au format XML

D’habitude se trouve à l’adresse http://monsite.com/sitemap.xml. La présence de la sitemap XML permettra aux moteurs de recherche de se déplacer plus facilement au sein du site. Elle est indispensable pour les boutiques en ligne. Le site peut avoir quelques sitemaps XML.

La sitemap XML peut être créée manuellement ou moyennant un générateur. Pour les sites jusqu’à 500 pages je vais chez XML-Sitemaps.com. Il existe également de nombreuses extensions spéciales qui s’intègrent dans le système de gestion de contenu du site, comme plugin pour WordPress, module pour Drupal ou Joomla!.

Avis post scriptum d’Olivier Tassel:

Contrairement à ce qu’on peut penser, générer un sitemap via un générateur n’améliore en rien le crawl de Google. C’est une action inutile. Le générateur crawl de la même manière (voir de manière moins efficace) que peut le faire Google sans sitemap : où est donc l’intérêt ?

Créer un sitemap est pertinent à partir du moment où on peut le générer directement depuis la base de données par exemple. Cela permet de présenter des URLs qui ne seraient pas accessibles facilement (et encore on peut se poser la question de la qualité de l’architecture du site dans ce cas).

5.2. Indication de la sitemap XML dans Google Webmasters Tools

Les sitemaps s’ajoutent ici: (Votre site) > Configuration du site > Sitemaps > Envoyer un Sitemap

3.2. Présence de la carte du site au format HTML

Si la sitemap XML n’est utilisée que par les robots, la carte du site au format HTML est aussi utile pour les robots que pour les visiteurs (au moins moi, je m’en sers assez souvent pour me faire l’impression de la structure d’un site). Elle permet également de réduire la profondeur des pages internes.

4. Robots.txt

Robots.txt est un fichier de texte placé dans la racine du site et destiné aux robots des moteurs de recherche. Le webmaster peut y indiquer les paramètres d’indexation de son site pour tous les robots à la fois comme pour chacun séparément.

Pour les sites que je référence j’ai un check-list suivant:

4.1. Présence du fichier robots.txt

Toujours placé à l’adresse: http://site.fr/robots.txt.

4.2. Interdiction d’indexer des pages inutiles

Quelles sont les pages à interdire:

  • pages dupliquées;
  • tags;
  • versions imprimables;
  • pages sans contenu;
  • résultats de recherche sur le site;
  • pages techniques etc.

4.3. Indication de la sitemap XML

On peut indiquer l’emplacement de la sitemap XML pour aider le robot à la trouver.

4.4. Indication du host (miroir principal)

La directive host indique au robot le miroir principal du site. Le miroir alternatif sera collé au principal.

Le fichier robots.txt le plus facile à l’air suivant:

[code=’js’]
User-agent: *
Disallow:
Host: www.site.fr
Sitemap: http://www.site.fr/sitemap.xml
[/code]

5. Région ciblée

Peut être indiquée dans Google Webmasters Tools. Je l’utilise d’habitude quand je référence un site en anglais et dans tous les autres cas où la langue ne détermine pas exactement le pays des visiteurs ciblés.

Google Webmasters Tools > Configuration du site > Paramètres > Zone géographique ciblée (Pour changer cochez la case «Emplacement des utilisateurs ciblés»)

6. Systèmes de statistiques

Bon, j’ai ajouté ce point, parce qu’il est encore très souvent que je tombe sur des sites qui contiennent (oh, mon dieu!) presque tous les compteurs possibles. Evidemment ce n’est pas correct et dans la majorité des cas ça ralentit fort le fonctionnement du site. Laissez seulement ce qui est important, à votre avis. Je garde en règle générale 3 au maximum: Google Analytics, Clicktale +1 qui est variable en fonction du projet.

Donc, ici on note 3 points:

6.1. Détection de systèmes de statistiques présents sur le site

6.2. Ajout de systèmes de statistiques utiles

6.3. Suppression de systèmes de statistiques inutiles

7. Hyperliens

7.1. Liens cassés

En bref, les liens cassés sont ceux qui ne mènent nulle part et donc inutiles aux visiteurs comme aux robots. Ils se détectent facilement par le fameux logiciel Xenu’s Link Sleuth qui malgré son âge fait toujours bien son travail)

7.2. Liens sortants

Trop de liens sortants, surtout sur la page d’accueil, vont disperser le jus tellement cher. Il vaut mieux réduire leur nombre n’en gardant que les plus importants.

7.3. Correction du code des liens

Le code des liens internes doit être standard (HTML):

[code=’html’]Page 1[/code]

Les liens en javascript, flash, avec des redirections, rel= »nofollow » etc. ne sont pas à conseiller: ayez pitié du pauvre robot).

Encore un petit moment concernant les liens internes. Je conseille toujours utiliser dans le maillage de liens les liens relatifs genre /page1.html ou encore /produits/veste.html. D’abord vous n’aurez pas besoin de modifier tous les hyperliens en cas de changement du nom de domaine et ensuite vous pouvez ne pas vous soucier si vous avez indiqué le bon miroir (avec www ou sans).

8. Images

8.1. Taille des images

Les images sont un des éléments principaux qui influencent la vitesse de chargement des pages web. Donc, moins ils pèsent, moins doivent attendre les visiteurs. La taille des images peut être réduite manuellement avec votre rédacteur graphique ou moyennant des services en ligne comme PunyPNG (vite et gratuit).

8.2. Images uniques et dupliquées

A côté de la croissance du contenu textuel dupliqué va la prolifération des images piquées sur d’autres sites. Évidemment, leur impact sur le rangement est plus modeste par rapport aux textes, mais je suis persuadé que les images uniques (et optimisées) vont apporter sa contribution à la pertinence et au karma du site. Pour vérifier si telle ou telle image est unique, je recommande le service TinEye.

8.3. Attributs alt et title

Les attributs alt et title (plus aussi la légende) bien remplis vont améliorer la pertinence de la page et augmenter les chances d’apparaître dans les résultats de recherche des images.

8.4. Logo cliquable menant à la page d’accueil

Simplifie la vie aux visiteurs qui sont habitués à un logo cliquable aussi bien qu’aux robots qui peuvent sans difficultés passer à la page d’accueil du site. Une erreur qui est souvent commise, à mon avis, est l’insertion du logo via CSS et non pas avec la balise HTML habituelle <img />. Une solution bizarre, car on ne peut pas, par exemple, ajouter dedans des attributs title et alt.

8.5. Présence d’un favicon

Toujours apprécié, un favicon donne au site le look achevé et peut influencer le taux de clics dans les SERP.

Un favicon représente une image avec une extension .ico et les dimensions 16px x 16px. Vous pouvez créer un favicon vous-même ou bien vous servir d’un des multiples générateurs de favicons. Une fois que l’image et préparée, chargez-la dans la racine du site et ajoutez dans la partie <head> du code source des pages une référence suivante:

[code=’html’][/code]

9. URL

9.1.  Pages statiques/dynamiques

Un des éléments importants de l’analyse d’un site web que je regarde parmi les premiers est la formation des adresses URL, notamment si elles sont statiques ou dynamiques.

Une adresse URL statique est inchangeable pour tous les groupes d’utilisateurs, indépendamment de leur localité, langue, historique des recherches etc. parce qu’elle ne contient pas de paramètres personnalisés.

Exemple d’une adresse statique: http://www.site.fr/assurances/assurance-auto.htm.

En même temps, une adresse dynamique n’est pas fixe et comprend des paramètres spéciaux (introduits par les symboles ? = &). Si on laisse tomber leur côté souvent illisible, un des plus grands défauts des adresses dynamiques est l’affichage du même contenu sur les adresses différentes, ce qui n’est pas du tout bien surtout avec la sortie du Panda. C’est la raison principale pour laquelle les webmasters transforment souvent des adresses dynamiques en statiques. A ce sujet Google recommande dans ses consignes «de limiter le nombre et les paramètres de ces URL».

Exemple d’une adresse dynamique: http://site.fr/forum/read.php?id_forum=3&id_theme=53008

9.2. Sessions

Certains sites sont réalisés avec l’utilisation des identifiants de session. Aurement dit, chaque personne (et robot) qui visite ce site reçoit un paramètre unique (avec la structure «?session_id=»). Ce paramètre s’ajoute dans l’adresse URL de la page sur laquelle se dirige l’utilisateur.  Les identifiants de session sont utilisés d’habitude pour la collecte de données sur les utilisateurs et le tracking de leur comportement sur une page donnée.

Une structure pareille des adresses trompe souvent les robots des moteurs de recherche. En leur attribuant à chaque fois un nouvel identifiant de session, elle les fait indexer toujours de nouveaux URL, bien qu’ils se rapportent aux pages déjà indexées. Mais le robot suit la formule net et précise «nouvelle adresse = nouvelle page». Ainsi, on risque avoir des problèmes de contenu dupliqué.

Quoique Google arrive pas mal à coller des miroirs, il vaut mieux renoncer aux identifiants de session dans les URL.

9.3. SEO friendly URL

Les SEO friendly URL apportent une contribution importante à la pertinence de la page, facilitent leur lecture par les robots, favorisent les mentions de la page par d’autres webmasters. Et on n’oublie l’ expérience utilisateur et que les URL font partie des SERP.

10. Qualité du code source

11.1. Encodage des caractères

Le Web est un espace supermultilingue. Beaucoup de langues ont leurs caractères spécifiques ce qui se reflète dans une multitude d’encodages existants. Si vous faites un audit technique d’un site en une langue que vous ne connaissez pas bien, prenez soin de retrouver des informations sur l’encodage web approprié.

11.2. CSS dans le code source

Plus propre est le code, mieux le lisent les robots des moteurs de recherche. Faites sortir tous les données sur les styles en dehors de la page dans les fichiers appropriés (style.css).

11.3. Javascript dans le code source

La même chose qu’avec le CSS. Bon, si sa quantité est modéré, on peut le laisser ainsi. Mais s’il y a de véritables kilomètres de Javascript et que le VRAI text de la page commence à la 10000-ème ligne du code, il faut mieux accorder une heure pour le bien ranger.

11.4. Validité chez W3 (HTML & CSS)

Rendez une visite sur http://validator.w3.org/ pour vérifier si la qualité du code de votre site est conforme aux standards de W3C. La validité du code CSS se fait ici: http://jigsaw.w3.org/css-validator/.

Essayez de réduire le nombre d’erreurs au minimum. Si votre site est 100% correct, vous aurez le plaisir de contempler un message pareil:

Ce document est valide conformément à la recommandation CSS niveau 2.1

11.5. Balises META remplies et corrects

Les balises META (description et keywords) doivent être remplies. Soignez surtout bien la balise meta-description qui fait partie des SERP et influe le CTR.

11. Contenu (du point de vue technique)

11.1. Pages dupliquées

Visitez une dizaine de pages textuelles du site, vérifiez si les textes sont originaux ou bien copiés sur d’autres ressources. Le contenu est un pilier fondamental du référencement et les textes doivent être uniques et bien soignés.

11.2. Contenu unique et répété au sein du site

Aussi un problème courant. Quand un texte est très bien rédigé, original, mais ses annonces sont répétées à travers tout le site. Cela nuit, à mon avis, la qualité des pages qui possèdent ainsi des morceaux dupliquées. Dans ce cas-là je préfère réduire des blocs répétés aux titres d’articles.

12.3. Balises <title> différentes

Pour un moteur de recherche la balise <title> sert à décrire de façon la plus laconique le contenu de la page. C’est pourquoi quand elle est identique et répétée sur beaucoup de pages, elle perd son importance et le site, par conséquent, perd de la pertinence, ses positions et ses visiteurs.

12.4. Fenêtres pop-up

Surtout sur un jeune site, il faut sûrement les éliminer si elles sont présentes.

12.5. Durée de chargement des pages

Comme on le sait, la durée de chargement des pages est un des facteurs de rangement de Google. Depuis peu, on peut la voir dans la nouvelle interface de Google Analytics, ce qui, convenez, une belle initiative. Par défaut, Google Analytics ne mesure pas la vitesse de chargement des pages. Pour cela, il faudra insérer une méthode supplémentaire dans le code du système sur votre site.

Vous pouvez trouver beaucoup de conseils et d’outils gratuits pour rendre votre site plus rapide et performant dans l’article «Let’s make the web faster» rédigé aimablement par l’équipe de Google.

12.6. Correction de l’en-tête<H1>

L’en-tête <h1> doit être présent sur toute page référencée, contenir le mot clef le plus important et avoir un air humain). Respectez la propreté de l’en-tête <h1> sans ajouter des mots inutiles et vides de sens.

12. Indexation

12.1. Permission d’indexer la page dans le robots.txt

Consultez le fichier robots.txt du site analysé et assurez-vous de l’absence des pages utiles en face de la directive Disallow.

12.2. Permission d’indexer la page dans la balise META robots

Ouvrez le code source de la page analysée (Ctrl + U) et regardez s’il y a dans la partie <head> la balise META robots. Si elle est absente ou, en cas de sa présence, son attribut content n’a pas de valeurs noindex, nofollow et none – alors il n’y a pas d’obstacles pour l’indexation correcte de la page. En fait, la balise META robots est multifonctionnelle et permet de conditionner assez finement la lecture de la page par les robots.

En bref, most wanded:
[code=’html’][/code]

12.3. Nombre de pages dans l’index principal et supplémentaire de Google

Comme on le sait, Google aime beaucoup trier les pages de sites. Les bonnes pages vont dans l’index principal, les pages pessimisées se retrouvent dans l’index supplémentaire et ne figurent presque pas dans les SERP.

Comment le vérifier? – On fait des requêtes suivantes dans Google:

  • Nombre total de pages indexées: site: exemple.fr
  • Nombre de pages dans l’index principal: site: exemple.fr/&
  • Nombre de pages dans l’index supplémentaire: site: exemple.fr -site: exemple.fr/&

12.4. Correspondance de la page réelle et celle dans le cache de Google

Une des premières choses que je regarde en analysant l’indexation d’un tel ou tel site, c’est le cache de Google. De temps en temps, on trouve des non-conformités paradoxales)

12.5. Structure du site et profondeur des pages importantes

Plus une page est loin de la page d’accueil, moins souvent elle sera fréquentée par un robot et moins de jus elle acquerra d’elle. Il suffit de suivre la fameuse règle de 3 clics – toute page du site doit être accessible en 3 clics depuis la page principale.

Chers amis, pour le moment c’est tout. Si j’ai oublié quelque chose d’important, merci de le noter dans les commentaires – je vais compléter l’article.

Alexis Rylko

Article de :

Alexis Rylko

Consultant SEO depuis 2009 & Directeur technique SEO chez iProspect France, formateur SEO, conférencier, éditeur de sites & développeur d’outils SEO.
🏆 Jeune personnalité Search de l'année 2022 (SEMY Awards)
🏆 Prix de la "Meilleure campagne SEO 2023" (SEMY Awards).

42 réflexions au sujet de “Guide détaillé de l’audit technique d’un site web”

  1. juste en complément du point 4.2, dans la mesure du possible, je met systématiquement les pages « mentions légales » , « conditions générales de vente » en rel noindex, nofollow, car ceux sont généralement ces pages qui arrive en 1ere position pour les « petits » sites vitrine . Logique puisqu’elles contiennent la plupart du temps énormément de contenu texte

    Répondre
  2. « La présence de la sitemap XML permettra aux moteurs de recherche de se déplacer plus facilement au sein du site […] La sitemap XML peut être créée manuellement ou moyennant un générateur. »

    Contrairement à ce qu’on peut penser, générer un sitemap via un générateur n’améliore en rien le crawl de Google. C’est une action inutile. Le générateur crawl de la même manière (voir de manière moins efficace) que peut le faire Google sans sitemap : où est donc l’intérêt ?
    Créer un sitemap est pertinent à partir du moment où on peut le générer directement depuis la base de données par exemple. Cela permet de présenter des URLs qui ne seraient pas accessibles facilement (et encore on peut se poser la question de la qualité de l’architecture du site dans ce cas)

    Répondre
  3. Dans le cas ou le sitemap XML présente des URLs creuses ou mal formées qui répondent en 200, Googlebot va passer du temps à les crawler, encore et encore :).
    Donc comme le dit Olivier, il faut effectivement trouver une solution en BDD pour présenter des URLs non accessibles à un générateur lambda, sinon c’est plus problématique qu’autre chose !

    Répondre
  4. Très bon post, ça manque les billets techniques dans la sphère SEO 😉
    Par contre, une petite question, où as-tu entendu parler de la directive host dans le fichier robots.txt. Je n’en ai pour ma part jamais entendu parler. Mais cela pourrait être bien pratique.

    Répondre
    • Outil seo, merci pour ton commentaire. En fait, la directive host est assez rare. Pour moi, je dirais, c’est une question d’habitude de l’utiliser qui vient des temps où je travaillais avec des moteurs différents. Dans la documentation de Google elle n’est pas présente, toutefois on la trouve chez d’autres moteurs de recherche.

      Répondre
  5. Très bon résumé pour tout audit de site.
    Il pourrait être utile de vérifier ou de mettre en place une balise rel=canonical afin de limiter les effets néfastes d’un duplciate content involontaire.

    Répondre
    • Merci, Francois, pour ton commentaire. Oui, l’attribut rel= »canonical » pourrait bien remplir la liste. Je ne l’ai pas ajouté car son éfficacite était jadis sous question et mes tests ne donnaient pas de réponses exactes.

      Répondre
  6. Merci d’avoir partagé cette liste! J’en avais fait une aussi mais je n’ai pas eu le courage de la partager et de l’écrire comme tu l’as fais…

    Je note que tu ne parles pas de l’emplacement du serveur. Il me semblait qu’il valait mieux être sur des IP correspondant au pays?

    Répondre
  7. Bravo pour la structuration. C’est facile à suivre pour un référenceur.
    Cependant je doute que les clients y comprennent grand chose..mais bon c’est le travail. Cheers.

    Répondre
  8. Bonjour,

    Merci pour ce sommaire très pertinent 🙂 Je reviens souvent le voir pour être sur de n’avoir rien n’oublier !

    Concernant le point 12.3. Nombre de pages dans l’index principal et supplémentaire de Google, votre technique pour déterminer le nombre de pages dans l’index principal et supplémentaire de Google, est-elle vérifiable ?
    Comment avez-vous eu connaissance de cette méthode, et pourquoi marche-t-elle ? Enfait je ne comprends pas bien la signification du « /& » pour Google.

    Merci d’avance et encore bravo pour l’article (même si j’arrive un peu tard xD)

    Répondre
  9. Bonjour,

    Je viens de tomber sur ce billet complet et structuré. L’article traite plus un audit de référencement qu’un audit de site Internet comme évoqué dans le titre principal mais le contenu est très instructif.

    Répondre
  10. Très bonne cheklist qui rappelle les incontournables de l’audit. Concernant les outils, je trouve personnellement que plusieurs outils combinés, même simple, sont parfois plus efficaces pour auditer un site que des usines à gaz qui vendent des outils tout en un au final assez incomplets !

    Répondre
  11. Bonjour Alex

    En 12.4, tu soulèves un point important mais ne précise pas de méthode/procédure/outils de vérification : comment dois-je faire pour effectuer cette vérification?

    Répondre

Répondre à Francois Annuler la réponse