Checklist SEO et GEO d’un site créé avec Claude Code

Pendant le développement, Claude Code pose souvent un noindex pour que le site en chantier ne sorte pas dans Google. Si la balise part en ligne avec le reste, le site entier reste invisible. Google ne l’affiche pas, et les IA qui cherchent sur le web ne le trouvent pas non plus.

Le noindex peut se cacher à trois endroits : une balise meta robots dans le code, un en-tête HTTP X-Robots-Tag, ou un réglage de l’hébergeur.

Vérifie que le site en production ne contient aucune directive noindex. Cherche dans le code les balises meta robots, les en-têtes X-Robots-Tag et la configuration de l'hébergeur, puis teste l'en-tête HTTP réel de la page d'accueil et de trois pages internes. Liste chaque page concernée. Retire le noindex des pages qui doivent être trouvées et garde-le seulement sur les environnements de prévisualisation.

Le fichier robots.txt, à la racine du site, dit aux robots ce qu’ils ont le droit d’explorer. Un Disallow: / recopié d’un modèle suffit à fermer tout le site. Un site peut être irréprochable partout ailleurs et rester invisible dans les IA à cause d’une seule ligne oubliée dans ce fichier.

Le fichier se termine par une ligne Sitemap: qui donne l’adresse complète du plan du site.

Vérifie le fichier robots.txt servi à la racine du site en production. Il doit exister, répondre en 200, n'interdire aucune page publique, et se terminer par une ligne Sitemap avec l'URL absolue du sitemap. Signale toute règle Disallow qui touche une page destinée à être trouvée, et montre-moi le fichier final avant de le déployer.

Chaque IA envoie ses propres robots, et un robots.txt peut les bloquer un par un. OpenAI en utilise trois (GPTBot pour l’entraînement, OAI-SearchBot pour la recherche, ChatGPT-User pour les visites demandées par un utilisateur), Anthropic aussi (ClaudeBot, Claude-SearchBot, Claude-User).

Tu peux très bien refuser l’entraînement et garder la recherche. Un site fermé à OAI-SearchBot n’est plus proposé comme source dans les réponses de recherche de ChatGPT.

Liste dans un tableau les robots d'IA et leur statut dans le robots.txt du site : autorisé, bloqué ou autorisé seulement sur certains chemins. Couvre au minimum GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-SearchBot, Claude-User, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended, Bingbot, MistralAI-User et CCBot. Ajoute un bloc qui autorise explicitement les robots de recherche et de citation, et demande-moi ce que je veux faire des robots d'entraînement.

Le blocage peut venir d’ailleurs que du robots.txt. Cloudflare bloque les robots d’IA par défaut sur les nouveaux domaines depuis juillet 2025. Certains hébergeurs renvoient aussi une erreur 403 à tout ce qui ne ressemble pas à un navigateur.

Le robots.txt a beau tout autoriser, le robot se fait alors renvoyer à l’entrée avant même de l’avoir lu.

Vérifie si l'hébergeur, le CDN ou le pare-feu du site bloque des robots. Regarde la configuration (Cloudflare, Vercel, Netlify ou autre) pour les options de blocage des robots d'IA, de protection anti-bot et de challenge JavaScript. Puis teste la page d'accueil avec les user-agents de Googlebot, Bingbot, GPTBot, OAI-SearchBot, ClaudeBot et PerplexityBot, et donne-moi le code HTTP obtenu pour chacun.

Les hébergeurs créent une adresse de prévisualisation à chaque déploiement, du genre mon-site-git-main.vercel.app. Si ces adresses sont indexables, Google peut les trouver et les afficher à la place du vrai site, avec un contenu en double.

Vérifie que les déploiements de prévisualisation et les sous-domaines techniques de l'hébergeur (par exemple *.vercel.app ou *.netlify.app) renvoient un en-tête X-Robots-Tag: noindex, ou redirigent vers le domaine principal. Vérifie aussi que le site de production, lui, ne reçoit pas ce noindex par erreur.

Un site publié sur l’adresse gratuite de l’hébergeur reste attaché à un domaine qui ne lui appartient pas. Le jour où il déménage sur un vrai domaine, l’historique, les liens reçus et les citations restent sur l’ancienne adresse.

C’est aussi à ce nom de domaine que les moteurs et les IA rattachent tout ce qui se dit de la marque ailleurs sur le web.

Vérifie que le site est configuré sur son nom de domaine définitif, en HTTPS, et que l'adresse fournie par l'hébergeur redirige en 301 vers ce domaine. Contrôle que toutes les URL absolues du code (canonical, sitemap, Open Graph, JSON-LD) utilisent ce domaine et aucun autre.

Le sitemap est le plan du site que les moteurs viennent lire. Il liste toutes les pages indexables, et seulement elles : une page en noindex, redirigée ou en erreur n’a rien à y faire.

La date lastmod de chaque page doit être la vraie date de dernière modification du contenu. Google s’en sert pour savoir quoi revisiter, et une date qui change à chaque déploiement finit par ne plus rien lui dire.

Vérifie que le site génère un sitemap.xml au build. Il doit contenir toutes les pages indexables, aucune page en noindex, redirigée ou en erreur, uniquement des URL absolues et canoniques, et une date lastmod qui correspond à la dernière modification réelle du contenu. Donne-moi le nombre d'URL du sitemap et le nombre de pages indexables du site, pour qu'on compare.

Beaucoup de sites construits en JavaScript renvoient le code 200 sur n’importe quelle adresse, puis affichent « page introuvable » à l’écran. Google appelle ça une soft 404 : il voit des milliers de fausses pages valides, et il passe son temps d’exploration dessus au lieu de visiter les vraies.

Une adresse qui n’existe pas doit renvoyer le code HTTP 404, avec une page qui propose de repartir vers l’accueil ou les pages principales.

Teste le code HTTP renvoyé par le serveur pour trois adresses qui n'existent pas sur le site. Chacune doit renvoyer 404, pas 200. Si le site est une application à page unique, configure le serveur ou le framework pour renvoyer un vrai 404, et vérifie que la page d'erreur propose des liens vers l'accueil et les pages principales.

La Search Console est l’outil gratuit de Google pour suivre l’indexation, les erreurs et les requêtes qui amènent du trafic. Sans elle, on ne sait pas si Google a trouvé le site, ni pourquoi il en ignore une partie.

La propriété de domaine se valide par un enregistrement DNS, puis on y soumet le sitemap.

Aide-moi à déclarer le site dans Google Search Console en propriété de domaine. Donne-moi l'enregistrement TXT à ajouter chez mon registrar, dis-moi où le mettre selon mon hébergeur, puis rappelle-moi de soumettre l'URL du sitemap une fois la propriété validée. Ne modifie pas la configuration DNS toi-même.

