# Comment créer des redirections 301 sans plugin WordPress ?

> Vous créez des redirections 301 sans plugin en écrivant la règle directement au niveau du serveur : dans le fichier .htaccess sur Apache, dans la configuration Nginx, ou via les règles d'un CDN comme Cloudflare. Là, la redirection se résout avant même que WordPress ne se charge, donc plus légère qu'un plugin, qui stocke ses règles en base et les vérifie à chaque requête. Pour quelques redirections, un plugin convient ; pour beaucoup, ou après un changement de plateforme, les règles côté serveur sont plus stables et rapides. Chaque règle doit être une 301 en un seul saut vers la bonne page. WPBuildAI génère la carte de redirections, prête pour .htaccess, Nginx ou le CDN.

Source: https://wpbuildai.com/fr/redirection-301-sans-plugin-wordpress/
By lawrence-arya · 2026-06-19

---
Vous créez des redirections 301 sans plugin en écrivant la règle directement au niveau du serveur : dans le fichier .htaccess sur Apache, dans la configuration Nginx, ou via les règles d'un CDN comme Cloudflare. La différence avec un plugin tient à l'endroit où la règle s'exécute. Au niveau du serveur, la redirection se résout avant même que WordPress ne se charge, alors qu'un plugin stocke ses règles en base de données et les vérifie à chaque requête, après le démarrage de WordPress. Pour quelques redirections, un plugin convient parfaitement ; pour beaucoup, ou après un changement de plateforme, les règles côté serveur sont plus stables et plus rapides. Dans tous les cas, chaque règle doit être une 301 en un seul saut vers la bonne page. WPBuildAI génère la carte de redirections, prête pour .htaccess, Nginx ou le CDN.

## Où vivent les redirections sans plugin

Sans plugin, une redirection vit dans l'un de trois endroits, tous en amont de WordPress. Le premier est la configuration du serveur web : .htaccess sur Apache, ou un bloc dans la config Nginx. Le deuxième est le CDN, par exemple les règles de redirection de Cloudflare, qui agissent en bordure de réseau, avant même le serveur. Le troisième, plus rare en pratique, est une règle au niveau de l'hébergement géré. Le point commun : la redirection est servie avant que le code de WordPress n'entre en jeu, et c'est précisément ce qui la rend légère.

## Le fichier .htaccess sur Apache

Sur un serveur Apache, les redirections s'écrivent dans le fichier .htaccess, à la racine du site. Une ligne du type Redirect 301 ancien-chemin nouvelle-URL, ou une règle de réécriture pour les motifs, indique au serveur de répondre aussitôt par une 301 quand l'ancienne URL arrive. L'avantage est qu'aucun plugin n'est nécessaire et que la règle agit avant WordPress. L'attention va à la syntaxe et à l'ordre des règles, car une erreur dans .htaccess peut affecter tout le site ; mieux vaut partir d'une carte propre et tester.

## La configuration Nginx

Sur Nginx, il n'y a pas de .htaccess : les redirections se placent dans le fichier de configuration du serveur, généralement avec une directive return 301 ou une réécriture dans le bloc du site. La logique est la même qu'avec Apache, seule la syntaxe change. Comme la config Nginx exige souvent un accès au serveur et un rechargement, il est courant de préparer la liste complète des redirections et de l'appliquer en une fois, plutôt que de les ajouter une par une. Là encore, la redirection se résout avant WordPress, donc sans peser sur l'application.

## Au niveau du CDN

Si vous utilisez un CDN comme Cloudflare, vous pouvez gérer les redirections en bordure, avec ses règles de redirection en masse. L'avantage est que la requête est redirigée avant même d'atteindre votre serveur, soit l'endroit le plus rapide possible. C'est une excellente option pour de grands ensembles de redirections, car elle décharge à la fois WordPress et le serveur d'origine. Vous chargez une liste ancien vers nouveau et le CDN l'applique. Pour un site comptant des milliers de redirections, cette voie garde tout hors de l'application.

