SEO technique WordPress : les 10 réglages à faire le jour de la mise en prod

Pourquoi ces réglages doivent être faits le jour même

J ai mis en production plus de 120 sites WordPress depuis 2015. Et chaque fois que je néglige un seul de ces réglages le jour J, je le paie dans les semaines qui suivent. Googlebot passe sur un nouveau site dans les 24 à 72 heures après sa mise en ligne. Ce premier crawl est déterminant : il fixe la structure d URL que Google va indexer, la vitesse perçue du site et la qualité technique globale.

Le problème, c est que beaucoup de développeurs WordPress considèrent le SEO technique comme une étape « post-lancement ». On met en prod, on envoie le lien au client, et on se dit qu on fera le SEO « la semaine prochaine ». Sauf que la semaine prochaine, Googlebot a déjà indexé des URL avec des paramètres sales, des pages en noindex oubliées depuis la préprod, et un robots.txt qui bloque le crawl.

Ces 10 réglages ne sont pas des optimisations avancées. Ce sont les fondations techniques sans lesquelles tout le reste du SEO (contenu, netlinking, maillage interne) ne sert strictement à rien. Si vous déployez un site WordPress sur un VPS, je vous recommande de lire mon tutoriel pour déployer WordPress sur un VPS OVH avant de revenir ici pour la partie SEO.

Réglage 1 : permaliens propres et structure d URL

C est le tout premier réglage à faire, avant même de publier le moindre contenu. Par défaut, WordPress génère des URL du type /?p=123. Ce format est illisible pour les humains et inutile pour Google. Rendez-vous dans Réglages > Permaliens et choisissez la structure « Nom de l article » (/%postname%/).

Si votre site a une structure éditoriale complexe avec des catégories bien définies, vous pouvez opter pour /%category%/%postname%/. Mais attention : ce choix est irréversible sans redirections massives. Changer de structure de permaliens six mois après le lancement signifie créer des centaines de redirections 301, avec un risque réel de perte de positionnement.

Quelques règles que j applique systématiquement :

• Les slugs en minuscules, sans accents, sans mots vides (le, la, de, du)
• Les tirets comme séparateurs, jamais les underscores
• Une longueur de slug entre 3 et 5 mots maximum
• Pas de dates dans l URL sauf pour un site d actualités

Pour les sites multilingues, j utilise des préfixes de langue dans l URL (/fr/, /en/) plutôt que des sous-domaines. C est plus simple à gérer et Google le comprend très bien avec les balises hreflang.

Réglages 2 et 3 : indexation, sitemap XML et robots.txt

Vérifiez immédiatement le réglage le plus dangereux de WordPress : Réglages > Lecture > Visibilité pour les moteurs de recherche. Si la case « Demander aux moteurs de recherche de ne pas indexer ce site » est cochée, Google ne vous indexera jamais. Ce réglage est souvent activé en développement et oublié à la mise en prod. J ai vu ce cas au moins 15 fois en audit.

Si vous utilisez WP-CLI, vous pouvez vérifier et corriger ce réglage en une commande :

wp option get blog_public
# Si ça retourne 0, le site est en noindex
wp option update blog_public 1

Ensuite, le sitemap XML. Depuis WordPress 5.5, un sitemap natif est généré à /wp-sitemap.xml. Il fonctionne, mais il est basique. Je recommande d utiliser celui de Yoast SEO ou Rank Math qui offrent un contrôle plus fin : exclusion de types de contenus, priorisation des pages, et surtout la prise en compte des balises noindex.

Pour le robots.txt, WordPress en génère un virtuel. Mais je préfère toujours créer un fichier physique à la racine du site avec ces directives minimales :

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://votre-domaine.fr/sitemap_index.xml

Ne bloquez jamais /wp-content/uploads/ dans le robots.txt. Vos images doivent être crawlables pour apparaître dans Google Images. Selon les recommandations officielles de Google sur le robots.txt, bloquer des ressources CSS ou JS empêche le rendu correct de vos pages et peut nuire à votre positionnement.

Réglages 4, 5 et 6 : HTTPS, redirections 301 et balises canonical

