Réglages des cookies

Les cookies nécessaires gardent le site fonctionnel. L'analytics montre quelles pages sont utiles. Vous pouvez changer votre choix à tout moment depuis le pied de page.

Politique de cookies — le détail : catégories de cookies, stockage de votre choix dans le navigateur et retrait du consentement.

Nécessaires

Fonctions de base du site et votre choix de consentement. Toujours actifs.

Mesure d'audience

Aide à comprendre comment le site est utilisé. Chargé uniquement avec votre accord.

GitHubTélécharger le ZIP

Vérifier les corrections SEO

Après une mise en production, revérifiez les constats ou les URL sélectionnés. Chaque constat reçoit l'un des statuts suivants : résolu, persistant, modifié ou non vérifiable. Seules les pages concernées sont prises en compte.

Voir sur GitHubDémarrage rapide

Ce qu'elle fait

  • Terminal : options de seohead verify-fixes

Revérification ciblée

Choisissez les éléments à contrôler par identifiant de constat, par URL concernée, à partir d'un fichier d'URL ou d'une vue de vérification enregistrée. SpiderHead ne recharge que ces pages, avec les règles HTTP, robots et de rendu enregistrées dans la base de référence. Les contrôles portant sur tout le site ne sont pas relancés.

  • Une sélection comprend au maximum 500 cibles de crawl et 5 000 constats.
  • Une sélection qui dépasse ces limites échoue. Elle n'est jamais échantillonnée.
  • --after utilise un audit ou un scan existant et plus récent : aucune requête n'est envoyée.

Verdicts encadrés

Une revérification partielle ne peut pas déclarer l'ensemble du site corrigé. Les contrôles portant sur tout le site ou non mesurés reçoivent le statut non vérifiable. Un crawl ultérieur invalide ne peut pas résoudre de constats, et réanalyser le même scan ne constitue pas une preuve récente.

  • Chaque verdict est accompagné de sa raison et des preuves.
  • Les résultats sont enregistrés dans un nouveau fichier JSON et Markdown, figé après écriture.
  • Les pages manquantes restent non vérifiables.

Registre des corrections

Pour les travaux plus longs, un registre des corrections rattaché à un projet suit chaque cas selon ses états successifs. Une tâche évolue selon les preuves de revérification : une tâche marquée comme terminée n'est donc pas confondue avec un site corrigé. Les revérifications restent limitées aux cas en attente exacts.

  • remediation-ingest charge un audit enregistré comme base de référence.
  • remediation-recheck revérifie les cas en attente, sans crawl du site.
  • remediation-report affiche les preuves avant et après, hors ligne.

Trois étapes, un seul scan enregistré

  1. Partir d'une base de référence

    Indiquez à verify-fixes le fichier audit.json ou le scan SQLite dont vous disposez déjà, puis choisissez les identifiants de constats ou les URL concernées.

  2. Revérifier uniquement les pages concernées

    L'outil recharge les URL sélectionnées avec les règles HTTP, robots et de rendu enregistrées dans la base de référence. Les contrôles portant sur tout le site ne sont pas relancés.

  3. Lire le verdict par constat

    Chaque constat est marqué résolu, persistant, modifié ou non vérifiable, avec sa raison et ses preuves, dans un nouveau fichier JSON ou Markdown figé.

Contrôles de cette fonctionnalité

ContrôleSignificationGravitéPreuve
BROKEN_PAGE_4XXLa page renvoie un statut 4xx  ; une revérification peut la montrer corrigée une fois l'URL revenue en 2xx.CriticalCode de statut avant et après, par URL
SERVER_ERROR_5XXLa page renvoie un statut 5xx  ; elle n'est résolue que si la revérification obtient un 2xx.CriticalCode de statut avant et après, par URL
TITLE_MISSINGLa page n'a pas de balise title  ; une correction apparaît comme résolue sur la même URL.CriticalLignes de constats de la base de référence et de la revérification pour l'URL
H1_MISSINGLa page n'a pas de titre H1.ImportantLignes de constats de la base de référence et de la revérification pour l'URL
CANONICAL_MISSINGLa page n'a pas de balise canonical.ImportantLignes de constats de la base de référence et de la revérification pour l'URL
REDIRECT_CHAINLa redirection passe par deux sauts ou plus avant l'URL finale.ImportantStatut par saut, issu de la revérification
BAD_REDIRECT_TYPELes codes 302, 303 ou 307 sont utilisés alors qu'une redirection permanente 301 est attendue.TipStatut par saut, issu de la revérification

Une seule commande

bash
seohead verify-fixes --baseline ./report/audit.json --urls https://example.com/old-page --out-dir ./verification-1

Commencez par installer : guide d'installation. Chaque commande fonctionne aussi comme outil MCP pour les agents IA.

Ce qu'il vous faut

  • Une base de référence : un fichier audit.json enregistré ou un scan SQLite
  • Une sélection : identifiants de constats, URL, un fichier d'URL ou une vue enregistrée
  • Un nouveau dossier de sortie (--out-dir) pour les fichiers de vérification
  • Facultatif : la configuration d'origine du crawler, si la base de référence a masqué les identifiants (--config)

Limites

  • Sans --after, l'outil envoie des requêtes de lecture aux URL que vous sélectionnez.
  • Seules les pages sélectionnées sont vérifiées. Le site n'est pas analysé à nouveau.
  • Un scan utilisé avec --after doit être distinct de la base de référence et postérieur à celle-ci.
  • Les contrôles portant sur l'ensemble du site ne peuvent pas être vérifiés à partir d'une revérification partielle.

Questions

Cela modifie-t-il quelque chose sur mon site ?
Non. L'outil envoie uniquement des requêtes de lecture aux URL que vous sélectionnez. Le résultat est un nouveau fichier de vérification, placé dans le dossier indiqué avec --out-dir.
Un résultat résolu signifie-t-il que tout le site est corrigé ?
Non. L'outil ne contrôle que les pages concernées que vous avez sélectionnées. Les contrôles portant sur tout le site ou non mesurés ne peuvent pas passer à corrigé à l'issue d'une revérification partielle  ; ils restent non vérifiables.
Faut-il d'abord relancer un crawl ?
Il faut une base de référence : un audit.json enregistré ou un scan SQLite. Pour vérifier sans requête réseau, passez --after avec un audit ultérieur existant  : l'outil fonctionne alors hors ligne.
Combien de constats peut-on vérifier en une seule exécution ?
Jusqu'à 500 cibles de crawl et 5 000 constats. Les sélections plus grandes échouent au lieu d'être échantillonnées  : découpez-les.
Quelle est la différence avec compare-crawls ?
compare-crawls compare deux fichiers enregistrés et ne récupère rien. verify-fixes recharge les pages que vous sélectionnez et donne un verdict par constat. Utilisez compare-crawls pour une vue d'ensemble d'une mise en production, et verify-fixes pour clore des tâches précises.
Puis-je l'utiliser depuis un assistant IA ?
Oui. La même opération est disponible dans le serveur MCP local sous le nom seo_verify_fixes, avec les mêmes arguments que la CLI.

Pour aller plus loin

Du blog et du glossaire

Checklist SEO pour un site : plus de 80 points à auditerBlog

Autres dans ce groupe · Import et comparaison

Analyseur d’exports Screaming FrogFonctionnalitéComparer les crawls avant et aprèsFonctionnalitéHistorique d'une URL entre les analysesFonctionnalité

Essayez-le sur votre site

Télécharger le ZIPToutes les fonctionnalités