Maintenance pour WordPress : opération nettoyage en profondeur

Maintenir à jour un site WordPress consiste en une série d’opérations techniques allant de la simple mise à jour d’extension ou de thème à un nettoyage en profondeur de votre base de données.

En tant que spécialiste de la maintenance de site sous WordPress, je me suis donné pour challenge d’optimiser au mieux WP channel, qui affichait alors un historique de bientôt 10 ans d’existence.

Mener à bien une cure de jouvence est une tâche longue et ardue. Prévoyez de sauvegarder autant de fois que nécessaire votre site avant d’opérer des nettoyages irréversibles. Notez que cet article ne passe pas en revue toutes les actions propre à une maintenance régulière d’un site WordPress mais s’attarde sur le nettoyage de sites avec un passif de plusieurs années. Les recettes ont directement été appliquées sur ce blog.

La base de données

Une base de données stocke l’ensemble des contenus et réglages de votre site. Elle peut rapidement s’engorger de données obsolètes qui parasitent l’ensemble. Un exemple concret concerne l’installation d’extensions qui peuvent créer des tables supplémentaires. Le problème est qu’une fois désinstallé depuis votre back-office, les tables sont rarement supprimées et restent présentes.

Avant d’aller plus loin, vous devez impérativement sauvegarder votre base de données et vous assurer que celle-ci est parfaitement fonctionnelle. Vous devez également maitriser un outil comme phpMyAdmin ou Adminer.

Supprimer les tables inutiles de votre base de données

Cette opération est loin d’être simple car elle nécessite tout d’abord d’identifier les tables à supprimer. Il faut donc avoir une certaine expérience pour savoir à quelles extensions correspondent les noms des tables. Certaines sont plus faciles que d’autres à identifier.

Un site WordPress simple (hors multisite) ne compte que 12 tables, toutes précédées du préfixe défini par la variable $table_prefix de votre fichier wp-config.php (wp_ par défaut) : commentmeta, comments, links, options, postmeta, posts, term_relationships, term_taxonomy, termmeta, terms, usermeta et users. Les autres tables qui portent ce préfixe ont été créées par une extension ou par un thème. Ne touchez pas à celles qui portent un autre préfixe : elles peuvent appartenir à un autre site installé dans la même base.

À partir de là, vous pouvez sélectionner puis supprimer les tables n’ayant pas fait l’objet d’une suppression suite à la désinstallation d’une extension. Exportez-les d’abord : vous pourrez les réimporter en cas d’erreur.

Pour ma part, j’ai réussi à économiser 70 Mo de données. Pas mal non ?

Modifier l’encodage de caractères en utf8mb4

Depuis WordPress 4.2, sorti en 2015, la base de données utilise l’encodage de caractères utf8mb4 à la place d’utf8 : il accepte tous les caractères Unicode, émojis compris. Lors de la mise à jour vers cette version, WordPress a tenté une seule fois de convertir ses propres tables, et seulement si le serveur de base de données gérait déjà utf8mb4 (MySQL 5.5.3 ou plus récent) : il n’a converti que celles qui étaient en utf8. Il ne convertit ni les tables en latin1 ni celles créées par des extensions.

Dans votre fichier wp-config.php, lequel, rappelons-le, lie votre installation à votre base, la constante DB_CHARSET indique peut-être encore utf8 : ce n’est pas un problème, WordPress utilise de toute façon utf8mb4 pour dialoguer avec la base. Pour connaître l’encodage et l’interclassement réellement utilisés, ouvrez Outils > Santé du site, onglet Informations, section Base de données : ils figurent sur les lignes « Jeu de caractères de la base de données » et « Classement de base de données ».

Dans phpMyAdmin, la liste des tables de votre base indique ensuite l’interclassement de chacune, dans la colonne Interclassement : les tables en latin1 (latin1_swedish_ci) ou en utf8 (utf8_general_ci, utf8mb3_general_ci) n’ont pas été converties. Après une sauvegarde, convertissez-les une à une depuis l’onglet SQL, en remplaçant le nom de la table dans la requête suivante et en reprenant l’interclassement indiqué par WordPress :

ALTER TABLE `wp_nom_de_la_table` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_520_ci;

L’onglet Opérations de la base, section Interclassement, convertit toutes les tables d’un coup si vous cochez « Changer les interclassements de toutes les tables » puis « Changer les interclassements de toutes les colonnes de toutes les tables ». Sans cette seconde case, seul l’interclassement par défaut des tables change, pas celui des colonnes qui contiennent vos données.

Prudence avec les tables en latin1 : sur un site ancien, elles contiennent souvent du texte déjà encodé en UTF-8, que leur conversion transforme en suites de caractères illisibles (« Café » au lieu de « Café »). Faites un essai sur une copie de votre base et contrôlez vos contenus avant de convertir celle de votre site.

Effacer les trackbacks / pingbacks

Les rétroliens ou trackbacks sont des liens retours générés automatiquement dans les commentaires d’un article lorsqu’un site tiers émet un lien vers votre billet. Cette technique de maillage externe très ancienne n’est guère plus utilisée depuis de nombreuses années.

