SEO technique : la checklist du développeur pour les consultants SEO checklist du développeur
Vous êtes consultant SEO et vous perdez du temps à courir après les corrections techniques que votre développeur n'a pas encore faites ? Cette checklist en 5 parties vous donne un langage commun pour cadrer les audits, prioriser les actions et livrer des sites qui rankent.
Vous avez livré un audit SEO technique complet. Vos 30 recommandations sont documentées, priorisées, argumentées. Trois mois plus tard, votre client vous demande pourquoi le trafic n'a pas bougé. Vous regardez le site : 5 points ont été corrigés. Les 25 restants attendent toujours le développeur.
Cette situation, tous les consultants SEO la connaissent. Elle n'est pas due à la mauvaise volonté du développeur : elle est le symptôme d'un problème de langage commun entre deux métiers qui ne se parlent pas naturellement. Cette checklist SEO technique en 5 parties a été conçue pour combler ce fossé. Partagez-la avec votre développeur ou votre partenaire technique au début de chaque projet : elle traduit vos exigences en tâches précises, vérifiables, et classées par ordre de priorité.
Le fossé entre SEO et développement
Le consultant SEO pense en termes de signaux, d'autorité, de crawl budget et de SERPs. Le développeur pense en termes de composants, de déploiements, de performances applicatives et de dette technique. Ces deux visions ne sont pas incompatibles, mais elles ne se parlent pas naturellement.
Le problème concret
Un développeur qui ne comprend pas pourquoi les balises canoniques comptent va les implémenter au dernier moment, partiellement, ou pas du tout. Un consultant SEO qui ne comprend pas les contraintes de rendu côté serveur va recommander des choses techniquement impossibles dans l'architecture choisie. Le résultat : des recommandations perdues, du temps gaspillé, et un client qui ne voit pas les résultats attendus.
La bonne nouvelle : vous n'avez pas besoin que votre développeur devienne consultant SEO, ni l'inverse. Vous avez besoin d'un contrat de collaboration clair, sous forme de checklist, qui définit ce qui doit être livré et comment le vérifier.
Selon une étude Ahrefs portant sur plus d'un milliard de pages web, 90,63% des pages n'obtiennent aucun trafic organique de Google. Parmi les causes principales figurent des problèmes techniques qui empêchent une indexation correcte. Des fondations solides ne suffisent pas à ranker, mais elles sont la condition sans laquelle tout le reste ne peut pas fonctionner.
Partie 1 : Fondations techniques
Les fondations techniques déterminent si Google peut accéder à votre site, le comprendre, et l'indexer correctement. Sans elles, le reste n'a aucune importance.
Robots.txt
Le fichier robots.txt indique aux robots d'exploration ce qu'ils peuvent et ne peuvent pas visiter. Une mauvaise configuration peut bloquer l'indexation de pages entières sans que vous le remarquiez.
| Point de contrôle | Outil de vérification |
|---|---|
| Le fichier robots.txt existe à la racine du site | Accès direct : domaine.com/robots.txt |
| Les pages importantes ne sont pas bloquées par Disallow | Google Search Console - Inspection d'URL |
| L'URL du sitemap est référencée dans robots.txt | Lecture directe du fichier |
| Les ressources CSS et JS ne sont pas bloquées | GSC - Rapport de couverture |
| Le fichier ne bloque pas les paramètres d'URL critiques | Screaming Frog |
Sitemap XML
Un sitemap bien construit aide Google à découvrir et prioriser vos pages. Son absence ou sa mauvaise configuration ralentit l'indexation, surtout pour les nouveaux sites.
| Point de contrôle | Outil de vérification |
|---|---|
| Le sitemap existe et est accessible (/sitemap.xml) | Accès direct + GSC - Sitemaps |
| Il est soumis dans Google Search Console | GSC - Sitemaps |
| Il ne contient que des pages indexables (pas de noindex) | Screaming Frog |
| Toutes les URLs sont canoniques (HTTPS, www cohérent) | Screaming Frog |
| Il est mis à jour automatiquement lors d'ajout de pages | Test après ajout d'une page |
| Les images importantes sont listées dans le sitemap images | Screaming Frog |
Redirections
Les redirections mal configurées diluent l'autorité de lien et créent des chaînes qui ralentissent le crawl. Un seul mauvais paramétrage au niveau du domaine peut coûter des mois de positionnement.
| Point de contrôle | Outil de vérification |
|---|---|
| Toutes les redirections HTTP vers HTTPS sont en 301 | httpstatus.io |
| Les redirections www vers non-www (ou inversement) sont en 301 | httpstatus.io |
| Il n'existe pas de chaînes de redirections (A vers B vers C) | Screaming Frog |
| Les pages supprimées redirigent vers une page pertinente, pas l'accueil | Screaming Frog |
| Les erreurs 404 ont été identifiées et traitées | GSC - Couverture |
| Les redirections temporaires (302) ne sont pas utilisées à tort | Screaming Frog |
Partie 2 : Performance et Core Web Vitals
Depuis la Page Experience Update de Google en 2021, les Core Web Vitals sont un facteur de ranking officiel. LCP, INP et CLS mesurent l'expérience réelle des utilisateurs et impactent directement votre positionnement dans les résultats de recherche. Nous avons consacré un article complet aux Core Web Vitals pour les agences en 2026 si vous souhaitez aller plus loin sur chaque métrique.
Seuils officiels Google en 2026
LCP (Largest Contentful Paint) : moins de 2,5 secondes = Good, entre 2,5 et 4 secondes = Needs Improvement, plus de 4 secondes = Poor. INP (Interaction to Next Paint) : moins de 200 ms = Good, entre 200 et 500 ms = Needs Improvement, plus de 500 ms = Poor. CLS (Cumulative Layout Shift) : moins de 0,1 = Good, entre 0,1 et 0,25 = Needs Improvement, plus de 0,25 = Poor.
LCP (Largest Contentful Paint) : temps de chargement principal
| Point de contrôle | Outil de vérification |
|---|---|
| L'image hero est préchargée avec l'attribut preload | PageSpeed Insights - Opportunités |
| L'image LCP est en format WebP ou AVIF | Lighthouse - Images |
| Le serveur répond en moins de 200 ms (TTFB) | PageSpeed Insights - TTFB |
| Les fonts sont préchargées et n'utilisent pas font-display:block | Lighthouse |
| Un CDN distribue les ressources statiques | WebPageTest |
| Le LCP ne dépend pas d'un script côté client pour s'afficher | Lighthouse - LCP element |
INP (Interaction to Next Paint) : réactivité
| Point de contrôle | Outil de vérification |
|---|---|
| Les scripts tiers (analytics, chat, pub) sont chargés de façon asynchrone | Lighthouse - Third-party code |
| Il n'y a pas de Long Tasks de plus de 50 ms bloquant le thread principal | Chrome DevTools - Performance |
| Les gestionnaires d'événements (click, scroll) sont optimisés | Chrome DevTools |
| Le bundle JavaScript est divisé (code splitting) pour éviter un JS initial lourd | Lighthouse - JavaScript execution |
CLS (Cumulative Layout Shift) : stabilité visuelle
| Point de contrôle | Outil de vérification |
|---|---|
| Toutes les images ont des attributs width et height explicitement définis | Screaming Frog |
| Les blocs publicitaires et embeds ont des espaces réservés (placeholders) | Test visuel |
| Les fonts web ne provoquent pas de FOUT visible lors du chargement | Test visuel |
| Les animations CSS n'affectent pas le layout (transform plutôt que width/height) | Lighthouse |
Optimisation des images
| Point de contrôle | Outil de vérification |
|---|---|
| Toutes les images sont compressées avant mise en ligne | Squoosh ou ImageOptim |
| Le lazy loading est activé sur les images hors viewport | Inspecteur Chrome |
| Les images responsive utilisent l'attribut srcset | Screaming Frog |
| Aucune image de fond critique n'est chargée via CSS seul | Lighthouse - LCP element |
Partie 3 : Structure HTML et balisage
La structure HTML de vos pages détermine comment Google comprend votre contenu et comment il extrait les informations pertinentes pour les résultats de recherche. Ces éléments sont souvent négligés lors du développement parce qu'ils ne sont pas visibles, mais ils sont parmi les plus impactants.
Balises title et meta description
| Point de contrôle | Outil de vérification |
|---|---|
| Chaque page a une balise title unique | Screaming Frog |
| Les titles font entre 50 et 60 caractères | Screaming Frog |
| Chaque page a une meta description unique | Screaming Frog |
| Les meta descriptions font entre 120 et 155 caractères | Screaming Frog |
| Aucune page n'a de title ou meta description dupliqué | Screaming Frog - Duplicates |
| Les titles contiennent le mot-clé cible naturellement | Revue manuelle |
Structure des headings
| Point de contrôle | Outil de vérification |
|---|---|
| Chaque page a exactement un H1 | Inspecteur Chrome |
| La hiérarchie H1, H2, H3 est respectée sans sauts | Screaming Frog |
| Les headings contiennent les mots-clés cibles naturellement | Revue manuelle |
| Le H1 est différent du title mais cohérent avec lui | Revue manuelle |
Balises canoniques
| Point de contrôle | Outil de vérification |
|---|---|
| Chaque page a une balise canonical pointant vers elle-même | Inspecteur Chrome |
| Les canonicals utilisent des URLs absolues (pas relatives) | Screaming Frog |
| Les pages paginées gèrent correctement leurs canonicals | Screaming Frog |
| La canonical est cohérente avec l'URL du sitemap | Screaming Frog |
Balises Open Graph et meta sociale
| Point de contrôle | Outil de vérification |
|---|---|
| Les balises og:title, og:description et og:image sont présentes | Facebook Debugger |
| L'image og:image fait au minimum 1200 x 630 px | Facebook Debugger |
| Les balises Twitter Card sont configurées | Twitter Card Validator |
| Les images sociales sont hébergées sur le même domaine | Inspecteur Chrome |
Partie 4 : Indexation et contenu dupliqué
Le contenu dupliqué et les problèmes d'indexation sont parmi les causes les plus fréquentes de sous-performance SEO. Ils sont aussi parmi les plus simples à corriger si identifiés tôt, et parmi les plus coûteux à ignorer sur le long terme.
Contrôle de l'indexation
| Point de contrôle | Outil de vérification |
|---|---|
| Les pages à ne pas indexer ont la balise meta robots noindex | Screaming Frog |
| Les pages noindex ne sont pas dans le sitemap XML | Screaming Frog |
| Les paramètres d'URL (filtres, tri, session) sont gérés par canonical ou noindex | GSC - Inspection d'URL |
| Les pages de résultats de recherche interne ne sont pas indexées | GSC - Couverture |
| La page 404 retourne bien un code HTTP 404, pas un 200 | httpstatus.io |
Contenu dupliqué technique
| Point de contrôle | Outil de vérification |
|---|---|
| Les versions HTTP et HTTPS redirigent vers une seule version | httpstatus.io |
| Les versions www et non-www redirigent vers une seule version | httpstatus.io |
| Les URLs avec et sans slash final sont canonicalisées | Screaming Frog |
| Les contenus de pagination ne créent pas de duplication | Screaming Frog |
| Les versions mobile et desktop sont unifiées (responsive, pas de site m.) | Test mobile |
Sites multilingues et multirégionaux
Pour les agences qui gèrent des clients avec des sites en plusieurs langues, les balises hreflang sont essentielles pour éviter que les versions linguistiques se cannibalisent mutuellement dans les SERPs. C'est un enjeu courant en Belgique, où coexistent contenu francophone et néerlandophone.
| Point de contrôle | Outil de vérification |
|---|---|
| Les balises hreflang sont présentes sur toutes les pages concernées | Screaming Frog |
| Chaque URL hreflang est absolue et accessible | hreflang.org |
| La balise hreflang x-default est définie sur la page par défaut | Screaming Frog |
| Les paires hreflang sont réciproques (si A pointe vers B, B pointe vers A) | Screaming Frog |
Partie 5 : Données structurées
Les données structurées (schema markup) permettent à Google de comprendre votre contenu et d'afficher des rich snippets dans les résultats de recherche : étoiles, FAQ, prix, événements, et bien d'autres. Ces enrichissements visuels augmentent le taux de clic sans nécessairement améliorer le positionnement, mais l'effet combiné peut être significatif.
Selon les données publiées par Google, les pages avec schema FAQ peuvent voir leur taux de clic augmenter de 20 à 30% grâce à l'affichage des questions directement dans la SERP. C'est une opportunité que beaucoup de développeurs ne saisissent pas par manque de familiarité avec le format JSON-LD.
| Type de schema | Usage recommandé | Impact potentiel |
|---|---|---|
| Organization / LocalBusiness | Toutes les pages (via header ou footer) | Autorité de marque + Knowledge Panel |
| WebSite | Page d'accueil uniquement | Sitelinks Search Box potentiel |
| Article / BlogPosting | Articles de blog et guides | +15 à 25% de CTR en moyenne |
| FAQPage | Pages avec sections questions-réponses | +20 à 30% de CTR |
| BreadcrumbList | Navigation fil d'Ariane | Affichage du chemin en SERP |
| Product | Pages produits e-commerce | Prix et disponibilité en SERP |
| Review / AggregateRating | Pages avec avis clients | Étoiles visibles dans les résultats |
Points de contrôle pour les données structurées
| Point de contrôle | Outil de vérification |
|---|---|
| Le schema Organization est implémenté sur l'ensemble du site | Rich Results Test |
| Le schema approprié est présent sur chaque type de page | Rich Results Test |
| Les données structurées sont en JSON-LD (recommandé par Google) | Inspecteur Chrome |
| Aucune erreur n'est signalée dans GSC - Améliorations | Google Search Console |
| Les données structurées ne contiennent pas d'informations trompeuses | Revue manuelle |
| Le schema LocalBusiness inclut adresse, téléphone et horaires si pertinent | Rich Results Test |
Utiliser cette checklist avec votre partenaire
Avoir une checklist est bien. Savoir l'intégrer dans un workflow de projet est encore mieux. Voici comment l'utiliser efficacement selon la phase du projet.
Brief initial avec la checklist
En début de projet, partagez la checklist complète avec votre développeur ou partenaire. Identifiez les points qui nécessitent une attention particulière selon l'architecture choisie (WordPress, Next.js, site statique). Convenez de qui est responsable de chaque section.
Revue à mi-développement
À mi-projet, passez en revue les sections Fondations et Structure HTML. Ces points sont plus faciles à corriger avant que le développement soit finalisé. Screaming Frog peut crawler le site de staging pour un premier bilan.
Validation complète pré-lancement
Avant la mise en ligne, passez l'intégralité de la checklist. Utilisez Google Search Console (avec validation de propriété sur le staging), PageSpeed Insights et le Rich Results Test. Documentez les scores obtenus pour référence future.
Audit post-lancement à 30 jours
Un mois après le lancement, vérifiez dans Google Search Console que toutes les pages importantes sont indexées, que les Core Web Vitals sont dans les seuils Good, et qu'aucune erreur de données structurées n'est signalée.
Revue trimestrielle sur les sites actifs
Les mises à jour de thème, les nouvelles pages et les modifications de code peuvent réintroduire des problèmes déjà résolus. Planifiez une revue rapide des points critiques tous les trois mois sur les sites que vous suivez.
Ce que vous devez attendre d'un bon partenaire développement
Si vous travaillez avec un partenaire white-label ou un prestataire technique, ces points devraient faire partie de la livraison standard, sans avoir à les demander explicitement à chaque projet.
Robots.txt et sitemap configurés
Le partenaire configure robots.txt et sitemap XML par défaut sur chaque projet livré.
Redirections propres par défaut
HTTPS, www/non-www et pages supprimées sont gérés avec des redirections 301 correctes.
Score PageSpeed 90+ à la livraison
Les Core Web Vitals sont dans les seuils Google à la livraison, pas après un cycle de corrections.
Balises méta uniques sur chaque page
Chaque page a un title et une meta description distincts, configurables par l'équipe SEO.
Schema Organization intégré
Les données structurées de base sont implémentées sans supplément dans chaque projet.
Documentation technique livrée
Un résumé des choix techniques et des points SEO est fourni avec chaque projet.
Si votre partenaire actuel ne livre pas ces éléments par défaut, c'est un signal à prendre au sérieux. Nous avons détaillé les critères pour choisir un bon partenaire de développement, y compris les aspects techniques liés au SEO. Et si vous êtes consultant SEO qui envisage de proposer des services de développement à vos clients, notre article sur pourquoi les agences SEO externalisent le développement web vous donnera une perspective utile sur ce modèle.
Pour comprendre comment les choix d'architecture du développeur impactent directement vos résultats SEO, l'article sur les fondations techniques du SEO que vous négligez complète utilement cette checklist.
Questions fréquentes
Conclusion
Le SEO technique n'est pas une option que l'on ajoute après coup : c'est une fondation que l'on pose correctement dès le début du développement. Cette checklist en 5 parties, partagée avec votre développeur au bon moment, peut faire la différence entre un site qui stagne et un site qui progresse régulièrement dans les résultats de recherche.
La réalité des agences SEO francophones, en Belgique comme en Suisse romande ou au Luxembourg, est souvent la même : les recommandations techniques sont correctes, mais leur implémentation reste partielle parce qu'il n'existe pas de processus clair entre consultant et développeur. Cette checklist est ce processus.
Si vous cherchez un partenaire de développement qui comprend ces enjeux par défaut, sans que vous ayez à tout spécifier à chaque projet, découvrez comment fonctionne notre service de développement web white-label. Vos recommandations SEO méritent un développeur qui les applique vraiment.
Articles complémentaires
Core Web Vitals : ce que chaque agence doit savoir en 2026
Les Core Web Vitals de Google sont désormais un facteur de classement confirmé. En 2026, les agences qui livrent des sites lents pénalisent doublement leurs clients : mauvaise expérience utilisateur et positionnement dégradé dans les résultats de recherche. Ce guide vous explique les trois métriques essentielles, comment les mesurer et comment garantir des scores optimaux à chaque livraison.
TechnologiesAu-delà du contenu : les fondations
Les agences SEO savent produire du contenu. Mais quand un site sous-performe malgré des dizaines d'articles optimisés, la cause est presque toujours technique : crawlabilité défaillante, Core Web Vitals dans le rouge, architecture incohérente. Cet article expose les fondations techniques du SEO que les consultants SEO francophones délèguent souvent à tort, et comment y remédier.
Études de CasÉtude de cas : de freelance surchargé
Thomas, freelance web à Namur, était bloqué à 4 500 euros par mois. Pas par manque de clients, mais par manque de capacité. Voici comment il a restructuré son activité grâce au white-label pour atteindre 9 200 euros mensuels sans travailler plus.