Umbodi est un agent SEO qui fonctionne avec GitHub. Il audite votre site, écrit le correctif et ouvre une pull request sur votre dépôt — il ne modifie jamais votre site directement. Vous relisez le diff et vous fusionnez, puis il ré-explore la page pour savoir que le correctif est bien en ligne.
Une GitHub App sur les dépôts que vous choisissez. Rien n’est fusionné sans vous, et rien n’atteint la production autrement que par votre propre déploiement.
La plupart des outils s’arrêtent après la deuxième. La quatrième est celle qui prouve que le travail a été réel.
Il lit votre sitemap, explore chaque page accessible et note ce qui vous coûte de la visibilité.
Titres, descriptions, données structurées et pages entières, rédigés comme la modification de fichier elle-même. Pas une tâche à faire.
Sur le dépôt que vous avez choisi, sous forme de branche et de diff. Votre revue, votre fusion, votre déploiement.
Appliqué signifie qu’un robot a vu la modification sur la page en ligne. Une pull request fusionnée mais jamais déployée reste non appliquée.
Chaque extension SEO qui modifie votre site directement réclame une permission qu’aucun autre prestataire n’obtient.
La même revue que toute autre modification de votre site. Un agent qui écrit en production, c’est une modification que personne n’a lue.
Une fusion regrettée, c’est un revert. Une écriture directe regrettée, c’est un incident, et vous l’apprenez par votre trafic.
Votre historique git dit ce qui a changé, quand et pourquoi — là où votre équipe regarde déjà, pas dans le tableau de bord d’un prestataire.
Si un relecteur ne peut pas dire à quoi sert une modification, la modification n’est pas terminée.
Un sujet par pull request. Pas un balayage de quarante fichiers à prendre ou à laisser en bloc.
Énoncé comme une projection et étiqueté comme telle. Un classement mesuré et un gain espéré ne partagent jamais le même chiffre ici.
S’il n’a pas pu ouvrir la pull request, il en nomme la raison — l’app non installée sur ce dépôt, par exemple — plutôt que d’annoncer une exécution propre qui n’a rien publié.
Umbodi le fait. Il audite vos pages, écrit le correctif et ouvre une pull request sur le dépôt dont votre site est issu. La modification est un diff que vous relisez et fusionnez comme n’importe quel autre. Umbodi n’a jamais d’accès en écriture à votre site en production.
Umbodi s’installe comme une GitHub App sur les dépôts que vous choisissez. Il n’ouvre de pull requests que sur ces dépôts, et si l’installation cesse de couvrir un dépôt, il le nomme au lieu d’annoncer une exécution propre qui n’a rien publié.
Non. Chaque modification qu’il apporte à un dépôt arrive sous forme de pull request. Rien n’est fusionné sans vous, et rien n’atteint la production autrement que par votre propre déploiement. Pour les sites qui ne sont pas dans un dépôt, Umbodi prépare le bloc exact à coller.
Après le déploiement, Umbodi ré-explore la page en ligne et vérifie que le correctif est présent dans ce que reçoit un robot. Appliqué signifie qu’une nouvelle exploration l’a vu, pas qu’une tâche a renvoyé un code de succès — une pull request fusionnée mais jamais déployée reste non appliquée.
Lancez d’abord l’audit et lisez ce qu’il trouve. La pull request vient après, quand vous êtes d’accord avec lui.