WordPress ou Claude Code : quelle solution SEO ?

La seule question qui tranche : qui touche au site après la mise en ligne

Le débat est mal posé. On compare des technologies alors que Google classe des pages, pas des technologies.
Un moteur voit du HTML, du texte, des liens, un temps de chargement, et la documentation de Google sur le fonctionnement de la recherche ne mentionne aucune technologie de site nulle part.
Il ne sait pas, et ne cherche pas à savoir, si ce HTML sort d'une base de données PHP ou d'un fichier posé sur un serveur.

Ce que la technologie change vraiment, c'est autre chose : le coût de chaque modification, et la liste des gens capables de la faire. C'est là que se joue la différence, pas dans les résultats de recherche.

Cinq éléments suffisent à trancher. Prenez-les dans l'ordre.

1. Qui publie sur le site chaque semaine. Vous, une assistante, un stagiaire, une agence, ou personne ?
2. Le site existe déjà et ramène déjà des clients, ou vous partez de zéro ?
3. Combien de pages vous devez produire dans les douze prochains mois : dix, ou trois cents ?
4. Qui répare quand ça casse, un mardi à 18 h, et sous combien de temps ?
5. Est-ce qu'il vous faut une boutique, des réservations ou des comptes clients ?

Les trois montages possibles

Il n'y a pas deux camps, il y en a trois. Le deuxième, celui que presque personne ne nomme, est celui qui convient au plus grand nombre.

WordPress tel quel

Un thème, quelques extensions, une extension de référencement pour gérer les titres, le plan du site et les données structurées qui produisent les résultats enrichis.

Vous ou votre équipe publiez depuis une interface, sans toucher à une ligne de code.

Bien réglé, un WordPress tient tête à n'importe quel site codé à la main dans les résultats de recherche. C'est le montage le plus répandu au monde, et il n'a rien perdu de son efficacité.

WordPress, piloté par une IA

Vous gardez exactement le même site. Vous y branchez un agent comme Claude Code, qui va lire et écrire dedans à votre place : créer trente pages sur un même modèle, corriger deux cents balises, réparer les liens internes cassés, traduire une rubrique entière.
L'interface reste là pour votre équipe, l'agent s'occupe du travail répétitif.

Sur ce point, un fait a changé récemment, et beaucoup d'articles ne l'ont pas encore intégré.

Le connecteur historique publié par Automattic, la société derrière WordPress.com, a été archivé le 19 janvier 2026. Il est remplacé par le MCP Adapter, hébergé cette fois dans l'organisation WordPress elle-même, qui s'appuie sur l'API Abilities arrivée avec WordPress 6.9.
Connexion posée sur l'ancien connecteur elle est à refaire. Et un prestataire qui vous propose encore l'ancien nom en 2026 n'a pas regardé depuis un moment.

D'où sort la date du 19 janvier 2026

• Source : les deux dépôts publics eux-mêmes, Automattic/wordpress-mcp qui porte la mention d'archivage, et la documentation WordPress.
• Méthode : lecture directe des dépôts pas un article de presse qui les cite.
• Ce qui n'est pas compté : les connecteurs communautaires, nombreux, qui continuent de fonctionner sans rapport avec cet archivage. Cette date ne dit rien de leur qualité.
• Ce que ça ne dit pas : l'ancien connecteur n'a pas cessé de fonctionner du jour au lendemain, il n'est simplement plus suivi.
• Dernière vérification : 19 août 2026.

Un site codé, piloté par une IA

Pas de base de données, pas d'extensions, pas de mises à jour mensuelles. Des fichiers servis tels quels, et un agent qui écrit ces fichiers quand vous le lui demandez en français.

C'est le montage de ce site : la page que vous lisez est un fichier, le sommaire à votre gauche est du code écrit en session, et il n'y a pas d'interface d'administration derrière.

La contrepartie est simple à formuler : pas d'interface plus personne ne publie sans passer par l'agent ou par un développeur. Si cette phrase vous inquiète, votre réponse est déjà dans les deux montages précédents.

Ce que chaque montage coûte vraiment, une fois le site en ligne

Les comparatifs habituels alignent des critères qui ne changent aucune décision : sécurité, performance, écosystème. Voici ce qui compte réellement le jour où le site tourne.

La dernière ligne fait basculer beaucoup de décisions, et pour de mauvaises raisons. Deux cents euros d'hébergement par an ne justifient jamais un changement de montage : deux cents euros une demi-heure de développeur.
Ce qui justifie un changement, c'est la ligne du dessus, celle qui dit si vous pouvez récupérer la main tout seul.

Ce qui casse dans chacun, et ce que ça prend de le réparer

Nous faisons tourner les trois montages en parallèle : des sites clients sous WordPress, un ensemble de sites éditoriaux également sous WordPress, et nos propres sites entièrement codés et pilotés par Claude Code.

Voici ce que ça donne quand ça casse, avec de vraies pannes, pas des risques théoriques.

Côté WordPress : ce qui casse est toujours entre les couches

