SEOPress : fonctions, robots.txt et comparaison Yoast

SEOPress est la principale alternative française à Yoast sur WordPress, et la comparaison entre les deux se réduit trop souvent à une liste de fonctions. Elle se joue en réalité sur trois points concrets : ce que la version gratuite couvre réellement, la manière dont le module se comporte dans votre site, et un piège de configuration qui fait perdre des heures à ceux qui ne le connaissent pas. Voici les trois.

Ce que couvre la version gratuite

C’est le point qui surprend le plus, parce que l’usage veut qu’un module gratuit soit une vitrine. Sur les fondamentaux, la version gratuite de SEOPress est autonome.

• Les balises title et meta description, par contenu et par modèle, avec des variables pour les archives et les taxonomies.
• Le plan de site XML, y compris pour les types de contenu personnalisés.
• Les redirections, avec gestion du code de retour. C’est la fonction qui manque le plus souvent ailleurs en version gratuite, et elle évite d’installer un module de plus.
• Le contrôle des archives, notamment la désactivation des archives d’auteur, utile sur un site à signature unique où elles font doublon avec la page d’accueil.
• Les données structurées et les métadonnées de partage social.

Le partage entre gratuit et payant évolue d’une version à l’autre, dans les deux camps. Plutôt que de recopier une liste qui sera fausse dans six mois, relevez-la au moment de votre choix sur le Site Officiel SEOPress, et comparez uniquement les fonctions que vous utiliserez réellement.

Le piège du robots.txt

C’est la question la plus posée autour de SEOPress, et la réponse tient à un comportement de WordPress lui-même qu’aucune interface ne signale.

WordPress ne crée pas de fichier robots.txt sur le disque. Il le génère à la volée quand un robot le demande, et c’est ce contenu virtuel que SEOPress vous laisse modifier. Le mécanisme fonctionne parfaitement, à une condition absolue : qu’aucun fichier robots.txt physique n’existe à la racine du site.

S’il en existe un, déposé par un hébergeur, par une ancienne installation ou par un module de cache, le serveur le sert directement et WordPress n’est jamais sollicité. Votre configuration dans SEOPress est alors enregistrée, affichée correctement dans l’administration, et totalement ignorée. Rien n’indique l’anomalie.

https://votre-site.fr/robots.txt

La vérification est immédiate : ouvrez cette adresse et comparez ce qui s’affiche avec ce que vous avez saisi. Si les deux diffèrent, cherchez le fichier à la racine et supprimez-le. C’est le même genre de panne silencieuse que celle décrite dans notre article sur la propagation DNS : tout paraît configuré, et rien ne s’applique.

Un rappel utile au passage : le robots.txt demande de ne pas explorer, il n’empêche pas d’indexer. Une page bloquée là mais liée depuis ailleurs peut apparaître dans les résultats, sans description. Pour la retirer de l’index, c’est la balise noindex qu’il faut poser, et elle suppose donc que la page reste explorable.

SEOPress ou Yoast : les critères qui départagent

Critère	Ce qu’il faut regarder
Empreinte dans le site	SEOPress se veut discret : pas de mention laissée dans le code servi, pas de sollicitation dans l’administration. C’est décisif pour une agence qui livre à un client.
Marque blanche	Possible avec SEOPress, ce qui permet de masquer le module dans un tableau de bord livré.
Collecte de données	À vérifier dans les deux cas, et à rapporter à vos obligations RGPD si votre site traite des données personnelles.
Écosystème et documentation	Yoast dispose d’une communauté plus large et de plus de ressources en anglais. SEOPress documente en français, ce qui compte pour une équipe non anglophone.
Poids	Les deux ajoutent des requêtes et du traitement. Mesurez avant et après plutôt que de vous fier aux annonces.

Le critère décisif, dans la pratique, est rarement la liste des fonctions : c’est de savoir si le module s’efface ou s’il s’impose. Sur un site livré à un client, un module qui affiche ses propres messages et sa propre marque dans l’administration crée une confusion durable.

Changer de module SEO : ce qu’il faut savoir avant

