Liens WordPress cassés : régénérer le .htaccess vite

by | WordPress

Si vos articles affichent soudain une 404 alors que la page d’accueil fonctionne, vous êtes très probablement face à un souci de règles de réécriture (rewrite rules) — et donc de permaliens “cassés”. Sur WordPress 6.9.4, la correction la plus fréquente consiste à régénérer les règles et, sur Apache, à réécrire le fichier .htaccess (quand WordPress en a le droit).

Le problème

Le symptôme typique : vos URL “propres” (ex. /mon-article/) ne pointent plus vers vos contenus. L’admin fonctionne, mais le front renvoie des 404, ou parfois une erreur serveur.

Voici des messages réalistes que vous pouvez voir :

# Dans le navigateur (front-end)
404 Not Found

# Dans certains logs Apache/Nginx (selon config)
rewrite or internal redirection cycle while internally redirecting to "/index.php"

# Dans WordPress / Site Health (selon hébergeur)
Le fichier .htaccess n'est pas accessible en écriture.

Où ça apparaît :

  • Front-end : pages, articles, catégories, pages produits WooCommerce en 404.
  • API REST (parfois) : endpoints qui ne répondent plus si la réécriture est cassée côté serveur.
  • Admin : souvent aucun souci… ce qui rend le bug déroutant.

Circonstances typiques que je vois souvent en dépannage :

  • Après une migration (nouveau serveur, nouveau domaine, passage HTTP → HTTPS).
  • Après avoir activé/désactivé un plugin qui déclare des routes (SEO, cache, sécurité, WooCommerce, LMS).
  • Après un changement de configuration serveur (passage Apache → Nginx, ou ajout d’un WAF).
  • Après avoir “nettoyé” le serveur et supprimé .htaccess sans le vouloir.

À qui s’adresse ce guide : si vous débutez sur WordPress (6.9.4 en avril 2026) et que vous voulez rétablir vos permaliens sans casser votre site. À la fin, vous saurez :

  • Identifier si le souci vient de WordPress (règles) ou du serveur (.htaccess/Nginx).
  • Régénérer proprement les règles de permaliens (sans “flush” inutile à chaque page).
  • Ajouter un bouton “un clic” dans l’admin, avec nonce (anti-CSRF) et vérifications.
  • Utiliser WP-CLI pour corriger vite, surtout en production.

Résumé rapide

  • Le correctif le plus sûr : Réglages → Permaliens → Enregistrer (même sans changer). Ça régénère les règles côté WordPress et tente de réécrire .htaccess sur Apache.
  • Si .htaccess n’est pas accessible en écriture : corrigez permissions/propriétaire, ou collez les règles manuellement.
  • Sur Nginx, .htaccess ne sert à rien : il faut une config Nginx correcte (try_files).
  • Évitez de lancer flush_rewrite_rules() à chaque chargement : ça plombe les performances.
  • En production, la méthode la plus propre : WP-CLI (wp rewrite flush).

Les symptômes

Les signes les plus courants quand les permaliens sont “cassés” :

  • 404 sur les articles/pages mais la page d’accueil fonctionne.
  • 404 sur /category/…, /tag/…, /author/…
  • WooCommerce : pages produit en 404, panier/commande qui redirigent mal.
  • Multilingue : un seul langage fonctionne (souvent la langue par défaut), les autres sont en 404.
  • Redirections étranges : boucle vers /index.php ou vers la home.
  • Erreur 500 juste après avoir “touché” .htaccess (règle invalide).
  • REST API : certains endpoints renvoient 404/401 alors que l’admin est OK (souvent lié à une réécriture ou à un WAF).
  • Ça marche en local (MAMP/Laragon) mais pas en production : module Apache absent, config Nginx différente, ou permissions différentes.

Compatibilité page builders : Divi 5, Elementor et Avada ne “cassent” pas les permaliens à eux seuls, mais ils dépendent fortement d’URL stables (templates, assets, prévisualisations). Quand les règles sont HS, vous verrez aussi :

  • Elementor : aperçu qui charge mal, prévisualisation en 404.
  • Divi 5 : Visual Builder qui boucle ou renvoie une page introuvable.
  • Avada : Fusion Builder qui n’affiche pas la page attendue en preview.

