Les bases du SEO technique à vérifier avant la mise en ligne d’un site

Le SEO technique a une économie particulière : presque tout ce qui suit est peu coûteux pendant la construction et coûteux à rattraper ensuite. C’est pourquoi on le saute si souvent, et pourquoi tant de sites sont mis en ligne avec un plafond déjà installé.

Rien de ce qui suit ne fera remonter un mauvais site. Ce que cela fait, c’est supprimer les raisons pour lesquelles un bon site ne peut pas remonter. Voyez-le comme un dégagement d’obstacles plutôt qu’un ajout d’avantages.

Vérifiez que le site peut être exploré et indexé

L’erreur SEO la plus coûteuse au monde est une balise noindex oubliée depuis la préproduction. Cela ne coûte rien à vérifier et cela arrive chaque semaine sur de vraies mises en ligne.

• Confirmez qu’il n’y a en production ni balise noindex ni en-tête X-Robots-Tag.
• Confirmez que robots.txt autorise ce que vous voulez explorer et bloque le reste.
• Assurez-vous que la préproduction est bloquée — idéalement derrière une authentification, pas seulement une directive robots.
• Vérifiez que le contenu important est présent dans la réponse HTML, et pas uniquement rendu par JavaScript côté client.

Ce dernier point provoque plus de dégâts silencieux que tous les autres réunis. Si votre contenu n’existe qu’après exécution du JavaScript, vous dépendez d’une seconde passe de rendu qui peut être plus lente, incomplète ou omise.

Fixez la structure des URL avant toute publication

Les URL sont le plus difficile à changer ensuite, parce que les changer implique des redirections, et que les redirections s’accumulent en chaînes.

• Minuscules, avec des tirets, lisibles et stables.
• Une structure qui reflète une hiérarchie réelle, plutôt plate que profonde par principe.
• Ni identifiants de session ni paramètres de suivi dans les URL canoniques.
• Une seule forme canonique : choisissez www ou non, slash final ou non, et redirigez l’autre.
• HTTPS partout, avec redirection du HTTP.

Des balises canoniques sur chaque page indexable

Une canonique auto-référençante sur chaque page est la valeur par défaut souhaitable. Elle ne coûte rien et résout une large part des ambiguïtés de contenu dupliqué avant qu’elles n’apparaissent.

Là où vous avez de vrais doublons — listes filtrées, versions imprimables, variantes de paramètres — pointez-les délibérément vers la version canonique plutôt que de laisser les moteurs deviner.

De vraies balises title et descriptions, rédigées

Chaque page a besoin d’un titre et d’une description uniques. Les générer depuis un champ de base de données produit un résultat techniquement unique et pratiquement inutile.

Rédigez-les à la main pour les pages importantes. Pour les grands catalogues, utilisez un gabarit avec assez de variables pour que le résultat reste distinguable et se lise comme une phrase.

Des données structurées, là où elles s’appliquent

Le balisage est utile quand il décrit quelque chose de réel : une organisation, un produit, un fil d’Ariane, un article, une FAQ effectivement visible sur la page.

Il n’est pas utile comme décoration, et inventer des notes ou des avis dans les données structurées est à la fois contraire aux consignes et le genre de raccourci difficile à défaire. Balisez ce qui est vrai.

Traitez les Core Web Vitals comme une exigence de conception

La performance coûte bien moins cher à concevoir qu’à optimiser après coup, parce que l’essentiel du coût est architectural et non une affaire de réglages de compression.

• LCP : identifiez l’élément le plus grand de chaque gabarit et faites-le charger en premier. Généralement une image de couverture : format moderne, bonne taille, et surtout pas de chargement différé.
• CLS : réservez l’espace de chaque image, iframe et encart. Définissez largeur et hauteur ou un ratio. Une mise en page qui saute pendant la lecture est un défaut de conception, pas une métrique.
• INP : gardez le thread principal libre. L’essentiel du délai d’interaction vient de scripts tiers qui font un travail que personne n’a demandé.
• Budgétez explicitement vos scripts tiers. Chacun est une taxe permanente.

Les images

Les images sont généralement l’élément le plus lourd de la page et le gain le plus facile.

• Servez des formats modernes — AVIF et WebP avec un repli.
• Plusieurs tailles avec srcset et un attribut sizes cohérent. N’envoyez pas une image de 2000 px à une vignette de 400 px.
• Chargement différé sous la ligne de flottaison, jamais pour l’image de couverture.
• Des dimensions explicites partout.
• Un texte alternatif descriptif sur les images porteuses de sens, un alt vide sur les décoratives. Les deux comptent ; bourrer l’alt de mots-clés n’aide ni l’un ni l’autre.

Sitemaps et maillage interne

Un sitemap XML doit contenir exactement les URL que vous voulez indexer : canoniques, en statut 200, indexables. Un sitemap rempli de redirections et de 404 est un signal sur la qualité de votre site, pas seulement un désagrément.

Le maillage interne compte plus qu’on ne le suppose. C’est ainsi que l’importance se communique, et une page vers laquelle aucun lien interne ne pointe transmet aux moteurs un message que vous n’aviez probablement pas prévu.

Installez la mesure avant d’en avoir besoin

Analytics et Search Console doivent être vérifiés et en collecte avant la mise en ligne, pas après avoir remarqué un problème.

Établissez la référence dès le premier jour. Sans elle, toute question future sur un éventuel changement restera sans réponse.

Si le site en remplace un autre

Alors il ne s’agit pas d’une mise en ligne mais d’une migration, et les règles sont différentes et plus strictes. Chaque ancienne URL a besoin d’une décision et d’une redirection. Nous l’avons traité séparément dans la checklist de migration, la partie la plus risquée de toute refonte.

La liste avant mise en ligne

Notre page référencement naturel couvre le travail continu qui suit, et création de sites web explique comment ces fondations sont intégrées plutôt qu’ajoutées.