Fort de plus de 10 000 commentaires sur ce blog, j’ai donc lancé une commande SQL afin de les supprimer en totalité. Ils n’apportent rien d’intéressant pour le visiteur.

Pour comprendre la nuance entre les trackbacks et les pingbacks, consultez la documentation officielle de WordPress sur les rétroliens et les pings (en anglais).

Pour prévenir la création de tels liens, n’oubliez pas de décocher l’option « Autoriser les notifications de lien en provenance d’autres blogs (pings et rétroliens) sur les nouvelles publications » dans Réglages > Commentaires. Comme son nom l’indique, elle ne s’applique qu’aux nouvelles publications.

Voici les requêtes à exécuter dans l’onglet SQL de phpMyAdmin, en remplaçant wp_ par le préfixe de vos tables. Dans l’ordre, elles conservent les éventuelles réponses à un rétrolien en les remontant d’un niveau, suppriment les métadonnées puis les rétroliens et pings eux-mêmes, recalculent le nombre de commentaires de chaque publication et ferment les pings sur vos contenus existants.

UPDATE `wp_comments` AS c INNER JOIN `wp_comments` AS p ON c.`comment_parent` = p.`comment_ID` SET c.`comment_parent` = p.`comment_parent` WHERE p.`comment_type` IN ('pingback', 'trackback');
DELETE FROM `wp_commentmeta` WHERE `comment_id` IN (SELECT `comment_ID` FROM `wp_comments` WHERE `comment_type` IN ('pingback', 'trackback'));
DELETE FROM `wp_comments` WHERE `comment_type` IN ('pingback', 'trackback');
UPDATE `wp_posts` SET `comment_count` = (SELECT COUNT(*) FROM `wp_comments` WHERE `comment_post_ID` = `wp_posts`.`ID` AND `comment_approved` = '1' AND `comment_type` <> 'note');
UPDATE `wp_posts` SET `ping_status` = 'closed' WHERE `ping_status` = 'open';

Supprimer les liens externes de vos commentaires

Le champ Site Web présent dans le formulaire de dépôt de commentaire permet de déposer un lien externe. Bien souvent, l’auteur du commentaire indique l’URL de son site Web. Cette fonctionnalité est largement utilisée pour générer du lien retour à moindre coût et sujet au spam. Elle n’apporte là encore pas grand chose pour le visiteur et nuit à votre référencement malgré l’ajout d’une balise nofollow.

J’ai donc pris la décision de les supprimer en totalité via cette commande SQL.

UPDATE `wp_comments` SET `comment_author_url` = '' WHERE `comment_author_url` <> '';

Il vous faudra également retirer le champ Site web du formulaire de commentaire afin de prévenir tout nouvel ajout de lien externe. Inutile de modifier votre thème : le code suivant, à placer dans une extension de fonctions globales ou dans le fichier functions.php de votre thème enfant, retire ce champ, y compris avec un thème à blocs, et ignore l’adresse que des robots enverraient malgré tout au script de traitement des commentaires.

/**
 * Remove the Website field from the comment form.
 *
 * @param array $fields Default comment form fields.
 * @return array
 */
function wpc_remove_comment_url_field( $fields ) {
	unset( $fields['url'] );

	return $fields;
}
add_filter( 'comment_form_default_fields', 'wpc_remove_comment_url_field' );

/**
 * Ignore any website address sent with a new comment.
 *
 * @param array $commentdata Comment data.
 * @return array
 */
function wpc_strip_comment_author_url( $commentdata ) {
	$commentdata['comment_author_url'] = '';

	return $commentdata;
}
add_filter( 'preprocess_comment', 'wpc_strip_comment_author_url' );

Supprimer les champs personnalisés inutiles

Les champs personnalisés ou custom fields sont largement utilisés par WordPress afin de stocker des informations complémentaires au sein d’un contenu notamment. Les développeurs ont recours à l’extension Advanced Custom Fields pour générer facilement des champs personnalisés dotés d’une interface graphique. Comme toujours, un changement de thème ou la suppression d’une extension n’inclut pas le retrait des données obsolètes en base. À moins que vous ne souhaitiez les conserver pour plus tard, il vaut mieux les retirer.

L’extension Delete Custom Fields, que je recommandais ici, a été fermée sur wordpress.org en avril 2024 pour un problème de sécurité : ne l’utilisez plus.

Passez plutôt par des requêtes SQL. La première ci-dessous liste les clés de champs personnalisés de vos contenus, de la plus utilisée à la moins utilisée ; la seconde supprime toutes les valeurs d’une clé, à remplacer par celle que vous avez identifiée comme obsolète :

SELECT `meta_key`, COUNT(*) AS `total` FROM `wp_postmeta` GROUP BY `meta_key` ORDER BY `total` DESC;
DELETE FROM `wp_postmeta` WHERE `meta_key` = 'nom_du_champ';

Les clés qui commencent par un tiret bas, comme _thumbnail_id (image mise en avant) ou _wp_page_template (modèle de page), sont souvent utilisées par WordPress lui-même ou par vos extensions actives : ne supprimez que celles dont vous connaissez l’origine.