Pourquoi ça arrive

Version débutant : WordPress doit “traduire” vos jolies URL (/mon-article/) en une requête interne (index.php?name=mon-article). Cette traduction se fait grâce à des règles de réécriture. Sur Apache, ces règles sont généralement écrites dans .htaccess.

Version technique : WordPress génère des rewrite rules via WP_Rewrite et les stocke en base (option rewrite_rules). Ensuite, selon le serveur :

  • Apache : WordPress tente d’écrire un bloc entre # BEGIN WordPress et # END WordPress dans .htaccess, en s’appuyant sur mod_rewrite.
  • Nginx : .htaccess est ignoré. La réécriture se fait dans la conf Nginx (souvent try_files).
  • IIS : règles dans web.config (plus rare aujourd’hui).

Causes probables (du plus fréquent au plus rare) :

  • 1) Rewrite rules non “flushées” après un changement (activation plugin, CPT, taxonomie, migration).
  • 2) .htaccess supprimé/corrompu ou bloc WordPress modifié à la main.
  • 3) Permissions/propriétaire empêchent WordPress d’écrire .htaccess.
  • 4) Serveur non compatible : mod_rewrite désactivé, AllowOverride None sur Apache, ou Nginx mal configuré.
  • 5) Conflit plugin de cache/sécurité qui injecte des règles agressives (ou un WAF qui bloque).
  • 6) Mauvaise base URL (siteurl/home) après migration : redirections et 404 en cascade.
  • 7) Réécritures personnalisées ajoutées dans le thème/plugin mais “flush” fait au mauvais moment.

Tableau de diagnostic (rapide)

Symptôme Cause probable Vérification Solution
404 sur articles/pages, home OK Règles non régénérées Réglages → Permaliens → Enregistrer Solution 1
404 partout sauf /wp-admin .htaccess manquant ou Nginx mal réglé Présence de .htaccess (Apache) / conf Nginx Solution 1 + “Si ça ne marche toujours pas”
Erreur 500 après édition .htaccess Syntaxe invalide / directive interdite Logs serveur, revenir en arrière Restaurer .htaccess, Solution 1
WordPress dit “.htaccess non accessible en écriture” Permissions/propriétaire FTP/SSH : droits et owner Corriger droits, ou coller les règles manuellement
Sur Nginx, “un clic” ne change rien .htaccess ignoré Vérifier le serveur (Nginx) Configurer try_files (section dédiée)

Prérequis avant de commencer

  • Sauvegarde : fichiers + base de données. Ne dépannez jamais “à l’aveugle” sur production.
  • Un accès : au minimum WP Admin. Idéalement FTP/SFTP ou SSH.
  • Versions : WordPress 6.9.4, PHP 8.1+ (recommandé). Une version PHP trop ancienne peut déclencher des erreurs annexes.
  • Outils utiles :

Pour activer le debug proprement (temporairement), éditez wp-config.php et ajoutez/ajustez :

// wp-config.php
// Sauvegardez avant de modifier. Ne laissez pas WP_DEBUG actif en permanence sur un site public.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );     // Log dans wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false );

Documentation officielle : Debug WordPress.

Solution 1 : régénérer .htaccess via Réglages → Permaliens (le “un clic” le plus sûr)

C’est la méthode la plus fiable pour débutants, et celle que j’utilise en premier sur 80% des cas. Elle régénère les règles de réécriture WordPress et, sur Apache, réécrit le bloc WordPress dans .htaccess si les permissions le permettent.

Étapes (sans code)

  1. Allez dans Réglages → Permaliens.
  2. Sans rien changer, cliquez sur Enregistrer les modifications.
  3. Testez une URL d’article en navigation privée (pour éviter un cache navigateur).

