Compétence SEO Engineering

Mission

Aider le projet à gagner une visibilité organique durable et des visites qualifiées en rendant les pages utiles découvrables, compréhensibles, éligibles à la recherche, dignes de confiance pour les utilisateurs, techniquement fiables et connectées aux objectifs métier.

Cette compétence est indépendante du projet. Adaptez-la au métier, à l'audience, au marché, au CMS/framework, à l'environnement d'hébergement, aux moteurs de recherche et à la demande réelle de l'utilisateur. Ne supposez pas que le projet est Next.js, un blog, un site e-commerce, un commerce local ou un domaine particulier avant de l'avoir inspecté.

Aucune technique ne garantit l'indexation, les résultats enrichis, les citations IA, le trafic, les leads ou une position dans les résultats de recherche. Les moteurs de recherche choisissent si et comment crawler, indexer et classer les pages. Soyez précis sur ce qui a été testé par rapport à ce qui est déduit.

Principes de fonctionnement non-négociables

Auditer avant de modifier. Inspectez le dépôt et, lorsque l'accès le permet, le site en production. Identifiez ce qui fonctionne déjà. Préservez la configuration correcte et la valeur SEO existante.
Priorité aux utilisateurs, guidé par les preuves. Optimisez pour la tâche du visiteur et la pertinence métier, et non pour la densité de mots-clés, un volume de contenu arbitraire ou l'exécution d'une liste de contrôle.
La documentation actuelle prime. Consultez la documentation officielle et actuelle des moteurs de recherche pour les affirmations affectées par les modifications des fonctionnalités de recherche, de l'éligibilité des schémas, des politiques anti-spam, des API, des robots d'indexation ou des outils. Privilégiez Google Search Central, la documentation Webmaster de Bing et la documentation officielle du framework/plateforme. Les articles de la communauté peuvent fournir des hypothèses, mais ne remplacent pas les directives officielles.
Modifications minimales et réversibles. Faites la plus petite implémentation qui corrige un problème vérifié. Ne refactorez pas de code non lié, ne changez pas de domaine/DNS/serveurs de noms, ne faites pas pivoter les identifiants, ne supprimez pas les jetons de vérification, ne changez pas d'hébergement et ne déployez pas en production sans autorisation explicite.
Ne jamais fabriquer de preuves. N'inventez pas de volumes de mots-clés, de difficulté de classement, de backlinks, de trafic, de concurrents, d'états d'indexation, de mesures de performance, de références d'auteurs, d'avis, de faits liés aux données structurées ou de résultats de tests réussis.
Pas de garanties de classement ni de spam. Ne recommandez pas le cloaking, le texte de mot-clé caché, le bourrage de mots-clés, les pages portes, le contenu de faible valeur à grande échelle, les systèmes de liens, les faux avis, les schémas trompeurs ou le contenu automatisé dont le but principal est de manipuler les classements.
Séparez les préoccupations. La crawlability, l'indexabilité, le classement, la présentation dans les résultats et la conversion sont distincts. Corrigez la couche pertinente plutôt que d'affirmer qu'un seul changement technique résoudra tous les problèmes.
Gardez les données sensibles en sécurité. N'exposez pas de secrets, de clés API, d'informations clients, d'identifiants d'analyse ou de pages privées dans les rapports, les commits, les journaux ou les exemples générés.
Respectez l'architecture existante. Apprenez la stack, les conventions de nommage, le modèle de routage et le processus de déploiement avant de choisir une implémentation. Privilégiez les patterns de projet établis plutôt que d'introduire des dépendances.
Signalez clairement l'incertitude. Si l'accès externe, les identifiants, l'accès réseau ou les tests en production ne sont pas disponibles, indiquez ce qui reste non vérifié et fournissez des vérifications manuelles sûres.

Aperçu du workflow

Pour les tâches SEO importantes, suivez cette séquence :

Comprendre le site et l'entreprise.
Établir la base de référence et inspecter l'implémentation.
Rechercher les exigences actuelles des moteurs de recherche si nécessaire.
Produire un diagnostic priorisé et un plan proposé.
Implémenter uniquement les changements autorisés et nécessaires.
Exécuter des tests pertinents et inspecter le comportement réel rendu/déployé.
Rapporter les changements, les preuves, les risques restants et les étapes de suivi.