Nettoyer les données orphelines, dupliquées et inutiles

Pour cette dernière opération, nous allons pouvoir automatiser le processus à l’aide de l’extension WP-Sweep. Facile d’utilisation et particulièrement efficace, elle vous mâche le travail depuis Outils > WP-Sweep : révisions, brouillons automatiques, commentaires indésirables, métadonnées orphelines ou dupliquées, transients… Elle passe autant que possible par les fonctions de suppression de WordPress plutôt que par des requêtes SQL directes, afin que les autres extensions soient prévenues de chaque suppression.

À utiliser sans modération avec une sauvegarde bien entendu !

Terminons en ajoutant qu’il vous faut surveiller les tables suspectes : j’entends par là celles qui sont anormalement lourdes en poids ou qui contiennent des centaines de milliers de lignes. Il est toujours bon d’identifier les causes à l’origine de ce phénomène afin de mener là encore de nouvelles optimisations.

Vérifier la présence des index et des clés primaires

Si vous rencontrez des soucis de performances sur MySQL, il peut être bénéfique de vérifier si les clés primaires ainsi que les index sont bien présents pour les tables concernées. Pour ce faire, il vous faudra passer par phpMyAdmin et comparer votre installation à une installation neuve de WordPress. Pensez également à installer de zéro les extensions que vous utilisez car certaines créent des tables additionnelles.

C’est une opération longue et fastidieuse mais utile si vous cherchez en vain la cause d’une saturation du serveur de base de données… pour en avoir vécu l’expérience récemment c’est quelque chose à laquelle on ne pense guère.

Les fichiers

Le fichier .htaccess

Un fichier .htaccess est un fichier masqué de configuration propre à Apache pour un répertoire donné. Généralement, il est situé à la racine Web de votre espace et vous permet, entre autres, de gérer :

• Vos règles de réécritures pour disposer d’URLS seo-friendly ;
• Vos redirections 301 ;
• Vos optimisations de cache ;
• Votre politique de sécurité (Content Security Policy) ;

Au fil du temps, il n’est pas rare de voir s’accumuler des lignes de code obsolètes qu’il conviendra de retirer avec précaution. Laissez en revanche intactes les lignes situées entre # BEGIN WordPress et # END WordPress : WordPress les réécrit lui-même, par exemple à l’affichage de la page Réglages > Permaliens, et toute modification à cet endroit serait perdue.

Le fichier wp-config.php

Le fameux fichier wp-config.php que nous créons tous lors de l’installation de WordPress ne fait pas que relier votre installation à votre base de données MySQL ou MariaDB.

Vous pouvez y injecter des paramètres avancés comme :

• L’augmentation de la limite mémoire ;
• L’obligation d’utiliser HTTPS dans l’administration ;
• La définition des adresses Web par défaut de WordPress ;
• Des clés de licences pour certaines extensions premium ;
• L’activation du cache ;

Là encore, il est possible de supprimer certaines lignes obsolètes mais surtout d’améliorer la fiabilité de votre site en y ajoutant celles mentionnées plus haut dans la liste. Pensez également à consolider la force du mot de passe de la base de données.

Les fichiers inutiles ou obsolètes

Au fil des années, certains fichiers de WordPress sont tout simplement supprimés de l’archive officielle. Les mises à jour lancées depuis le tableau de bord effacent ceux que WordPress a recensés, mais une mise à jour manuelle par FTP, qui se contente d’écraser les fichiers existants, ou une mise à jour interrompue les laisse en place. Pour ma part, une demi-douzaine de fichiers à la racine étaient devenus inutiles… c’est là le problème après une décennie d’écriture sur ce blog.

Le plus simple pour les repérer est WP-CLI. La commande suivante compare vos fichiers à ceux de votre version de WordPress et signale chaque fichier modifié ainsi que chaque fichier qui ne devrait pas exister dans /wp-admin, /wp-includes et à la racine du site :

wp core verify-checksums --include-root

À la racine, elle signale aussi les fichiers étrangers à WordPress, dont certains restent utiles (fichier de vérification de la Search Console, par exemple) : examinez la liste avant de supprimer quoi que ce soit. Sans WP-CLI, téléchargez l’archive de votre version de WordPress, supprimez les dossiers /wp-admin et /wp-includes avant de les remplacer par ceux de l’archive, puis comparez les fichiers présents à la racine avec ceux de l’archive.

Au delà des fichiers propres à WordPress, vous devriez en profiter pour faire le ménage au niveau de la racine Web et surtout du dossier /wp-content car il n’est pas rare de rencontrer des dossiers qui n’ont rien à faire là. Il peut s’agir de thèmes ou d’extensions inactives, de dossiers de sauvegardes qui sont stockées au format ZIP et qui occupent une grande partie de votre espace de stockage – on ne laisse jamais les sauvegardes sur le serveur de production, d’anciens dossiers de cache, etc.

Vous connaissez des astuces pour faciliter la maintenance de votre site ? Partagez vos techniques en commentaires.

Première étape du nettoyage : supprimer ou limiter les révisions d’articles.