Ce qui se passe en coulisses : WordPress “flush” ses règles (il régénère et sauvegarde rewrite_rules) et tente d’écrire le bloc WordPress dans .htaccess (Apache). La fonction centrale côté WordPress est documentée ici : flush_rewrite_rules().

Cas fréquent : WordPress ne peut pas écrire .htaccess

Si WordPress affiche que .htaccess n’est pas accessible en écriture, vous avez deux options :

  • Option A (recommandée) : corriger les permissions/propriétaire via votre hébergeur (évite de laisser des droits trop ouverts).
  • Option B : copier/coller manuellement le bloc proposé par WordPress dans .htaccess.

Bloc standard WordPress (Apache) que vous verrez souvent proposé. Attention : il peut varier selon sous-dossier, multisite, etc. Ne copiez pas ce bloc si votre WordPress est installé dans un sous-répertoire sans adapter.

# Exemple de bloc WordPress typique (Apache)
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Si vous êtes sur Nginx, ne perdez pas de temps avec .htaccess : passez directement à la section “Si ça ne marche toujours pas” (partie Nginx).

Code AVANT / APRÈS (erreur classique : flush au mauvais endroit)

J’ai souvent vu ce problème sur des sites où quelqu’un a copié un snippet “magique” trouvé sur un forum et l’a collé dans functions.php. Résultat : WordPress régénère les règles à chaque page, ce qui peut ralentir fortement le site (et parfois créer des effets de bord).

AVANT (cassé : flush à chaque chargement)

Où c’est collé : functions.php du thème (souvent) ou un plugin de snippets.

<?php
// Mauvaise pratique : flush des permaliens à chaque page.
// J'ai déjà vu ça faire exploser le TTFB sur des sites un peu chargés.

add_action( 'init', function () {
	flush_rewrite_rules();
} );

APRÈS (corrigé : flush une seule fois à l’activation)

Où coller : créez un mini-plugin (recommandé) dans wp-content/plugins/bpcab-rewrite-fix/bpcab-rewrite-fix.php, puis activez-le. Évitez de mettre ça dans le thème : un changement de thème désactive votre correctif.

<?php
/**
 * Plugin Name: BPCAB - Flush permaliens à l'activation
 * Description: Régénère les règles de réécriture une seule fois à l'activation (WordPress 6.9.4+).
 * Version: 1.0.0
 */

defined( 'ABSPATH' ) || exit;

/**
 * Hook d'activation : déclenché une seule fois quand le plugin est activé.
 * Ici, on régénère les règles proprement.
 */
register_activation_hook( __FILE__, function () {
	// true = écrit aussi les règles dans .htaccess si possible (Apache)
	flush_rewrite_rules( true );
} );

/**
 * Hook de désactivation : optionnel, mais propre.
 */
register_deactivation_hook( __FILE__, function () {
	flush_rewrite_rules( true );
} );

Pourquoi ça corrige : vous ne “flushez” qu’au moment où c’est nécessaire (quand des règles changent), pas à chaque requête. Le hook (crochet) register_activation_hook est un mécanisme WordPress qui exécute une fonction lors de l’activation d’un plugin.

Documentation : Activation/Deactivation Hooks.

Solution 2 : ajouter un bouton “Régénérer .htaccess” dans l’admin (sans plugin)

Vous voulez un vrai “un clic” dans l’admin, réutilisable quand vous migrez ou après certains changements ? Voici une solution propre : une page d’outils dans l’admin qui exécute un flush, protégée par capability (droits) et nonce.

Termes :

  • Action (hook) : point d’accroche où WordPress exécute votre code (ex. admin_menu).
  • Capability : permission utilisateur (ex. manage_options pour les administrateurs).
  • Nonce : jeton anti-CSRF pour éviter qu’un site externe déclenche l’action à votre place.

Où coller le code : créez un mu-plugin (must-use plugin) pour que ça reste actif même si vous changez de thème/plugins.

  • Chemin : wp-content/mu-plugins/bpcab-oneclick-htaccess.php
  • Si le dossier mu-plugins n’existe pas, créez-le.

Sauvegardez avant de modifier. Une erreur de syntaxe PHP peut bloquer l’admin.