Pour une demande ciblée (par exemple, améliorer une balise titre), n'utilisez que les parties pertinentes de ce workflow, mais vérifiez toujours les effets secondaires et évitez les affirmations non étayées.

1. Découvrir le projet et ses objectifs

Inspectez le dépôt et les indices de déploiement avant de suggérer du code. Identifiez, selon le cas :

Objectif du site/de l'entreprise, audience, offre, modèle de monétisation, principales conversions et cibles géographiques/linguistiques.
Type de site : informationnel, éditeur de contenu, SaaS, marketplace, e-commerce, commerce local, portfolio, documentation, forum, éditeur ou hybride.
Framework/CMS et version, routeur, stratégie de rendu, source de contenu, gestionnaire de paquets, commandes de build/lint/test et bibliothèques SEO existantes.
Configuration d'hébergement/CDN/edge, variantes de domaine, redirections, configuration d'environnement, et staging vs production.
Types de routes : page d'accueil, page de service/catégorie, pages de détail, blog/article, auteur, résultats de recherche, tags/catégories, pagination, URL filtrées/facettées, variantes de produits, routes localisées et pages d'erreur.
Outils d'analyse et de recherche existants : Google Search Console, GA4 ou autre outil d'analyse, Bing Webmaster Tools, accès aux logs, suivi de classement, rapports de crawl, suivi des conversions et plateforme de gestion du consentement.
Décisions techniques existantes : hôte canonique, stratégie de sitemap, règles robots, redirections, données structurées, hreflang, politique d'indexation, modèles de métadonnées et maillage interne.

Ne demandez pas d'informations que le dépôt ou le contexte fourni contient déjà. Si un fait critique ne peut être établi, continuez avec des hypothèses explicites ou posez une question concise lorsque la décision en dépend réellement.

2. Base de référence et crawl du site

Utilisez les outils disponibles adaptés à l'environnement. Préférez un crawl représentatif et une inspection ciblée du code plutôt que des hypothèses basées uniquement sur les noms de fichiers.

Inspection du dépôt

Inspectez les fichiers et chemins sources pertinents, y compris, mais sans s'y limiter :

Fichiers de package/configuration, configuration du framework, configuration d'hébergement/déploiement, middleware/proxy et règles de redirection.
Layouts racine et imbriqués, modules de route/page, aides à la métadonnée, schémas de contenu, configuration CMS, modèles et composants de navigation/pied de page partagés.
sitemap.xml ou code de génération de sitemap, robots.txt, logique canonique, redirections et aides à la construction d'URL.
Générateurs de données structurées, composants image/vidéo, configuration d'analyse/consentement et gestion des 404/410.
Tests existants et vérifications CI.

Ne divulguez pas les valeurs .env ou d'autres secrets. Vérifiez si les variables requises existent sans imprimer les valeurs.

Inspection du site en direct, si autorisé

Testez des classes d'URL représentatives et inspectez les réponses et le HTML rendu. Capturez :

Code de statut, chaîne de redirection et URL finale.
Balise canonique, titre, méta-description, directives robots et en-têtes robots.
Contenu principal en HTML brut et en HTML rendu lorsque JavaScript est impliqué.
Liens internes, inclusion dans le sitemap, données structurées et versions dupliquées évidentes.
Rendu mobile, échecs de rendu évidents et données de performance disponibles.

Échantillonnez au minimum la page d'accueil, les pages clés de conversion/service, les principales pages de liste, les pages de détail représentatives, un article de blog, une page de catégorie/tag/filtre si applicable, une URL valide avec paramètres de requête et une URL inexistante. Pour les grands sites, construisez un échantillon de crawl et segmentez par modèle. N'affirmez pas avoir crawlé chaque URL si ce n'est pas le cas.

Preuves de base de référence

Enregistrez les bases de référence disponibles avant les changements : nombre d'URL par modèle, distribution des codes de réponse, indexabilité, cohérence canonique, erreurs de sitemap, clics organiques/impressions/CTR/position, conversions, Core Web Vitals et résultats métier pertinents. N'inventez pas de mesures manquantes.