ChatGPT s’appuie en grande partie sur l’index de Bing pour trouver ses sources, tout comme Copilot. Un site absent de Bing a beau être bien placé dans Google, ces IA ont du mal à le trouver.

Bing Webmaster Tools peut importer directement les sites déjà validés dans la Search Console.

Explique-moi comment déclarer le site dans Bing Webmaster Tools en important la propriété depuis Google Search Console, puis vérifie que le sitemap est bien accessible pour Bing. Rappelle-moi les étapes qui demandent une action de ma part dans l'interface.

IndexNow est un protocole qui signale instantanément une page nouvelle ou modifiée à Bing, Yandex et aux autres moteurs qui l’utilisent. Google ne l’utilise pas : pour lui, ce sont le sitemap et les liens internes qui accélèrent la découverte.

Le signal part à la publication et à chaque mise à jour réelle du contenu, jamais à chaque déploiement technique.

Mets en place IndexNow sur le site. Génère une clé, sers-la dans un fichier texte à la racine, puis ajoute au processus de déploiement un appel qui envoie à l'API IndexNow uniquement les URL créées ou dont le contenu a changé. Ajoute la page qui liste le contenu (blog, actualités) quand un nouvel article est publié. Montre-moi le code avant de l'activer.

Une étude publiée par Vercel en décembre 2024 a montré qu’aucun des grands robots d’IA (OpenAI, Anthropic, Perplexity) n’exécute le JavaScript. Seuls Googlebot, Gemini et Applebot affichent la page comme un navigateur.

Donc un texte ajouté par JavaScript une fois la page chargée est invisible pour la plupart des IA. Le rendu côté serveur (SSR) ou la génération de pages statiques (SSG) règle la question.

Pour la page d'accueil et trois pages internes, récupère le HTML brut renvoyé par le serveur, sans exécuter le JavaScript (par exemple avec curl). Vérifie que le titre, les intertitres, le texte principal et les liens de navigation y figurent en entier. Si une partie n'apparaît qu'après exécution du JavaScript, propose-moi de passer ces pages en rendu serveur ou en génération statique avec le framework du projet.

Sur certains sites en JavaScript, le titre et la description de la page sont ajoutés après le chargement. Les robots qui n’exécutent pas le script voient alors le même titre générique sur toutes les pages, ou aucun titre du tout.

Vérifie dans le HTML brut renvoyé par le serveur, sans JavaScript, que chaque type de page contient son propre title, sa meta description, sa balise canonical et ses balises Open Graph. Compare avec le HTML affiché dans le navigateur et signale tout écart.

