Avant de proposer le SEO technique comme service, nous avons fait ce que la plupart des agences évitent : nous avons retourné le processus contre nous-mêmes.
Nous avons lancé un audit technique complet sur prixelo.com. Pas un environnement de staging, pas un site de démo — le vrai site, celui que les prospects regardent avant de nous écrire. Nous nous attendions à quelques petits problèmes. Nous avons trouvé sept choses qui jouaient activement contre nous.
Cet article est cet audit, tel quel. Pas de client composite, pas d'étude de cas inventée. Juste ce que nous avons trouvé sur notre propre site, et ce que chaque bug nous apprend sur la façon dont les moteurs de recherche voient réellement une page, par rapport à la façon dont un navigateur vous l'affiche.
Le sitemap omettait la majeure partie du site
Nous avons ouvert sitemap.xml en nous attendant à une simple formalité. Nous avons trouvé un fichier qui ne listait qu'une fraction de nos pages réelles. Des sections entières du site — des pages que nous avions mises en ligne, liées en interne, et censées se positionner — en étaient tout simplement absentes.
Un sitemap n'est pas un simple bonus. C'est la carte que vous remettez à Google pour qu'il n'ait pas à deviner la structure de votre site en suivant uniquement les liens. Une page en ligne, liée en interne, mais absente du sitemap peut finir par être indexée, mais c'est plus lent, moins fiable, et cela signale aux robots que les métadonnées de votre site ne sont pas fiables. Si le sitemap se trompe une fois, un robot a moins de raisons de le considérer comme faisant autorité ailleurs.
Notre JSON-LD Organization était cassé sur tout le site
Nous vérifions systématiquement nos données structurées avec un validateur. Les nôtres échouaient. Sur chaque page.
La cause était un bug d'échappement dans le template — un caractère de notre schéma Organization était mal encodé au moment du rendu, ce qui rendait le bloc JSON-LD syntaxiquement invalide sur chaque page où il apparaissait. Google ne parse pas partiellement un JSON cassé. Soit il le parse proprement, soit il rejette le bloc entier. Donc, depuis un temps indéterminé, nous avions zéro donnée structurée qui parvenait à Google, sur tout le site, tout en croyant disposer d'un balisage complet. C'est le genre de bug qui ne produit aucune erreur dans un navigateur — la page a l'air normale — et aucun avertissement, à moins d'aller spécifiquement le chercher dans un validateur de schéma ou dans le rapport des résultats enrichis de Search Console.
Des soft-404 qui renvoyaient un code HTTP 200
Certaines URL cassées ou supprimées du site ne renvoyaient pas de statut 404. Elles servaient un contenu de repli — une page générique — pendant que le serveur disait au navigateur et à tous les robots : « 200 OK, cette page existe ».
C'est ce qu'on appelle un soft-404, et c'est pire qu'un vrai 404. Un vrai 404 dit clairement aux moteurs de recherche : cette URL a disparu, retirez-la de l'index. Un soft-404 leur dit : cette URL va bien, continuez à la crawler et à l'indexer, même s'il n'y a rien ici. Laissé tel quel, cela gaspille le budget de crawl sur des pages qui n'existent pas et peut diluer l'évaluation de vos vraies pages, car le robot dépense du temps et de la confiance sur des impasses qui se prétendent actives.
Des balises canonical pointant vers le mauvais domaine
Plusieurs pages avaient des balises canonical qui référençaient la version sans www de notre propre domaine, laquelle redirige elle-même ailleurs — un reliquat d'une configuration antérieure. Une balise canonical est une instruction directe adressée aux moteurs de recherche : « indexez cette URL comme la version faisant autorité, pas celle que vous consultez actuellement ». Quand elle pointe au mauvais endroit, vous dites explicitement à Google de créditer une autre URL pour votre propre contenu. Dans le meilleur des cas, elle est ignorée. Dans le pire des cas, vous détournez activement vos propres signaux de positionnement loin de la page qui en a besoin.
Des meta descriptions tronquées en plein mot
Un problème plus mineur, mais du genre qui érode la confiance à force de s'accumuler : plusieurs meta descriptions étaient coupées en plein mot directement dans le HTML brut, pas seulement tronquées à l'affichage dans les résultats de recherche. C'est un bug de template ou de limite de caractères, pas un artefact d'affichage, et cela se traduit par des phrases inachevées dans vos balises <meta> — visibles par quiconque consulte le code source, et un petit signal, mais bien réel, de négligence sur une page qui cherche à paraître crédible.
Un robots.txt obsolète servi depuis un répertoire antérieur au site actuel
C'était la découverte la plus étrange. Le robots.txt réellement servi n'était pas celui de notre base de code actuelle. Il provenait d'un ancien répertoire hérité, resté sur le serveur — un vestige d'une version précédente du site qui aurait dû être entièrement retirée. L'application en production n'avait aucune idée que ce fichier existait, ni que c'était lui que les robots lisaient réellement.
robots.txt est l'un des premiers fichiers qu'un robot demande. Si la version servie est obsolète, elle peut bloquer des chemins qui devraient être crawlables, en autoriser d'autres qui ne devraient pas l'être, ou simplement pointer vers un sitemap qui n'existe plus. Et comme il vit en dehors de votre chemin de déploiement habituel, il est invisible pour quiconque examine la base de code actuelle — il faut vérifier ce qui est réellement servi à cette URL, pas ce que vous pensez avoir mis en ligne.
Des pages qui disaient « introuvable » aux robots à cause d'une détection de slug uniquement côté client
Le dernier est un problème de rendu JavaScript, et c'est un piège classique pour tout ce qui repose sur du routage côté client. Certaines pages déterminaient le contenu à afficher à partir d'un slug qui n'était résolu que dans le navigateur, après l'exécution du JavaScript. Les robots qui n'exécutent pas entièrement le JavaScript côté client — ou qui expirent avant que la résolution n'aboutisse — reçoivent la réponse initiale du serveur, ne trouvent aucun slug correspondant, et se voient servir un état « introuvable ». La page fonctionne parfaitement pour un humain. Elle est invisible ou cassée pour un robot qui ne va jamais assez loin pour voir le vrai contenu.
Ce que cela nous apprend vraiment
Aucun de ces bugs n'est exotique. Ce sont les modes de défaillance classiques de tout site qui a grandi au-delà de sa première version : de l'infrastructure héritée que personne n'a mise hors service, un changement de template qui a discrètement cassé l'encodage, un schéma de routage optimisé pour les utilisateurs mais jamais vérifié du point de vue des robots. Chacun de ces problèmes était invisible dans un navigateur normal, et invisible à moins de chercher spécifiquement à voir la page comme la voit un robot, pas comme la voit une personne.
C'est ça, le vrai travail. Le SEO technique, ce n'est pas des suggestions de mots-clés ou des calendriers éditoriaux — c'est trouver l'écart entre ce à quoi votre site ressemble pour vous et ce à quoi il ressemble pour les systèmes qui décident de l'indexer et de le positionner. Nous avons corrigé les sept problèmes sur notre propre site en construisant notre service de SEO, parce que nous n'allions pas vendre un audit que nous n'avions pas d'abord fait passer sur nous-mêmes.
Si vous voulez savoir si votre propre site souffre de variantes de ces mêmes problèmes, c'est exactement ce que notre équipe SEO vérifie en premier — avant toute conversation sur le contenu ou le positionnement.
