Activer les permaliens basés sur le nom de l’article sur le site de staging

By , Founder · Updated

Lorsque tu crées un site de staging par défaut situé dans un sous-dossier, WP STAGING configure l’option « Permaliens » du site de staging sur « Plain » et désactive l’option « Permaliens basés sur le nom de l’article ». Cela garantit que le site de staging s’ouvre correctement sur tous les types de serveurs.

Si tu utilises la version PRO de WP STAGING et que tu as créé un site de staging dans un sous-domaine comme staging.example.com, tu peux activer les permaliens basés sur le nom de l’article sous wp-admin > réglages > permaliens. Cela devrait fonctionner immédiatement.

La version Pro de WP STAGING dispose de l’option « Conserver les permaliens ». À chaque fois que tu crées un nouveau site de staging et actives cette option, le site de staging utilisera exactement la même structure de permaliens que le site en production. Tu trouveras cette option sous WP STAGING > Réglages > Keep Permalinks.

Si tu actives cette option et que le site de staging te redirige vers le site en production ou affiche une erreur 404, suis cet article !

En général, il est parfaitement acceptable d’utiliser des permaliens simples sur un site de staging. Souvent, il n’y a pas de nécessité technique d’activer des permaliens personnalisés pour bénéficier d’un site de staging.

Néanmoins, si tu veux activer les permaliens personnalisés sur ton site de staging pour avoir la même structure de liens, tu devras d’abord déterminer quel serveur web tourne sur ton serveur ou ton plan d’hébergement.

Tu dois accéder au tableau de bord d’administration de ton site de staging WordPress pour activer les permaliens basés sur le nom de l’article.

Si tu essaies d’accéder au tableau de bord d’administration de ton site de staging et que le site de staging te redirige vers le site en production, ajoute le slug wp-admin à la fin de l’URL comme https://example.com/stagingsite/wp-admin

Cela te permet d’accéder au wp-admin de ton site.

(Une telle redirection peut se produire si tu utilises des Plugins de langue comme WPML ou Polylang, qui ajoutent un slug de langue à l’URL. Ces Plugins ont souvent besoin que les permaliens soient activés)

Serveur web Apache

Si le serveur web Apache sert ton site, il y a de bonnes chances que les permaliens conviviaux pour les moteurs de recherche fonctionnent sans travail supplémentaire.

Active simplement les permaliens sur la page :

Staging Site > wp-admin > Settings > Permalinks

Il est très probable que cela fonctionne bien dès le départ.

Si cela ne donne pas le résultat escompté et que les liens sur le site de staging génèrent une erreur 400, crée un nouveau fichier .htaccess et colle-le à la racine du site de staging en utilisant un client FTP ou un Plugin de gestionnaire de fichiers.

Le contenu de ce fichier devrait ressembler à ceci :

# BEGIN WordPress 
RewriteEngine On 
RewriteBase /staging/ 
RewriteRule ^index\.php$ - [L] 
RewriteCond %{REQUEST_FILENAME} !-f 
RewriteCond %{REQUEST_FILENAME} !-d 
RewriteRule . /staging/index.php [L] 
# END WordPress

Remplace le texte mis en évidence staging par le nom du sous-dossier où se trouve le site de staging !

Serveur web Apache | Multisites

En général, WP STAGING prend en charge et effectue les ajustements nécessaires au fichier .htaccess lorsque tu clones un multisite WordPress.

Les règles suivantes seront placées dans un fichier .htaccess à la racine du site de staging pour les multisites en sous-domaine et en sous-dossier :

Multisite en sous-domaine, ex. staging.example.com

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]

# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]

Multisite en sous-dossier, ex. example.com/staging

RewriteEngine On
RewriteBase /staging/
RewriteRule ^index\.php$ - [L]

# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]

Remplace le texte mis en évidence staging par le nom du sous-dossier où se trouve le site de staging !

Serveur web Nginx

Si ton site utilise Nginx, essaie d’abord d’activer les permaliens conviviaux pour les moteurs de recherche sur le site de staging. Si cela ne fonctionne pas, suis les étapes ci-dessous pour activer les permaliens dans Nginx.

Ouvre wp-admin et va dans Réglages > Permaliens, puis sélectionne Nom de l’article.

