SEO technique : corriger ce qui bloque votre site

Les erreurs techniques ne sont pas très variées. D'un site à l'autre, ce sont presque toujours les mêmes familles qui reviennent, et elles se corrigent avec des gestes connus.

Aucune de ces corrections n'est spectaculaire. Prises ensemble, elles décident de ce que Google voit du site, et elles conditionnent tout le reste : un excellent contenu sur une page non indexée ne sert à rien.

Nous commençons donc toujours par l'état des lieux, jamais par la production de texte. Tant que la mécanique n'est pas en ordre, écrire davantage revient à remplir un réservoir percé.

Il existe deux façons de mesurer la vitesse d'un site. La mesure en laboratoire simule une visite sur une machine standard. La mesure de terrain provient des visites réelles de vos utilisateurs, avec leurs téléphones et leurs connexions. C'est celle que Google utilise, et c'est celle que nous regardons en premier.

Trois indicateurs comptent. Le LCP mesure le temps au bout duquel le plus gros élément visible s'affiche. L'INP mesure le délai entre l'action d'un visiteur et la réponse de la page. Le CLS mesure les déplacements de mise en page pendant le chargement, ces boutons qui bougent au moment où vous cliquez.

Ce qui les fait décrocher figure presque toujours dans la même liste : images envoyées en pleine résolution et redimensionnées par le navigateur, polices chargées depuis un domaine externe, scripts de suivi et bannières de consentement qui bloquent l'affichage, absence de cache côté serveur.

Nous corrigeons dans cet ordre : d'abord le serveur et le cache, ensuite les images et les polices, enfin les scripts tiers. Chaque correction est mesurée avant et après sur les mêmes gabarits, parce qu'un chiffre isolé ne prouve rien. Nous écrivons aussi ce que nous ne pouvons pas corriger.

Dans Search Console, le rapport d'indexation sépare les pages indexées de celles qui ne le sont pas, avec un motif pour chacune. Ce rapport est le point de départ de tout diagnostic sérieux, et il est rarement lu jusqu'au bout.

Les motifs les plus fréquents appellent chacun une réponse différente. Une page explorée mais non indexée signale le plus souvent un contenu jugé faible ou trop proche d'une autre page du site. Une page découverte mais jamais explorée signale un problème de découverte : aucun lien interne n'y mène. Une page en double sans canonique choisie par vous signale que Google a tranché à votre place. Une erreur de serveur intermittente pendant l'exploration suffit à faire sortir des pages de l'index.

Nous traitons chaque motif séparément, avec la liste des pages concernées et une action précise, pas une recommandation générale. Certaines pages doivent être corrigées, d'autres fusionnées, d'autres supprimées volontairement. Le maillage interne fait partie du même chantier : une page qui ne reçoit aucun lien depuis le reste du site est une page que vous demandez à Google de trouver par politesse.

Les données structurées sont un balisage ajouté au code de la page pour décrire son contenu dans un format que les moteurs lisent sans interprétation : une entreprise, un service, un produit, une question fréquente, un fil d'ariane.

Nous posons le balisage utile au type de page, et seulement celui-là. Une fiche produit décrit le produit, sa disponibilité et son prix tels qu'ils sont réellement affichés. Une page de questions décrit des questions qui existent dans le texte visible.

Deux règles évitent les ennuis. La première : le balisage doit correspondre à ce que voit le visiteur. Un prix balisé différent du prix affiché, ou des avis balisés qui ne figurent nulle part sur la page, exposent le site à une action manuelle. La seconde : aucun balisage n'assure un affichage enrichi dans les résultats. Le balisage rend cet affichage possible, Google décide seul de l'appliquer, et nous ne vendons pas cette décision comme un résultat acquis.

Un site en plusieurs langues ajoute une couche que les sites monolingues n'ont pas : il faut indiquer à Google quelle version montrer à quel public, sinon les versions se remplacent les unes les autres dans les résultats.

Nous appliquons cette configuration sur notre propre site, publié en six langues, et nous connaissons les points où elle casse. Les annotations doivent être réciproques : si la page française pointe vers la page allemande, la page allemande doit pointer vers la page française, sinon l'ensemble est ignoré. Chaque version doit se déclarer elle-même, avec un code de langue valide, et une version par défaut doit être désignée pour les visiteurs qui ne correspondent à aucune langue déclarée. Les adresses citées doivent être les adresses canoniques, pas des variantes redirigées.

