Checklist de diagnostic
| Domaine | Vérification | Preuve attendue |
|---|---|---|
| Accès et périmètre | Identifier les parcours essentiels et les accès disponibles. | Liste des URL, parcours et responsables ; accès manquants signalés. |
| Sauvegardes | Contrôler fichiers, base et possibilité de restauration. | Référence de sauvegarde et compte rendu du dernier essai de restauration. |
| Sécurité et composants | Relever versions, comptes privilégiés et anomalies HTTPS. | Inventaire daté et anomalies localisées, sans export public des données sensibles. |
| Indexation | Comparer statut HTTP, canonique, noindex et état Search Console. | Relevé par URL, avec exclusions prévues et écarts à expliquer. |
| Performance | Mesurer les pages représentatives sur mobile et ordinateur. | Rapports datés, conditions du test et distinction terrain/laboratoire. |
| Parcours et formulaires | Essayer navigation, clavier et transmission d’une demande de test. | Résultat par scénario et confirmation de réception, ou échec documenté. |
Définir ce que le site doit permettre
Écrivez les parcours indispensables : trouver une prestation, consulter un document, envoyer une demande ou commander. Choisissez ensuite des pages représentatives : accueil, page de service, article, contact et, si nécessaire, produit et commande. Ajoutez les pages signalées comme défaillantes. Un échantillon doit couvrir les différents modèles, pas seulement les pages qui fonctionnent déjà.
Un formulaire peut afficher un message de succès sans transmettre la demande. Une page peut répondre correctement tout en étant exclue de l’indexation. Auditer un site WordPress consiste à repérer ces écarts, puis à expliquer comment les confirmer. Cette checklist sert à préparer un diagnostic ; elle ne remplace pas un test d’intrusion et ne suppose aucun résultat obtenu sur votre site.
Notez la date, les URL, le navigateur et les conditions de mesure. Demandez les accès nécessaires à WordPress, à l’hébergement et à Search Console, avec des comptes nominatifs. Le guide pour récupérer les accès WordPress auprès d’un prestataire aide à préparer ce passage souvent bloquant.
Vérifier la possibilité de revenir en arrière
Demandez où sont conservés les fichiers et la base de données, de quand date la dernière sauvegarde et qui sait la restaurer. Une notification de sauvegarde réussie ne démontre pas que le site redémarrera. Recherchez le compte rendu d’une restauration sur une copie isolée, avec date et vérification des médias et des contenus.
Pendant le diagnostic, ne lancez pas une mise à jour pour faire disparaître une alerte. Inscrivez-la au rapport et préparez son traitement séparément. La sécurisation et la gestion des sauvegardes demandent une procédure et un responsable, au-delà du choix d’une extension.
Examiner WordPress sans tout reconfigurer
Dans Outils > Santé du site, consultez les onglets État et Informations. Relevez les versions de WordPress, PHP, du thème et des extensions, ainsi que les anomalies remontées. Cet écran fournit des indices techniques ; il ne certifie ni la sécurité ni le bon fonctionnement des parcours. Ne publiez pas son export brut : il contient des informations sur l’environnement.
Associez les extensions à leurs fonctions et les comptes privilégiés à leurs responsables. Pour une anomalie serveur, demandez les extraits de journaux nécessaires au diagnostic, sans données personnelles.
Une extension inactive mérite un examen, mais son remplacement ou sa suppression relève du plan de correction. Pour approfondir les comptes, les mises à jour et les accès, consultez les principes de sécurité WordPress.
Contrôler l’accès aux contenus et leur indexation
Pour chaque page importante, consignez le statut HTTP, la destination finale, la canonique et une éventuelle directive noindex. Dans Search Console, comparez l’URL déclarée et l’état connu par Google. Une réponse 200 autorise le traitement du contenu, sans garantir son indexation. Un sitemap sert à signaler des URL : sa présence ne prouve pas qu’elles sont toutes retenues.
Triez les 404 selon leur origine. Un lien interne cassé vers une ressource utile doit être réparé. Une page déplacée vers un équivalent précis peut justifier une redirection permanente. Une ancienne page supprimée sans remplacement peut conserver une vraie 404. Rediriger toutes les erreurs vers l’accueil brouille le diagnostic. Ces contrôles prolongent le travail de SEO technique.
Mesurer la vitesse et essayer les parcours
Mesurez les mêmes modèles de pages sur mobile et ordinateur, en conservant les conditions du test. Distinguez les données de terrain disponibles des simulations de laboratoire. Un score isolé ne décrit pas tous les visiteurs. Relevez le principal élément affiché tardivement, les décalages visuels et les interactions gênantes, puis formulez une hypothèse à vérifier. Le guide sur la vitesse d’un site web replace ces mesures dans leur contexte.
Parcourez aussi le site au clavier. Essayez le menu, les liens, les champs obligatoires et les messages d’erreur. Envoyez une demande identifiée comme test et confirmez sa réception dans la boîte ou l’outil prévu. Pour une boutique, préparez un scénario en environnement de test avec paiement de test, commande et notifications ; ne déclenchez pas une transaction réelle sans l’avoir organisée.
Livrer une liste de décisions vérifiables
Pour chaque anomalie, renseignez : URL, observation, preuve, conséquence, correction proposée, responsable et critère de clôture. Par exemple, « formulaire contact : message de confirmation visible, réception non confirmée » est un constat. « Configurer un autre service d’envoi » reste une solution à étudier, pas une cause démontrée.
- Urgent : parcours essentiel indisponible ou incident de sécurité avéré, à traiter selon une procédure d’incident.
- À planifier : problème confirmé sur un modèle important, avec correction à tester sur copie.
- À explorer : indice incomplet ou amélioration dont l’intérêt reste à mesurer.
Terminez par les limites : accès manquants, pages non visitées, données de terrain absentes et tests non réalisés. Cette traçabilité rend la checklist complémentaire d’un audit WordPress accompagné et permet de vérifier ultérieurement ce qui a réellement été corrigé. Pour organiser le suivi après les corrections, reprenez la checklist de maintenance WordPress mensuelle.
Sources officielles
Documentation consultée le 19 octobre 2026.