Certaines applications affichent toutes leurs pages à la même adresse, ou changent de page avec un dièse (/#/contact). Pour un moteur, tout ce qui suit le dièse n’existe pas : le site entier se résume alors à une seule page.

Vérifie que le routage du site donne une URL distincte, sans dièse, à chaque page, et que chacune de ces URL renvoie directement le bon contenu quand on l'ouvre dans un nouvel onglet. Si le site utilise un routage par dièse, propose la migration vers un routage par chemin, avec les redirections nécessaires.

Un moteur suit un lien quand il trouve une balise <a href="…"> avec une adresse réelle. Un bouton qui change de page avec un onClick, ou un lien en href="#", ne mène nulle part pour lui. Les pages qu’il devait relier restent alors orphelines.

Parcours les composants de navigation, les boutons et les cartes du site. Liste chaque endroit où l'on change de page sans balise a avec un href réel : onClick seul, href="#", href vide, lien construit en JavaScript. Remplace-les par de vrais liens, en gardant le composant de lien du framework s'il produit bien une balise a.

Les accordéons, onglets et « lire la suite » sont pratiques pour la lecture. S’ils vont chercher leur texte sur le serveur au moment du clic, ce texte n’existe pas pour les robots.

Les éléments natifs <details> et <summary> gardent le texte dans le HTML, même replié, et fonctionnent sans une ligne de JavaScript.

Repère les accordéons, onglets, FAQ et blocs « voir plus » du site. Vérifie que leur texte est présent dans le HTML initial, même quand il est replié. Si un contenu est chargé au clic, fais-le passer dans le HTML de la page, de préférence avec les balises details et summary.

Une IA lit du texte, donc un tarif, une liste de services ou des horaires posés dans un visuel n’existent pas pour elle. Une information absente du texte ne peut pas être citée.

L’image peut rester pour l’œil, à condition que la même information figure aussi en texte sur la page.

Repère les images, infographies, PDF et éléments canvas du site qui portent des informations (prix, offres, horaires, chiffres, étapes). Pour chacun, dis-moi si la même information existe aussi en texte HTML sur la page. Propose un bloc de texte ou un tableau HTML là où elle manque.

Un site peut répondre sur quatre adresses : avec ou sans www, en http ou en https. Si les quatre affichent la page, Google voit quatre sites en double et répartit entre eux les liens reçus.

Il en faut une seule, et les trois autres y redirigent en 301, en un seul saut.

Teste les quatre variantes de la page d'accueil : http et https, avec et sans www. Trois doivent rediriger en 301 vers la version retenue, en une seule redirection, sans chaîne. Fais la même vérification avec et sans slash final sur deux pages internes, et dis-moi quelle règle le site applique.

Une bonne URL se lit à voix haute : des mots en minuscules, séparés par des tirets, sans identifiant technique ni paramètre. /services/audit-seo/ dit de quoi parle la page, alors que /page?id=42 ne dit rien.

Une fois qu’une adresse est publiée et partagée, elle ne change plus. Une nouvelle version de la page s’écrit à la même adresse.

Liste toutes les URL publiques du site et signale celles qui contiennent des majuscules, des underscores, des accents, des identifiants techniques, des paramètres ou plus de quatre niveaux de dossiers. Propose une URL corrigée pour chacune, mais ne change aucune adresse déjà en ligne sans prévoir la redirection 301 correspondante et sans mon accord.

La balise canonical indique à Google l’adresse officielle d’une page. Elle sert quand le même contenu est accessible à plusieurs endroits, avec des paramètres de tri ou des codes de suivi. Sans elle, Google choisit tout seul, et pas toujours la bonne.

Elle pointe vers l’adresse absolue de la page elle-même, avec le bon domaine.

Vérifie que chaque page indexable contient une seule balise link rel="canonical", avec une URL absolue en https, sur le domaine principal, qui pointe vers la page elle-même. Signale les pages sans canonical, avec une canonical relative, ou qui pointent vers une autre page ou vers une page en noindex.

Plus une page est enfouie dans l’arborescence, moins les moteurs la visitent et moins ils lui accordent d’importance. Les pages qui comptent pour le business sont accessibles en trois clics depuis l’accueil, par le menu ou par des liens dans le contenu.

Calcule la profondeur de clic de chaque page du site depuis la page d'accueil, en suivant uniquement les liens HTML. Liste les pages à plus de trois clics, et propose pour chacune la page depuis laquelle ajouter un lien pour la remonter.

Le fil d’Ariane (Accueil › Rubrique › Page) montre au visiteur où il se trouve. Balisé en BreadcrumbList, il aide aussi Google et les IA à comprendre comment les pages du site s’emboîtent.

Ajoute un fil d'Ariane visible sur toutes les pages sauf l'accueil, construit à partir de l'arborescence réelle du site, avec de vrais liens HTML. Génère le JSON-LD BreadcrumbList correspondant, avec des URL absolues, et vérifie qu'il reprend exactement les libellés affichés.

Quand le nouveau site remplace un ancien, les anciennes adresses ont accumulé des liens, des favoris et des positions dans Google. Sans précaution, tout cet historique finit sur des pages 404.

Le plus sûr est de reprendre les mêmes URL, page pour page, dans le nouveau site. Quand une adresse doit vraiment changer, un plan de redirections l’accompagne, et chaque ancienne URL redirige en 301 vers la nouvelle page qui lui correspond le mieux.

Rediriger tout vers l’accueil ne sert à rien, parce que Google le traite comme une fausse 404.

Le site existait avant cette version. Récupère la liste des anciennes URL (sitemap de l'ancien site, export Search Console, ou liste que je te fournis) et vérifie pour chacune si la même URL existe dans le nouveau site. Garde l'URL identique partout où c'est possible. Pour celles qui doivent changer ou disparaître, construis une table de correspondance ancienne URL vers nouvelle URL, page par page, et signale celles qui n'ont aucun équivalent. Configure ensuite les redirections 301 dans le framework ou chez l'hébergeur, sans chaîne, et teste chacune.

Le title est le titre bleu de la page de résultats. C’est aussi la première chose qu’une IA lit pour savoir de quoi parle la page. Au-delà de 70 caractères, Google le coupe. En dessous de 40, il se prive de mots qui auraient pu déclencher le clic.

Il commence par le sujet de la page et reste unique sur tout le site. Le nom de la marque s’y ajoute sur l’accueil et sur les pages où il aide au clic.

Liste le title de chaque page du site avec son nombre de caractères. Signale ceux qui sont en double, vides, génériques (« Accueil », « Page »), sous 40 ou au-dessus de 70 caractères. Propose un title pour chaque page à corriger, qui commence par le sujet de la page, et attends ma validation avant de les appliquer.

La meta description est le texte gris sous le titre dans la page de résultats. Elle ne compte pas dans le classement, alors qu’elle décide souvent du clic.

Elle dit ce que la page contient. Une amorce comme « Dans cet article, nous verrons » gaspille la moitié des caractères. Une page sans description laisse Google en fabriquer une, parfois à partir de n’importe quel bout de code.

Liste la meta description de chaque page avec son nombre de caractères. Signale celles qui manquent, qui sont en double, sous 110 ou au-dessus de 155 caractères, ou qui commencent par « Découvrez ». Propose une description pour chaque page à corriger, qui dit concrètement ce que la page apporte, et attends ma validation avant de les appliquer.

Le H1 est le titre principal visible de la page : il y en a un, et un seul. Les H2 découpent le contenu en sections, les H3 découpent les H2, sans sauter de niveau.

Les IA découpent une page par ses intertitres pour en extraire des passages. Un titre affiché en gros mais codé comme un paragraphe ne découpe rien, et la section entière se mélange à la précédente.

Pour chaque page, liste la hiérarchie des balises h1 à h4. Signale les pages sans h1 ou avec plusieurs h1 (y compris un h1 caché en CSS), les sauts de niveau, et les titres visuels codés en div ou en p. Corrige la structure sans changer l'apparence : le style passe par les classes CSS, le niveau de titre par la balise.

L’attribut lang de la balise <html> dit dans quelle langue est écrite la page. Les moteurs, les lecteurs d’écran et les IA s’en servent pour classer et prononcer le contenu.

Un site généré en anglais par défaut garde souvent lang="en" sur des pages écrites en français.

Vérifie que la balise html de chaque page porte l'attribut lang qui correspond à la langue réelle du contenu, par exemple lang="fr" ou lang="fr-FR" pour un site en français. Vérifie aussi que la balise meta viewport est présente sur toutes les pages.

Les balises header, nav, main, article, aside et footer disent à quoi sert chaque zone de la page. Un robot repère ainsi le contenu principal et le sépare du menu et du pied de page.

Sur un site construit uniquement avec des div, le robot doit deviner où commence le texte qui compte.

Vérifie que chaque gabarit de page utilise les balises sémantiques HTML : header, nav, main (une seule par page), article pour un contenu éditorial, aside pour les compléments, footer. Remplace les div qui jouent ces rôles par la bonne balise, sans changer le rendu visuel.

Google affiche la favicon à côté du nom du site dans les résultats sur mobile. Sans elle, Google met une icône grise par défaut, et le résultat se fond dans la liste.

Elle doit être carrée, d’au moins 48 × 48 pixels, et déclarée dans le code de la page d’accueil.

Vérifie que le site déclare une favicon carrée d'au moins 48 × 48 pixels dans le head de la page d'accueil, accessible par une URL stable qui répond 200 et que le robots.txt n'interdit pas. Ajoute aussi une apple-touch-icon de 180 × 180 pixels.

Les données structurées décrivent le site dans un langage que les moteurs lisent sans interpréter. Sur la page d’accueil, le socle se compose d’un Organization (ou d’une Person pour une marque personnelle) et d’un WebSite.

C’est ce bloc qui dit aux IA quelle marque se trouve derrière le site, avec son nom, son logo et sa description.

Génère le JSON-LD de la page d'accueil avec un @graph qui contient un nœud Organization (ou Person si le site porte une marque personnelle) et un nœud WebSite. Renseigne le nom exact, l'URL, le logo en URL absolue, une description d'une phrase et l'adresse de contact. Utilise uniquement des informations visibles sur le site, et demande-moi celles qui manquent au lieu de les inventer.

La propriété sameAs liste les autres pages qui représentent la même marque : LinkedIn, Instagram, fiche Google Business Profile, chaîne YouTube, notice BnF. C’est ce qui permet à une IA de comprendre que ces profils et ce site sont une seule et même entité.

On n’y met que des profils qui existent vraiment et qui répondent.

Ajoute une propriété sameAs au nœud Organization ou Person du JSON-LD, avec les URL de mes profils officiels. Demande-moi la liste au lieu de la deviner, puis teste chaque URL et retire celles qui ne répondent pas en 200. Vérifie que le nom affiché sur chaque profil correspond au nom utilisé sur le site.

Chaque entité du site (la marque, la personne, le site, une offre) reçoit un identifiant @id fixe, par exemple https://www.exemple.fr/#organisation. Les autres pages y font référence au lieu de redéclarer l’entité à chaque fois.

Un même identifiant ne se définit qu’une fois par page, avec les mêmes valeurs partout. Avec deux descriptions différentes pour une même entité, le moteur en retient une seule, sans qu’on sache laquelle.

Relis tout le JSON-LD du site et construis la liste des @id utilisés. Vérifie que chaque entité a un @id absolu et stable, qu'elle n'est définie qu'une fois par page, que ses valeurs sont identiques d'une page à l'autre, et qu'aucune référence @id ne pointe vers une entité qui n'existe pas. Propose un @graph unique et relié si le balisage actuel est éparpillé.

Une fiche produit, un article et une page de contact ne se balisent pas de la même façon, et cinq cas couvrent la plupart des sites.

• Un article reçoit un BlogPosting, avec son auteur et ses dates.
• Une page de vente reçoit un Product, un Service ou un Course.
• Un commerce reçoit un LocalBusiness, avec son adresse et ses horaires.
• Un événement reçoit un Event, avec son lieu.
• Un outil en ligne reçoit un WebApplication.

Le balisage se déduit du type de page dans le gabarit, pour qu’une nouvelle page le reçoive automatiquement.

Liste les types de pages du site (accueil, article, service, produit, contact, à propos, événement, outil). Pour chacun, dis-moi quel type Schema.org lui correspond et génère le JSON-LD depuis le gabarit, pour que toute nouvelle page du même type le reçoive automatiquement. Relie chaque bloc à l'Organization ou à la Person par son @id.

Les données structurées décrivent ce qui est affiché à l’écran, et rien de plus. Google peut retirer les résultats enrichis de tout le site pour des avis introuvables sur la page, un prix différent de celui affiché ou des horaires inventés.

Compare le JSON-LD de chaque page avec son contenu visible. Signale toute information présente dans le balisage et absente de la page : avis, note moyenne, prix, horaires, adresse, dates. Signale aussi les champs vides ou restés sur une valeur d'exemple. Retire du balisage ce qui n'est pas visible.

Un plugin, un module du framework et un composant écrit à la main peuvent produire chacun leur balisage. La page se retrouve alors avec deux WebSite, ou deux organisations aux noms différents, et le moteur n’en retient aucune correctement.

Vérifie combien de blocs script type="application/ld+json" chaque page contient, et d'où vient chacun (composant, bibliothèque, plugin). Signale les entités déclarées deux fois avec des valeurs différentes. Propose de regrouper tout le balisage dans un seul composant qui produit un @graph unique.

Une virgule en trop ou une accolade oubliée, et le moteur ignore tout le bloc. Deux outils gratuits se complètent. Le test des résultats enrichis de Google dit ce qui peut s’afficher dans la page de résultats, et le validateur de Schema.org vérifie la syntaxe.

Certains types ne donnent plus de résultat enrichi, comme FAQPage et HowTo pour la plupart des sites. Ils restent utiles pour décrire la page, sans attendre d’affichage particulier dans Google.

Extrais le JSON-LD de chaque type de page, vérifie qu'il se parse sans erreur, que les types et propriétés sont correctement orthographiés, que les URL et images sont absolues, que les prix sont numériques avec une devise. Donne-moi ensuite les URL à passer dans le test des résultats enrichis de Google et dans validator.schema.org.

Une IA ne recommande pas quelqu’un dont elle ne sait rien. La page À propos dit qui est la personne ou l’entreprise, son parcours, ses références, et ce qu’elle fait pour qui.

Elle se balise en ProfilePage ou en AboutPage, reliée à la Person ou à l’Organization du site.

Vérifie qu'une page À propos existe, qu'elle est liée depuis le menu ou le pied de page, et qu'elle présente en texte : qui je suis, mon parcours, mes références vérifiables, ce que je propose et à qui. Ajoute le JSON-LD ProfilePage ou AboutPage relié à la Person ou à l'Organization du site par son @id. Liste les informations qui manquent au lieu de les rédiger à ma place.

Un article signé « L’équipe » ne dit ni qui l’a écrit, ni pourquoi on devrait le croire. La signature apparaît en haut et en bas du contenu, avec un lien vers la page auteur, qui peut être la page À propos.

Dans le balisage, la propriété author pointe vers la même Person sur tous les articles.

Vérifie que chaque article ou contenu éditorial affiche le nom de son auteur en haut et en bas, avec un lien vers la page auteur ou À propos. Dans le JSON-LD, la propriété author doit référencer le même @id de Person sur tous les articles. Liste les contenus sans auteur.

Une IA recoupe les sources pour comprendre une entité. « Consultante SEO » sur le site, « formatrice marketing » sur LinkedIn et « experte digitale » dans le balisage font trois personnes différentes aux yeux de l’IA, et aucune n’est assez solide pour être citée.

La même formule se reprend mot pour mot sur le site, dans le JSON-LD, sur les réseaux et dans les fiches d’annuaire.

Relève sur le site toutes les formulations du nom de la marque, de mon titre professionnel et de la description de mon activité : pages, pied de page, balises meta, JSON-LD. Signale les variantes. Propose une formulation unique à reprendre partout, et donne-moi la liste des profils externes où je dois la reporter moi-même.

Un site où on ne trouve ni qui le tient ni comment le joindre fait fuir les visiteurs, et les évaluateurs de Google le notent aussi. En France, les mentions légales sont aussi une obligation.

Les liens vers les mentions légales, la politique de confidentialité et le contact vivent dans le pied de page, cliquables sur toutes les pages.

Vérifie que le pied de page de toutes les pages contient des liens cliquables vers les mentions légales, la politique de confidentialité et la page contact. Vérifie que les mentions légales indiquent le nom de l'éditeur, son statut, son numéro d'immatriculation, son adresse, un moyen de contact, le directeur de la publication et l'hébergeur du site. Liste ce qui manque.

Un site généré arrive souvent avec du contenu de démonstration, comme du Lorem ipsum, un « Jean Dupont, CEO », des avis inventés ou « 500 clients satisfaits ». Un faux avis est une pratique commerciale trompeuse en France, et une IA qui le reprend répète une information fausse sur la marque.

Cherche dans tout le site le contenu de démonstration resté en place : Lorem ipsum, noms fictifs, avis et témoignages sans source, logos de clients génériques, chiffres non justifiés, adresses et numéros d'exemple, liens vers #. Liste chaque occurrence avec son fichier. Ne remplace rien par un autre texte inventé : je fournis le vrai contenu.

Les IA et Google privilégient une information récente sur les sujets qui bougent. Une date de publication visible montre que la page est suivie, et la mention « mis à jour le » s’ajoute quand le contenu a vraiment changé.

La date de mise à jour correspond à une modification du contenu, jamais à un simple redéploiement technique.

Vérifie que chaque article affiche sa date de publication, et une date de mise à jour quand le contenu a changé plus de 24 heures après la publication. Vérifie que ces dates sont identiques dans le texte visible, dans le JSON-LD (datePublished, dateModified) et dans le lastmod du sitemap. Assure-toi qu'un déploiement technique ne modifie pas dateModified.

Quand quelqu’un demande à une IA de lui recommander un prestataire, elle a besoin de critères pour trancher. Si le site ne dit nulle part quel problème il règle, pour quel public et avec quelle approche, l’IA le déduit. Et elle se trompe souvent.

Cette phrase de positionnement apparaît sur l’accueil et sur les pages d’offre, en texte, pas seulement dans un slogan graphique.

Relis la page d'accueil et les pages d'offre, puis dis-moi si on y trouve en texte, de façon explicite : le problème traité, le public visé nommé en toutes lettres, l'approche utilisée et ce qui la distingue. Cite les phrases qui répondent à chacun de ces points, et signale ceux qui manquent. Ne rédige pas le positionnement à ma place.

Une promesse comme « le meilleur accompagnement du marché » ne convainc personne, et une IA ne la répète pas. Elle reprend ce qu’elle peut vérifier ailleurs que sur le site, et ces preuves-là prennent trois formes.

• Des études de cas nommées et des avis réels.
• Des logos de clients, affichés avec leur accord.
• Un livre publié, une conférence, un article de presse.

Quand une preuve existe ailleurs sur le web, un lien vers la source la rend recoupable.

Liste les promesses et affirmations fortes du site (résultats, expertise, clients, chiffres). Pour chacune, dis-moi si une preuve est présente sur la page, et si elle renvoie vers une source externe vérifiable. Propose un emplacement pour chaque preuve manquante, sans en inventer aucune.

Une page traite un sujet principal et répond à une question précise que se pose la cible. Deux pages qui visent la même requête se font concurrence, et Google hésite entre les deux sans en classer aucune correctement.

Liste les pages du site avec, pour chacune, la requête principale qu'elle vise selon son title, son h1 et son contenu. Signale les pages qui visent la même requête ou des requêtes très proches, et propose pour chaque doublon de fusionner, de différencier l'angle, ou de relier les deux pages par un lien.

Un site peut parler de « solutions de visibilité digitale » quand ses clients cherchent « référencement de mon site ». Les moteurs et les IA rapprochent une question des pages qui emploient les mêmes mots.

Les mots de la cible apparaissent dans le title, le H1, les intertitres et le texte, sans bourrage.

Pour chaque page d'offre ou de service, donne-moi la liste des termes que ma cible utiliserait pour chercher ce service, puis dis-moi lesquels apparaissent déjà dans le title, le h1, les h2 et le texte. Propose des reformulations là où le site emploie un jargon interne, et attends ma validation avant de modifier un texte.

Claude Code peut générer des centaines de pages en quelques minutes, une par ville ou par mot-clé. Depuis mars 2024, Google range la production de pages en masse pour manipuler le classement parmi le spam, que le texte vienne d’une IA ou d’un humain.

Une page mérite sa place si elle dit quelque chose que la page d’à côté ne dit pas.

Repère les groupes de pages construites sur le même gabarit avec un contenu presque identique (pages par ville, par mot-clé, par variante). Pour chaque groupe, calcule la part de texte commune entre les pages et dis-moi lesquelles apportent une information propre. Propose de fusionner, d'enrichir ou de passer en noindex celles qui n'en apportent pas.

Une page de catégorie sans texte ou une page « Nos services » de deux lignes n’apportent rien au lecteur. Google les compte pourtant quand il juge la qualité de l’ensemble du site.

Liste les pages indexables qui contiennent moins de 150 mots de texte visible hors menu et pied de page. Pour chacune, dis-moi si elle a vocation à être trouvée dans Google. Propose de l'enrichir, de la fusionner avec une autre page, ou de la passer en noindex.

Un même paragraphe de présentation, recopié en bas de chaque page, finit par peser plus lourd que le contenu propre de la page. Le moteur voit alors des pages qui se ressemblent toutes.

Repère les blocs de texte de plus de 40 mots qui se répètent à l'identique sur plusieurs pages, hors menu et pied de page. Liste-les avec les pages concernées, et propose de les raccourcir, de les remplacer par un lien vers une page dédiée, ou de les varier.

Un chiffre, une étude ou une réglementation citée sans source ne se vérifie pas. Un lien vers la source primaire, dans le corps du texte, rend l’information recoupable par le lecteur et par les IA.

Liste dans les contenus du site chaque chiffre, statistique, citation et référence à une étude ou à un texte officiel. Pour chacun, dis-moi si une source est donnée, et si le lien pointe vers la source primaire ou vers un site qui la reprend. Signale les chiffres sans source, sans en supprimer ni en modifier aucun.

Les IA découpent une page en passages et gardent ceux qui répondent directement à une question. La première phrase sous un intertitre donne donc la réponse, avant le raisonnement.

Cette phrase se comprend seule, sortie de la page : elle nomme son sujet au lieu de dire « il » ou « cela ».

Pour chaque h2 des pages de contenu, relis le premier paragraphe qui suit. Dis-moi s'il répond directement à la question posée par l'intertitre et s'il reste compréhensible cité seul, sans le reste de la page. Propose une première phrase réécrite là où ce n'est pas le cas, sans modifier le texte avant ma validation.

Les gens posent des questions complètes aux IA : « combien coûte un audit SEO », « comment choisir un consultant ». Des intertitres formulés comme ces questions aident l’IA à relier la page à la demande.

Un intertitre générique comme « Nos avantages » ne correspond à aucune question.

Liste les h2 des pages principales. Signale ceux qui sont génériques (« Présentation », « Nos avantages », « Pourquoi nous ») et propose pour chacun une formulation qui reprend une question réelle de ma cible. Garde les titres neutres, sans « ton » ni « votre ». Attends ma validation avant de les changer.

Une IA fait plus confiance à un chiffre qu’elle retrouve à l’identique sur plusieurs sources. « 42 % » sur une page et « plus de 40 % » sur une autre donnent deux versions. L’IA préfère alors citer une source plus constante.

Un chiffre se reprend avec la même valeur et la même source sur le site, les réseaux et la newsletter.

Relève tous les chiffres du site : tarifs, nombre de clients, années d'expérience, résultats, statistiques. Signale ceux qui apparaissent avec des valeurs ou des formulations différentes selon les pages, dans le texte visible comme dans le JSON-LD. Présente-moi les écarts dans un tableau, sans rien corriger.

Une comparaison entre deux offres ou une méthode en cinq étapes se lisent mal dans un paragraphe continu. En liste ou en tableau HTML, elles se découpent proprement, pour le lecteur comme pour l’IA qui cherche des critères de choix.

Repère dans les contenus les paragraphes qui énumèrent plus de trois éléments, décrivent une suite d'étapes ou comparent plusieurs options. Propose de les transformer en liste ul ou ol, ou en tableau HTML avec des en-têtes th, sans modifier le texte lui-même.

Une FAQ reprend les questions que les clients posent vraiment avant d’acheter : le prix, le délai, ce qui est inclus, pour qui c’est fait. Chaque réponse est un passage autonome que les IA peuvent reprendre tel quel.

Le balisage FAQPage décrit ces questions sans garantir d’affichage particulier dans Google.

Pour la page d'accueil et chaque page d'offre, vérifie s'il existe une FAQ visible. Propose une liste de questions que ma cible pose avant d'acheter, et laisse-moi rédiger ou valider les réponses. Intègre ensuite la FAQ en HTML avec details et summary, et ajoute le JSON-LD FAQPage correspondant, avec exactement les mêmes textes.

Une méthode qui porte un nom devient une entité. Quand une IA veut en parler, elle doit citer ce nom, donc sa source. Une méthode sans nom, l’IA la résume en deux lignes et cite quelqu’un d’autre.

Le nom s’écrit toujours de la même façon, et une page du site l’explique.

Relève dans le site les méthodes, offres, programmes ou concepts propres à la marque. Vérifie pour chacun que le nom est écrit exactement de la même façon partout, et qu'une page le présente et le définit en une phrase. Signale ceux qui n'ont pas de nom ou pas de page dédiée.

Le fichier llms.txt, posé à la racine, présente le site en Markdown : un résumé, puis la liste des pages principales avec une ligne d’explication. C’est une proposition apparue en 2024, et aucun grand moteur n’a confirmé s’en servir.

Il se pose en quelques minutes et ne remplace aucun des autres critères de cette liste.

Crée un fichier llms.txt à la racine du site, en Markdown : un titre h1 avec le nom de la marque, un résumé d'une phrase en citation, puis une section qui liste les pages principales avec leur URL absolue et une ligne de description, et enfin l'URL du sitemap. Utilise uniquement des informations déjà présentes sur le site.

Google mesure trois indicateurs sur les visites réelles, les Core Web Vitals, avec un seuil à respecter pour chacun.

• Le LCP, le temps d’affichage du plus gros élément, reste sous 2,5 secondes.
• L’INP, la réactivité au clic, reste sous 200 millisecondes.
• Le CLS, les décalages de mise en page, reste sous 0,1.

Ce qui compte, ce sont les mesures prises sur les vrais visiteurs, visibles dans la Search Console. Un score lancé depuis un ordinateur en fibre ne dit rien d’un téléphone en 4G dans le métro.

Lance une mesure Lighthouse en mode mobile sur la page d'accueil et sur les deux gabarits les plus visités, puis donne-moi le LCP, l'INP estimé (ou le Total Blocking Time), le CLS et le TTFB. Pour chaque indicateur hors des seuils (LCP 2,5 s, INP 200 ms, CLS 0,1, TTFB 0,8 s), identifie la cause principale dans le code et propose la correction.

Une image sans attributs width et height fait sauter la mise en page quand elle arrive : le texte descend sous le doigt du lecteur. C’est ce que mesure le CLS.

En CSS, une hauteur imposée à une image s’accompagne de width: auto, sinon l’image se déforme.

Vérifie que toutes les images du site, y compris le logo et les images des gabarits, ont des attributs width et height qui correspondent à leur ratio réel. Contrôle ensuite en CSS qu'aucune image n'a une hauteur imposée sans width: auto, et teste le rendu mobile pour t'assurer qu'aucune image n'est déformée.

Une photo de 4 000 pixels affichée dans un encart de 400 pixels fait télécharger dix fois trop de données. Chaque image se sert au format WebP ou AVIF, à deux fois sa taille d’affichage au maximum pour les écrans haute définition.

Google choisit parfois la plus grande image de la page comme vignette dans ses résultats. Une image de décor servie en très grand peut donc s’y retrouver à la place de l’image principale.

Liste les images du site avec leur poids, leurs dimensions réelles et leur taille d'affichage. Signale celles de plus de 150 Ko, celles servies à plus de deux fois leur taille d'affichage, et celles en JPEG ou PNG qui pourraient passer en WebP ou AVIF. Mets en place le composant image du framework, avec srcset, si ce n'est pas déjà fait.

Le chargement différé (loading="lazy") retarde les images qui sont plus bas dans la page. Appliqué à l’image principale du haut de page, il retarde justement l’élément que Google chronomètre pour le LCP.

Vérifie que les images situées sous le premier écran utilisent loading="lazy", et que l'image principale du haut de page ne l'utilise pas. Ajoute fetchpriority="high" sur cette image principale. Fais la vérification sur la page d'accueil et sur chaque gabarit.

Des polices chargées depuis Google Fonts ajoutent une connexion vers un autre serveur, et un bandeau de cookies peut les bloquer avant le consentement. La page s’affiche alors dans une police de secours, puis saute quand la vraie arrive.

Les polices se servent depuis le même domaine que le site, en WOFF2, avec seulement les graisses utilisées.

Vérifie comment le site charge ses polices. Si elles viennent d'un service externe, télécharge-les au format WOFF2, sers-les depuis le domaine du site avec @font-face et font-display: swap, garde uniquement les graisses réellement utilisées, et précharge la police du texte principal. Vérifie que les URL des polices utilisent exactement le même domaine que les pages, www compris.

Google explore et évalue d’abord la version mobile des sites. Un élément trop large qui fait défiler la page sur le côté dégrade l’expérience, tout comme un texte trop petit ou des boutons collés.

Sur une capture d’écran, tout a l’air de rentrer dans l’écran. Mesure la largeur du document et vérifie qu’elle ne dépasse pas celle de l’écran.

Ouvre la page d'accueil et chaque gabarit dans un navigateur en émulation mobile à 375 pixels de large. Mesure document.documentElement.scrollWidth et compare-le à clientWidth. Si le document est plus large que l'écran, liste les éléments qui dépassent et corrige-les. Vérifie aussi que le texte fait au moins 16 pixels et que les éléments cliquables ne se touchent pas.

Le temps de réponse du serveur, mesuré au premier octet (TTFB), reste sous 0,8 seconde. Les fichiers CSS et JavaScript sont minifiés, compressés en gzip ou brotli, et mis en cache par le navigateur.

Une bibliothèque de 300 Ko chargée pour une seule animation ralentit toutes les pages.

Mesure le TTFB de la page d'accueil (le temps jusqu'au premier octet, pas le téléchargement complet). Vérifie que le HTML, le CSS et le JavaScript sont compressés en gzip ou brotli, que les fichiers statiques ont un en-tête de cache long, et liste les bibliothèques JavaScript chargées avec leur poids. Signale celles qu'on pourrait retirer ou charger seulement sur les pages qui en ont besoin.

L’attribut alt décrit l’image pour ceux qui ne la voient pas : les lecteurs d’écran, Google Images et les IA. Il décrit ce que montre l’image, sans liste de mots-clés.

Une image purement décorative reçoit un alt="" vide, pour que les lecteurs d’écran la sautent.

Liste toutes les images du site avec leur texte alternatif. Signale celles qui n'ont pas d'attribut alt, celles dont le alt est un nom de fichier ou une liste de mots-clés, et celles qui sont décoratives mais portent un texte. Propose un alt descriptif pour chaque image de contenu, et attends ma validation avant de les appliquer.

Google lit aussi le nom du fichier pour comprendre une image. atelier-ceramique-lyon.webp lui dit quelque chose, alors que IMG_4587.webp ou image-1.png ne lui disent rien.

Liste les images du site dont le nom de fichier ne décrit pas le contenu (IMG_, DSC_, image-1, capture, chaînes aléatoires). Propose un nom en minuscules, avec des tirets, qui décrit l'image. Renomme-les et mets à jour toutes les références dans le code, puis vérifie qu'aucune image n'est cassée.

Une image posée en arrière-plan CSS n’existe pas pour Google Images, et elle ne peut pas porter de texte alternatif. Les images qui ont un sens (photo d’un produit, schéma, portrait) passent par une balise <img>, et le CSS garde les décors.

Repère les images chargées en background-image dans le CSS. Pour chacune, dis-moi si elle porte une information (produit, personne, schéma) ou si elle est décorative. Transforme les images porteuses d'information en balises img avec un alt, en gardant le même rendu.

Une IA ne regarde pas une vidéo : elle lit ce qui l’entoure. Un titre, une description, les chapitres et une transcription en texte sur la page rendent son contenu citable.

Le balisage VideoObject décrit la vidéo avec sa date de mise en ligne, sa durée et sa vignette.

Liste les vidéos intégrées au site. Pour chacune, vérifie qu'un titre, une description et une transcription en texte sont présents sur la page, et qu'un JSON-LD VideoObject indique name, description, thumbnailUrl, uploadDate avec l'heure et le fuseau, et duration. Utilise youtube-nocookie.com pour les intégrations YouTube.

Une page qui ne reçoit aucun lien depuis le reste du site est orpheline. Les moteurs la trouvent mal ou pas du tout, même si elle figure dans le sitemap.

Les pages qui comptent le plus pour le business reçoivent le plus de liens internes.

Construis la liste de tous les liens internes du site et compte, pour chaque page, le nombre de pages différentes qui pointent vers elle. Signale les pages orphelines et celles qui reçoivent un seul lien. Propose, pour chacune, deux pages du site où ajouter un lien contextuel pertinent.

Le texte cliquable d’un lien dit aux moteurs de quoi parle la page vers laquelle il pointe. « Cliquez ici » ou « en savoir plus » ne disent rien, alors que « notre audit de site e-commerce » donne le sujet.

Les ancres varient d’un lien à l’autre, sans répéter partout la même expression exacte.

Liste les liens internes dont le texte d'ancre est générique : « cliquez ici », « ici », « en savoir plus », « lire la suite », « découvrir ». Pour chacun, propose une ancre qui décrit la page de destination, en variant les formulations d'un lien à l'autre.

Un lien interne qui mène à une page 404 frustre le visiteur et gaspille le passage du robot. Un lien qui pointe vers une ancienne adresse redirigée fait faire un détour inutile.

Les liens relatifs sont un piège fréquent sur les sites générés : contact.html fonctionne depuis l’accueil et casse depuis une page placée dans un sous-dossier.

Explore le site en suivant tous les liens internes et liste ceux qui renvoient une erreur 404 ou 500, ceux qui passent par une redirection, et les liens relatifs qui changent de destination selon la page où ils se trouvent. Corrige chaque lien pour qu'il pointe directement vers l'URL finale, en chemin absolu depuis la racine.

Les pages qui traitent d’un même sujet se lient entre elles et vers une page principale qui fait le tour du sujet. Ce regroupement montre aux moteurs et aux IA sur quels sujets le site fait autorité.

Chaque contenu propose aussi une étape suivante (un outil, une offre, un autre article), pour que le lecteur ne reparte pas en fin de page.

Regroupe les pages du site par sujet. Pour chaque groupe, identifie la page principale et vérifie que les autres pages du groupe pointent vers elle et vers une ou deux pages sœurs. Vérifie aussi que chaque contenu propose au moins un lien vers une étape suivante. Propose les liens manquants avec l'ancre et la phrase où les placer.

Les balises Open Graph (og:title, og:description, og:image, og:url) décident de l’aperçu qui s’affiche quand une page est partagée sur LinkedIn, Facebook, WhatsApp ou Slack. Sans elles, la plateforme prend n’importe quel texte et n’importe quelle image.

Les balises twitter:card font le même travail pour X.

Vérifie que chaque page contient og:title, og:description, og:image, og:url, og:type et twitter:card, générés depuis les métadonnées de la page. L'og:url doit être identique à la balise canonical. Signale les pages où ces balises manquent ou reprennent les valeurs de la page d'accueil.

LinkedIn affiche la grande carte de partage à partir d’une image de 1 200 pixels de large, et Facebook recommande le même format. En dessous, l’aperçu se réduit à une petite vignette qui passe inaperçue dans le fil.

Une image de partage générée automatiquement pour chaque page, avec son titre, évite de réutiliser la même photo partout.

Vérifie que l'og:image de chaque page fait au moins 1 200 × 630 pixels, pèse moins de 1 Mo, est servie en URL absolue et répond en 200. Propose de générer automatiquement une image de partage par page à partir de son titre, avec le logo du site, si le projet n'en a pas.

Une traduction affichée en JavaScript sur la même adresse reste invisible pour les moteurs et les IA, qui ne voient que la langue d’origine. Chaque langue a son URL, par exemple /en/ pour l’anglais, avec un contenu servi dans le HTML.

Ce critère ne concerne que les sites en plusieurs langues.

Si le site existe en plusieurs langues, vérifie que chaque version a ses propres URL, que le contenu traduit est présent dans le HTML servi par le serveur, et que l'attribut lang de chaque page correspond à sa langue. Signale toute traduction chargée uniquement en JavaScript.

Les balises hreflang disent à Google quelle version montrer selon la langue de l’internaute. Elles fonctionnent par paires : si la page française pointe vers l’anglaise, l’anglaise doit pointer vers la française, et chacune vers elle-même.

Une balise x-default indique la version à montrer quand aucune langue ne correspond.

Si le site existe en plusieurs langues, vérifie que chaque page déclare des balises hreflang vers toutes ses versions, elle-même comprise, avec des codes valides (fr, fr-FR, en-GB et non en-UK), une balise x-default, et des liens réciproques. Vérifie que chaque URL citée dans un hreflang est canonique et répond en 200.

Sans mesure, impossible de savoir si le site rapporte quelque chose. L’outil d’analyse (Google Analytics 4, Matomo, Plausible) suit les visites. Il suit surtout les actions qui comptent, comme un formulaire envoyé, un rendez-vous réservé ou un achat.

L’installation respecte le consentement des visiteurs quand l’outil dépose des cookies.

Vérifie quel outil de mesure d'audience est installé et s'il se charge sur toutes les pages. Liste les actions importantes du site (formulaire, réservation, achat, clic sur un téléphone ou un e-mail) et dis-moi lesquelles sont suivies comme événements ou conversions. Vérifie que le chargement respecte le bandeau de consentement si l'outil dépose des cookies.

Les visites qui viennent de ChatGPT, Perplexity, Gemini, Copilot ou Claude arrivent avec l’adresse de ces services comme provenance. Regroupées dans un canal à part, elles montrent quelles pages les IA recommandent et ce que ces visiteurs font ensuite.

Aide-moi à créer dans mon outil d'analyse un regroupement de canaux « IA » qui rassemble les visites dont la provenance contient chatgpt.com, perplexity.ai, gemini.google.com, copilot.microsoft.com, claude.ai ou chat.mistral.ai. Donne-moi les étapes exactes dans l'interface de mon outil, et la liste des pages d'arrivée à surveiller.

Il n’existe pas de classement fixe dans les IA : leurs réponses changent d’une question à l’autre et d’un jour à l’autre. Le suivi repose donc sur une liste de questions que pose la cible, testées régulièrement, toujours avec le même outil.

Pour chaque question, on relève si la marque est mentionnée, si le site est cité en source, et si l’IA dit vrai sur la marque.

Aide-moi à construire une liste de 15 à 20 questions que ma cible pose aux IA avant de choisir un prestataire comme moi : des questions de découverte, de comparaison et de décision, plus deux questions sur ma marque. Prépare un tableau de suivi avec, pour chaque question et chaque IA testée : marque mentionnée, site cité en source, exactitude de ce qui est dit, concurrents cités à ma place.

Un site en ligne n’est pas encore un site indexé. Dans la Search Console, le rapport sur l’indexation des pages montre celles que Google a retenues. Il donne aussi la raison pour laquelle il en écarte d’autres.

Un nouveau contenu met souvent plusieurs semaines avant sa première impression dans la Search Console.

Prépare-moi un plan de contrôle de l'indexation pour les 30 jours qui suivent la mise en ligne : quoi regarder dans la Search Console à J+1, J+7 et J+30 (pages indexées, pages exclues et leurs raisons, erreurs du sitemap, Core Web Vitals), et quelles URL passer dans l'outil d'inspection en priorité.

Claude Code relit le fichier CLAUDE.md à chaque session. Les règles qui y figurent s’appliquent à chaque nouvelle page et à chaque modification, sans avoir à les redemander.

Sans ce fichier, une page ajoutée dans trois mois peut repartir sans title, sans balisage et sans lien interne.

Ajoute au fichier CLAUDE.md du projet une section « SEO et GEO » qui résume les règles à respecter pour toute nouvelle page ou modification : title unique de 40 à 70 caractères, meta description de 110 à 155 caractères, un seul h1, canonical absolue, texte présent dans le HTML serveur, alt sur les images, JSON-LD déduit du type de page, page ajoutée au sitemap et reliée par au moins un lien interne. Montre-moi la section avant de l'enregistrer.

Un jour de rush, on déploie sans repasser la checklist, et c’est ce jour-là qu’une règle saute. Un script qui contrôle les balises de chaque page après le build bloque le déploiement quand il trouve un défaut. Il vérifie le title, la meta, le H1, la canonical, les alt et le JSON-LD.

Le contrôle porte sur le HTML final, tel que les robots le reçoivent, pas sur les fichiers sources.

Écris un script de contrôle qui s'exécute après le build, sur le HTML généré. Pour chaque page, il vérifie : un title de 40 à 70 caractères, une meta description de 110 à 155 caractères, un seul h1, une canonical absolue, un attribut alt sur chaque image, un JSON-LD qui se parse, et la présence de la page dans le sitemap si elle est indexable. Il sort une erreur et bloque le déploiement en cas de défaut bloquant.

Après une modification, le CDN ou le cache du navigateur peut continuer à servir l’ancienne version pendant des heures. Une correction qui ne se voit pas en ligne n’existe pas encore pour Google.

Le contrôle se fait sur l’URL en ligne, avec un paramètre qui contourne le cache, par exemple ?v=2.

Après ce déploiement, vide le cache du CDN ou de l'hébergeur si le projet en utilise un. Puis récupère la page modifiée en ligne avec un paramètre anti-cache (?v= suivi d'un nombre aléatoire) et vérifie que la modification apparaît bien dans le HTML servi. Dis-moi si l'URL sans paramètre sert encore l'ancienne version.