L'erreur la plus coûteuse est plus simple que tout cela : une traduction automatique publiée sur six langues sans relecture. Le balisage est alors correct et le résultat mauvais. Une langue mérite d'être publiée quand quelqu'un la relit.

Le cas du multidomaine se traite autrement. Pour TalkBridge, marque internationale, la présence web est double, sur un domaine en .co.uk et un domaine en .com. Deux domaines distincts ne se gèrent pas comme deux sous-dossiers d'un même site, et le choix se fait avant la construction, pas après.

Une migration est le moment où un site perd le plus de trafic en une seule nuit. Changement de technologie, changement d'adresses, changement d'hébergement : chacun de ces trois événements suffit, et ils arrivent souvent ensemble.

Notre méthode part d'un inventaire complet des adresses existantes, relevé dans le site, dans Search Console et dans les journaux du serveur, jamais de mémoire. Chaque ancienne adresse reçoit une correspondance vers une nouvelle adresse équivalente. Les redirections sont permanentes, testées sur un environnement de préproduction avant la bascule, avec les variantes qui traînent toujours : majuscules, barre oblique finale, paramètres d'origine, sous-domaine avec ou sans www.

La partie hébergement et messagerie est celle que l'on oublie. Pour un distributeur de matériaux de construction, la migration d'un hébergement cPanel vers notre propre serveur CyberPanel comprenait la reconfiguration complète de la messagerie, traitée comme une étape du projet et vérifiée avant la bascule.

Après la mise en ligne, nous lisons les mêmes indicateurs à sept jours, à trente jours, puis à trois mois : pages indexées face à la liste attendue, erreurs d'exploration, impressions et clics par page comparés à la période précédente. Les variations des deux premières semaines sont normales, la réexploration n'est pas instantanée.

Google consacre à chaque site une quantité d'exploration limitée. Sur un site de trente pages, la question ne se pose pas. Sur une boutique avec des filtres, elle décide de la fraîcheur de votre catalogue dans l'index.

Le gaspillage vient toujours des mêmes endroits : les combinaisons de filtres qui créent des milliers d'adresses différentes pour le même contenu, les paramètres de suivi ajoutés aux liens, les pages de résultats de recherche interne laissées ouvertes à l'exploration, les calendriers qui produisent des dates sans fin, et les versions imprimables de chaque page.

Nous lisons les journaux du serveur pour voir ce que les robots visitent réellement, et la comparaison est souvent instructive : des milliers de passages sur des pages sans intérêt, presque aucun sur les fiches récentes. Le travail consiste ensuite à fermer ce qui n'a pas à être exploré, à canoniser ce qui doit rester accessible sans être indexé, et à corriger les erreurs de serveur qui ralentissent l'exploration. Sur un gros catalogue, cette remise en ordre change davantage la couverture de l'index qu'une réécriture de contenu.

Le livrable n'est pas un rapport d'outil exporté en PDF. C'est une liste de correctifs, classée par impact estimé et par effort, avec pour chaque ligne la page ou le gabarit concerné, ce qui ne va pas, ce qu'il faut changer, et comment vérifier que c'est fait.

Trois niveaux la structurent. Les corrections bloquantes touchent l'indexation et passent en premier. Les corrections à fort effet touchent la vitesse, les doublons et le maillage. Les corrections d'entretien peuvent attendre la vague suivante.

Ensuite, deux voies. Soit votre développeur applique la liste et nous restons disponibles pour les questions et la vérification. Soit nous appliquons les correctifs nous-mêmes, avec un accès au dépôt de code et une préproduction, et vous validez avant la mise en ligne.

Ce que nous ne vous vendons pas, parce que cela n'existe pas : une position assurée dans Google, un audit automatique présenté comme un diagnostic, des corrections facturées sans que vous puissiez les vérifier, et des rapports mensuels qui répètent des courbes sans dire ce qui a été fait. Vos accès restent à votre nom, Search Console comprise.

Le montant dépend de la taille du site et de l'état du code. Nos tarifs de référencement sont détaillés sur la page consacrée au prix du référencement naturel, et nous ne les dupliquons pas ici.

Pages liées: refonte avec suivi des positions · test SEO gratuit en ligne