Expertise · SEO
SEO technique et structurel — indexabilité, adresses canoniques, plan de site généré à partir des données, redirections, titres et descriptions, contenu mince, vitesse mesurée en octets. Sans promesses de positions.
Déjà construitDouă implementări proprii, ambele deschise pe disc. Prima: auditul acestui site — 249 de adrese parcurse cu cereri directe, 23 de coloane per adresă, rezultatul într-un fișier tabelar versionat lângă cod, plus reparațiile care au ieșit din el (adresa canonică rezolvată o dată pentru toate rutele, adresa de partajare, harta de site generată din date). A doua: `mega-seo-analyzer`, un analizor propriu cu 16 module de analiză și un scor ponderat scris explicit în cod. Ce nu putem susține și nu vom scrie: poziții obținute sau procente de creștere. Nu avem măsurători publicabile pentru așa ceva.
Le SEO classique est un métier d’inventaire, pas d’idées. Un moteur de recherche doit pouvoir accéder à chaque page, comprendre quelle est sa version officielle, recevoir un titre et une description qui ne se répètent pas et trouver assez de contenu pour mériter une place dans une liste. Presque tout ce qui se casse ici peut se compter, et ce qui peut se compter peut se réparer.
C’est pourquoi nous commençons par un parcours complet, pas par un échantillon. Sur ce site, 249 adresses sont sorties, chacune avec 23 colonnes : code de réponse, adresse canonique, titre, description, hreflang, nombre de blocs de données structurées, volume de texte visible et le reste. Le résultat est un fichier tabulaire versionné à côté du code, donc chaque affirmation ci-dessous peut être reproduite avec les commandes de l’annexe du rapport.
Voici ce qui est sorti : 244 adresses répondent 200 et cinq redirigent. 131 pages n’avaient pas d’adresse canonique. 219 sur 244 déclaraient la page d’accueil comme adresse de partage, donc tout partage affichait la mauvaise page. 100 titres dépassaient 60 caractères, le plus long en ayant 106. 65 pages partageaient une seule description générée à partir du modèle. 96 pages avaient moins de 2.000 caractères de texte visible. Les deux premières ont été corrigées avec une ligne chacune dans l’agencement de base, qui s’applique à chaque route ; le reste est dans la liste de travail, avec une priorité écrite.
Cette page est l’une des trois. Le SEO s’occupe des moteurs qui renvoient une liste de liens. La visibilité dans les réponses générées par des modèles est autre chose et a sa propre page, parce qu’elle se contrôle autrement et — important — ne peut pas être promise. Les réponses directes et les données structurées constituent la troisième. Ce qui est commun aux trois : la page doit être accessible, rendue côté serveur et avoir une seule adresse officielle. Cette partie se fait une fois et sert à tout.
Ce que cela comprend
Requêtes directes vers chaque adresse connue, sans suivre les redirections, avec au maximum six requêtes simultanées pour ne pas déranger le serveur, et 23 colonnes par adresse : code, adresse canonique, titre, description, hreflang, nombre de blocs de données structurées, volume de texte visible. Le résultat est un fichier tabulaire que nous livrons. Sur ce site : 249 adresses, dont 244 répondent 200 et 5 redirigent.
131 pages ne déclaraient aucune adresse canonique, et 219 sur 244 déclaraient la page d’accueil comme adresse de partage — donc tout partage sur les réseaux affichait une autre page. Les deux ont été corrigées avec une déclaration relative dans l’agencement de base, qui se résout pour chaque route séparément. C’est une ligne de code au lieu d’une convention que chaque nouvelle page aurait dû retenir toute seule.
La carte se construit à partir des sources de contenu et passe par une déduplication finale — sur ce site, 147 adresses, le même chiffre dans le code et dans le fichier servi en production. Un script lancé après publication échoue si la carte perd une page ou si apparaissent des variantes d’adresse qui ne s’ouvrent pas. Ce qui manque aujourd’hui, dit comme manque : les entrées ne portent pas de date de dernière modification, et 93 adresses indexables ne sont pas encore incluses.
Lors d’une restructuration, chaque adresse existante reçoit un verdict : elle reste, elle est redirigée définitivement ou elle disparaît. Sur ce site, 43 redirections sont sorties dans la configuration. Vérifiés séparément aussi, les éléments que personne ne teste : le passage du domaine sans `www` à celui avec `www` n’existe qu’une fois ; l’adresse avec une barre finale redirige correctement ; l’adresse écrite en majuscules renvoie 404, donc il n’existe pas de duplicat d’écriture.
100 titres sur 244 dépassent 60 caractères, le plus long en ayant 106 — le risque est la troncature dans les résultats. 33 descriptions dépassent 160 caractères, mais zéro manquent. Plus grave : 65 pages partagent une seule description générée à partir du modèle, et 30 d’entre elles diffèrent entre elles par 240 octets au total. Médiane de texte visible : 2.328 caractères, avec 96 pages sous 2.000. Ce sont des chiffres, pas des impressions, et chacun a une liste d’adresses derrière.
Notre analyseur comporte 16 modules — par page, performance, plan du site, sécurité, accessibilité, infrastructure de noms, informations d’enregistrement du domaine, liens externes, réseaux sociaux, pile technique, positions, recherche de mots-clés, audit général — plus des modules de comparaison : recherche de concurrents, écart de mots-clés, écart de contenu, repères. Le score global est pondéré explicitement dans le code : performance 0,20, SEO 0,20, par page 0,15, sécurité 0,15, réponses directes 0,10, accessibilité 0,10, social 0,10. Les modules qui échouent ne font pas baisser le score — ils sortent de la pondération, afin qu’un service externe en panne ne produise pas un faux rapport.
Une redirection effectuée depuis l’intérieur de l’application construit la page et seulement ensuite envoie la réponse de redirection. Sur ce site, il y a 11 cas de ce type, chacun produisant plus de 200 KB de HTML avant de dire « allez ailleurs ». Cela fonctionne, mais c’est du gaspillage ; les déplacer dans la configuration est un petit travail avec un effet direct sur le budget de crawl. C’est dans la liste des réparations, inscrite comme manque.
J’ai demandé cinq adresses avec 18 identifiants d’agent différents et j’ai comparé le code, la taille et l’empreinte du contenu normalisé. Tous reçoivent 200 et exactement le même contenu qu’un navigateur ; `robots.txt` est identique, 129 octets, pour tous ; il n’y a ni blocage, ni challenge, ni limitation pour les crawlers. La seule différence reproductible — 237 octets de moins sur une page dynamique, pour trois agents — vient du framework lui-même, qui leur envoie du HTML complet non streamé, donc plus de contenu déjà rendu, pas moins.
Nous ne promettons pas de positions, de pourcentages de croissance ni un nombre de visites. Nous n’avons pas de mesures publiables pour cela et nous n’inventons rien. Ce que nous livrons est vérifiable autrement : la liste des adresses avec l’état de chacune, les réparations effectuées, la vérification exécutée après publication et la différence mesurable entre l’état d’avant et celui d’après — en octets, codes et nombres de pages, pas en promesses.
À quoi cela ressemble
La première livraison est le fichier tabulaire avec chaque adresse et son état sur 23 colonnes, plus les commandes qui le reproduisent. À partir de là, toute discussion a une ligne en arrière-plan. C’est aussi le moment où l’on découvre les adresses que personne ne savait exister.
D’abord les choses qui se corrigent à un endroit et s’appliquent partout : l’adresse canonique, l’adresse de partage, le comportement de la page d’erreur, les règles pour les robots. Ensuite celles qui demandent du travail par page : titres, descriptions, contenu mince. L’ordre n’est pas négociable — à l’inverse, vous réparez manuellement une centaine de pages pour quelque chose qui se résolvait avec une ligne.
Le plan est relié aux sources de données, afin qu’une nouvelle page entre d’elle-même. Les anciennes adresses reçoivent des redirections permanentes dans la configuration, pas à l’intérieur de l’application. Nous livrons la liste complète des décisions, adresse par adresse.
Nous livrons un script exécuté après chaque publication, qui échoue si une adresse canonique a disparu, si le plan du site a perdu une page ou si `robots.txt` a commencé à bloquer des ressources de rendu. Sans lui, les réparations s’érodent en quelques mois et personne ne le remarque avant le prochain audit.
Si vous avez la Search Console et un outil d’analyse, nous montons le reporting dessus et nous définissons ce que nous suivons. Si vous n’en avez pas, la première étape est d’en avoir — et nous le disons avant, pas après. Ce que nous ne faisons pas : nous ne rapportons pas des positions d’un outil tiers comme s’il s’agissait de données de source.
Les données
Les questions que pose toute personne ayant un délégué à la protection des données — posées ici avant qu'il ne les pose.
Un cas
La situation
Un site restructuré récemment, avec environ 250 adresses publiques. Toutes répondaient 200 et rien ne semblait anormal. La question de départ n’était pas « comment augmenter le trafic », mais « que déclare chaque page sur elle-même ».
Ce que nous avons construit
Nous avons parcouru chaque adresse avec des requêtes directes, sans suivre les redirections, avec au maximum six requêtes simultanées, et nous avons écrit pour chacune 23 colonnes dans un fichier tabulaire versionné à côté du code. Nous y avons ensuite exécuté des vérifications distinctes : qui déclare quelle adresse canonique, qui déclare quelle adresse de partage, quelles longueurs ont les titres et les descriptions, combien de pages partagent la même description de gabarit, combien de texte visible a chacune, ce que le serveur renvoie pour 18 identifiants d’agent différents, ce qu’il propose en compression et en protocole. Chaque chiffre a été lu dans la réponse réelle, et non déduit de la configuration.
Ce qui en est sorti
244 adresses répondent 200, cinq redirigent. 131 pages ne déclaraient pas d’adresse canonique ; 219 des 244 déclaraient la page d’accueil comme adresse de partage. Les deux ont été corrigées par une déclaration relative dans l’assemblage de base — deux lignes qui s’appliquent à chaque route, au lieu d’une correction sur chaque page. Le reste des constats a été intégré dans un plan en onze étapes, par ordre d’impact : 100 titres de plus de 60 caractères, 65 pages avec une description de gabarit, 96 pages avec moins de 2.000 caractères de texte, 93 adresses indexables absentes de la carte, 11 redirections effectuées depuis l’intérieur de l’application.
Ce que le cas ne dit pas
L’audit a été réalisé sans accès à la console de recherche et sans données de trafic, volontairement, et la limite est écrite dans le rapport : nous pouvons dire ce qui ne va pas techniquement, pas ce qui se passe dans les résultats. Sur les onze étapes du plan, deux sont appliquées aujourd’hui ; le reste sont des travaux ouverts, pas cochés. Un rapport qui déclare toutes les étapes terminées le jour même où elles ont été écrites n’est pas un rapport.
Questions
Le public est différent. Le SEO s’adresse aux moteurs qui renvoient une liste de liens — votre page apparaît, la personne clique. Le GEO s’adresse aux modèles génératifs qui composent une réponse et peuvent citer une source ; il n’y a là ni position ni garantie, donc on travaille sur ce qui peut être contrôlé, pas sur le résultat. L’AEO s’adresse aux réponses directes — l’extrait, le panneau d’information, la réponse vocale — et s’appuie sur des données structurées correctes. La base est commune : une page accessible, rendue côté serveur, avec une seule adresse officielle. Cette partie se fait une fois.
Un fichier tabulaire avec chaque adresse du site et son état sur 23 colonnes — code de réponse, adresse canonique, titre, description, hreflang, blocs de données structurées, volume de texte — plus un rapport écrit avec les constats dans l’ordre d’impact, chacun avec l’emplacement dans le code, le critère et la correction. Et les commandes qui reproduisent chaque chiffre. Sur ce site, 249 lignes sont sorties ; elles sont bien dans le dépôt, à côté du code.
Non, et aucune position particulière non plus. Nous n’avons pas de mesures publiables pour des résultats de ce type et nous n’inventons pas. Ce que nous pouvons montrer, c’est la différence vérifiable : combien de pages n’avaient pas d’adresse canonique avant et combien en ont maintenant, combien déclaraient incorrectement l’adresse de partage, combien d’anciennes adresses sont restées sans redirection. Sur ce site, les chiffres étaient 131, respectivement 219 sur 244. Ce sont des faits ; une position promise ne l’est pas.
Grâce à un script exécuté après chaque publication, qui vérifie les adresses canoniques, les ancres de contenu, le plan du site et `robots.txt`, et échoue si quelque chose a disparu. Les corrections SEO s’érodent exactement comme toute autre convention non écrite : quelqu’un ajoute une nouvelle page, oublie une déclaration, et personne ne le remarque avant l’audit suivant. Un script le remarque immédiatement.
Les deux ont leur utilité, mais l’analyse technique, nous la faisons avec un analyseur propre : 16 modules — on-page, performance, plan du site, sécurité, accessibilité, infrastructure de noms, enregistrement de domaine, liens externes, réseaux sociaux, pile technique, positions, mots-clés — plus des modules de comparaison avec les concurrents. Le score global a des pondérations écrites dans le code, pas cachées : performance et SEO à 0,20 chacun, on-page et sécurité à 0,15 chacun, le reste à 0,10. Un module qui échoue sort du calcul des pondérations au lieu de produire un faux score.
Nous les signalons comme un risque, pas comme une opportunité. Sur ce site, 100 des 147 adresses du plan du site sont des combinaisons service × domaine, et 65 pages partagent une seule description issue du modèle — 30 d’entre elles ne diffèrent entre elles que de 240 octets au total. Un moteur de recherche traite cela comme du contenu produit à grande échelle, et le risque est une sanction, pas un gain de visibilité. La solution est un contenu réel sur chaque page ou moins de pages. Nous ne recommandons pas la génération de pages comme stratégie.
Elle compte, mais pas sous la forme qu’on vend habituellement. Nous ne vous donnons pas un score de laboratoire, parce qu’il est facile à faire varier et qu’il ne dit pas ce qu’un visiteur vit. Nous vous donnons des octets mesurés : combien pèse le HTML compressé, ce qui est transmis à chaque navigation, ce que contiennent les paquets JavaScript, si le serveur offre une compression moderne et un nouveau protocole. Sur ce site : il n’offre ni Brotli ni HTTP/2, le catalogue de traductions coûte environ 70 KB compressés à chaque navigation, et un paquet de 443 KB contient quatre catalogues de langue dont un seul est utilisé. Les trois sont dans la liste des réparations.
C’est une décision du propriétaire du site, pas de nous, et cela exige de séparer trois catégories qui, aujourd’hui, sont traitées de manière identique sur la plupart des sites : les crawlers de recherche qui renvoient des gens vers le site, les agents déclenchés par un humain qui a demandé la page, et les crawlers d’entraînement. Les règles pour eux sont indépendantes. Sur ce site, il existe à ce moment une seule règle générale, donc la position est implicite — et nous le disons, au lieu de prétendre que c’est une stratégie. Les détails relèvent de la page de visibilité dans les réponses générées.
Nous n’achetons pas de liens et nous ne construisons pas de réseaux de sites. Nous ne générons pas de pages à grande échelle pour couvrir des combinaisons de mots. Nous ne rapportons pas des positions reprises d’un outil tiers comme s’il s’agissait de données de source. Et nous ne déclarons pas un audit terminé sans le fichier tableur et les commandes qui le reproduisent — un rapport que vous ne pouvez pas vérifier vous-même n’est pas un audit, c’est un avis.
14 d'entre elles sont du code et des fichiers de nos dépôts. Nous n'en publions ni le nom ni la ligne : réunies sur une seule page, elles décriraient trop précisément comment sont construits des systèmes qui ne sont pas seulement les nôtres. Nous les parcourons avec vous, dans le dépôt, sur demande — la vérification reste possible, elle se fait simplement lors d'un échange.
Racontez-nous votre processus. Ensemble, nous décidons ce qui vaut la peine d'être construit, ce que nous pouvons connecter et comment nous vérifions le résultat.