AUDIT N°4 →
trainrboost.com
Cet audit a été réalisé par un agent IA, à partir d'un crawl complet du site. Je le partage tel quel, avec ses qualités et ses limites.
TrainRBoost est un portfolio d'apps santé et fitness : Puna pour le bodyweight, Cactus pour l'hydratation, Doudou pour le suivi bébé, plus une bibliothèque d'exercices, des calculateurs et des programmes.
401 URLs crawlées.
Premier constat : ce site est beaucoup plus propre que les précédents.
401 pages répondent en 200
393 pages sont indexables
Aucune 404 dans le crawl
Aucun title dupliqué
Aucune meta description dupliquée
Un H1 présent sur chaque page
Le contenu est bien visible dans le HTML brut
Donc ici, ce n'est pas un audit catastrophe.
Le sujet est plus subtil : plusieurs signaux SEO sont propres individuellement, mais trop répliqués en template.
On dirait un site qui a compris le SEO, mais qui a poussé certaines logiques sans les contextualiser.
La home a un canonical sans slash
URL crawlée :
trainrboost.com/
Canonical déclaré :
trainrboost.com
Sur une home, Google normalise généralement ce type de différence. Pas un vrai problème d'indexation.
Mais dans le crawl, la home ressort en canonical_mismatch, et c'est la page la plus forte du site : 793 liens internes pointent vers elle, PageRank interne max.
Sur une page aussi centrale, autant éviter l'ambiguïté.
La meta keywords est identique sur les 401 pages
Toutes les pages servent exactement la même balise meta keywords :
bodyweight training, home workout, calisthenics, workout program, strength training, mobility, fitness app
Le problème n'est pas la balise elle-même. Google l'ignore depuis 2009, donc aucune pénalité.
Le problème, c'est que cette liste est copiée sur des pages qui ne parlent absolument pas de ça :
la page Cactus, qui est une app de suivi d'hydratation
la page Doudou, qui est une app de suivi bébé
les pages cactus-privacy, doudou-terms, privacy, terms
les comparatifs comme Cactus vs WaterMinder ou Doudou vs Huckleberry
les pages outils comme BMI calculator ou pace calculator
Ça donne un signal de template SEO global, pas contextualisé.
Et ça révèle aux concurrents les requêtes ciblées, en plus de polluer le code source.
1 945 liens internes pointent vers des pages noindex
Le crawl remonte 8 pages noindex, ce qui est normal : privacy, terms, support, pages d'upsell des funnels.
Mais ces pages reçoivent énormément de liens internes :
Privacy : 403 liens internes
Terms : 375 liens internes
Support : 344 liens internes
Au total, environ 1 945 liens internes pointent vers des pages que le site déclare lui-même comme non destinées à l'index.
C'est mécanique avec un footer sitewide, donc à nuancer.
Mais à côté, les pages exercices, qui sont le cœur du SEO programmatique du site, reçoivent en moyenne 6 à 10 liens chacune.
Leur PageRank interne moyen est à 20, contre 90 pour Privacy et Terms.
Le maillage donne donc plus de poids aux pages légales qu'aux pages qui doivent ranker.
Le multilingue est appliqué sur les outils, pas sur les exercices
Le site déclare 6 sitemaps de langues :
de
en
es
fr
it
pt-BR
La structure est intéressante.
Les 25 pages outils ont des balises hreflang complètes vers les 6 langues.
Les 333 pages exercices n'ont que des hreflang "en" et "x-default".
Ce n'est pas forcément une erreur.
C'est probablement un choix de stratégie : traduire les calculateurs pour capter du trafic international sur des requêtes universelles comme BMI, TDEE, pace calculator, etc., et garder la bibliothèque d'exercices en anglais uniquement.
Le point d'attention : dans le crawl HTML, je ne trouve aucun lien interne classique vers les versions /fr/, /de/, /es/, /it/, /pt-BR/.
Les versions traduites des outils existent, sont déclarées dans les sitemaps et en hreflang, mais elles ne semblent pas accessibles via un sélecteur de langue ou un lien visible dans le HTML brut.
Donc Google les découvre via le sitemap et les balises hreflang, mais l'utilisateur n'a pas de chemin évident pour y arriver.
Pour du SEO international, je préférerais un maillage multilingue plus visible.
Mais c'est un choix qui se défend.
Certaines pages catégorie sont énormes
Les pages bodypart de la bibliothèque d'exercices sont très lourdes :
/exercises/bodypart/waist : 75 879 mots, 540 KB de HTML, 90 images
/exercises/bodypart/back : 71 641 mots, 493 KB
/exercises/bodypart/upper-legs : 63 372 mots, 458 KB
/exercises : 65 335 mots, 458 KB
L'intention est claire : lister un maximum d'exercices pour bien distribuer le maillage interne.
Mais à 540 KB par page, sur mobile en 4G, ça se ressent probablement.
Sur les Core Web Vitals, c'est un point d'attention.
La question est de savoir si tout ce contenu doit charger d'un bloc, ou si une partie pourrait être paginée ou chargée progressivement.
1 480 liens App Store et Google Play sans texte d'ancre
Le crawl remonte 1 480 liens externes vers
apps.apple.com ou
play.google.com, tous avec un texte d'ancre vide.
Ils sont présents sur 377 pages.
Ce sont probablement des boutons ou des images cliquables.
Côté SEO pur, ce n'est pas pénalisant.
Côté accessibilité et lisibilité HTML, c'est un point faible.
Et ce sont les CTA les plus importants commercialement du site.
Si ces boutons portaient un libellé clair du type "Download on the App Store" ou "Get it on Google Play", soit dans un texte visible, soit dans un attribut aria-label, ce serait plus propre.
Le schema est très présent, peut-être trop générique
Le site utilise beaucoup de données structurées.
C'est un vrai point positif sur le principe.
Mais le crawl révèle une répétition très lourde :
Organization : 401 pages
WebSite : 401 pages
SearchAction : 401 pages
FAQPage : 376 pages
MobileApplication : 351 pages
HowTo : 343 pages
Le schema MobileApplication apparaît sur 323 pages exercices et 25 pages outils.
Sur une page comme "3/4 Sit-up", l'entité principale devrait probablement être l'exercice : HowTo, muscles ciblés, étapes, erreurs courantes, variantes.
L'app peut rester présente dans le contexte, mais quand le même MobileApplication est poussé sur 351 pages, le signal devient bruité.
Idem pour la FAQPage présente sur 376 pages.
Si chaque page a sa propre FAQ contextualisée, c'est OK.
Si c'est la même FAQ globale dupliquée partout, ça peut envoyer un mauvais signal.
Les points positifs
Plusieurs choses sont bien faites.
Le header Cache-Control est correctement configuré :
s-maxage=31536000, public, max-age=86400, must-revalidate
Cache CDN d'un an, cache navigateur d'un jour, sur Cloudflare.
C'est la première fois sur les quatre audits qu'on voit une configuration de cache aussi propre.
La densité de contenu est élevée : 6 263 mots en moyenne par page, et même les pages les plus thin sont à 1 370 mots.
Pas de contenu vide.
Le contenu est rendu côté serveur.
Pas de dépendance JavaScript pour le crawl.
Contrairement à l'audit Vistia, ici Googlebot reçoit du HTML directement exploitable.
La stratégie de comparaisons concurrentielles est intelligente :
Puna vs Freeletics
Puna vs Hevy
Puna vs Nike Training
Cactus vs WaterMinder
Cactus vs Plant Nanny
Doudou vs Huckleberry
Arnie vs Strong
Ce sont des pages à fort intent commercial, qui peuvent capter des requêtes de comparaison souvent moins concurrentielles que les requêtes pures.
Conclusion
Ce crawl montre un site qui a déjà compris beaucoup de choses en SEO.
Le problème n'est pas un bug bloquant.
C'est plutôt un excès de templating : les mêmes briques techniques sont réutilisées partout, même sur des pages qui auraient mérité d'être traitées spécifiquement.
Si je devais prioriser :
supprimer ou contextualiser la meta keywords copiée partout
nettoyer le canonical de la home
ajouter un libellé propre sur les CTA App Store et Google Play
spécialiser les schemas selon le type de page
ajouter un maillage HTML visible vers les versions multilingues des outils
rééquilibrer le maillage interne pour pousser plus les pages exercices
alléger ou paginer les très grosses pages bodypart
La bonne nouvelle : ce ne sont pas des problèmes profonds.
C'est du nettoyage de template.
Sur un site de 400 pages déjà bien structuré, ce genre de correction peut avoir un effet très propre, et assez rapide.
L'audit peut contenir des erreurs ou manquer de contexte.
Le but reste d'apprendre ensemble sur des cas réels.
Prochain audit : on continue.