Un site WordPress peut perdre son trafic, sa vitesse ou sa sécurité sans afficher la moindre erreur. Les pages s’ouvrent, les formulaires partent, l’administration répond. Rien n’alerte, et c’est précisément le problème : personne ne cherche une panne qui ne se voit pas.
Les erreurs de ce comparatif ont ce point commun. Aucune ne fait tomber le site, toutes coûtent cher au bout de quelques mois : des pages qui sortent de Google, une version de PHP abandonnée, une sauvegarde qui ne se restaure pas le jour où l’on en a besoin. Plus d’un tiers des sites WordPress tournaient d’ailleurs, en octobre 2026, sur une version de PHP qui ne reçoit plus de correctifs de sécurité.
Pour chaque erreur, vous trouverez la façon de la repérer avec les outils déjà à votre disposition (la Santé du site, la Search Console, WP-CLI) et la façon de la corriger. Puis une histoire réelle, celle d’un grand distributeur britannique qui a changé ses adresses web et l’a payé pendant trois mois.
Comment nous les avons classées
Nous n’avons trouvé aucune étude qui classe ces erreurs par fréquence, et nous n’en inventerons pas. Notre ordre suit un critère simple : l’ampleur de la perte possible, multipliée par le temps pendant lequel elle peut passer inaperçue.
Les trois premières peuvent effacer le trafic issu de Google ou le site entier, alors que tout semble fonctionner. Les trois suivantes ouvrent la porte à une intrusion ou bloquent les mises à jour. Les trois d’après dégradent la qualité et la vitesse. La dernière est l’habitude qui aurait permis d’en repérer plusieurs autres.
1. La case de non-indexation laissée cochée : invisible pour Google
Pourquoi c’est grave
Dans Réglages, puis Lecture, la case « Demander aux moteurs de recherche de ne pas indexer ce site » fait exactement ce qu’elle annonce. On la coche souvent pendant la construction ou sur une copie de travail, puis une migration ou une copie de base de données l’emporte en production. Le site fonctionne parfaitement pour chaque visiteur humain.
Depuis WordPress 5.3, cette case n’agit plus sur le fichier robots.txt : elle ajoute une balise noindex, nofollow dans chaque page et, depuis l’arrivée des plans de site intégrés en 5.5, désactive aussi le plan de site XML. Google retire alors les pages au fil de ses passages. Sa documentation prévient qu’un nouveau passage peut prendre des mois pour les pages moins importantes, d’où une baisse progressive que l’on met souvent sur le compte d’autre chose.
En 2024, un propriétaire de site a demandé dans le podcast de Google pourquoi son site avait disparu juste après avoir migré son site WordPress vers un hébergement autonome (probablement depuis WordPress.com, selon Search Engine Journal). John Mueller a répondu que, selon lui, le nouveau site bloquait d’une façon ou d’une autre les moteurs de recherche, et a conseillé de commencer par la Search Console.
Comment la repérer
Depuis WordPress 6.9, la Santé du site signale la case cochée, mais seulement comme amélioration recommandée, pas comme problème critique. Dans la Search Console, le rapport d’indexation des pages affiche un motif lié à la balise noindex, et l’outil d’inspection d’URL indique si l’indexation est autorisée. En ligne de commande, wp option get blog_public renvoie 0 si la case est cochée.
Comment corriger
Décochez la case, ou lancez wp option update blog_public 1. Dans la Search Console, testez l’URL en direct, demandez l’indexation des pages clés et soumettez à nouveau le plan de site. Pour vos copies de travail, préférez une protection par mot de passe, que Google recommande lui-même, à cette case qui finit toujours par voyager.
2. Des permaliens changés sans redirections : chaque lien pointe vers une erreur
Pourquoi c’est grave
Une nouvelle installation de WordPress utilise encore par défaut une structure d’adresses avec la date et le titre. Beaucoup de propriétaires passent plus tard au seul titre de la publication, plus lisible, ou réorganisent leurs catégories. Chaque ancienne adresse, celle que Google connaît et que d’autres sites citent, renvoie alors une erreur 404.
WordPress ne rattrape que certains cas. Quand vous modifiez l’identifiant d’un seul article, il redirige l’ancienne adresse. Sur une erreur 404, il tente aussi de deviner l’article voulu à partir du début de son identifiant. Mais cette devinette peut tomber à côté, et elle ne couvre ni les changements de base des catégories, ni les pages déplacées dans l’arborescence.
Comment la repérer
Dans la Search Console, le rapport d’indexation des pages montre un pic de pages introuvables après le changement. La Santé du site affiche la structure actuelle des permaliens dans son onglet d’informations, mais pas son historique. Le plus sûr reste de tester les anciennes adresses, issues d’un ancien plan de site ou d’un export de votre outil de statistiques, avec curl -I.
Comment corriger
Avant tout changement, exportez toutes les adresses indexées ou citées. Après, posez une redirection permanente 301 de chaque ancienne adresse vers son équivalent exact, et non vers la page d’accueil. Google demande de garder ces redirections au moins un an, de préférer les codes 301 ou 308, et prévient que les redirections temporaires ne transmettent pas le même signal. Le plugin Redirection, installé sur plus de deux millions de sites, gère ces correspondances sans toucher au serveur.
3. Des sauvegardes jamais restaurées : la fausse assurance
Pourquoi c’est grave
Une sauvegarde qui existe n’est pas une sauvegarde qui fonctionne. Elle peut ne contenir que la base de données, ou que les fichiers, alors que la documentation de WordPress rappelle qu’il faut les deux. Elle peut dormir sur le même serveur que le site, ou dans le même centre de données. Elle peut surtout n’avoir jamais été testée.
La page officielle de WordPress consacrée aux sauvegardes ne parle pas de test de restauration. L’agence américaine de cybersécurité, la CISA, en fait au contraire une règle : vérifier que l’équipe sait restaurer rapidement les données, en tout ou en partie. Notre comparatif des plugins de sauvegarde WordPress raconte ce qu’il en coûte de l’oublier, avec l’incendie d’un centre de données strasbourgeois.
Comment la repérer
Aucun outil ne le fera pour vous : la Santé du site ne teste pas les sauvegardes. Seul un exercice de restauration prouve qu’une sauvegarde est bonne. Restaurez-la sur une copie de travail, chronométrez l’opération, vérifiez les contenus et connectez-vous.
Comment corriger
Appliquez la règle 3-2-1 : trois copies, sur deux supports différents, dont une hors site. Avec WP-CLI, wp db export sauvegarde la base, wp db import la restaure, et wp search-replace adapte les adresses à la copie de test, données sérialisées comprises. Notez le temps de restauration : c’est la durée de votre prochaine panne.
4. Une version de PHP dépassée : la faille que personne ne voit
Pourquoi c’est grave
PHP est le langage qui fait tourner WordPress, et chaque version n’est maintenue que quelques années. PHP 8.1 ne reçoit plus de correctifs de sécurité depuis le 31 décembre 2025, et PHP 8.2 cessera d’en recevoir le 31 décembre 2026. À cette date, si rien ne bouge, environ six sites WordPress sur dix tourneront sur une version abandonnée.
WordPress recommande PHP 8.3 ou plus, et la version 7.0 a relevé le minimum à PHP 7.4 : les sites en PHP 7.2 ou 7.3 restent bloqués sur WordPress 6.9. Le gain de vitesse d’une mise à jour est réel mais modeste. L’argument principal est la sécurité.
Comment la repérer
La Santé du site compare votre version aux recommandations de WordPress. Attention à un piège : le 1er octobre 2026, le service qu’elle interroge considérait encore PHP 8.1 comme sûr, et ne l’affichait donc qu’en amélioration recommandée. Fiez-vous aux dates publiées par php.net.
Autre piège : wp cli info affiche la version de PHP utilisée par la ligne de commande, qui n’est pas forcément celle du serveur web. Pour cette dernière, consultez l’onglet d’informations de la Santé du site, rubrique Serveur, ou votre panneau d’hébergement.
Comment corriger
Clonez le site sur une copie de travail, passez-la en PHP 8.3, 8.4 ou 8.5, mettez d’abord à jour plugins et thème, activez le journal d’erreurs, puis parcourez les parcours clés : commande, formulaires, connexion. Ne vous fiez pas à l’ancien plugin PHP Compatibility Checker, qui n’est plus maintenu et ne vérifie que jusqu’à PHP 8.0. Notre guide des versions de PHP pour WordPress détaille la démarche.
5. Trop de plugins, et des plugins abandonnés
Pourquoi c’est grave
Ce sont deux problèmes distincts. L’excès de plugins pèse sur la vitesse, multiplie les conflits et gonfle les options chargées à chaque page. L’abandon, lui, est un risque de sécurité. Selon Patchstack, 91 % des nouvelles failles liées à WordPress découvertes en 2025 touchaient des plugins, et près de la moitié n’avaient pas de correctif au moment de leur publication, et un plugin abandonné n’en recevra jamais.
Plus inquiétant, WordPress n’affiche aucun avertissement quand un plugin installé a été fermé sur WordPress.org. Il apparaît dans la liste comme n’importe quel plugin à jour.
Comment les repérer
La Santé du site signale les plugins à mettre à jour, les plugins inactifs, qu’elle qualifie de cibles tentantes pour les attaquants, les thèmes inactifs, et les options chargées automatiquement quand elles dépassent un certain volume. Pour les plugins fermés, WP-CLI fait mieux que l’interface :
wp plugin list --fields=name,status,version,wporg_status,wporg_last_updatedUn statut closed signifie que le plugin a été retiré du répertoire. Un statut vide désigne un plugin qui n’y a jamais figuré, comme une extension premium, que cette commande ne peut pas juger.
Comment corriger
Supprimez les plugins inactifs et les thèmes inutilisés, en gardant un thème par défaut de secours. Remplacez les plugins fermés, retirez ceux qui font doublon, et vérifiez après chaque désinstallation qu’il ne reste pas d’options orphelines. Query Monitor aide à mesurer ce que chaque plugin coûte en requêtes.
6. Un compte « admin » et des mots de passe faibles
Pourquoi c’est grave
La documentation officielle de WordPress le dit sans détour : n’utilisez pas l’identifiant « admin ». C’est le premier essayé par les robots qui testent des mots de passe à la chaîne, avec « webmaster ». Combiné à un mot de passe faible ou réutilisé, il transforme une attaque de masse en intrusion réussie.
Comment le repérer
La Santé du site ne vérifie ni les identifiants ni la force des mots de passe. WP-CLI liste les administrateurs avec wp user list --role=administrator --fields=ID,user_login,user_email. Regardez aussi les comptes d’administrateur oubliés, d’anciens prestataires ou d’anciens salariés.
Comment corriger
Un identifiant ne se renomme pas dans WordPress. Créez un nouvel administrateur, connectez-vous avec lui, puis supprimez l’ancien en lui réattribuant ses contenus : wp user delete 123 --reassign=567. Sans cette réattribution, les articles de l’ancien compte sont supprimés avec lui.
Renommer « admin » ne retire qu’une devinette : les identifiants réels restent souvent visibles. L’essentiel est ailleurs, dans des mots de passe uniques, un gestionnaire de mots de passe et la double authentification pour tous les administrateurs. Nos 10 mesures pour sécuriser WordPress détaillent ces protections.
7. Pas de site de préproduction : on teste sur les clients
Pourquoi c’est grave
Mettre à jour un plugin, un thème, PHP ou WordPress directement en production revient à tester sur vos visiteurs. WordPress a ajouté des filets de sécurité : un mode de récupération en cas d’erreur fatale depuis la version 5.2, et un retour arrière automatique des mises à jour automatiques de plugins qui provoquent une erreur fatale, depuis la 6.6. Mais ces filets ne rattrapent que les erreurs fatales, pas une mise en page cassée ou un tunnel de commande qui calcule mal.
Comment la repérer
Aucun test automatique ne vérifie l’existence d’une préproduction. Posez-vous trois questions : existe-t-il une copie de travail, est-elle protégée par un mot de passe, et chaque copie déclare-t-elle son rôle ? Depuis WordPress 5.5, la constante WP_ENVIRONMENT_TYPE permet d’indiquer si un site est local, de développement, de préproduction ou de production.
Comment corriger
De nombreux hébergeurs proposent une préproduction en un clic, et des plugins comme WP Staging en créent une. Déclarez-la avec wp config set WP_ENVIRONMENT_TYPE staging --type=constant, protégez-la par un mot de passe HTTP, et ne recopiez jamais ses réglages d’indexation vers la production, comme dans l’erreur numéro un.
8. Modifier le thème parent : des changements effacés à la prochaine mise à jour
Pourquoi c’est grave
Modifier directement les fichiers d’un thème acheté ou téléchargé, par l’éditeur intégré, par FTP ou par Git, conduit à l’une de deux impasses. Soit la prochaine mise à jour écrase les modifications, soit le propriétaire cesse de mettre à jour le thème pour les protéger, et accumule les failles. L’éditeur de fichiers de WordPress l’affiche d’ailleurs en avertissement.
Les thèmes de blocs nuancent le problème. Les changements faits dans l’éditeur de site sont stockés dans la base de données et survivent aux mises à jour. Seules les modifications de fichiers exigent encore un thème enfant.
Comment le repérer
Dans l’onglet d’informations de la Santé du site, la rubrique du thème actif indique s’il a un thème parent. Un thème qui affiche une mise à jour disponible depuis des mois est un signal d’alerte. Pour savoir si des fichiers ont été modifiés, comparez-les à une copie neuve de la même version téléchargée depuis WordPress.org.
Comment corriger
Créez un thème enfant, avec un fichier style.css dont l’en-tête Template désigne le dossier du parent. Déplacez-y les modifications, réinstallez un parent propre, puis mettez-le à jour. Ajoutez define( 'DISALLOW_FILE_EDIT', true ); dans wp-config.php pour retirer les éditeurs de fichiers de l’administration.
9. Des images trop lourdes : la lenteur qui s’installe
Pourquoi c’est grave
Une photo envoyée telle qu’elle sort de l’appareil pèse plusieurs mégaoctets. Multipliée par les pages et les articles, elle ralentit l’affichage et pèse sur les Core Web Vitals, les indicateurs de vitesse que Google mesure chez les vrais visiteurs. Selon le Web Almanac 2025, WordPress reste parmi les CMS les moins bien classés sur ces indicateurs.
WordPress fait pourtant beaucoup par lui-même : réduction des très grandes images à 2 560 pixels, chargement différé, formats WebP et AVIF. Depuis la version 7.1, la compression et le redimensionnement se font même dans le navigateur, mais seulement sous Chrome et les navigateurs de la même famille, et sans conversion automatique vers WebP ou AVIF, hormis les photos HEIC converties en JPEG.
Comment les repérer
Le rapport Core Web Vitals de la Search Console regroupe les adresses lentes à partir de données réelles. PageSpeed Insights signale les images à mieux compresser, convertir ou dimensionner. La Santé du site ne juge pas le poids des images.
Comment corriger
Redimensionnez avant l’envoi, activez un format moderne avec le module Modern Image Formats de l’équipe performance de WordPress, et n’appliquez jamais le chargement différé à l’image principale du haut de page. Notre sélection de plugins de vitesse WordPress complète ces réglages.
10. Ignorer la Santé du site : le tableau de bord que personne n’ouvre
Pourquoi c’est grave
Depuis WordPress 5.2, le menu Outils, puis Santé du site, fait passer une série de tests et classe les résultats en problèmes critiques, améliorations recommandées et tests réussis. Une vérification tourne chaque semaine en arrière-plan. Ses alertes couvrent plusieurs erreurs de ce comparatif (indexation désactivée, PHP dépassé, plugins inactifs ou à mettre à jour) et d’autres réglages risqués : affichage des erreurs aux visiteurs, et, depuis WordPress 7.0, inscription ouverte avec un rôle trop élevé.
Ce qu’elle ne voit pas
La Santé du site ne vérifie ni les sauvegardes, ni les identifiants d’administrateur, ni la double authentification, ni les plugins fermés, ni les thèmes parents modifiés, ni le poids des images, ni les redirections, ni la préproduction. Elle couvre trois ou quatre des dix erreurs de ce comparatif, ce qui en fait un filet utile mais pas un audit.
Comment en faire une habitude
Ouvrez-la une fois par mois, traitez les problèmes critiques, et exportez l’onglet d’informations quand vous demandez de l’aide à un prestataire. En ligne de commande, les commandes wp site-health existent, mais seulement dans les versions de développement (nightly) de WP-CLI ou en paquet à installer : la version stable actuelle, 2.12.0, ne les contient pas.
Le cas réel : Asda change ses adresses et perd trois mois
L’histoire qui suit ne concerne pas un site WordPress. C’est la version à grande échelle d’un changement de permaliens, et elle montre ce qui arrive quand des redirections manquent, même chez une entreprise qui a les moyens de bien faire.
Un déménagement en apparence anodin
Asda est l’une des plus grandes chaînes de supermarchés du Royaume-Uni. Sa boutique en ligne vivait sur un sous-domaine, groceries.asda.com. Juste avant le changement, selon les données de l’outil d’analyse SEO Sistrix, Asda occupait sa meilleure position de visibilité dans Google depuis plus de sept ans.
Le 22 août 2025, l’enseigne déplace sa boutique vers un répertoire du domaine principal, www.asda.com/groceries/. L’ancienne organisation des adresses, par rayons, catégories et étagères, disparaît au profit d’une structure plus propre et plus lisible. Sur le papier, c’est une amélioration.
Ce qui s’est mal passé
Les nouvelles sous-catégories ne correspondent pas aux anciennes. Certaines pages de catégorie reçoivent une redirection individuelle vers leur équivalent et continuent de fonctionner. D’autres renvoient une erreur 404. Sistrix cite une ancienne page d’étagère, qui se classait très bien, toujours en erreur 404 lors de l’analyse de Sistrix.
Une semaine après le changement, la visibilité d’Asda a reculé de 12 %, au profit de ses concurrents. Les captures de l’Internet Archive montrent par ailleurs que l’ancienne page d’accueil de la boutique a d’abord renvoyé une redirection temporaire, avant de passer à une redirection permanente fin septembre. Or Google rappelle qu’une redirection temporaire ne lui indique pas que la nouvelle adresse doit remplacer l’ancienne.
Trois mois pour revenir
Le 18 novembre 2025, soit environ trois mois plus tard, la visibilité d’Asda était revenue à son niveau d’avant. Sistrix y voit un schéma observé depuis des années : il faut environ trois mois à Google pour redécouvrir entièrement un nouveau répertoire. Entre-temps, selon l’outil, la baisse représentait des millions de clics potentiels perdus, une estimation issue de son modèle et non des chiffres d’Asda.
Nous n’avons trouvé aucune communication d’Asda sur l’opération. Nos sources sont l’analyse de Sistrix et les captures de l’Internet Archive, ce qui invite à la prudence sur les détails.
Ce qu’un propriétaire de site WordPress doit en retenir
Avant de toucher aux permaliens ou aux catégories, exportez chaque adresse qui reçoit du trafic. Posez une redirection permanente par ancienne adresse, vers son véritable équivalent, et gardez-la au moins un an. Surveillez chaque jour les pages introuvables dans la Search Console pendant les premières semaines. Et retenez l’ordre de grandeur : une grande marque a passé trois mois sous sa visibilité habituelle ; Google compte plutôt quelques semaines pour un site petit ou moyen, à condition que chaque ancienne adresse soit redirigée.
Par où commencer
Un premier audit tient en une demi-heure. Ouvrez la Santé du site et notez les problèmes critiques. Dans la Search Console, regardez le rapport d’indexation des pages, en particulier les pages exclues par une balise noindex et les pages introuvables. Puis lancez trois commandes WP-CLI :
wp option get blog_public
wp plugin list --fields=name,status,version,wporg_status
wp user list --role=administrator --fields=ID,user_loginEnfin, planifiez une restauration de sauvegarde sur une copie de travail. Notre checklist de maintenance WordPress transforme ces vérifications en routine.
Tableau récapitulatif
| Erreur | Ce qu’on perd | Comment la repérer | Santé du site |
|---|---|---|---|
| Indexation désactivée | Le trafic Google | Search Console, blog_public |
Oui, depuis 6.9 |
| Permaliens sans redirections | Positions et liens entrants | Pages introuvables dans la Search Console | Non |
| Sauvegardes non testées | Le site entier | Exercice de restauration | Non |
| PHP dépassé | Les correctifs de sécurité | Dates de php.net | En partie |
| Plugins abandonnés | Sécurité et vitesse | wporg_status dans WP-CLI |
En partie |
| Compte « admin » | Le contrôle du site | wp user list |
Non |
| Pas de préproduction | Des ventes, des formulaires | WP_ENVIRONMENT_TYPE |
Non |
| Thème parent modifié | Les mises à jour du thème | Comparaison avec une copie neuve | Non |
| Images trop lourdes | La vitesse | Core Web Vitals, PageSpeed Insights | Non |
| Santé du site ignorée | Les alertes précoces | Une visite par mois | Elle-même |
Questions fréquentes
La case de non-indexation retire-t-elle mon site de Google immédiatement ?
Non. Google retire les pages au fur et à mesure qu’il les explore à nouveau, ce qui, selon Google, peut prendre des mois pour les pages les moins importantes. C’est ce qui rend l’erreur si difficile à relier à sa cause.
Peut-on renommer le compte « admin » ?
Pas directement : WordPress interdit de modifier un identifiant, dans l’interface comme avec WP-CLI. Il faut créer un nouvel administrateur, lui réattribuer les contenus, puis supprimer l’ancien compte.
Quelle version de PHP utiliser en 2026 ?
PHP 8.3 au minimum, comme le recommande WordPress, et PHP 8.4 ou 8.5 si vos plugins le supportent (l’équipe hébergement de WordPress les recommande pour une nouvelle installation). PHP 8.2 cesse de recevoir des correctifs de sécurité à la fin de l’année 2026.
WordPress redirige-t-il les anciennes adresses après un changement de permaliens ?
Seulement en partie. Il redirige l’ancien identifiant d’un article modifié individuellement, et tente de deviner l’article voulu sur une erreur 404. Il ne gère ni les changements de structure globaux, ni les catégories. Des redirections explicites restent indispensables.
La Santé du site suffit-elle à surveiller mon site ?
Non. Elle détecte bien les versions dépassées, les plugins inactifs et quelques réglages dangereux, mais ignore les sauvegardes, les comptes, les redirections et le poids des pages. Complétez-la par la Search Console et une restauration régulière.
Faut-il un thème enfant avec un thème de blocs ?
Pas pour les réglages faits dans l’éditeur de site, enregistrés dans la base de données. Oui dès que vous modifiez des fichiers, ajoutez des fichiers de modèles ou du code.
Conclusion
Ces dix erreurs ont en commun de ne rien casser de visible. Elles laissent le site fonctionner pendant qu’il perd ses positions, sa sécurité ou sa capacité à revenir après un incident. L’histoire d’Asda le montre à grande échelle : trois mois sous sa visibilité habituelle, après une migration aux redirections incomplètes.
Les outils pour les repérer sont gratuits et déjà là. Il suffit de les ouvrir : la Santé du site une fois par mois, la Search Console une fois par semaine, et une restauration de sauvegarde avant d’en avoir besoin.
Sources
- WordPress.org (octobre 2026). Statistics
- WordPress.org (mai 2026). Requirements
- Make WordPress Core, John Blackbourn (9 janvier 2026). Dropping support for PHP 7.2 and 7.3
- PHP.net. Supported Versions
- WordPress, GitHub (branche 7.1). class-wp-site-health.php
- WordPress.org Documentation (juillet 2026). Site Health screen
- Make WordPress Core, Peter Wilson (2 septembre 2019). Changes to prevent search engines indexing sites
- Google Search Central. Block Search indexing with noindex
- Google Search Console Help. Page indexing report
- Google Search Central (août 2026). Site moves with URL changes
- Google Search Central (avril 2026). Redirects and Google Search
- Search Engine Journal, Roger Montti (20 avril 2024). Google On Diagnosing A Deindexed WordPress Site
- WordPress Developer Resources (juin 2026). Backups
- CISA. Back Up Business Data
- Patchstack (25 février 2026). State of WordPress Security in 2026
- Patchstack (18 octobre 2024). Security implications of plugin closures
- WP-CLI. wp plugin list
- WordPress Developer Resources (février 2026). Brute Force Attacks
- WP-CLI. wp user delete
- WordPress Developer Resources. wp_get_environment_type()
- WordPress Developer Resources. Child Themes
- Make WordPress Core, Adam Silverstein (22 juillet 2026). Client-side media processing in WordPress 7.1
- HTTP Archive (15 janvier 2026). Web Almanac 2025, CMS
- Google Search Console Help. Core Web Vitals report
- GitHub, WP-CLI. site-health-command
- Sistrix, Steve Paine (3 septembre 2025, mis à jour le 6 janvier 2026). Asda Domain Visibility in Complex Subdomain to Subdirectory Migration
- WordPress.org. Redirection
- Make WordPress Core (25 juin 2024). WordPress 6.6 Field Guide
- Google Search Central. Control what you share with Google
- WordPress Developer Resources (janvier 2026). Hardening WordPress
- Internet Archive (août à décembre 2025). Captures de groceries.asda.com
- Kinsta (décembre 2025). PHP benchmarks
- Make WordPress Hosting. WordPress 7.0 server compatibility
LaFactory conçoit, développe et maintient des sites WordPress et WooCommerce, audits techniques compris, et développe ses propres plugins. Parlons de votre projet WordPress.