Code complet (page Outils → Régénérer les permaliens)

<?php
/**
 * MU Plugin: BPCAB - Régénérer les permaliens en un clic
 * Description: Ajoute une page dans Outils permettant de régénérer les règles de réécriture (.htaccess sur Apache).
 * Compatibilité: WordPress 6.9.4+, PHP 8.1+
 */

defined( 'ABSPATH' ) || exit;

/**
 * Ajoute une page dans le menu "Outils".
 */
add_action( 'admin_menu', function () {
	add_management_page(
		'Régénérer les permaliens',
		'Régénérer les permaliens',
		'manage_options',
		'bpcab-rewrite-flush',
		'bpcab_render_rewrite_flush_page'
	);
} );

/**
 * Affiche la page et gère l'action sécurisée.
 */
function bpcab_render_rewrite_flush_page() {
	if ( ! current_user_can( 'manage_options' ) ) {
		wp_die( 'Accès refusé.' );
	}

	$did_flush = false;

	// Si le formulaire a été soumis, on vérifie le nonce.
	if ( isset( $_POST['bpcab_rewrite_flush'] ) ) {
		check_admin_referer( 'bpcab_rewrite_flush_action', 'bpcab_rewrite_flush_nonce' );

		// Régénère les règles et tente d'écrire .htaccess (Apache).
		flush_rewrite_rules( true );

		$did_flush = true;
	}

	echo '<div class="wrap">';
	echo '<h1>Régénérer les permaliens</h1>';

	if ( $did_flush ) {
		echo '<div class="notice notice-success is-dismissible"><p><strong>OK</strong> : règles de réécriture régénérées.</p></div>';
	}

	echo '<p>Utilisez ce bouton si vos URL renvoient des 404 après une migration, un changement de plugin, ou une modification de structure d’URL.</p>';
	echo '<p><strong>Attention</strong> : sur Nginx, ce bouton régénère les règles côté WordPress, mais ne remplace pas une configuration serveur correcte.</p>';

	echo '<form method="post">';
	wp_nonce_field( 'bpcab_rewrite_flush_action', 'bpcab_rewrite_flush_nonce' );
	echo '<p><button type="submit" class="button button-primary" name="bpcab_rewrite_flush" value="1">Régénérer maintenant</button></p>';
	echo '</form>';

	echo '<hr />';
	echo '<h2>Vérification rapide</h2>';
	echo '<ol>';
	echo '<li>Ouvrez un article au hasard dans un nouvel onglet.</li>';
	echo '<li>Si vous utilisez un plugin de cache, videz son cache.</li>';
	echo '<li>Testez en navigation privée.</li>';
	echo '</ol>';

	echo '</div>';
}

Pourquoi cette solution est “safe”

  • Elle exige manage_options (administrateur).
  • Elle protège l’action avec un nonce (sinon, n’importe quel lien externe pourrait déclencher le flush si vous êtes connecté).
  • Elle n’exécute flush_rewrite_rules() que sur demande, pas à chaque page.

Référence nonce : Nonces.

Compatibilité Divi 5 / Elementor / Avada

Aucune dépendance : c’est une page dans l’admin. Sur des sites builder, je conseille juste de vider aussi :

  • Le cache du builder (Elementor : Regenerate CSS & Data si nécessaire, Divi : options de performance, Avada : cache/compilation).
  • Le cache du plugin de performance (LiteSpeed Cache, WP Rocket, etc.).

Solution 3 : WP-CLI (rapide, propre, idéal en production)

Quand vous avez SSH, WP-CLI est souvent le moyen le plus rapide, surtout en production où vous voulez éviter de cliquer dans l’admin. WP-CLI est l’outil officiel en ligne de commande pour administrer WordPress : WP-CLI Commands.

Commandes utiles

Depuis la racine de WordPress :

# 1) Vérifier que WP-CLI voit bien le site
wp core version

# 2) Flush des règles de réécriture
wp rewrite flush --hard

# 3) (Optionnel) Lister les règles pour debug
wp rewrite list --format=table