Pour tester, ouvre la page d’accueil de ton site et clique sur n’importe quel lien.
Si la page s’ouvre comme prévu, c’est terminé. Si elle retourne une erreur 404, utilise les étapes avancées ci-dessous :

Crée un nouveau bloc serveur dans nginx.conf similaire au snippet suivant :

location /staging{
        try_files $uri $uri/ /staging/index.php?$args;
}

Remplace le texte mis en évidence staging par le nom du sous-dossier où se trouve le site de staging !

Change également le chemin vers le fichier socket PHP s’il est différent sur ton système. Cela ne donne qu’une idée de ce qu’il faut modifier. N’utilise pas ces valeurs mot pour mot sans vérifier si ta configuration NGINX est différente.

Sache que tu as besoin d’un accès complet à ton serveur pour suivre les étapes ci-dessus. Si tu ne sais pas ce que font ces lignes, il vaut mieux demander à quelqu’un de t’aider avec les modifications ou laisser les permaliens désactivés.

Après avoir fait cela, le serveur Nginx doit être redémarré, et tu pourras profiter de ton site de staging avec les permaliens personnalisés activés.

Cela nécessitera toujours que tu configures un bloc Nginx spécifique avec le nom de dossier du site de staging.

Une autre approche optionnelle consiste à créer un bloc serveur et à laisser Nginx effectuer une réécriture automatique chaque fois que WordPress est chargé depuis un sous-dossier :

PHP
# Matches /<folder>/... – except for WP core folders
location ~ ^/(?!wp-admin|wp-content|wp-includes)([a-zA-Z0-9_-]+)(?:/|$) {
    set $first_seg $1;
    # First try static files/folders …
    try_files $uri $uri/ @maybe_staging;
}

# Checks whether /<folder>/index.php exists; if so, rewrite there,
# otherwise fall back to the live front controller.
location @maybe_staging {
    if (-f $document_root/$first_seg/index.php) {
        rewrite ^ /$first_seg/index.php?$args last;
    }
    rewrite ^ /index.php?$args last;
}

Serveur web NGINX | Multisites

Les Multisites WordPress ont besoin d’une configuration légèrement différente.

Ci-dessous, tu trouveras un exemple de nginx.conf pour un multisite de staging dans un sous-dossier.

Nous avons mis en évidence les parties pertinentes. Après avoir ajouté cette configuration à ton nginx.conf, tu dois redémarrer le serveur NGINX.

Si ton serveur utilise NGINX et que tu ne sais pas où ajouter cette configuration, demande à ton hébergeur.

Site de staging dans un sous-dossier, ex. example.com/staging

server {
listen 80; listen [::]:80;
server_name example.com/staging;

root /var/www/multi; # This is the path to your multisite website

if (!-e $request_filename) {
rewrite /wp-admin$ $scheme://$host$request_uri/ permanent;
rewrite ^/staging(/[^/]+)?(/wp-.*) /staging$2 last;
rewrite ^/staging(/[^/]+)?(/.*\.php)$ /staging$2 last;
}

location / {
try_files $uri $uri/ /index.php?$args;
}

location /staging/ {
try_files $uri $uri/ /staging/index.php?$args ;
}

location ~ \.php$ {
include fastcgi_params;
fastcgi_intercept_errors on;
fastcgi_pass php7-fpm;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
fastcgi_param DOCUMENT_ROOT $realpath_root;
}
}

Remplace le texte mis en évidence staging par le nom du sous-dossier où se trouve le site de staging !

Site de staging dans un sous-domaine, ex. staging.example.com

Si ton site de staging est situé dans un sous-domaine, tu peux utiliser la même configuration que ci-dessus avec quelques légères modifications :

server {
listen 80; listen [::]:80;
server_name staging.example.com;

# Below should be the path to your staging site
root /var/www/multi/staging; 

if (!-e $request_filename) {
rewrite /wp-admin$ $scheme://$host$request_uri/ permanent;
rewrite ^/(/[^/]+)?(/wp-.*) /$2 last;
rewrite ^/(/[^/]+)?(/.*\.php)$ /$2 last;
}

location / {
try_files $uri $uri/ /staging/index.php?$args ;
}

location ~ \.php$ {
include fastcgi_params;
fastcgi_intercept_errors on;
fastcgi_pass php7-fpm;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
fastcgi_param DOCUMENT_ROOT $realpath_root;
}
}