La panne typique n'est pas une faille de sécurité, c'est un empilement.
Sur un site client, une modification restait invisible en ligne pendant des heures : trois systèmes de mise en cache se superposaient, celui de l'hébergeur, celui de l'extension d'optimisation, et celui du constructeur de pages. Le bouton « vider le cache » de l'un ne vide pas les deux autres.

Le temps perdu ne vient jamais de la modification elle-même, il vient de la chaîne d'outils empilés autour.

Deuxième cas, plus vicieux, sur un déploiement automatisé de thème : l'outil d'hébergement ne remplaçait pas le dossier existant, il en créait un nouveau à côté avec un suffixe aléatoire, pendant que le site continuait de servir l'ancien.
Tout indiquait un succès. Il a fallu cinq cycles pour comprendre. Une automatisation qui répond « c'est fait » n'a pas prouvé que c'est fait.

Troisième cas, celui qui coûte le plus cher : une commande de vidage de cache écrite un peu vite a supprimé une option de configuration en production et cassé l'affichage d'un site en ligne.
Sur WordPress, la base de données mélange vos réglages et les données temporaires des extensions, et la frontière entre les deux n'est pas évidente.

Côté site codé : ce qui casse est toujours invisible

Le site ne tombe pas. C'est précisément le problème : les défauts ne se voient pas.

Nous avons remplacé dix-huit images d'illustration, déployé, et quinze sont restées les anciennes à l'écran. Le fichier sur le serveur était pourtant le bon, octet pour octet.
La cause : le serveur demande aux navigateurs de garder les images trente jours, et une image remplacée sous le même nom garde la même adresse. Un visiteur déjà venu voit l'ancienne version pendant un mois, et rien nulle part ne signale l'erreur.

Autre cas, plus grave côté référencement. Un bloc de texte important n'était ajouté à la page qu'après un clic du visiteur. À l'écran, tout allait bien.
Pour un moteur, ce texte n'existait pas : un robot d'exploration ne clique pas.

Sur un site classique, le contenu est dans la page par construction. Sur un site codé, il faut vérifier ce que contient la page avant toute action de l'utilisateur, sinon vous écrivez pour personne.

Ces deux familles de pannes ont un point commun qui devrait guider votre choix.

Sur WordPress, les incidents sont bruyants et fréquents, et n'importe quel prestataire sait les traiter. Sur un site codé, ils sont rares et silencieux, et il faut savoir où regarder.

Votre cas en cinq lignes

Trouvez la ligne qui vous décrit, la réponse est au bout.

• Votre site vous amène déjà des clients. Ne changez rien au socle. Branchez un agent dessus pour le travail répétitif, et gardez votre interface pour publier.
• Quelqu'un doit publier sans vous, chaque semaine. WordPress, sans hésiter. La question du site codé ne se pose même pas.
• Vous partez de zéro, sur un site vitrine que personne ne touchera entre deux refontes. Un site codé et piloté par une IA coûte moins cher à faire vivre, et il sera plus rapide.
• Vous devez produire des centaines de pages sur un même modèle. Les deux montages avec IA font le travail. Choisissez selon la ligne 2, pas selon la technique.
• Il vous faut une boutique, des réservations ou des comptes clients. WordPress. L'écosystème n'a pas d'équivalent, et reconstruire ça à la main coûte dix fois le prix.

Si deux lignes vous décrivent en même temps, la première l'emporte toujours sur les autres.

Les trois erreurs qui coûtent le plus cher

Demander un audit à une IA sans lui donner de données. Une question posée à vide produit une liste de recommandations plausibles et sans hiérarchie.

Fournissez une exploration complète du site, les positions réelles et les pages qui reçoivent des visites, et la même IA devient redoutable. La différence entre les deux façons de demander est plus grande que la différence entre deux outils.

Changer de montage pour régler un problème de contenu. C'est l'erreur qui revient le plus, et la plus coûteuse.
Si vos pages ne se classent pas, la cause est dans ce qu'elles disent, pas dans la façon dont elles sont servies. C'est aussi ce que dit le guide de Google sur le contenu utile, qui parle de personnes et de questions, jamais d'outils.

Une stratégie de contenu qui répond vraiment aux questions posées change davantage vos résultats que n'importe quelle refonte technique.

Empiler sans jamais retirer. Chaque extension ajoutée est une pièce de plus qui peut casser, sur WordPress comme ailleurs. La même règle vaut pour les automatisations : trois automatismes bien cadrés valent mieux que quinze qui se marchent dessus.

C'est aussi vrai pour vos balises de titre et vos meta descriptions, que trois extensions différentes peuvent écrire en même temps sans que vous sachiez laquelle gagne.

Une dernière remarque, qui vaut pour les trois montages. Un site rapide et propre ne remplace pas une raison d'être trouvé.

Si le sujet vous dépasse, travailler avec une agence web près de chez vous a un avantage concret sur ce genre d'arbitrage : quelqu'un peut venir voir votre activité et comprendre ce que vos clients cherchent réellement avant de trancher sur la technique.