La migration entre modules concurrents est prévue de part et d’autre, et elle fonctionne. Deux précautions s’imposent néanmoins.

1. Sauvegardez la base avant. L’import réécrit des métadonnées sur l’ensemble des contenus, en une opération. La méthode est décrite dans notre guide sur les sauvegardes automatiques.
2. Désinstallez l’ancien après vérification, pas avant. Tant que les deux modules sont actifs, deux jeux de balises peuvent être produits. Contrôlez le code source servi d’une page avant de supprimer quoi que ce soit.

Vérifiez ensuite les redirections : elles sont stockées par le module et ne se transfèrent pas toujours à l’identique. Une redirection perdue devient une erreur 404 silencieuse, et personne ne la remarque avant plusieurs semaines.

Le cas WooCommerce

Une boutique pose des problèmes que ne connaît pas un site éditorial, et c’est souvent ce qui décide du module.

• Les données structurées de produit conditionnent l’affichage du prix et de la disponibilité dans les résultats. Vérifiez qu’elles sont produites pour les produits variables, et pas seulement pour les produits simples.
• Les pages de filtres et de tri multiplient les adresses pour un même catalogue. Sans réglage, elles produisent des dizaines de variantes concurrentes qu’il faut canoniser ou exclure.
• Les fiches épuisées ou supprimées doivent être redirigées vers une catégorie plutôt que renvoyer une erreur, sous peine d’accumuler des 404 à mesure que le catalogue tourne.

Ce qu’aucun module SEO ne fera à votre place

La réserve mérite d’être posée franchement, parce que l’attente est souvent disproportionnée. Un module SEO est un outil de saisie et de production de balises. Il ne produit pas de positionnement.

• Il ne choisit pas vos requêtes cibles. Le champ « mot-clé principal » sert à déclencher son analyse, pas à indiquer quoi que ce soit à Google.
• Sa pastille verte n’est pas un indicateur de position. Elle mesure la conformité à une liste de règles internes au module, qui n’a aucun statut auprès des moteurs.
• Il n’écrit pas les titles. Un modèle générique produit des balises toutes semblables et toutes tronquées dans les résultats. Le gain vient de titles rédigés un par un.
• Il ne rend pas un site rapide. C’est un sujet distinct, traité dans notre article sur l’optimisation des performances sans changer d’hébergement.
• Il ne sécurise rien. Les mesures utiles sont d’un autre ordre, et nous les détaillons dans notre article sur la sécurisation d’un site WordPress.

Autrement dit, le choix entre SEOPress et Yoast pèse beaucoup moins que ce que vous en ferez. Les deux produisent des balises correctes. Seul le contenu que vous y mettez fait la différence.

Questions fréquentes sur SEOPress

Comment modifier le robots.txt avec SEOPress ?

Depuis les réglages du module, qui modifient le robots.txt virtuel généré par WordPress. Cela ne fonctionne que si aucun fichier robots.txt physique n’existe à la racine : dans le cas contraire, le serveur sert ce fichier et la configuration du module est ignorée sans aucun avertissement.

Les redirections sont-elles incluses dans SEOPress gratuit ?

Oui, la gestion des redirections avec choix du code de retour figure dans la version gratuite. C’est l’une des fonctions qui évite d’installer un module supplémentaire.

SEOPress est-il meilleur que Yoast ?

Les deux couvrent les fondamentaux de la même manière. Le départage se fait sur la discrétion du module dans le site livré, la possibilité de marque blanche, la langue de la documentation et la collecte de données, pas sur la longueur de la liste de fonctions.

Bloquer une page dans le robots.txt la retire-t-elle de Google ?

Non. Le robots.txt demande de ne pas explorer la page, pas de ne pas l’indexer. Une page bloquée mais liée depuis ailleurs peut apparaître dans les résultats sans description. Pour la désindexer, il faut une balise noindex, donc laisser la page explorable.

Peut-on passer de Yoast à SEOPress sans tout perdre ?

Oui, un import est prévu. Sauvegardez la base avant, car l’opération réécrit les métadonnées de tous les contenus en une fois, et contrôlez le code source d’une page avant de désinstaller l’ancien module.