Remplace le texte mis en évidence staging par le nom du sous-dossier où se trouve le site de staging.

Bitnami (Apache)

Tu dois prendre des mesures supplémentaires si tu utilises WordPress dans une instance Bitnami.

Les permaliens basés sur le nom de l’article ne sont pas pris en charge immédiatement sur les instances WordPress Bitnami, car Bitnami n’utilise pas .htaccess dans le dossier racine du site web. Il ignore tout fichier .htaccess présent à cet endroit.

Bitnami n’utilise pas le fichier .htaccess par défaut à la racine de ton site ; à la place, toutes les configurations htaccess sont ajoutées à un fichier appelé : /opt/bitnami/apps/APPNAME/conf/htaccess.conf.

Donc si tu veux que les permaliens fonctionnent, tu devras modifier le fichier htaccess.conf

Va dans ce fichier et ajoutes-y ce qui suit :

<Directory /opt/bitnami/apps/wordpress/htdocs/STAGING>
 <IfModule mod_rewrite.c>
 RewriteEngine On
 RewriteBase /STAGING/
 RewriteRule ^index\.php$ - [L]
 RewriteCond %{REQUEST_FILENAME} !-f
 RewriteCond %{REQUEST_FILENAME} !-d
 RewriteRule . /STAGING/index.php [L]
 </IfModule>
 </Directory>

Important : renomme le mot STAGING par le nom du dossier de ton site de staging !
 

Une autre option serait de garder les permaliens sur les réglages simples, et tu n’auras pas besoin de modifier le fichier htaccess.conf du tout.

Microsoft Azure

Azure utilise le serveur Microsoft IIS et nécessite un fichier web.config personnalisé à la racine du répertoire web du site de staging.

D’abord, tu dois voir le fichier web.config sur le site « en production » et noter le nom de la règle dans cette ligne :

<rule name="WordPress: http://wordpress-arc.azurewebsites.net" patternSyntax="Wildcard">

C’est WordPress: http://wordpress-arc.azurewebsites.net dans cet exemple.

Ensuite, crée un nouveau fichier web.config dans le répertoire du site « staging » avec ce qui suit :

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <rewrite>
      <rules>
      <remove name="WordPress: http://wordpress-arc.azurewebsites.net"/>
      <rule name="staging" patternSyntax="Wildcard">
        <match url="*"/>
          <conditions>
            <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true"/>
            <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true"/>
          </conditions>
        <action type="Rewrite" url="index.php"/>
      </rule></rules>
    </rewrite>
  </system.webServer>
</configuration>

Assure-toi que cette ligne :

<remove name="WordPress: http://wordpress-arc.azurewebsites.net"/>

a le même nom de règle que celui défini dans le fichier web.config du site en production, qui était WordPress: http://wordpress-arc.azurewebsites.net dans notre exemple.

Microsoft IIS

  • D’abord, ouvre le fichier web.config dans le répertoire racine du site en production pour noter cette ligne :
    <rule name= »WordPress: https://example.com/ » patternSyntax= »Wildcard »>
    En particulier le nom de la règle : WordPress: https://example.com/
  • Ensuite, crée un nouveau fichier web.config dans le répertoire du site de staging avec ce snippet de code :
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
   <system.webServer>
     <rewrite>
      <rules>
        <remove name="WordPress: https://example.com/" />
        <rule name="WordPress: https://example.com/staging" patternSyntax="Wildcard">
         <match url="*"/>
          <conditions>
           <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true"/>
           <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true"/>
          </conditions>
         <action type="Rewrite" url="index.php"/>
        </rule></rules>
       </rewrite>
   </system.webServer>
</configuration>

Assure-toi que la ligne <remove name="WordPress: https://example.com/" /> a le même « name » que celui que tu as dans le web.config du site en production.

Et assure-toi que cette ligne <rule name="WordPress: https://example.com/staging" patternSyntax="Wildcard"> a le bon nom de répertoire du site de staging.

Updated on mai 23, 2026

Rene Hermenau

Auteur : Rene Hermenau

About the author: René Hermenau is the founder of WP STAGING. He works on WordPress backups, staging, migrations, database handling, and safe deployment workflows.