3. Prioriser les problèmes de manière rationnelle

Utilisez la sévérité et la confiance plutôt qu'un score SEO vague. Une échelle de priorité pratique :

P0 — Critique : noindex à l'échelle du site, blocage accidentel par robots, mauvaise canonique sur les routes principales, boucle de redirection, panne de production, erreurs 5xx généralisées, perte de domaine/migration d'URL, compromission de sécurité, ou tout autre problème empêchant les pages importantes d'être accessibles/indexables.
P1 — Élevée : Les pages importantes/monétisées sont bloquées, mal canonisées, omises de la navigation/du sitemap, ne rendent aucun contenu substantiel, renvoient des statuts incorrects ou présentent un défaut de modèle systématique.
P2 — Moyenne : Problèmes importants de métadonnées/données structurées/maillage interne/performance, sections orphelines, pages dupliquées, mauvaise couverture de contenu ou obstacles significatifs à la conversion.
P3 — Faible/opportunité : Améliorations mineures de copie, polissage à faible impact, données structurées optionnelles, lacunes isolées dans le texte alternatif ou opportunités de contenu spéculatives.

Pour chaque constatation, indiquez : la preuve, les URL/modèles concernés, l'impact probable sur l'utilisateur/la recherche, la confiance, l'effort d'implémentation, le risque, la recommandation et la méthode de validation. N'assimilez pas la sévérité à un changement de classement garanti.

4. SEO technique : crawling, indexation, URL et codes de statut

Crawlability et indexabilité

Séparez l'accès au crawl (robots.txt, réponses serveur, liens accessibles), les instructions d'indexation (noindex, signaux canoniques, statut), la sélection canonique et le classement.
Assurez-vous que le contenu public important est accessible via des liens crawlables normaux et répond correctement.
Utilisez noindex uniquement intentionnellement. N'oubliez pas que robots.txt bloque le crawling ; ce n'est pas un moyen fiable de supprimer une URL des résultats de recherche, et un robot d'indexation doit généralement récupérer une page pour voir sa directive noindex au niveau de la page.
N'interdisez pas les ressources nécessaires au rendu ou à la compréhension d'un contenu important, sauf si le blocage est intentionnel et validé.
Gardez les zones de connexion, de compte, d'administration, de paiement, de recherche interne, d'aperçu, de staging et privées hors de la recherche, le cas échéant. Protégez le contenu privé avec une autorisation ; robots.txt n'est pas un contrôle d'accès.
Assurez-vous que les pages manquantes renvoient un vrai 404 ou 410 le cas échéant plutôt qu'un soft 404 200. Ne redirigez pas les URLs supprimées sans rapport vers la page d'accueil.
Ne forcez pas l'indexation de chaque URL. Certains filtres, résultats de recherche interne, pages de tag légères, variantes dupliquées et pages utilitaires peuvent ne pas mériter l'indexation.
Considérez l'optimisation du budget de crawl comme une préoccupation spécialisée pour les sites très volumineux ou fréquemment mis à jour, et non comme un rituel pour les petits sites.

Canonicalisation et normalisation des URLs

Choisissez un format de protocole/hôte/chemin préféré qui correspond à la décision commerciale réelle, à la configuration du domaine et à la valeur SEO existante. Ne supposez pas que www ou non-www est intrinsèquement supérieur.
Pour les URLs véritablement dupliquées, alignez les redirections permanentes si approprié, les éléments de lien canonique, les liens internes, les URLs de sitemap et les URLs de données structurées.
Utilisez une canonique absolue correcte pour chaque page indexable. Évitez de canoniser du contenu non lié ou toutes les pages vers la page d'accueil.
Traitez les redirections comme des signaux de canonicalisation forts, rel="canonical" comme un signal fort et l'inclusion dans le sitemap comme un signal plus faible. Ce sont des signaux, pas des commandes absolues.
Gardez les cibles canoniques indexables, crawlables, réussies et pertinentes. Évitez les chaînes et boucles de redirection ; utilisez des redirections directes vers la destination finale.
Ne supprimez pas aveuglément les paramètres de requête légitimes. Comprenez le suivi de campagne, les filtres, la pagination, le tri, les variantes de produits et la fonctionnalité de l'application avant de normaliser les URLs.
Préservez les URLs existantes de valeur, sauf s'il existe une raison claire de les modifier.

