Claude pour l'audit technique SEO : auditez le repository, pas le crawl

Cherchez comment utiliser Claude pour l'audit technique SEO et vous trouverez invariablement le même conseil : exportez un crawl, collez les pires lignes dans une fenêtre de chat, et demandez à Claude ce qu'il faut en faire. Ce flux de travail traite Claude comme un endroit plus intelligent pour lire un rapport de crawler — et il gaspille presque tout ce pour quoi le modèle est vraiment doué. L'audit technique SEO sur un site moderne n'est pas un problème de page rendue qui se trouve avoir du code derrière. C'est du code : les règles robots, la génération de sitemap, la logique canonicale, les métadonnées, les redirections et les données structurées sont tous des fichiers source. Le bon endroit pour mettre Claude n'est pas du côté export d'un crawler. C'est dans le repository, où il peut lire les fichiers qui provoquent les symptômes que le crawler photographie — et ensuite les corriger dans la même session, en tant que pull request qu'un humain révise.

Ce guide est l'article technique SEO de notre pilier Claude for SEO. Il couvre ce que Claude peut déterminer sur votre audit technique SEO statiquement — avant que quoi que ce soit soit crawlé — la liste de contrôle concrète fichier par fichier, comment les corrections se distribuent sous forme de PRs, et la partie que presque chaque flux de travail AI-SEO omet : vérifier chaque correction dans Search Console environ trois semaines plus tard, de sorte que « Claude l'a corrigé » devient une affirmation mesurée au lieu d'une affirmation pleine d'espoir. Une divulgation honnête d'avance : la requête que cet article cible enregistre essentiellement aucun volume de recherche pour le moment. La pratique est en avance sur la demande. C'est généralement le meilleur moment pour écrire le guide.

Le crawler a trouvé le symptôme. Le repository contient la cause

Un crawler fonctionne de l'extérieur vers l'intérieur. Il récupère les pages rendues, échantillonne ce qu'il peut atteindre, et signale les symptômes : deux canonicaux en conflit ici, une chaîne de redirection là, un groupe de pages manquant du sitemap. Chaque symptôme a une cause, et sur un site construit avec un framework, la cause n'est presque jamais sur la page — elle est dans un template, un fichier config, ou une branche middleware. Le crawler peut vous dire qu'une centaine de pages portent le mauvais canonique. Il ne peut pas vous dire que les cent sont rendues par un fichier layout avec une mauvaise ligne, parce qu'il n'a jamais vu le fichier layout.

Claude exécuté dans le repository démarre à partir de la cause. Il lit le template et sait — sans récupérer une seule URL — que chaque page que le template rend hérite du bug. Cette inversion change les économies de l'audit deux fois. Couverture : un crawler échantillonne, mais une lecture de fichier est exhaustive, parce qu'une fonction generateMetadata est les métadonnées de chaque route qui l'utilise. Vitesse : le premier passage d'un audit technique sur un site Next.js consiste à lire peut-être dix fichiers, ce qui prend à Claude quelques secondes, pas les heures qu'un crawl complet prend sur un grand site.

Sur un site que nous avons audité, la route du sitemap parcourait une collection de contenu qui avait été restructurée mois plus tôt. Le sitemap compilait, se déployait et retournait un 200 valide — il avait simplement cessé d'inclure les pages de tout un template. Un crawler ne voyait rien de mal, parce que chaque page qu'il atteignait était bien ; les pages manquantes étaient exactement celles pour lesquelles il n'avait pas de chemin. Lire app/sitemap.ts contre l'arborescence des routes réelles a révélé l'écart en un passage. C'est la catégorie de bug pour lequel existe l'audit repository-first : invisible de l'extérieur, une lecture de fichier de l'intérieur.

Un crawler signale qu'une centaine de pages portent le mauvais canonique. Le repository vous montre la ligne unique, dans un template unique, dont tous les cents l'héritent — et Claude peut lire cette ligne, la corriger, et ouvrir la PR dans la même session.

Ce que Claude peut lire qu'un crawler ne peut pas

Sur un site Next.js — et chaque framework sérieux a des équivalents — la surface technique SEO se concentre dans une courte liste de fichiers. C'est la carte à partir de laquelle Claude fonctionne, et chaque fichier a une classe d'échec caractéristique qui est pleinement visible en source et largement invisible dans un crawl.

Remarquez ce qui unit les lignes en évidence : ce sont des bugs qui passent tous les builds, se déploient sans erreur, et produisent aucun défaut visible sur une page individuelle. Ils n'existent que comme une relation entre fichiers — sitemap par rapport à l'arborescence des routes, canonique par rapport à l'origine — qui est précisément le type de raisonnement cross-file qu'un modèle de langage avec accès au repository est construit pour, et qu'un crawler page-par-page ne l'est pas.

La liste de contrôle repository-first, fichier par fichier

Voici le passage concret, dans l'ordre que Claude devrait l'exécuter — chaque vérification associée à la condition de passage et à la métrique Search Console qui vérifiera la correction. La métrique est engagée quand la détection est classée, pas après que la correction soit distribuée ; cette discipline, et pourquoi la version plus profonde à cinq couches de cet audit est structurée de la façon qu'elle l'est, sont couvertes dans le guide complémentaire sur les audits technique SEO.

Deux habitudes rendent cette liste de contrôle pratique. Premièrement, Claude devrait lire les fichiers comme un système, pas une liste — la vérification de redirection n'a de sens que quand les redirections next.config et les réécritures middleware sont composées ensemble, et la vérification canonique n'a de sens que contre l'origine en direct. Deuxièmement, chaque détection devrait être classée avant que quoi que ce soit soit corrigé, avec son impact attendu et sa métrique de vérification attachée, de sorte que l'audit produit une queue responsable au lieu de quelques heures héroïques d'édits non enregistrés.