Ce que fait –hard : il demande un flush “dur”, et sur Apache il tente aussi d’écrire .htaccess (quand c’est possible). Si vous êtes sur Nginx, ça ne “répare” pas Nginx, mais ça remet au propre les règles côté WordPress.

Code AVANT / APRÈS (cas réel : script de déploiement incomplet)

J’ai déjà vu des pipelines CI/CD qui déploient WordPress (ou un thème) et oublient de flusher après l’ajout d’un CPT. Résultat : tout marche en staging, mais 404 en prod.

AVANT (déploiement sans flush)

# Script de déploiement (extrait)
composer install --no-dev
wp plugin activate mon-plugin-cpt
# Oubli : pas de flush, les nouvelles routes ne répondent pas

APRÈS (flush maîtrisé)

# Script de déploiement (extrait)
composer install --no-dev
wp plugin activate mon-plugin-cpt
wp rewrite flush --hard

Pourquoi ça corrige : vous synchronisez l’état “code” (CPT/taxonomies/routes) avec l’état “règles de réécriture” au bon moment.

Vérifications après correction

Après la régénération, vérifiez de façon reproductible :

  1. Ouvrez un article et une page en navigation privée.
  2. Testez une archive (catégorie / tag) et une page système (ex. /wp-sitemap.xml si activé).
  3. Si vous avez WooCommerce : testez un produit + le panier.
  4. Videz les caches :
    • Cache plugin (WP Rocket, LiteSpeed Cache, etc.).
    • Cache serveur (si votre hébergeur en a un).
    • Cache CDN (Cloudflare, etc.).
  5. Regardez wp-content/debug.log si vous avez activé WP_DEBUG.

Si vous utilisez Query Monitor, regardez si une requête renvoie 404 à cause d’un “main query” qui ne matche rien (ça arrive quand la règle n’existe plus).

Si ça ne marche toujours pas

Ici, on sort du “un clic” : si vos permaliens restent cassés après un flush, c’est très souvent un souci serveur, un cache agressif, ou une base URL incohérente.

Étape 1 : identifier votre serveur (Apache vs Nginx)

  • Dans beaucoup d’hébergeurs, c’est indiqué dans le panneau.
  • Vous pouvez aussi regarder les en-têtes HTTP (outil “Inspecter” du navigateur → Réseau) : Server: nginx ou Server: Apache (pas toujours fiable).

Étape 2 : si vous êtes sur Nginx, corrigez la conf (sinon .htaccess ne sert à rien)

Configuration Nginx classique pour WordPress (exemple générique). Vous aurez besoin de votre hébergeur si vous n’avez pas accès :

# Exemple Nginx (à adapter)
location / {
	try_files $uri $uri/ /index.php?$args;
}

Sans ce try_files, vous pouvez flusher autant que vous voulez : Nginx ne transmettra pas les URL à WordPress correctement.

Étape 3 : vérifier .htaccess (Apache)

  • Le fichier .htaccess doit être à la racine WordPress (là où se trouve wp-config.php).
  • Le bloc WordPress doit être valide et non dupliqué.
  • Le serveur doit autoriser les overrides : AllowOverride All (sinon .htaccess est ignoré).
  • mod_rewrite doit être activé.

Si vous obtenez une 500 juste après modification, revenez immédiatement à la version précédente du fichier. Une directive interdite par l’hébergeur (ou une faute de frappe) suffit.

Étape 4 : vérifier siteurl/home après migration

Quand l’URL du site est incohérente, vous pouvez avoir des redirections bizarres et des 404. Vérifiez :

  • Réglages → Général : “Adresse web de WordPress (URL)” et “Adresse web du site (URL)”.

Si l’admin est inaccessible, WP-CLI peut aider :

wp option get home
wp option get siteurl

Référence : wp option.

Étape 5 : conflit plugin/thème (cache, sécurité, redirections)

