Le problème : une page invisible pour Google

J'avais déployé mehdibuilds.pages.dev après plusieurs sessions de design - palette, typographie, structure, contenu. Le résultat était visuellement propre. Mais côté SEO, la page était nue.

Audit rapide : voici ce qui manquait.

  • Pas de <meta name="description">
  • Pas de balise canonical
  • Pas de tags Open Graph (partage sur X, LinkedIn : lien brut sans preview)
  • Pas de Twitter Card
  • Pas de JSON-LD Schema.org
  • Heading hierarchy cassée : plusieurs <div class="section-title"> au lieu de <h2>
  • Pas de <h1> du tout dans le DOM
  • Doublon silencieux : index.html et mehdi-builds-pitch.html - deux versions désynchronisées

Chaque point seul n'est pas bloquant. Ensemble, ils signalent à Google une page non structurée, non identifiable, sans contexte social. Résultat : pas d'indexation propre, pas de rich snippets, partages sociaux sans aperçu.

Contexte

La page est un single-file HTML - pas de framework, pas de build step, pas de Next.js. Tout le SEO est donc injecté directement dans le <head> du fichier.

TÂCHE 1 : Injection du head SEO complet

La première étape était mécanique mais critique : injecter tous les blocs manquants en tête de fichier.

Canonical + meta description

Une seule URL canonique pour éviter le duplicate content si la page est un jour accessible via plusieurs chemins. La meta description est le premier texte visible dans les SERPs - 155 caractères max, mot-clé principal en premier. 

<meta name="description" content="Builder IA par méthode. Agents autonomes,
stack souveraine RGPD-native, prospection B2B automatisée. Paris 2026." />
<link rel="canonical" href="https://mehdibuilds.pages.dev/" />

Open Graph + Twitter Card

Sans ces balises, un lien partagé sur X ou LinkedIn affiche juste l'URL. Avec, il affiche titre, description et image. Pour une page personnelle, c'est la différence entre un lien mort et un vrai signal de crédibilité. 

<meta property="og:type"        content="website" />
<meta property="og:url"         content="https://mehdibuilds.pages.dev/" />
<meta property="og:title"       content="MehdiBuilds - Agent IA & automatisation B2B" />
<meta property="og:description" content="Builder IA par méthode..." />
<meta name="twitter:card"       content="summary_large_image" />
<meta name="twitter:creator"    content="@MehdiBuilds" />

JSON-LD Schema.org : Person + WebSite

Le schema JSON-LD est la pièce la plus sous-estimée. Il donne à Google une description structurée de l'entité - qui je suis, ce que je fais, mes liens sociaux. C'est ce qui permet les rich results dans les SERPs sur une requête de nom propre. 

{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "MehdiBuilds",
  "url": "https://mehdibuilds.pages.dev",
  "jobTitle": "Builder IA - VibeCraft Agency",
  "sameAs": ["https://x.com/MehdiBuilds", "https://x.com/VibeCraftAgent"],
  "knowsAbout": ["Agents IA", "Automatisation B2B", "Claude Code", "Stack souveraine RGPD"]
}

TÂCHE 2 : Restructuration sémantique H1 / H2 / H3

Une page HTML bien structurée a une hiérarchie de titres cohérente : un seul <h1>, des <h2> pour chaque section, des <h3> pour les sous-éléments. C'est un signal de structure pour Google, mais aussi pour les lecteurs d'écran.

Sur ma page, tous les titres de section étaient des <div> avec une classe CSS. Visuellement identiques, sémantiquement muets.

Le H1 : la tagline, pas le nom

Choix stratégique : le <h1> porte la tagline "builder IA par méthode." - pas le nom de marque. Raison : le nom @MehdiBuilds est déjà dans la balise <title>, le schema Person et l'URL. Le H1 doit cibler un mot-clé sémantique, pas répéter une identité déjà signalée.

6 H2, 8 H3

Un <h2> par section principale (QUI, BUILD, PRODUITS, FORMATION, AGENCY, BUILD IN PUBLIC). Un <h3> par carte produit (FounderSales, MarketingPilot, GrowthPilot, score-leads.py) et par étape Agency (Audit Stack IA, Rapports IA, Funnel System, Workflows GTM IA).

Le changement est purement dans le markup. Le rendu visuel reste identique - le style CSS reste accroché à la classe, pas à la balise.

TÂCHE 3 : Fix du doublon silencieux

Problème découvert en fin de session : deux fichiers coexistaient dans le répertoire de déploiement - index.html et mehdi-builds-pitch.html. Cloudflare Pages sert index.html par défaut. Or, index.html était une version antérieure, avant toutes les corrections.

Tout le travail SEO et sémantique était donc dans mehdi-builds-pitch.html, invisible en production.

Fix : copier mehdi-builds-pitch.html vers index.html, supprimer le doublon. Un seul fichier, une seule source de vérité.

Leçon retenue

Un déploiement sans vérifier quel fichier est réellement servi, c'est du travail qui disparaît en silence. Toujours inspecter l'URL de prod après chaque push.

Résultat : ce que la page signale maintenant

  • Meta description + canonical
  • Open Graph complet - previews sur X et LinkedIn
  • Twitter Card summary_large_image
  • JSON-LD Person + WebSite - rich results potentiels sur requête de marque
  • Un seul H1 sémantique sur le mot-clé principal
  • 6 H2 + 8 H3 - hiérarchie complète
  • Un seul fichier en production - plus de doublon

Le tout en un seul fichier HTML statique, sans framework, sans build step, sans plugin. Déployé sur Cloudflare Pages, servi en moins de 50ms depuis le edge.

Ce qui m'a permis de faire ça vite : Claude Code + Hermes Gateway sur VPS. Je décris le diagnostic, Hermes exécute les patches. Chaque modification est une instruction précise sur un fichier précis - pas de génération magique, pas de réécriture complète. De la chirurgie.

C'est exactement ce que je déploie chez des clients : des systèmes qui s'exécutent vite, modifiés avec précision, versionnés proprement.