## Pourquoi c'est plus rapide qu'un plugin

La raison de la vitesse est simple : moins de travail par requête. Un plugin de redirection démarre WordPress, se charge et interroge la base pour comparer l'URL à ses règles, le tout avant de répondre. Une règle côté serveur répond par la 301 sans rien démarrer de tout cela. Sur quelques redirections, la différence est invisible, mais sur des milliers elle pèse sur le Time to First Byte, qui entre dans les Core Web Vitals décrits sur [web.dev](https://web.dev/articles/vitals). Le Web Almanac 2024 ([HTTP Archive](https://almanac.httparchive.org/en/2024/)) rappelle tout ce que WordPress fait déjà par requête, et un plugin de redirection chargé en ajoute.

## Les règles d'une redirection propre

Déplacer les redirections vers le serveur ne doit pas en compromettre la justesse. Les règles habituelles tiennent : chaque redirection est une 301 permanente, se résout en un seul saut vers la bonne page, et ne pointe pas tout vers l'accueil, que Google lit comme une erreur soft 404, selon la [documentation sur les redirections](https://developers.google.com/search/docs/crawling-indexing/301-redirects). Évitez les chaînes et les boucles, et n'en abusez pas en nombre, comme l'explique [combien de redirections sont trop nombreuses](/how-many-301-redirects-are-too-many-seo-speed/). Après avoir chargé les règles, vérifiez un échantillon, comme dans [vérifier que les redirections fonctionnent](/check-if-301-redirects-are-working-correctly/).

## Étapes

1. **Inventoriez les URLs** et construisez la carte ancien vers nouveau.
2. **Choisissez l'endroit :** .htaccess (Apache), config Nginx, ou CDN.
3. **Générez les règles** au format adapté à cet endroit.
4. **Appliquez la liste** en une fois, pas une règle à la fois.
5. **Vérifiez** que les redirections se résolvent en un saut.
6. **Gardez le fichier** sous gestion de version et surveillez les 404.

## Exemple : déplacer une section

Prenons un site qui déplace une section, changeant des centaines d'URLs, et qui veut éviter un plugin lourd. On construit la carte ancien vers nouveau et on l'exporte en règles Nginx, car le site tourne sur ce serveur. Les règles sont chargées dans la config en une fois, et les redirections se résolvent désormais avant WordPress. On vérifie qu'un échantillon répond par une 301 en un seul saut vers la bonne page, conforme au guide sur le [déplacement avec changement d'URL](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes). Le Time to First Byte n'est pas affecté, et les redirections fonctionnent comme avec un plugin, mais sans son poids.

## Les erreurs à éviter

- Utiliser un plugin pour des milliers de redirections, alourdissant chaque requête.
- Se tromper dans la syntaxe de .htaccess, avec un effet sur tout le site.
- Pointer les redirections vers l'accueil au lieu de la bonne page.
- Créer des chaînes ou des boucles en les déplaçant vers le serveur.
- Ne pas vérifier que les règles du serveur se résolvent en un saut.

## Ce qu'il faut retenir

Vous créez des redirections 301 sans plugin en écrivant la règle au niveau du serveur : .htaccess sur Apache, config Nginx, ou règles du CDN. Là, elle se résout avant que WordPress ne se charge, donc plus rapide qu'un plugin qui interroge la base à chaque requête. Pour quelques redirections, un plugin suffit ; pour beaucoup, ou lors d'une migration, le serveur est le bon choix. Gardez chaque règle une 301 en un seul saut vers la bonne page, évitez chaînes et boucles, et vérifiez un échantillon. WPBuildAI génère la carte de redirections, prête pour .htaccess, Nginx ou le CDN. Envoyez l'adresse de votre site pour une analyse gratuite.

Sans affiliation avec WordPress, Lovable, Webflow, Shopify, Wix ou Squarespace.