En 2026, un site sans HTTPS n est tout simplement plus indexé correctement par Google. Chrome affiche un avertissement « Non sécurisé » dans la barre d adresse, et les Core Web Vitals ne sont même pas mesurés sur les sites HTTP. Si vous hébergez votre WordPress sur un VPS, utilisez Certbot avec Let s Encrypt pour obtenir un certificat SSL gratuit et renouvelé automatiquement.

Une fois le HTTPS en place, vérifiez trois choses :

• L adresse du site dans Réglages > Général commence bien par https://
• Toutes les URL en HTTP redirigent en 301 vers HTTPS (pas en 302)
• Il n y a pas de contenu mixte (mixed content) : des ressources HTTP appelées sur une page HTTPS

Pour les redirections, ajoutez ces lignes dans votre .htaccess (Apache) :

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Choisissez aussi entre www et non-www et forcez la redirection. Les deux versions qui coexistent créent du contenu dupliqué. Personnellement, je choisis toujours le non-www : c est plus court, plus propre, et les utilisateurs ne tapent plus « www » depuis longtemps.

Enfin, les balises canonical. Yoast SEO et Rank Math les ajoutent automatiquement, mais vérifiez qu elles pointent bien vers l URL propre et non vers une URL avec des paramètres UTM ou des filtres de pagination. Une canonical mal configurée peut faire disparaître des pages entières de l index.

Si vous gérez vos sauvegardes avant la mise en prod, mon comparatif UpdraftPlus vs BackWPup vs rsync vous donnera la bonne méthode pour ne rien perdre en cas de problème.

Réglages 7 et 8 : performance côté serveur et cache

La performance est un facteur de classement officiel depuis 2021 avec les Core Web Vitals. Le jour de la mise en prod, trois métriques doivent être dans le vert :

Pour atteindre ces seuils sur WordPress, voici ce que je configure systématiquement le jour J :

Côté serveur, activez le cache objet avec Redis ou Memcached. Sur un VPS OVH avec 2 Go de RAM, Redis consomme environ 50 Mo et divise le temps de réponse du back-end par 3. Ajoutez un cache de page avec WP Super Cache ou WP Rocket (payant mais excellent). Le cache de page transforme vos pages PHP dynamiques en fichiers HTML statiques servis directement par Apache ou Nginx.

Côté front, minifiez et concaténez vos fichiers CSS et JS. Activez la compression Gzip ou Brotli dans votre configuration serveur. Différez le chargement des scripts non critiques avec l attribut defer ou async. Chaque milliseconde compte : selon la documentation Web Vitals de Google, un site qui passe de « moyen » à « bon » sur le LCP gagne en moyenne 24 % de pages vues supplémentaires.

Un point souvent négligé : le TTFB (Time to First Byte). Si votre serveur met plus de 600 ms à répondre, aucun plugin de cache côté front ne compensera. C est un problème d hébergement. Vérifiez que votre base MySQL est optimisée avec des index corrects et que le wp_options n est pas surchargé par des transients expirés. Si vous utilisez Docker Compose en local, profitez-en pour tester ces réglages avant la mise en prod.

Réglage 9 : images, lazy loading et formats modernes

Les images représentent en moyenne 50 à 70 % du poids total d une page WordPress. Le jour de la mise en prod, trois actions sont non négociables :

Premièrement, convertissez toutes vos images en WebP ou AVIF. Le format WebP offre une réduction de poids de 25 à 35 % par rapport au JPEG pour une qualité visuelle identique. L AVIF va encore plus loin avec 40 à 50 % de réduction. J ai écrit un guide complet sur l optimisation des images WordPress en WebP et AVIF qui détaille les plugins et configurations à utiliser.

Deuxièmement, activez le lazy loading natif. Depuis WordPress 5.5, l attribut loading="lazy" est ajouté automatiquement aux images. Mais vérifiez qu il n est pas appliqué à l image LCP (la plus grande image au-dessus de la ligne de flottaison). Mettre du lazy loading sur l image LCP ralentit son affichage et dégrade directement votre score. Pour l image LCP, ajoutez plutôt l attribut fetchpriority="high".

Troisièmement, définissez les attributs width et height sur toutes vos balises <img>. Sans ces dimensions, le navigateur ne peut pas réserver l espace nécessaire et provoque des sauts de mise en page (CLS). WordPress le fait automatiquement pour les images ajoutées via la médiathèque, mais pas pour celles insérées manuellement dans le code du thème.