Utilisez Health Check en mode dépannage : vous désactivez plugins/thème pour vous seulement (les visiteurs ne voient rien). Dans mon expérience, les suspects fréquents :

  • Plugins de cache (règles serveur injectées, redirections forcées).
  • Plugins de sécurité (WAF, blocage REST, restrictions de fichiers).
  • Plugins multilingues (structures d’URL spécifiques).

Étape 6 : vider tous les caches (vraiment)

Erreur classique : “j’ai vidé le cache” = seulement le cache navigateur. Sur un site moderne, vous avez souvent 3 à 5 couches :

  • Cache navigateur
  • Cache plugin
  • Cache serveur (FastCGI, LiteSpeed, Varnish)
  • Cache CDN
  • Cache du builder (CSS/JS compilés)

Étape 7 : vérifier les permissions (Apache)

Si WordPress ne peut pas écrire .htaccess, vous êtes tenté de mettre 777. Évitez. Corrigez plutôt propriétaire/groupe via l’hébergeur. Référence PHP sur les permissions (pour comprendre) : chmod().

Pièges et erreurs courantes

Symptôme / erreur Cause probable Solution recommandée
“J’ai cliqué sur Enregistrer, rien ne change” Serveur Nginx, .htaccess ignoré Configurer Nginx (try_files) + flush WP
Erreur 500 après édition .htaccess Faute de frappe, directive interdite, bloc dupliqué Restaurer .htaccess, puis Solution 1
Les permaliens recassent après chaque déploiement Rewrite rules pas flushées après ajout CPT/taxonomies Flush à l’activation (Solution 1) ou WP-CLI (Solution 3)
Site lent après “réparation” flush_rewrite_rules() exécuté sur init Retirer le snippet, flush uniquement à l’activation
Snippet copié au mauvais endroit Collé dans un plugin de cache, ou dans un fichier core Mettre dans mu-plugin ou mini-plugin, jamais dans core
Page d’admin blanche après ajout du code Oubli de point-virgule / parenthèse Corriger la syntaxe, regarder les logs PHP
Le bouton “un clic” fonctionne, mais certaines URL restent en 404 Conflit plugin, règles custom, redirections Health Check + désactivation ciblée

Erreur que je vois souvent : confondre action et filtre

Un hook peut être une action (déclenche quelque chose) ou un filtre (modifie une valeur). Le flush est une action : on ne “filtre” pas des permaliens, on régénère des règles. Si vous tombez sur un vieux tutoriel qui recommande un filtre étrange, méfiez-vous : beaucoup de snippets datent de l’époque où les pratiques étaient moins strictes sur la performance.

Variante / alternative

Méthode sans code : plugin de gestion des permaliens / redirections

Si vous ne voulez pas toucher au code, vous pouvez utiliser un plugin fiable pour gérer des redirections et diagnostiquer des 404. Ce n’est pas une “réparation .htaccess” à proprement parler, mais ça aide à limiter l’impact utilisateur pendant que vous corrigez la réécriture.

  • Par exemple, un plugin de redirection reconnu (sur WordPress.org Plugins) peut journaliser les 404 et vous montrer si le problème est global (réécriture) ou ciblé (URL changées).

Attention sécurité : évitez les plugins qui proposent d’éditer .htaccess sans contrôle fin. Un champ “éditeur .htaccess” mal protégé peut devenir un risque si un compte admin est compromis.

Méthode développeur : flush ciblé après enregistrement de la structure

Si vous développez un plugin qui enregistre un CPT (Custom Post Type = type de contenu personnalisé), vous devez flusher une fois à l’activation, pas à chaque chargement. Exemple minimal (plugin) :

<?php
/**
 * Plugin Name: BPCAB - Exemple CPT + flush propre
 */

defined( 'ABSPATH' ) || exit;

function bpcab_register_book_cpt() {
	register_post_type( 'book', array(
		'label' => 'Livres',
		'public' => true,
		'rewrite' => array( 'slug' => 'livres' ),
		'show_in_rest' => true, // Gutenberg / REST API
	) );
}
add_action( 'init', 'bpcab_register_book_cpt' );

