Le premier janvier, un client bien intentionné a voulu « nettoyer un peu les réglages » de son site pendant les fêtes. Résultat trouvé le 2 janvier au matin : la case « Décourager les moteurs de recherche d’indexer ce site » cochée par erreur dans l’écran « Lecture », probablement en pensant faire l’inverse. Deux semaines de désindexation partielle avant que quelqu’un ne remarque la chute de trafic et n’en trouve la cause.
Ce genre d’incident se répète avec une poignée de réglages toujours identiques : ceux qui semblent anodins dans leur formulation mais dont la conséquence est immédiate et parfois difficile à diagnostiquer. Voici les principaux candidats à verrouiller, avec la méthode la plus fiable pour chacun.
Visibilité du site pour les moteurs de recherche
Ce réglage, stocké dans l’option blog_public, peut être verrouillé pour ne jamais repasser à une valeur bloquant l’indexation, quel que soit ce qui est soumis via le formulaire :
function vr_verrouiller_visibilite( $value ) {
return 1; // toujours autoriser l'indexation, quoi qu'on tente de soumettre
}
add_filter( 'pre_update_option_blog_public', 'vr_verrouiller_visibilite' );
Le fuseau horaire
Un changement accidentel de fuseau horaire décale silencieusement tous les horaires de publication planifiée, souvent sans que personne ne s’en aperçoive avant plusieurs jours. Verrouiller timezone_string et gmt_offset évite ce genre de dérive :
function vr_verrouiller_fuseau_horaire( $value ) {
return 'Europe/Paris';
}
add_filter( 'pre_update_option_timezone_string', 'vr_verrouiller_fuseau_horaire' );La structure des permaliens
Changer la structure des permaliens sans redirections adéquates casse instantanément tous les liens internes et externes déjà partagés vers le site. Ce réglage ne bénéficie pas d’un filtre pre_update_option dédié aussi direct ; la protection la plus fiable consiste à retirer purement et simplement l’accès à l’écran concerné pour les rôles autres qu’administrateur technique :
function vr_restreindre_ecran_permaliens() {
global $pagenow;
if ( 'options-permalink.php' === $pagenow && ! current_user_can( 'manage_options' ) ) {
wp_die( 'Cet écran est réservé à l\'équipe technique.' );
}
}
add_action( 'admin_init', 'vr_restreindre_ecran_permaliens' );Pourquoi un simple disabled côté formulaire ne suffit jamais
Ajouter l’attribut HTML disabled sur un champ de formulaire empêche seulement sa modification via l’interface visible : rien n’empêche une requête envoyée directement, ou un navigateur avec les outils de développement ouverts, de contourner cette limite purement esthétique. Seul un filtre pre_update_option_{option} ou une vérification de capacité au niveau serveur constitue une vraie protection.
Checklist des réglages à évaluer sur chaque projet
- Visibilité du site pour les moteurs de recherche (
blog_public) : à verrouiller sur tout site en production. - Fuseau horaire et format de date : à verrouiller dès qu’une planification de contenu est en jeu.
- Structure des permaliens : à restreindre par capacité plutôt qu’à verrouiller totalement, un changement légitime restant parfois nécessaire en début de projet.
- Adresse e-mail d’administration : à surveiller, un changement ici redirige silencieusement toutes les notifications critiques du site.
- Nom et description du site utilisés dans les métadonnées : impact SEO direct en cas de modification hasardeuse.
La bonne question à se poser pour chaque réglage n’est pas « est-ce que ça peut arriver », mais « qu’est-ce qui se passe concrètement, et combien de temps avant que quelqu’un s’en aperçoive, si ce réglage change sans le vouloir ».
Ce qui n’est volontairement pas couvert ici
Cette liste ne traite pas des rôles et capacités personnalisés dans leur ensemble, qui offrent une réponse plus large et plus structurée à ce même problème de fond, mais qui demande un investissement de mise en place plus important, réservé aux projets où plusieurs profils d’utilisateurs coexistent réellement.
En résumé
Trois ou quatre réglages concentrent l’essentiel des incidents accidentels causés par un client bien intentionné. Les verrouiller avec un filtre pre_update_option_{option} ou une restriction de capacité prend quelques minutes et évite des heures de diagnostic a posteriori sur un problème qui, sur le moment, ne ressemble à rien d’identifiable.
