Corriger le SEO dans le code, pas dans un rapport

Le problème du SEO technique n'a jamais été de trouver les anomalies. N'importe quel crawler en liste des centaines en une heure.

Le problème, c'est la distance entre cette liste et un site corrigé. Cette distance se mesure en semaines, et c'est là que meurent la plupart des audits.

L'entonnoir dans lequel tout se perd

Le trajet habituel d'une anomalie détectée :

1. Le crawler la signale.
2. Quelqu'un la lit et décide qu'elle compte.
3. Quelqu'un trouve quel fichier produit ce HTML.
4. Quelqu'un écrit la modification.
5. Quelqu'un la teste.
6. Quelqu'un la déploie.
7. Quelqu'un vérifie qu'elle a marché.

Les étapes 3 à 6 demandent un accès au code et du temps de développeur — la ressource la plus rare de toute organisation. L'étape 7 n'a lieu à peu près jamais.

Résultat : un rapport de 230 lignes produit une dizaine de corrections dans le trimestre. Ce n'est pas un problème de motivation, c'est un problème de coût unitaire.

Ce qui change quand la correction arrive en pull request

Le trajet devient :

1. Le crawler signale.
2. Quelqu'un décide que ça compte.
3. Une pull request existe.
4. Quelqu'un relit trois lignes de diff et fusionne.
5. Le crawl suivant confirme.

Les étapes coûteuses disparaissent, et surtout la septième — la vérification — devient automatique parce qu'elle est adossée au crawl suivant.

L'étape 4 reste humaine, et doit le rester. Un diff de trois lignes se relit en trente secondes, et c'est ce qui rend le reste acceptable.

L'étape difficile : trouver le bon fichier

C'est ici que tout se joue, et c'est la partie que les démonstrations passent sous silence.

Une page HTML en production ne dit pas quel fichier l'a produite. Entre les deux il y a un générateur de site, des gabarits, des composants, des couches de configuration.

La question décisive est toujours la même : l'anomalie vient-elle de la page ou du gabarit ?

• 120 fiches produit sans meta description → le gabarit ne l'émet pas. Une modification, un fichier, 120 lignes de rapport qui disparaissent.
• 3 articles sans description → trois contenus à compléter, page par page.

Se tromper de côté produit soit une correction inutile, soit 120 modifications là où une seule suffisait.

Et quand la correspondance n'est pas certaine, la bonne réponse est de refuser la correction. Un correctif appliqué au mauvais fichier coûte plus cher à défaire qu'à ne jamais faire.

Ce qu'une machine peut écrire, et ce qu'elle ne devrait pas

La ligne est nette, et elle passe entre deux familles.

Les corrections déterministes. Une canonical incohérente, un hreflang réciproque manquant, un lien interne qui traverse une redirection, une boucle de redirection. La valeur à écrire n'est pas une opinion : elle se déduit du crawl. Le rôle du modèle se limite à insérer correctement cette valeur dans votre code.

Les corrections rédactionnelles. Un title, une meta description, un alt. Là, le modèle écrit vraiment quelque chose. C'est utile, souvent bon — et ça mérite une relecture, parce qu'un texte plausible n'est pas un texte juste.

La conséquence pratique : une automatisation sérieuse traite ces deux familles différemment. Fusionner sans relecture une correction déterministe est défendable ; fusionner sans relecture une phrase écrite par un modèle ne l'est pas.

Corriger dans le code, ou corriger à l'affichage

Il existe une autre façon d'automatiser : ne pas toucher au dépôt du tout. Un script inséré dans vos pages, ou un intermédiaire placé devant votre site, réécrit le HTML au moment où il part vers le visiteur. Le title manquant apparaît, la canonical se corrige, et le rapport passe au vert.

Il faut dire ce que cette approche règle vraiment, parce que c'est réel : elle ne demande aucun accès au code, elle s'installe en quelques minutes, et elle fonctionne quand le site n'a pas de dépôt Git ou quand l'équipe technique est indisponible. Pour un site qu'on ne peut pas modifier, c'est la seule option.

Trois choses ne suivent pas.

La correction appartient au service, pas à vous. L'abonnement s'arrête, le script ne se charge plus, la page redevient exactement ce qu'elle était. Vous n'avez rien accumulé : vous avez loué un état.

Votre code reste faux. Le gabarit qui n'émettait pas de meta description ne l'émet toujours pas. Le prochain développeur qui l'ouvre reproduira l'anomalie sur les pages suivantes, parce que rien dans le dépôt ne lui dit qu'il y a un problème. La couche d'affichage masque le défaut au lieu de le retirer.

Une pièce de plus entre le visiteur et la page. Ce qui réécrit peut tomber en panne, ralentir, ou se tromper — et ce qui passe par le navigateur suppose que le robot qui vous lit exécute bien le script.

Le test qui tranche tient en une question : que reste-t-il si vous arrêtez votre abonnement demain ? Une pull request fusionnée est dans votre dépôt, dans votre historique, relue et approuvée par quelqu'un de chez vous. Elle ne s'évapore pas avec le fournisseur qui l'a proposée, et elle reste vraie même si vous changez d'outil — ou si vous n'en utilisez plus aucun.

C'est le même critère que pour le reste de cet article : une correction compte quand elle survit à ce qui l'a produite.

Et la vérification, qui manque partout

Une pull request fusionnée n'est pas une anomalie corrigée. Entre les deux il y a un déploiement, un cache, parfois un CDN, et l'hypothèse que le correctif était le bon.

La seule preuve qui vaille est un crawl postérieur au déploiement qui ne voit plus l'anomalie.

Et il faut aussi regarder l'autre direction : quelles anomalies sont apparues entre les deux crawls ? Une correction de canonical qui règle 40 URLs et en met 12 en noindex est un échec, même si le total a baissé.

C'est la boucle complète : détecter, décider, corriger, déployer, vérifier, recommencer. Tant qu'une étape manque, l'audit reste un document.

Ce que ça ne remplace pas

Ni la stratégie éditoriale, ni le choix des pages qui méritent votre temps, ni la compréhension de votre marché. Une machine qui corrige des canonical ne sait pas quelles pages vous rapportent de l'argent.

Elle enlève juste le travail qui n'aurait jamais dû coûter des semaines.