Landing page SEO : publier, structurer, valider

Créer des pages d'atterrissage SEO

Utilisez cette compétence pour créer, améliorer, auditer, déployer ou valider des pages d'atterrissage.

N'utilisez pas cette compétence pour de simples modifications de texte, de style ou de composant, sauf si le SEO, la conversion, l'accessibilité, les performances, le déploiement ou l'état de préparation au lancement font partie de la demande.

Flux de travail principal

1. Inspectez le projet existant avant de modifier.
2. Identifiez l'entreprise/entité, le public, l'emplacement, les services, l'objectif de conversion et la cible de déploiement.
3. Identifiez la pile technologique et respectez ses conventions.
4. Vérifiez les métadonnées, les titres, les données structurées, le sitemap, les robots (y compris l'accès des robots IA), llms.txt, le favicon, le manifeste, les aperçus sociaux et les faits commerciaux visibles.
5. Examinez la mise en page responsive, l'accessibilité, le dimensionnement des images, le chargement JavaScript et les risques de CLS (Cumulative Layout Shift).
6. Effectuez des modifications concrètes de fichiers en utilisant le style du projet existant.
7. Exécutez les outils de validation disponibles ou fournissez les commandes exactes si bloqué.
8. Résumez les modifications, la vérification, les risques restants et les étapes post-lancement.

Priorités par défaut

• Rendre la première zone d'affichage claire : entité, offre, emplacement ou public, et CTA principal.
• Garder les faits importants visibles dans le HTML, pas seulement dans les métadonnées ou les JSON-LD.
• Privilégier le schéma Service pour les services ; utiliser le schéma Product uniquement avec des données d'offre de produit réelles.
• Pour les entreprises locales, privilégier la cohérence NAP (nom, adresse, téléphone), les zones de service, les horaires d'ouverture, les liens vers les cartes/profils, les avis et les photos réelles.
• Considérer le nom de domaine personnalisé, le profil Google Business, les avis, les citations, la Search Console et les photos réelles comme un travail de lancement/hors site, pas seulement des ajustements de code.
• Après un changement de domaine ou de déploiement, mettre à jour le canonique, le sitemap, l'URL du sitemap dans robots.txt, les URL des données structurées, les URL des images sociales et la propriété Search Console.
• Ne pas simuler de notes, d'avis, de garanties, de classements, d'indexation, de Core Web Vitals, de scores Lighthouse/PageSpeed, d'état de déploiement, d'état de citation IA/AI Overview, ou de résultats d'API.
• Les schémas FAQ et HowTo ne produisent plus de résultats enrichis Google (FAQ supprimé le 7 mai 2026 ; HowTo supprimé en 2023) ; gardez le schéma FAQPage pour la compréhension par l'IA/les moteurs de réponse, pas pour une fonctionnalité SERP promise.
• Demandez au propriétaire du site avant de modifier l'accès des robots IA dans robots.txt ; cela modifie l'exposition réelle aux citations des assistants et à l'entraînement des modèles. Notez que les AI Overviews/AI Mode de Google sont régis par l'accès normal de Googlebot et les contrôles de la Search Console, pas par les jetons de robots IA.
• llms.txt est une hygiène optionnelle sans gain prouvé de classement ou de citation, et Google déclare qu'il n'est pas nécessaire pour les fonctionnalités IA ; proposez-le, ne le vendez pas comme un gain de visibilité IA.
• Faites correspondre le design au type de page et au public ; privilégiez la clarté, la confiance, la convivialité mobile et la conversion plutôt que la décoration.

Quand lire les références

• Pour le flux de construction et la structure de la page, lisez references/landing-page-workflow.md.
• Pour les détails d'implémentation spécifiques au framework, lisez references/framework-implementation.md.
• Pour les textes de page d'atterrissage, les CTA et les signaux de confiance, lisez references/content-conversion.md.
• Pour les vérifications SEO, AEO, GEO et de recherche locale, lisez references/seo-aeo-geo-checklist.md.
• Pour les sites web d'entreprises locales, lisez references/local-business-seo.md.
• Pour les préoccupations relatives aux JSON-LD et aux résultats enrichis, lisez references/structured-data.md.
• Pour le travail sur les performances, l'accessibilité et le CLS, lisez references/performance-accessibility.md.
• Pour les scripts de validation, Lighthouse/PageSpeed, Search Console et le reporting, lisez references/validation-workflow.md.
• Pour le déploiement, les domaines, la Search Console et le profil Google Business, lisez references/deployment-domain-search-console.md.
• Pour llms.txt, l'accès des robots IA et le reporting de recherche IA, lisez references/ai-crawlers-and-llms-txt.md.
• Pour WebMCP, les outils appelables par les agents et les formulaires prêts pour les agents, lisez references/webmcp.md.

Modèles

Utilisez les modèles uniquement comme points de départ. Adaptez-les au projet avant de les insérer :

• templates/metadata-head.html
• templates/site.webmanifest
• templates/robots.txt
• templates/sitemap.xml
• templates/local-business-jsonld.html
• templates/website-jsonld.html
• templates/website-with-search-jsonld.html - hérité ; son SearchAction ne produit plus de fonctionnalité Google
• templates/organization-jsonld.html
• templates/person-jsonld.html
• templates/breadcrumb-jsonld.html
• templates/faq-jsonld.html
• templates/service-offer-catalog-jsonld.html
• templates/static-landing-page.html
• templates/launch-checklist.md
• templates/privacy-notice.md
• templates/llms.txt

Scripts

Les scripts sont des aides facultatives. Exécutez-les depuis la racine du projet cible lorsque l'environnement le permet :

• scripts/check-metadata.mjs [html-file] [--no-write] - vérifications statiques des métadonnées, titres, images, favicon, manifeste et SEO de base.
• scripts/check-structured-data.mjs [html-file] [--no-write] - analyse JSON-LD et vérifications de cohérence du schéma.
• scripts/check-links.mjs [html-file] [--network] [--no-write] - liens locaux, fragments, ressources et vérifications optionnelles d'URL externes.
• scripts/check-site-files.mjs [site-root] [--no-write] - vérifications de robots.txt, sitemap.xml, site.webmanifest, llms.txt et icônes courantes ; passez public pour les dossiers publics des frameworks.
• scripts/check-placeholders.mjs [paths...] [--no-write] - vérification des {{PLACEHOLDER}} non remplacés après l'application des modèles.
• scripts/run-lighthouse.mjs <url> [mobile|desktop] - rapport Lighthouse JSON.
• scripts/summarize-lighthouse.mjs [lighthouse-json-report] [--no-write] - résumé Markdown à partir d'un rapport Lighthouse.
• scripts/run-pagespeed.mjs <url> [mobile|desktop] - rapport PageSpeed Insights JSON.
• scripts/summarize-pagespeed.mjs [pagespeed-json-report] [--no-write] - résumé Markdown à partir d'un rapport PageSpeed.
• scripts/list-search-console-sites.mjs [--no-write] - lister les propriétés Search Console vérifiées.
• scripts/submit-sitemap.mjs <search-console-site-url> <sitemap-url> - soumettre un sitemap via l'API Search Console.
• scripts/inspect-url.mjs <inspection-url> <search-console-site-url> [language-code] - inspecter les données d'indexation d'une URL via l'API Search Console.

Utilisez PAGESPEED_API_KEY pour les appels à l'API PageSpeed lorsqu'elle est disponible.

Utilisez GOOGLE_SEARCH_CONSOLE_ACCESS_TOKEN uniquement pour les actions prises en charge de l'API Search Console.

Si une action basée sur une API nécessite des identifiants et que la variable d'environnement est manquante, demandez à l'utilisateur de l'exporter dans son propre terminal. Ne lui demandez pas de coller le secret dans la conversation, et ne tapez jamais une clé vous-même dans une commande : une clé collée ou écrite en ligne se retrouve dans la transcription et les journaux, tandis qu'une variable exportée est héritée par ces scripts sans jamais entrer dans la conversation. references/validation-workflow.md contient les commandes par shell.

N'écrivez pas de secrets dans .env, les fichiers suivis ou la configuration du projet, sauf si l'utilisateur le demande explicitement.

Si les identifiants, le réseau, les dépendances ou le quota ne sont pas disponibles, ne simulez pas de succès. Expliquez le blocage et fournissez des étapes manuelles ou des commandes de repli.

En cas de doute sur l'utilisation, exécutez le script avec des arguments manquants pour voir son texte d'aide ou lisez references/validation-workflow.md.

Règles

• Privilégiez les modifications concrètes de fichiers plutôt que les conseils génériques.
• Respectez les conventions du projet existant.
• Ne demandez d'identifiants que lorsque l'action demandée en a besoin, et faites-les exporter par l'utilisateur plutôt que de les coller.
• Ne bourrez pas de mots-clés.
• N'ajoutez pas de notes fictives, d'avis fictifs ou de déclarations non étayées.
• Ne promettez pas de résultats de classement, d'indexation ou de Core Web Vitals.
• Évitez les animations d'entrée qui déplacent la mise en page. Privilégiez les révélations par opacité lorsque l'animation est nécessaire.
• Les frameworks ne sont pas mauvais par défaut. Utilisez du HTML statique pour les sites simples, et utilisez React, Next.js, Astro ou des frameworks similaires lorsque le projet les utilise déjà ou a besoin de leurs fonctionnalités.
• Pour les entreprises locales, privilégiez le nom exact de l'entreprise, la cohérence NAP, la zone de service, les horaires d'ouverture, le lien vers la carte, le profil Google Business ou l'équivalent local, les avis et les conseils sur le nom de domaine personnalisé.