Réglage 10 : données structurées, balises meta et Search Console

Les données structurées ne sont pas un facteur de classement direct, mais elles génèrent des résultats enrichis (rich snippets) qui augmentent considérablement le taux de clic. Sur un site vitrine WordPress, j implémente systématiquement ces types Schema.org :

• Organization : nom, logo, coordonnées, réseaux sociaux
• LocalBusiness : si le client a une adresse physique
• BreadcrumbList : le fil d Ariane pour chaque page
• Article ou BlogPosting : pour les contenus éditoriaux
• FAQPage : pour les sections de questions fréquentes

Rank Math gère très bien les données structurées de base sans code. Pour des schémas plus complexes, j utilise le plugin Schema Pro ou j injecte le JSON-LD directement dans le functions.php du thème enfant.

Pour les balises meta, vérifiez que chaque page a :

• Un title unique de 50 à 60 caractères avec le mot-clé principal
• Une meta description de 140 à 155 caractères qui donne envie de cliquer
• Les balises Open Graph et Twitter Card pour un affichage correct sur les réseaux sociaux

Enfin, le jour même de la mise en prod, soumettez votre site à la Google Search Console. Ajoutez la propriété, vérifiez-la via un enregistrement DNS TXT, soumettez votre sitemap et demandez l indexation de vos pages principales. Connectez aussi un outil d analytics respectueux du RGPD ; mon comparatif Plausible vs Umami vs Matomo vous aidera à choisir.

La CNIL propose une liste d outils analytics exemptés de consentement sous certaines conditions. Si vous utilisez Matomo ou Plausible correctement configurés, vous pouvez mesurer votre trafic sans bandeau de cookies pour l analytics.

La checklist complète à imprimer avant chaque mise en prod

Voici la checklist que j utilise personnellement sur chaque projet. Je la parcours méthodiquement le jour du lancement, et je ne considère un site comme « live » que quand chaque point est validé.

Pour automatiser une partie de ces vérifications, un workflow Git avec hooks et CI peut exécuter des tests Lighthouse à chaque déploiement. C est ce que je fais sur tous mes projets clients depuis 2024.

Les erreurs que je corrige encore en 2026 chez mes clients

Après plus de dix ans de freelance WordPress, certaines erreurs reviennent de façon récurrente. Voici celles que je rencontre le plus souvent lors de mes audits SEO techniques :

Le robots.txt qui bloque tout. Un développeur qui oublie de retirer le Disallow: / ajouté en préprod. Le site est en ligne depuis trois semaines et le client se demande pourquoi il n apparaît pas sur Google. J ai vu ce cas au moins une fois par trimestre.

Les pages de pagination sans canonical. WordPress génère des pages /page/2/, /page/3/ pour les archives. Sans balise canonical correcte, Google indexe ces pages comme du contenu dupliqué de la page principale. Google recommande officiellement d utiliser la pagination avec des liens rel="next" et rel="prev" lorsque c est pertinent.

Les plugins SEO en double. Yoast ET Rank Math installés en même temps. Chacun génère ses propres balises meta, ses propres canonical, ses propres sitemaps. Résultat : des balises en double dans le code source et un comportement imprévisible pour Googlebot. Un seul plugin SEO, toujours.

Le thème qui charge 15 polices Google Fonts. Chaque police externe ajoute une requête DNS, une connexion TLS et un téléchargement. Je vois régulièrement des sites qui chargent 800 Ko de polices alors que deux variantes suffiraient. Hébergez vos polices en local avec @font-face et utilisez font-display: swap pour éviter le flash de texte invisible.

Les URLs de préprod qui restent dans le contenu. Des liens internes qui pointent encore vers https://dev.monsite.fr ou http://localhost:8080. Avant la mise en prod, faites un rechercher-remplacer dans la base de données avec WP-CLI :

wp search-replace 'https://dev.monsite.fr' 'https://monsite.fr' --all-tables --dry-run

Retirez le --dry-run une fois que vous avez vérifié le nombre de remplacements. Pour des opérations comme celle-ci, WP-CLI est indispensable.