Construction de SEOReport: De l'heuristique au lancement
En transformant 2 années d'heuristiques d'optimisation web faites à la main en un moteur d'audit, un produit, et un lead $10M.
Developed by Robert E. Beckner III (Merlin) | rbeckner.com
J'ai passé environ 2 années à enrichir les heuristiques à travers mes projets. Je ne construisais pas un produit au début. J'essayais de comprendre pourquoi certains sites apparaissaient et d'autres non.Le travail couvrait plus d'une discipline. Données structurées. Parité mobile. À quelle vitesse une page charge réellement pour un utilisateur réel, pas seulement un score. Si la posture de sécurité d'un site nuisait silencieusement à ses signaux de confiance. Si les moteurs de recherche voyaient le même contenu que les humains. Chaque heuristique m'a appris quelque chose sur l'écart entre "nous avons construit un site web" et "les moteurs de recherche comprennent ce que nous faisons."Grâce à ce raffinement, j'ai créé des formules à travers 50+ heuristiques. Certaines mesuraient la crawlabilité. D'autres mesuraient la parité de rendu entre bots et humains. Quelques-unes suivaient la mise en œuvre standardisée de la sécurité. Les motifs étaient cohérents. Les problèmes étaient structurels. Et ils étaient corrigibles.Un site de prêt a obtenu 65, et nous l'avons porté à 100#
Le vrai test est survenu lorsque j'ai exécuté l'ensemble complet sur le site d'un ami. Il dirige une société de prêt appelée Sphinx Capital. J'avais versé tout ce que j'avais appris dans une refonte de son site.J'ai utilisé ma propre infrastructure pour effectuer un audit privé. Le site a obtenu environ 65 sur 100 contre l'ensemble d'heuristiques. Au cours des 30 prochains jours, nous avons reconstruit la fondation — données structurées, configuration canonique, vitesse de page, rendu mobile, en-têtes de sécurité, toute la pile. Le score a grimpé à 100.Le trafic a commencé à arriver presque immédiatement. C'était le premier signal que les heuristiques n'étaient pas seulement théoriquement solides. Elles fonctionnaient dans un marché réel avec une réelle concurrence.Pendant que le trafic arrivait, j’ai commencé à emballer le moteur d’audit en un produit#
Le moteur s’était déjà prouvé sur un vrai site, alors je l’ai emballé dans un produit appelé the free audit engine I run. La version gratuite est sortie en premier. Je l’ai partagée avec des créateurs indépendants — peintres, musiciens, photographes qui gèrent leurs propres sites sans budget pour une agence. Les rapports leur ont fourni une liste priorisée de corrections structurelles. Beaucoup ont agi et ont vu le trafic s’améliorer en quelques semaines.Le même système de traduction que j’avais construit au cours des 4 dernières années rendait les rapports en 9 langues. Ce n’était pas une fonction que j’ai ajoutée plus tard. C’était l’infrastructure dès le départ. Un artiste en Colombie et un petit prêteur aux États‑Unis pouvaient tous deux lire leurs audits dans leur propre langue sans friction.Je construisais encore le produit pour qu’il soit poli quand le moment est arrivé.Quelqu'un a cherché Google pour un prêt de rénovation et revente et a généré un prospect de $10#
Cela s'est produit environ 30 jours après la refonte terminée. L'utilisateur utilisait un appareil mobile et a rempli la demande de prêt en moins de 5 minutes. Le lead valait $10M.Ce seul résultat de recherche a été le moment où j'ai réalisé que le moteur ne fonctionnait pas seulement. Il fonctionnait pour de l'argent réel, sur des marchés réels, contre une concurrence réelle, sur l'appareil que la plupart des gens utilisent réellement. La base technique que j'avais peaufinée pendant 2 années venait tout juste de générer un lead d'une valeur supérieure à la plupart des budgets marketing annuels — et il est arrivé de façon organique, via la recherche, parce que le site était crawlable, rapide et clair.Après le lancement du moteur d’audit, 1,149 rapports ont révélé le même schéma#
Depuis le lancement de l’outil d’audit gratuit, les schémas ne sont devenus que plus clairs. À travers 1,122 audits gratuits :| % of audits | |
|---|---|
| Security gaps | 88 |
| Performance concerns | 82 |
| Crawlability issues | 81 |
| Canonical/redirect problems | 67 |
| Site architecture gaps | 40 |
graph LR
A[Effectuer un audit technique] --> B{Problème critique trouvé?}
B -->|Oui| C[Corriger en quelques jours]
B -->|Non| D[Optimiser la vitesse]
C e1@--> E[Réindexer]
D --> E
E e2@--> F[Découverte organique]
e1@{ animation: slow }
e2@{ animation: slow }Copy sourceLe problème de découverte est plus important que le contenu#
La plupart des sites échouent à la première étape de la découverte : les moteurs de recherche ne peuvent pas explorer, indexer ou classer leurs pages. Un calendrier de contenu n'a pas d'importance si l'infrastructure sous-jacente est cassée.Les problèmes les plus courants ne sont pas glamour. Ils sont structurels :- Sitemaps manquants ou mal formés — Google ne peut pas trouver vos pages si vous ne lui dites pas où elles se trouvent.
- Pas de balises canoniques — Le même contenu existe à plusieurs URL, répartissant l'autorité entre des doublons.
- Hreflang cassé — Les sites multilingues servent la mauvaise langue à la mauvaise région, ce qui confond les robots d'exploration.
- Ressources bloquant le rendu — Les pages semblent correctes pour les humains mais sont vides pour les bots.
- Temps de réponse serveur lents — Les robots abandonnent les pages avant qu'elles ne soient complètement chargées.