register_activation_hook( __FILE__, function () {
	// Important : enregistrer le CPT avant le flush, sinon les règles ne l'incluent pas.
	bpcab_register_book_cpt();
	flush_rewrite_rules( true );
} );

Référence register_post_type : register_post_type().

Éviter ce problème à l’avenir

  • Ne modifiez jamais le core (fichiers WordPress). Tout doit aller dans un plugin, mu-plugin ou thème enfant.
  • Évitez les snippets “flush sur init”. Si vous devez flusher, faites-le :
    • à l’activation d’un plugin
    • après une migration (one-shot)
    • via WP-CLI en déploiement
  • Gardez une copie de .htaccess (si Apache) dans votre sauvegarde, ou dans votre gestion de config serveur.
  • Sur Nginx : documentez votre bloc WordPress (try_files) et ne le laissez pas “implicite”.
  • Après installation d’un builder (Divi/Elementor/Avada) : testez une page, un article, une archive, et la prévisualisation. Ça détecte tôt les soucis de rewrite.

Petit contrôle automatisé (optionnel) via WP-CLI

Vous pouvez ajouter un check dans votre routine de maintenance :

# Vérifier qu'une URL répond (exemple simple)
wp eval "echo home_url('/?p=1');"

Ce n’est pas un test complet, mais ça vous pousse à vérifier régulièrement que le routage fonctionne.

Ressources

Questions fréquentes

Est-ce que “Enregistrer les permaliens” régénère vraiment .htaccess ?

Sur Apache, oui : WordPress régénère ses règles et tente d’écrire le bloc WordPress dans .htaccess si le fichier est accessible en écriture. Sur Nginx, .htaccess n’est pas utilisé.

Pourquoi je vois encore des 404 après le flush ?

Le plus fréquent : cache (plugin/CDN), serveur Nginx mal configuré, ou .htaccess ignoré (AllowOverride). Faites la checklist “Si ça ne marche toujours pas”.

Dois-je mettre flush_rewrite_rules() dans functions.php ?

Non, pas en continu. Si vous devez le faire, utilisez un mini-plugin avec register_activation_hook (flush une seule fois). Le mettre sur init ralentit le site.

Mon hébergeur est sur Nginx : quelle est la solution “un clic” ?

Le “clic” régénère les règles WordPress, mais la vraie correction est serveur : ajoutez/validez try_files $uri $uri/ /index.php?$args; dans la conf Nginx. Ensuite, faites un flush via l’admin ou WP-CLI.

Est-ce que Divi 5 / Elementor / Avada peuvent casser les permaliens ?

Ils ne cassent pas la réécriture à eux seuls. En revanche, ils rendent les symptômes plus visibles (preview qui boucle, assets qui semblent incohérents). Corrigez d’abord la réécriture, puis videz les caches du builder.

J’ai une erreur 500 après avoir collé un bloc .htaccess trouvé sur internet

Restaurez immédiatement votre sauvegarde du fichier. Ensuite, repassez par Réglages → Permaliens. Les blocs “génériques” ne tiennent pas compte des sous-dossiers, multisites, ou restrictions d’hébergeur.

Faut-il régénérer les permaliens après chaque mise à jour WordPress ?

Non. Faites-le seulement si vous observez un symptôme (404, routage cassé) ou après un changement qui affecte les routes (CPT/taxonomies, migration, changement de structure d’URL).

Est-ce risqué de rendre .htaccess “écrivable” ?

Le risque n’est pas le fait d’être écrivable en soi, mais de le rendre trop permissif (ex. droits trop ouverts) ou de permettre à un acteur malveillant d’y injecter des règles. Préférez corriger propriétaire/groupe proprement et gardez un accès SFTP/SSH sécurisé.

Je suis en multisite : c’est la même chose ?

Le principe est identique (flush des règles), mais le bloc .htaccess multisite est différent. Ne copiez pas un bloc “site simple”. Utilisez Réglages → Permaliens (ou WP-CLI), puis appliquez le bloc spécifique fourni par votre réseau si nécessaire.

Articles connexes

Submit a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.