AUDIT N°8 â
peaklab.fr
Cet audit a Ă©tĂ© rĂ©alisĂ© avec lâaide dâune IA, Ă partir dâun crawl complet du site. Je le partage tel quel, avec ses qualitĂ©s et ses limites.
PeakLab est une agence de développement web, automatisation et IA pour PME : applications sur mesure, éligibilité CII, résultats garantis par contrat.
Site bilingue FR/EN.
1288 URLs crawlées.
Premier constat : ce nâest pas un site vide ou cassĂ©.
1280 pages répondent en 200, 1269 sont indexables, le contenu est rendu cÎté serveur, la structure FR/EN existe, le sitemap répond en 200, les pages ont des titles, des metas, des H1, du schema et du contenu.
On est face Ă une vraie machine SEO.
Glossaire massif, blog, pages services, cas clients, outils interactifs de lead-gen.
Le problĂšme nâest donc pas âil nây a pas de SEOâ.
Le problĂšme, câest plutĂŽt la cohĂ©rence entre les signaux.
La partie anglaise contient encore beaucoup de français
Câest probablement le point le plus important.
Le site a une vraie structure anglaise avec des URLs en /en/.
Mais sur les 127 pages /en/blog/, 77 ont encore un title entiĂšrement français, alors que lâattribut lang dĂ©clare âenâ.
Exemples :
/en/blog/comment-choisir-une-agence-de-developpement-web-en-2026
Title : âComment choisir une agence de dĂ©veloppement web en 2026 ? | PeakLabâ
/en/blog/claude-vs-chatgpt-vs-gemini-quel-ia-choisir-pour-developper
Title : âClaude vs ChatGPT vs Gemini : quel IA choisir pour dĂ©velopper ?â
/en/blog/astuces-comment-creer-un-cahier-des-charges
Title : âAstuces : Comment crĂ©er un cahier des charges ?â
Donc Google voit une URL anglaise, un lang="en", mais un title français, et probablement du contenu français.
Pour du SEO international, le signal devient confus.
La page risque de ne pas ĂȘtre parfaitement claire pour lâanglais, ni parfaitement propre pour le français.
Ce nâest pas dramatique si la traduction est en cours.
Mais tant que ces pages /en/ ne sont pas réellement traduites, elles brouillent la structure internationale du site.
Chaque page embarque un socle commun énorme
Toutes les pages affichent un volume de texte trÚs élevé.
Sur le glossaire, le minimum observé est autour de 24 500 mots.
Une définition de glossaire ne fait pas 24 500 mots.
Il y a donc trÚs probablement un énorme bloc partagé sur toutes les pages : méga-menu, méga-footer, listes de services, glossaire, blog ou contenus répétés.
Le contenu unique de chaque page existe, mais il est noyé dans un socle commun massif.
ConsĂ©quence : Google reçoit des pages qui se ressemblent Ă©normĂ©ment entre elles, puis doit isoler le vrai contenu spĂ©cifique au milieu dâun gros bloc rĂ©pĂ©tĂ©.
Sur un site programmatique ou semi-programmatique, câest un vrai point dâattention.
Ce nâest pas juste une question de poids HTML.
Câest aussi une question de diffĂ©renciation entre les pages.
Deux outils de lead-gen héritent du title de la home
Le site propose plusieurs outils interactifs intéressants.
Certains sont bien optimisés :
/calculateur-pertes-web
/quiz-revendabilite
/diagnostic-dependance-technologique
Mais deux outils semblent hériter du title générique de la home :
/detective-fuites-argent
/generateur-cahier-des-charges
Ils ont pourtant des H1 propres, comme âDĂ©tective des fuites dâargentâ ou âChat avec lâarchitecte de projetâ.
Le contenu a été pensé.
Mais le title et la meta ne semblent pas avoir suivi.
Dans les SERPs, ces pages risquent donc dâapparaĂźtre avec un titre gĂ©nĂ©rique dâagence au lieu dâun titre centrĂ© sur lâoutil.
Pour des pages de lead-gen, câest dommage, parce que le CTR peut ĂȘtre directement impactĂ©.
Détail au passage : /en/quiz-revendabilite a un title anglais, mais un H1 resté en français.
Huit pages en 404 sont encore dans le sitemap et le maillage
Le crawl remonte 8 pages en 404, avec des chemins FR et EN.
Exemples :
/glossaire/alpine-js
/glossaire/asp-net-core
/glossaire/okr-objectives-and-key-results
/services/agence-ecommerce/startups
Ces URLs sont déclarées dans le sitemap et reçoivent encore des liens internes.
Le pattern ressemble à des slugs renommés sans redirection ou sans nettoyage du sitemap.
Chaque ancienne URL devrait soit rediriger en 301 vers la bonne page, soit sortir du sitemap et du maillage.
Ă noter : ces 404 servent un fallback avec le title de la home et un H1 vide.
Ce nâest pas bloquant, mais la gestion 404 pourrait ĂȘtre plus propre.
La meta keywords est copiée sur les 1288 pages
Toutes les pages servent une balise meta keywords.
Deux listes dominent : une version française sur 652 pages et une version anglaise sur 632 pages.
Exemple cÎté FR :
audit, application web, application, accompagnement, réduction de coût, diagnostic, formation, autonomie, fuites, pertes, optimisation
Google ignore cette balise depuis des années.
Donc ce nâest pas pĂ©nalisant en soi.
Mais elle est dupliquĂ©e partout, ne sert quasiment Ă rien, et rĂ©vĂšle la logique de mots-clĂ©s Ă nâimporte quel concurrent qui regarde le code source.
Sur un site aussi travaillé, je la supprimerais simplement.
1004 pages sur 1280 nâont pas dâog:image
Pour un site qui publie autant de contenu, câest beaucoup.
Blog, glossaire, services, cas clients : toutes ces pages peuvent ĂȘtre partagĂ©es sur X, LinkedIn, Slack ou dans des conversations privĂ©es.
Lâog:image nâest pas un facteur SEO direct.
Mais pour la diffusion sociale, ça compte.
Quand une page sort sans visuel, elle perd une partie de son impact.
Sur une machine de contenu aussi large, les pages importantes devraient avoir une image sociale propre.
Une URL Cloudflare reçoit 1328 liens internes
Le crawl remonte 1328 liens internes vers :
/cdn-cgi/l/email-protection
Câest liĂ© Ă la protection email de Cloudflare.
Le robots.txt bloque bien /cdn-cgi/, donc le crawler ne va pas plus loin.
Mais dans le graphe de liens internes, cette URL technique devient lâune des URLs les plus linkĂ©es du site.
Ce nâest pas le problĂšme du siĂšcle.
Mais câest du bruit inutile.
Sur un site propre, une URL Cloudflare technique ne devrait pas capter autant de liens internes.
HTML trÚs lourd et aucun cache malgré Cloudflare
Le HTML moyen tourne autour de 330 KB.
La home dépasse 835 KB.
Certaines pages services dépassent 600 KB.
Câest probablement liĂ© au gros socle commun du point 2.
à ça sâajoute un Cache-Control trĂšs dĂ©fensif sur les pages :
private, no-cache, no-store, max-age=0, must-revalidate
Cloudflare est devant le site, mais le HTML ressort en DYNAMIC partout.
Pas dâETag.
Pas de Last-Modified.
Donc Googlebot ne peut pas vraiment faire de requĂȘtes conditionnelles propres.
Temps de réponse moyen observé : environ 816 ms, avec des pics à plus de 3,5 secondes.
Quand on combine pages lourdes, cache dĂ©sactivĂ©, pas dâETag, pas de Last-Modified et 1288 URLs, on demande Ă Googlebot de retĂ©lĂ©charger beaucoup de HTML Ă chaque passage.
Pour un site qui vend du dĂ©veloppement web, de lâIA et de la performance, câest un point assez visible.
Quelques détails complémentaires
Certaines URLs /fr/ redirigent vers les versions sans /fr/.
Exemple :
/fr/services/saas â /services/agence-saas
Câest dĂ©fendable si le français est la langue par dĂ©faut, mais ça crĂ©e des chemins un peu hybrides.
Le crawl remonte aussi 353 pages avec title dupliqué, réparties sur 167 titres distincts.
Il y a également un doublon de slug dans le glossaire :
/glossaire/a-b-deployment
/glossaire/ab-deployment
Enfin, beaucoup de liens externes vers
wa.me,
x.com, YouTube ou LinkedIn ont un texte dâancre vide.
Ce sont probablement des icĂŽnes sociales.
Un aria-label propre amĂ©liorerait lâaccessibilitĂ© et la lisibilitĂ© HTML.
Les points positifs
Il y en a beaucoup.
Le site est rendu cÎté serveur.
Le contenu est présent dans le HTML.
Le multilingue est globalement bien construit, avec des hreflang FR, EN et x-default sur beaucoup de pages.
Le sitemap principal répond en 200.
Les pages ont des titles, metas, H1 et du schema.
Le schema est riche : WebSite, Organization, ProfessionalService, FAQPage, AggregateRating, PostalAddress, OpeningHoursSpecification.
La stratégie de contenu est claire : glossaire technique, blog fourni, pages services, cas clients, outils interactifs.
Les outils de lead-gen sont une trÚs bonne idée : calculateur de pertes, quiz de revendabilité, diagnostic de dépendance techno.
LâindexabilitĂ© est saine : 1269 pages indexables sur 1288.
Les images sont plutÎt bien renseignées : 134 sans alt sur 5291, soit environ 3%.
Et le robots.txt bloque certains crawlers dâentraĂźnement IA comme CCBot, Bytespider ou meta-externalagent.
Câest un choix stratĂ©gique qui peut se dĂ©fendre pour une agence qui veut protĂ©ger son contenu.
Conclusion
PeakLab a déjà beaucoup travaillé son SEO.
Ce nâest pas un site cassĂ©.
Câest une base massive, avec de vrais contenus, une structure internationale, des pages services, un glossaire, du blog et des outils.
Les deux vrais sujets sont ailleurs :
la partie anglaise encore trop française sur une partie du blog
le gros socle de contenu dupliqué qui alourdit et uniformise les pages
DerriĂšre, il y a surtout du nettoyage technique et de lâalignement :
404 dans le sitemap
titles génériques sur certains outils
meta keywords copiée partout
og:image absente sur beaucoup de pages
cache HTML désactivé
HTML trĂšs lourd
liens Cloudflare inutiles
titres dupliqués
Si je devais prioriser :
finir proprement les pages /en/blog/
identifier et alléger le socle commun répété sur chaque page
ajouter un title et une meta spécifiques aux outils de lead-gen
corriger les 404 du sitemap et du maillage
supprimer la meta keywords copiée partout
activer un cache HTML public et ajouter ETag ou Last-Modified
ajouter des og:image sur les pages importantes
différencier les titles dupliqués
fusionner ou rediriger les doublons de slug
nettoyer les liens vers /cdn-cgi/l/email-protection
ajouter des labels aux liens sociaux
La bonne nouvelle : la stratégie est déjà là .
Ce ne sont pas des corrections de fond, plutĂŽt de lâalignement, du nettoyage et de lâoptimisation de poids.
Sur un site qui a déjà autant de contenu, ce genre de correction peut avoir un effet trÚs propre.
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.