Les corrections se distribuent comme des pull requests, pas des tickets

C'est ici que le cadre repository-first cesse d'être une optimisation d'audit et devient un modèle opérationnel différent. Dans le flux crawler-et-chat, une détection devient un ticket, le ticket attend un développeur, le développeur re-dérive le contexte que l'outil avait déjà, et la correction arrive des semaines plus tard — si elle arrive. Quand Claude est déjà dans le repository, l'entité qui a trouvé la metadataBase manquante est l'entité qui édite le fichier. La distance entre le diagnostic et la correction s'effondre d'un sprint à un diff.

Le point de contrôle ne disparaît pas — il se déplace à l'endroit où les équipes de logiciels en ont déjà un : la pull request. Claude ouvre une PR avec la détection, la preuve, et la modification ; un humain révise et fusionne. Rien ne s'atterrit silencieusement. C'est important en audit technique SEO plus que presque n'importe où ailleurs, parce que les mêmes fichiers qui fixent l'indexation peuvent la détruire — une mauvaise règle robots ou une mauvaise redirection est un incident sitewide, et une correction canonique d'une ligne et une catastrophe canonique d'une ligne se ressemblent presque identiquement dans un diff. La PR est la porte de révision humaine, et elle produit quelque chose que les tickets ne font jamais : un enregistrement horodaté et révisable de exactement ce qui a changé, dont l'étape de vérification va avoir besoin.

Pas fait jusqu'à ce que Search Console le dise

Une PR fusionnée est toujours une affirmation. La correction robots devrait restaurer les impressions sur la section bloquée ; la consolidation canonique devrait lever la position sur l'URL survivante. Que ce soit le cas est un fait qui n'existe pas jusqu'à ce que Google recrawle, retraite, et accumule assez de nouvelles données de requête pour comparer — en pratique, environ trois semaines. La plupart des flux de travail SEO assistés par IA se terminent à la fusion et laissent l'affirmation se tenir éternellement. C'est la moitié du travail que cette méthode entière existe pour éviter.

La forme de travail est un tableau de tâches qui ferme la boucle. Chaque détection de liste de contrôle se pose comme une tâche portant sa métrique de vérification et sa cible ; la PR fusionnée bascule la tâche à done avec l'URL de la PR attachée ; et un monitor hebdomadaire relit Search Console sur tout ce qui dépasse sa date de vérification et écrit le verdict — confirmé, régressé, ou inconclusive. Claude fait la lecture et la correction ; le tableau le souvenir ; Search Console fait le jugement. La mécanique de cette boucle — et pourquoi trois semaines est la physique de la source de données plutôt qu'un choix de produit — sont le sujet du guide complémentaire sur le SEO en boucle fermée.

Exécutez ceci pendant un trimestre et le sous-produit devient l'actif : un enregistrement per-site du moment où les corrections technique SEO vérificatif vraiment. Les consolidations canoniques confirmant fiablement, le travail de rendu lisant deux fois inconclusive de suite — le prochain passage d'audit démarre à partir de cette histoire mesurée au lieu d'une échelle de sévérité générique, qui est comment la boucle devient plus intelligente à propos d'un site au lieu de l'auditer de zéro pour toujours.

Ce que Claude ne peut pas voir du repository

Repository-first est une grande part de l'audit technique SEO. Ce n'est pas tout, et prétendre le contraire briserait la règle d'honnêteté de la méthode elle-même. Trois points aveugles restent en dehors de l'arborescence source peu importe la qualité du modèle.

Ce que Google a vraiment fait. Le repository montre l'intention ; seul Search Console montre le résultat — ce qui a été indexé, ce qui s'affiche, ce qui gagne des clics. L'audit lit GSC tout au long comme l'enregistrement de la réalité, pas juste au moment de la vérification. Ce que les vrais utilisateurs expérimentent. Les Core Web Vitals sont jugés sur les données de champ au 75e percentile des vraies visites. Claude peut repérer l'image non redimensionnée et le script bloquant en source, mais le verdict vient de la mesure de champ, et les scores de labo flattent chaque site. Ce qui s'assit en dehors du repository. Les règles CDN, la configuration edge, un reverse proxy que quelqu'un a configuré en 2021 — si ce n'est pas dans l'arborescence source, une lecture source ne peut pas le trouver, et un crawl confirmant du site en direct reste la vérification croisée honnête que ce que le code veut dire est ce que le serveur sert.

Comment exécuter ceci sur votre propre site

La configuration est délibérément ennuyeuse. Claude Code fonctionne dans votre repository de site — le même endroit où vos développeurs travaillent déjà — et se connecte sur MCP aux données qu'il ne peut pas connaître de la source : la performance Search Console, le tableau de tâches partagé, et le fallback crawl. Le guide de connexion couvre l'installation à une commande. De là, la boucle ci-dessus est le manuel d'exploitation : lisez les dix fichiers, classez les détections avec leurs métriques de vérification, distribuez les corrections sélectionnées comme des PRs, et laissez le monitor hebdomadaire écrire les verdicts.

Si vous voulez voir la moitié find s'exécuter contre vos propres données d'abord, le rapport SEO gratuit connecte votre Search Console et révèle où la couche technique vous coûte déjà — les sections affichées mais jamais choisies, les URLs se battant avec elles-mêmes. Et si vous préfériez que la boucle entière s'exécutait comme un service — les détections classées, les PRs ouvertes, les verdicts lus — réservez un appel et nous parcourrons ce que cela ressemble sur votre repository.