Transactionnel · P0
SEO technique : rendre le site réellement explorable et indexable
Le SEO technique garantit qu'un moteur peut accéder au contenu, le rendre, le comprendre et le juger éligible. Tant que cette couche est défaillante, le travail éditorial et l'autorité ne produisent rien de mesurable. L'intervention porte sur le code, la configuration serveur et les templates, avec un contrôle par re-crawl après chaque correctif.
Périmètre
Ce que couvre cette prestation
Diagnostic et correction de la couche d'accès : exploration, rendu, indexabilité, signaux de duplication, performance de livraison et balisage machine.
Inclus
- robots.txt, meta robots, en-tête X-Robots-Tag et cohérence entre les trois
- Canonical auto-référente, duplication par paramètres, variantes avec et sans slash
- Codes HTTP, chaînes et boucles de redirection, 404 et 410 réels
- Sitemaps XML : exactitude, segmentation par type, lastmod significatif
- Rendu : présence du contenu principal dans le HTML servi, hydratation, contenu injecté côté client
- Budget de crawl : facettes, filtres, calendriers, recherche interne, pagination
- Données structurées générées depuis des données réelles et validées en intégration continue
- Core Web Vitals : LCP, INP, CLS au 75e centile terrain quand des données existent
- En-têtes de sécurité et politique de contenu, qui conditionnent aussi la livraison
Hors périmètre
- Refonte d'architecture applicative non justifiée par un gain d'indexation mesurable
- Optimisation de scores de laboratoire sans effet terrain constatable
- Migration de framework pour des raisons de mode
Problèmes traités
Ce qui amène généralement à cette page
Le contenu principal dépend du JavaScript
Si le texte et les liens n'existent qu'après hydratation, l'exploration devient coûteuse et incertaine. Le contenu principal doit être présent dans le HTML servi.
Le budget de crawl part dans des URL sans valeur
Facettes combinées, tris, paramètres de session et recherche interne peuvent générer un volume d'URL très supérieur au catalogue réel. Les pages importantes sont alors explorées rarement.
Les signaux de duplication se contredisent
Canonical qui pointe ailleurs, sitemap qui liste des URL redirigées, meta robots en désaccord avec robots.txt : le moteur arbitre lui-même, souvent à l'inverse de l'intention.
Les redirections forment des chaînes
Les chaînes et les boucles diluent les signaux et ralentissent l'exploration. Une redirection doit atteindre sa destination finale en un saut.
Livrables
Ce que vous recevez
-
Rapport de crawl commenté
Inventaire des URL servies, statuts, indexabilité, profondeur, duplication, avec les écarts par rapport au sitemap et à Search Console.
-
Spécifications par template
Pour chaque gabarit : règles de canonical, de robots, de pagination, de balisage et de rendu, avec le comportement attendu.
-
Table de redirections
Mapping source vers destination finale, sans chaîne ni boucle, avec les cas assumés en 410 plutôt qu'en redirection de complaisance.
-
Jeu de contrôles automatisables
Vérifications à intégrer dans votre chaîne d'intégration continue : liens cassés, canonical, H1 unique, JSON-LD parseable, destinations de redirection existantes.
Méthode
Comment on procède
-
Observer le servi, pas le supposé
Comparaison entre le HTML servi, le DOM rendu et ce que voit un client sans JavaScript. Les écarts sont la matière du diagnostic.
-
Mesurer le crawl réel
Quand les logs sont disponibles, répartition des hits par répertoire et par code de statut. Sinon, approximation par crawl et par rapports d'indexation, annoncée comme telle.
-
Corriger la couche d'accès en premier
Indexabilité, statuts, duplication, puis seulement architecture et performance. L'ordre évite de travailler sur des pages que le moteur ne retient pas.
-
Automatiser le contrôle
Les règles obtenues deviennent des tests. Un correctif non testé se perd à la prochaine mise en production.
Preuves
Ce qui est vérifiable
- Ce site est construit avec les contrôles qu'il recommande : liens internes, canonical, H1 unique, JSON-LD, destinations de redirection et texte de remplissage sont vérifiés par script avant publication.
- Le contenu principal de chaque page de ce site est présent dans le HTML servi : il reste lisible avec JavaScript désactivé.
- Le mapping de migration de ce domaine traite 404 URL sans aucune redirection de masse vers l'accueil.
Les chiffres cités proviennent des exports Search Console de ce domaine datés du 26 octobre 2026, publiés avec leurs limites sur la page études de cas. Aucun résultat client n'est publié sans accord et sans fenêtre de mesure explicite.
Cas d'usage
Situations typiques
Catalogue avec navigation à facettes
Arbitrage entre indexation, canonical et blocage, facette par facette, selon la demande de recherche réelle.
Application en rendu client
Passage au rendu serveur ou au prérendu pour les routes qui doivent être indexées, en conservant l'expérience applicative ailleurs.
Site avec historique de migrations successives
Nettoyage des chaînes de redirection accumulées et remise à plat des canonical.
Limites et cas où cela ne s'applique pas
- Corriger la technique ne crée pas de demande : si l'intention n'est pas couverte par un contenu utile, l'indexation ne suffit pas.
- Sans logs serveur, le comportement des robots est déduit et non mesuré.
- Les données Core Web Vitals terrain n'existent pas pour les sites à faible trafic : la mesure se fait alors en laboratoire, avec une confiance moindre.
- Certaines limites viennent du CMS ou de l'hébergement : le correctif peut exiger un changement d'infrastructure, qui est alors chiffré séparément.
Questions fréquentes
Faut-il bloquer les facettes dans robots.txt ?
Pas systématiquement. Bloquer dans robots.txt empêche l'exploration mais pas forcément l'indexation d'une URL découverte par un lien. Selon le cas, la bonne réponse est une canonical, une balise meta robots noindex sur une URL explorable, ou l'absence de génération du lien. La décision se prend facette par facette, en fonction de la demande de recherche.
Le rendu dynamique est-il une bonne solution ?
C'est une solution de contournement, pas une cible. Elle ajoute une infrastructure à maintenir et une source de divergence entre ce que voient les robots et les utilisateurs. Le rendu serveur ou le prérendu des routes indexables est préférable quand il est atteignable.
Combien de temps pour que les correctifs soient pris en compte ?
Le délai dépend de la fréquence d'exploration de chaque URL. Une page populaire est re-explorée rapidement ; une page profonde peut attendre longtemps. L'inspection d'URL dans Search Console permet de forcer un contrôle sur un échantillon, pas sur un site entier.
Faut-il un fichier llms.txt ?
C'est un fichier optionnel, utile éventuellement comme documentation pour des agents, mais il ne constitue pas un levier de classement. La documentation Google renvoie aux fondamentaux SEO plutôt qu'à des fichiers dédiés.
Pour aller plus loin
Pages et outils liés
Diagnostic
Lancer un diagnostic technique
Une réponse argumentée sous deux jours ouvrés, avec un premier avis sur le maillon qui bloque. Pas de prise de rendez-vous imposée avant d'avoir compris le contexte.