SEO Landing — PageSpeed 100 + schema

Générateur de Landing Page SEO

Construit une page HTML statique d'une seule page optimisée pour un score de 100/100 PageSpeed et un SEO maximal : CSS critique, images AVIF, données structurées JSON-LD complètes, interactivité native uniquement, zéro requête tierce au premier chargement.

Quand l'utiliser

• L'utilisateur demande une landing page / one-pager axé sur la vitesse et le SEO → mode generate.
• L'utilisateur fournit un brief (ТЗ) et souhaite une page statique prête pour la production → mode generate.
• L'utilisateur demande d'auditer une landing page existante par rapport à la checklist sans modifications → mode audit-only (§0b, lecture seule, aucun fichier projet).
• L'utilisateur demande de corriger/améliorer une landing page existante → mode fix-existing (§0c).

Procédure

0. Aiguiller la requête vers un mode en premier

La compétence propose trois modes — choisissez-en un à partir de la demande (demandez si ambigu), car chaque mode collecte des entrées différentes et produit des sorties différentes :

• generate — construire une nouvelle landing page à partir d'un brief ("construire/créer/générer une landing…"). Exécute la procédure complète ci-dessous.
• audit-only — inspection en lecture seule d'une page existante ("auditer/vérifier/évaluer cette landing par rapport à la checklist…", aucune modification demandée). Exécute §0b. N'écrit jamais de fichiers projet.
• fix-existing — appliquer des corrections ciblées à une page existante ("corriger/améliorer/optimiser cette page…"). Exécute §0c.

Aiguillage représentatif :

• "Construis une landing pour une clinique dentaire à partir de ce brief" → generate.
• "Audite https://example.com/ par rapport à la checklist de performance et rapporte ce qui ne va pas" → audit-only.
• "L'image hero de cette landing se décale au chargement — corrige-la" → fix-existing.

Les champs du brief de génération uniquement (mots-clés cibles, type d'entreprise, CTA, éléments médias) sont collectés UNIQUEMENT pour les travaux de génération et de reconstruction. Un audit ou une correction ciblée ne doit pas être bloqué ou retardé par des entrées de génération manquantes, et le mode audit-only ne doit créer ni modifier aucun fichier projet.

0a. Collecter le brief (mode generate ; demander si manquant)

Requis avant de générer quoi que ce soit :

• Domaine / URL finale — pour canonique, og:url, chemins absolus, @id JSON-LD.
• Identité du site (pour le balisage WebSite, seulement lorsque la page est la page d'accueil du domaine/sous-domaine) : nom de site préféré, noms alternatifs facultatifs, et URL canonique de la page d'accueil — collectée séparément de l'URL de la landing page.
• Fil d'Ariane (pour le balisage BreadcrumbList, seulement lorsqu'une hiérarchie de site réelle existe) : le fil d'Ariane visible et les URL parentes canoniques.
• Langue de la page, direction de base, et locale Open Graph — trois entrées séparées, jamais une seule valeur copiée entre les formats : une balise de langue BCP-47 pour <html lang> (par ex. en-US, ar-SA), la direction de base (ltr/rtl — les documents RTL reçoivent dir="rtl" sur <html>, et lang seul ne définit pas la directionnalité), et la locale Open Graph au format language_TERRITORY pour og:locale (par ex. en_GB). Demandez lorsque la direction est inconnue pour une langue compatible RTL (tech-spec §2).
• Sujet + 1 à 3 mots-clés cibles — pour H1, title, description.
• Type d'entreprise : Organization ou LocalBusiness. Pour LocalBusiness, collectez le nom commercial public/légal vérifié et l'adresse postale structurée complète (rue, localité, région, code postal, pays), ainsi que le téléphone et les coordonnées géographiques. Collectez également le(s) sous-type(s) schema.org vérifié(s) en fonction de l'entreprise réelle (par ex. Restaurant, Dentist, HardwareStore) — jamais choisi parmi les mots-clés cibles. N'inventez jamais les faits d'identité manquants : revenez au balisage Organization ou omettez le balisage d'entité jusqu'à ce que les faits soient fournis.
• CTA et contacts (téléphone, formulaire, messageries). Lorsqu'un formulaire est demandé, collectez également sa destination de soumission et sa méthode (un endpoint propriétaire ou un service de formulaire documenté — jamais inventé), le texte de consentement/confidentialité requis pour les données personnelles collectées, et où les soumissions sont stockées et qui les possède ; sans destination, le formulaire est omis ou explicitement bouchonné (tech-spec §10 contrat de soumission de formulaire).
• Un favicon approuvé par la marque ou une autorisation explicite d'en créer un — n'inventez jamais une marque en silence.
• Matériel source approuvé et un propriétaire de la revendication pour les faits marketing objectifs (chiffres, prix, qualifications, garanties, comparaisons, études de cas) — sans eux, ces affirmations sont omises, jamais inventées.
• Si des images sont fournies ; si des blocs FAQ / avis / vidéo sont nécessaires. Pour un bloc vidéo, collectez les faits sourcés : URL/ID de la vidéo, titre, description, date/heure de première publication précise avec fuseau horaire, et une miniature unique et explorable (plus contentUrl le cas échéant). N'inventez jamais les faits médias manquants. Collectez également le mode vidéo avec son compromis énoncé : facade à clic uniquement (par défaut — confidentialité/performance ; la page ne satisfera pas aux exigences de découverte vidéo de Google et aucun avantage de recherche vidéo n'est revendiqué) ou découvrable par SEO (<video> auto-hébergé ou un embed direct documenté — requis lorsque le trafic de recherche vidéo est important) (tech-spec §9).