Un site se dégrade sans prévenir : une page supprimée, un lien qui casse, un noindex qui réapparaît après une mise à jour. Un contrôle hebdomadaire des pages du sitemap attrape ces problèmes avant que Google ne les remarque.

La surveillance ne remonte que ce qui a changé depuis la dernière fois, sinon plus personne ne l’ouvre au bout de trois semaines.

Écris un script de surveillance à lancer une fois par semaine. Il parcourt les URL du sitemap et relève le code HTTP, la présence d'un noindex, le title et la canonical de chaque page, ainsi que les liens internes cassés. Il compare avec la passe précédente, enregistrée dans un fichier, et ne signale que ce qui est apparu ou a disparu depuis.

Un bandeau de consentement peut recouvrir toute la page, ou bloquer les polices et les scripts avant l’accord. Les robots ne voient alors pas la page telle que les visiteurs la voient.

Le contenu reste lisible derrière le bandeau, et seuls les outils de mesure et de publicité attendent le consentement.

Vérifie ce que bloque le bandeau de consentement avant l'accord du visiteur. Le texte de la page, les polices, les images et les scripts nécessaires à l'affichage doivent se charger sans consentement. Seuls les outils de mesure, de publicité et les contenus tiers comme les vidéos doivent attendre. Vérifie aussi que le bandeau ne recouvre pas tout le contenu sur mobile.