Redirections et erreurs

Utilisez des redirections permanentes (301 ou 308) lorsqu'une URL a été définitivement déplacée et que la plateforme les prend en charge correctement ; utilisez des redirections temporaires pour des conditions temporaires.
Testez le comportement HTTP/HTTPS, www/non-www et la barre oblique finale uniquement selon l'architecture de site prévue.
Préservez le chemin et les paramètres de requête significatifs lors de la normalisation du nom d'hôte ou du protocole.
Évitez les règles larges qui capturent les points de terminaison API, les ressources, les sous-domaines ou les chemins sans rapport.
Pour les changements d'URL, créez un mappage un-à-un de l'ancienne à la nouvelle URL partout où un équivalent existe réellement. Redirigez les URLs obsolètes vers le remplacement le plus pertinent, pas indistinctement vers la page d'accueil.
Vérifiez les codes de statut et les sauts de redirection dans l'environnement déployé ; la configuration locale seule ne prouve pas le comportement en production.

JavaScript et rendu

Confirmez que le contenu principal, les titres de page, les métadonnées, les indications canoniques, les liens et les données structurées sont présents dans la sortie crawlable/rendue.
Utilisez le rendu côté serveur, la génération statique ou le prérendu lorsque cela est approprié pour la stack et le site, mais ne migrez pas les frameworks uniquement à cause du folklore SEO.
Rendez la navigation importante crawlable avec des liens normaux <a href="...">. Ne dépendez pas uniquement des gestionnaires de clic ou des interactions inaccessibles de l'application shell pour la découverte.
Ne comptez pas sur l'interaction utilisateur, l'authentification ou les effets différés côté client pour révéler un contenu indexable essentiel.
Évitez les valeurs canoniques ou robots contradictoires entre le HTML initial et le HTML rendu par JavaScript. Si JavaScript modifie les métadonnées, inspectez la sortie rendue.
Utilisez les systèmes de métadonnées et de routage natifs du framework plutôt que de dupliquer les métadonnées via des mécanismes contradictoires.

Sitemap XML

Générez les sitemaps à partir de la source réelle de route/contenu lorsque c'est possible.
Incluez uniquement les URLs canoniques préférées qui devraient être éligibles à l'indexation ; excluez les redirections, les URLs noindex, les erreurs, les pages privées et les variantes d'URL non pertinentes.
Utilisez des URLs absolues et l'hôte/protocole préféré de manière cohérente.
Mettez à jour automatiquement les sitemaps lorsque du contenu éligible est publié, mis à jour ou supprimé.
Utilisez des valeurs lastmod significatives uniquement lorsqu'elles sont étayées par une date de modification matérielle réelle ; ne mettez pas à jour chaque date à chaque déploiement.
Respectez les limites du protocole sitemap ; utilisez un index de sitemap et des sitemaps segmentés lorsque l'échelle ou la maintenabilité le justifie. Plusieurs sitemaps n'améliorent pas intrinsèquement les classements.
Validez la syntaxe XML, le statut de réponse, le type de contenu, le nombre d'URL et des exemples d'URL. Vérifiez le rapport Sitemaps dans Search Console si autorisé.
N'affirmez pas que la soumission d'un sitemap garantit le crawling, l'indexation ou le classement.

robots.txt et directives

Inspectez les directives existantes avant de modifier. Préservez les règles sauf si elles sont erronées ou ont un objectif documenté clair.
Ajoutez l'emplacement du sitemap le cas échéant et assurez-vous qu'il s'agit de l'URL canonique du sitemap.
Distinguez les directives de crawl robots.txt des directives d'index meta robots et X-Robots-Tag.
Soyez particulièrement prudent

arunacharya1603/seo-engineering

Qu'est-ce que seo-engineering ?

Demander à votre IA préférée

Documentation