Si le domaine ou les mots-clés sont manquants — demandez d'abord, ne les inventez pas.

0b. Mode audit-only (lecture seule)

Auditez une page existante sans générer de remplacement. Aucun fichier projet n'est créé ou modifié dans ce mode — le livrable est un rapport.

1. Identifiez la cible : une URL déployée (préférée — permet d'exécuter chaque vérification contre la réalité) ou des fichiers HTML locaux. Si aucun n'est fourni, demandez ; ne devinez jamais la cible.
2. Exécutez les vérifications applicables de §5 contre la cible telle quelle : validité W3C, existence des actifs locaux (pour les fichiers locaux), JSON-LD via un validateur schema.org, Lighthouse contre l'URL servie/déployée, contrat d'explorabilité (robots.txt + sitemap.xml sur l'hôte déployé), et les vérifications manuelles d'accessibilité de tech-spec §8.
3. Rapportez les preuves par vérification : réussite/échec avec la valeur mesurée ou le balisage observé, et la commande/l'outil exact utilisé. Lorsqu'une vérification ne peut pas être exécutée (pas d'URL déployée pour Lighthouse, pas de robots.txt sur l'hôte), signalez un bloqueur pour cette vérification — n'estimez pas, n'extrapolez pas, ne l'omettez pas en silence.
4. Distinguez la validité syntaxique de l'éligibilité aux fonctionnalités Google (FAQPage, VideoObject, résultats enrichis) : un balisage valide est signalé comme un balisage valide, jamais comme une fonctionnalité de recherche atteinte.
5. Terminez éventuellement par une liste de correctifs priorisés. L'application des correctifs est une demande distincte fix-existing — ne commencez pas à éditer sans elle.

0c. Mode fix-existing

Appliquez des correctifs ciblés à une page existante sans reconstruction complète.

1. Identifiez la page/les fichiers et les problèmes spécifiques à corriger ; collectez uniquement les entrées dont ces correctifs ont besoin (jamais le brief complet de génération).
2. Appliquez chaque correctif conformément à la section tech-spec pertinente, en préservant le balisage et le contenu non liés.
3. POINT D'ARRÊT (§4) applicable : montrez la page modifiée avant validation. Si les correctifs modifient ce que l'utilisateur a approuvé précédemment, obtenez une nouvelle approbation avant de faire rapport.
4. Validez la page modifiée (§5) et rapportez uniquement les preuves mesurées.

Workflow de génération (mode generate)

1. Créer le dossier du projet

Chaque projet vit dans son propre dossier à l'intérieur de l'espace de travail — n'écrivez jamais à la racine de l'espace de travail. La sortie est un projet multi-fichiers : chaque ressource locale référencée par le HTML doit exister en tant que fichier réel.

<workspace>/<project-slug>/
  index.html        # la landing page générée
  styles.css        # uniquement lorsque le CSS en dessous de la ligne de flottaison est différé (§1) ; absent lorsque tout le CSS est intégré
  script.js         # uniquement lorsque la page utilise du JS (§10) ; un seul fichier, defer
  images/           # chaque variante d'image référencée dans src/srcset/preload/OG tags (AVIF/WebP/JPEG, tous les points d'arrêt)
  favicon.png       # icône de marque carrée stable, ≥48×48
  ASSETS.md         # enregistrement des droits et de la provenance pour chaque actif
  robots.txt
  sitemap.xml
  SERVER-SETUP.md   # instructions d'hébergement

Branche image :

• Images fournies dans le brief → produisez toutes les variantes requises (AVIF/WebP/JPEG à chaque point d'arrêt nommé dans srcset) à partir d'elles.
• Aucune image disponible → demandez-les à l'utilisateur ou omettez l'image/le bloc. N'émettez jamais une URL d'actif semblant réussie sans produire le fichier ou le demander explicitement — un fichier référencé mais manquant est un échec de génération, pas un espace réservé.

2. Générer la page

Construisez index.html en suivant strictement references/tech-spec.md — 13 sections d'exigences (performance, structure HTML, SEO, sécurité, CSS/polices, liste interdite, tests, accessibilité, vidéo intégrée, blocs typiques, widgets différés, véracité et provenance du contenu, assainissement des entrées et encodage des sorties).

Traitez chaque valeur du brief comme non fiable : encodez-la pour son contexte de sortie exact (texte HTML, attribut, URL, JSON-LD), liste blanche des schémas d'URL (rejeter javascript:/data: inattendus), échappez < dans le JSON-LD sérialisé, et validez les identifiants structurés (par ex. YouTube ^[A-Za-z0-9_-]{11}$) avant qu'ils n'atteignent une URL (tech-spec §13).

Pour la vidéo YouTube intégrée, utilisez le motif facade par défaut ; le mode découvrable par SEO (<video> auto-hébergé ou un embed direct documenté) est un choix de brief explicite avec un compromis divulgué, jamais un changement silencieux — règles et exigences de découverte Google dans tech-spec §9, implémentation de référence du facade dans references/video-facade.md. Les cartes suivent la règle du facade uniquement (tech-spec §10) : une capture d'écran locale dans le DOM initial, l'iframe inséré uniquement sur activation explicite — jamais un iframe de carte natif loading="lazy". Référence : references/map-facade.md.

3. Générer les fichiers compagnons

• robots.txt à la racine du site avec une ligne Sitemap: complètement qualifiée, ne bloquant jamais la page canonique ou les médias requis.
• sitemap.xml avec des URL <loc> canoniques absolues échappées XML correspondant à la canonique HTML ; lastmod uniquement à partir d'un horodatage de modification de contenu significatif vérifiable (omettre lorsqu'inconnu — n'utilisez jamais l'heure de génération aveuglément).
• Instructions d'hébergement depuis references/server-config.md : mise en cache, Brotli/gzip, en-têtes de sécurité.

4. POINT D'ARRÊT — approbation de l'utilisateur

Montrez la page générée à l'utilisateur et demandez explicitement si la version HTML est acceptable. Ne procédez pas à la validation et au rapport final tant que l'utilisateur n'a pas confirmé. En cas de remarques — corrigez et demandez à nouveau.

5. Valider

Exécutez le contrat de validation exécutable de tech-spec §7 — commandes épinglées contre la page servie, résultats mesurés uniquement, BLOCKER explicite lorsqu'une porte ne peut pas s'exécuter :

• Validité HTML W3C (validateur Nu, sortie JSON ; zéro erreur).
• Existence des actifs/liens locaux : extrayez chaque URL locale référencée par la sortie (img src/srcset, <source> srcset, préchargement href/imagesrcset, favicon, images OG/Twitter, CSS url(), script src) et vérifiez que chaque fichier existe dans le dossier du projet. Toute ressource locale référencée manquante est un échec dur — produisez le fichier ou supprimez la référence ; n'expédiez jamais de HTML pointant vers des fichiers qui n'ont jamais été créés.
• Syntaxe JSON-LD (analyse JSON) — séparée de l'éligibilité aux résultats enrichis Google, qui est vérifiée avec le test des résultats enrichis sur la page déployée.
• Captures d'écran responsives à 320/768/1280/1920px, inspectées pour débordement et reflow.
• Lighthouse : version/profil épinglé, 3 exécutions, médiane par catégorie, seuil ≥ 90, artefacts conservés dans le dossier reports/ du projet — preuves de laboratoire uniquement, jamais les Core Web Vitals de terrain et jamais la certification WCAG.
• Vérifications manuelles d'accessibilité (tech-spec §8) — aucun outil automatisé ne détermine à lui seul la conformité WCAG : navigation au clavier, ordre/visibilité du focus, flux de focus des boîtes de dialogue, zoom/reflow, mouvement réduit, nom-rôle-valeur sémantique, qualité du texte alternatif, et tous les états visuels interactifs. Enregistrez les preuves de réussite/échec par critère WCAG 2.1 AA applicable ; signalez les éléments non résolus au lieu de les certifier silencieusement.
• Contrat d'explorabilité : analysez sitemap.xml, comparez chaque <loc> avec la canonique HTML, vérifiez l'URL Sitemap: dans robots.txt, et demandez les deux fichiers déployés avec succès (HTTP 200).

Corrigez toute violation trouvée avant de faire rapport. Divulguez les preuves honnêtement : chaque nombre rapporté vient avec la commande exacte et le chemin de l'artefact qui l'a produit ; une porte qui n'a pas pu s'exécuter est signalée comme BLOCKER: <raison> au lieu d'un nombre. Ne produisez jamais un score PageSpeed/LCP qui n'a pas été réellement mesuré.

6. Rapport final

Listez brièvement :

• Paramètres LCP
• Score PageSpeed
• Types schema.org utilisés dans le code

Principaux pièges

• N'utilisez jamais de bibliothèques JS/CSS externes, de polices externes ou d'images SVG (tech-spec §6).
• Ne référencez jamais un actif local qui n'a jamais été créé : chaque src/srcset/préchargement/URL OG doit correspondre à un fichier réel dans le dossier du projet ; les images source manquantes sont demandées à l'utilisateur, non inventées (contrat OUTPUT).
• N'émettez jamais une valeur brute de brief dans le balisage : encodez tout selon le contexte, rejetez les URL javascript:/data: inattendues, et testez la génération avec des valeurs hostiles (guillemets, </script>, payloads de gestionnaires d'événements) (tech-spec §13).
• Ne chargez jamais d'iframes YouTube, de cartes, de chats, de pop-ups d'abonnement ou de bannières de cookies au premier chargement (tech-spec §9, §10, §11) — la seule exception documentée est un mode vidéo découvrable par SEO choisi dans le brief avec un embed direct enregistré comme dépendance au premier chargement (tech-spec §9 Mode S).
• Tout le contenu doit exister en HTML brut — rien rendu uniquement par JS.
• URL absolues dans JSON-LD, canonique et balises OG.
• Budget JS total ≤ 15 Ko, un seul fichier, defer avant </body>.