Besoin d’envoyer proprement un visiteur d’une page à une autre sans bricolage en JavaScript ou méta refresh ? Une Redirection URL en PHP se gère en une ligne avec header et Location, mais les détails techniques font toute la différence entre un site propre et un nid à bugs SEO. Entre la gestion des codes HTTP (302, redirection 301, 307), l’arrêt du script avec exit ou die, la compatibilité CLI/CGI et les sessions qui traînent, beaucoup de petits pièges finissent par coûter cher, surtout quand on commence à migrer des URL en prod.
Dans ce mode d’emploi, on suit un cas concret, celui d’un site vitrine en PHP classique qui évolue au fil du temps : changement de structure d’URL, cloisonnement d’une zone membre, mise en place d’un reverse proxy. L’objectif est simple : sécuriser la PHP redirection, éviter de balancer le trafic dans le mur et conserver un SEO correct pendant les refontes. Au passage, ce guide montre comment encapsuler la logique de redirect dans une fonction réutilisable, comment choisir entre exit() et die(), et dans quels cas il vaut mieux basculer la logique côté serveur avec un RedirectMatch dans un .htaccess. L’idée n’est pas de remplir l’écran de théorie, mais de fournir des exemples de code et du code pratique utilisable tel quel dans un projet réel.
En bref :
- header(« Location: … ») doit partir avant tout affichage HTML, sinon pas de redirection fiable.
- Sans code HTTP précisé, PHP envoie par défaut un 302, ce qui n’est pas adapté pour une migration permanente.
- Pour un changement définitif d’URL, une redirection 301 permet de transmettre le signal SEO aux moteurs.
- exit() ou die() après la redirection évitent l’exécution de logique sensible derrière.
- Mieux vaut encapsuler la PHP redirection dans une fonction utilitaire pour centraliser les règles.
- Sur les gros sites, les redirections structurantes ont un impact direct sur le référencement et le trafic organique.
Redirection URL en PHP avec header et Location : le minimum vital
La base de la Redirection URL en PHP repose sur un en-tête HTTP envoyé par la fonction header. Cet en-tête contient un champ Location indiquant au navigateur la nouvelle adresse à charger. Tant que rien n’a été envoyé au client (pas même un espace ou un BOM), le serveur peut modifier les en-têtes et déclencher la redirection.
Sur le site de Clara, une développeuse freelance qui maintient un vieux site d’association, le besoin est simple : déplacer une page d’actualités vers un nouveau chemin sans casser les anciens liens partagés par mail. Voici un premier code pratique minimal :
exemples de code pour une redirection simple :
<?php
header(« Location: https://exemple.com/nouvelle-page.php »);
exit();
?>
Deux points à retenir ici. D’abord, tout appel à header(« Location: … ») doit absolument se produire avant le moindre écho de HTML ou de texte. Ensuite, l’appel à exit() coupe le script net, ce qui évite de faire tourner du code inutile derrière la redirection. Cette combinaison suffit pour la majorité des cas simples, tant qu’on accepte le comportement par défaut du code HTTP 302.
Mode d’emploi précis : gérer les redirections 301, 302 et 307
La brique suivante consiste à choisir le code de statut HTTP adapté. PHP envoie un 302 si aucun code n’est précisé. Pour une migration permanente d’URL, ce choix est discutable, surtout sur un site qui travaille son SEO. Par exemple, lors d’une refonte, Clara doit déplacer définitivement tout un bloc de contenus. Continuer à envoyer des 302 empêche les moteurs d’enregistrer clairement la nouvelle structure.
Voici un mode d’emploi plus explicite :
<?php
$url = « https://exemple.com/nouvelle-page.php »;
header(« Location: » . $url, true, 301);
exit();
?>
La présence du troisième paramètre dans header précise le code HTTP. Un 301 indique que la ressource a été déplacée définitivement, ce qui aide les robots à transférer le signal de popularité de l’ancienne URL vers la nouvelle. Pour une maintenance temporaire ou un test A/B, un 302 ou un 307 reste plus logique, car le changement n’est pas figé dans le temps. Ajuster ce détail évite des surprises sur le trafic organique, surtout si une refonte plus large est prévue comme décrit dans ce retour d’expérience sur une refonte WordPress bien préparée.
Construire une fonction redirect réutilisable en PHP
Sur un projet un peu sérieux, multiplier les header(« Location: … ») en dur dans tout le code devient vite pénible. Les règles changent, le comportement doit évoluer, et on se retrouve à corriger dix fichiers différents. Clara a réglé le problème en créant une fonction PHP redirection centralisée, utilisable depuis n’importe quel contrôleur.
Un exemple de fonction robuste :
<?php
function redirect($url, $statusCode = 302)
{
if (headers_sent()) {
return;
}
header(« Location: » . $url, true, $statusCode);
exit();
}
// utilisation
redirect(« /zone-membre/dashboard.php », 303);
?>
L’intérêt ici n’est pas seulement la lisibilité. La fonction gère le cas où les en-têtes sont déjà partis, ce qui évite une erreur PHP visible en production. Elle permet aussi de standardiser les codes HTTP utilisés, par exemple en réservant le 303 après un POST pour forcer un GET sur la nouvelle URL, ce qui simplifie la gestion des formulaires et des rechargements intempestifs côté utilisateur.
Prendre en compte CLI, CGI et sessions dans les redirections
Dès que l’application PHP tourne dans des contextes différents (scripts CLI pour les tâches CRON, hébergement en mode CGI, etc.), les redirections doivent prendre quelques précautions supplémentaires. Un script lancé en ligne de commande n’a évidemment pas besoin d’envoyer un Location, et un hébergement CGI interprète certains en-têtes de façon particulière.
Voici un code pratique plus avancé qui couvre ces scénarios :
<?php
function smart_redirect($url, $code = 302)
{
if (strncmp(‘cli’, PHP_SAPI, 3) === 0) {
return;
}
if (headers_sent()) {
return;
}
if (session_id() !== ») {
session_regenerate_id(true);
session_write_close();
}
if (strncmp(‘cgi’, PHP_SAPI, 3) === 0) {
header(sprintf(‘Status: %03u’, $code), true, $code);
}
$code = preg_match(‘~^30[1237]$~’, $code) ? $code : 302;
header(« Location: » . $url, true, $code);
exit();
}
?>
Cette approche limite les comportements étranges sur certains hébergements mutualisés et évite que des sessions restent verrouillées pendant qu’un autre onglet attend l’accès. Ce type de détail fait gagner de la réactivité quand le site héberge un espace client un peu fréquenté.
Exit vs die après une redirection PHP : impact sur la connexion
Beaucoup de développeurs considèrent exit() et die() comme strictement interchangeables. Dans la pratique, leur comportement vis-à-vis de la connexion HTTP n’est pas strictement identique. Sur un site à fort trafic, cette différence peut influencer la façon dont les connexions persistantes sont gérées par le serveur.
Deux variantes très simples :
<?php
header(‘HTTP/1.1 304 Not Modified’);
exit();
?>
<?php
header(‘HTTP/1.1 304 Not Modified’);
die();
?>
Dans le premier cas, la connexion peut rester ouverte en mode persistant. Dans le second, la connexion est explicitement fermée. Sur un petit site vitrine, la différence est anecdotique. Sur une architecture où chaque requête compte, ce type de réglage peut s’intégrer à une stratégie plus globale d’optimisation, en complément d’outils comme la compression HTTP analysée dans l’article sur l’usage de gzip sous Linux. Le choix entre les deux fonctions dépend donc du style d’architecture, pas uniquement de goûts personnels.
Pourquoi il ne faut jamais oublier exit ou die derrière un header Location
Revenons au quotidien. Sur le site de Clara, une redirection protège une zone réservée : si l’utilisateur n’est pas authentifié, le script envoie un header(« Location: /login.php »). Un jour, un stagiaire oublie le exit() derrière. Résultat discret mais réel : selon certains navigateurs et caches, le script continue d’exécuter la partie censée être protégée, ce qui peut générer des logs, des appels à la base de données et parfois du contenu envoyé avant qu’un proxy intermédiaire ne décide finalement d’honorer la redirection.
Cela peut sembler théorique, mais sur des environnements avec reverse proxy, cache applicatif ou CDN, ce comportement partiel ouvre la porte à des fuites d’informations. La bonne habitude reste donc simple : toute redirection PHP doit se terminer par exit() ou die(), sans exception sur du code exposé à Internet. Ce réflexe est aussi utile pour diagnostiquer les chemins d’exécution, car un var_dump laissé après un header Location ne sera jamais atteint en production.
Redirection PHP et SEO : quand Location impacte votre trafic
Dès qu’un site vit du trafic organique, une Redirection URL mal réglée en PHP n’est plus qu’un détail technique. Une série de 302 là où des 301 seraient plus logiques peut retarder la consolidation des signaux sur une nouvelle arborescence. À l’inverse, figer des 301 trop tôt bloque parfois des expérimentations d’URL qui auraient gagné à rester temporaires.
Pour un site de e-commerce ou un blog qui refond régulièrement ses catégories, un audit SEO rapide sur les codes de redirection évite de tirer une balle dans le pied. Les différences entre SEO et SEM, détaillées dans l’analyse consacrée à ces stratégies, aident déjà à cadrer l’enjeu global, comme expliqué dans ce contenu sur les différences SEO / SEM. Sur le terrain, l’enjeu pour les redirections PHP reste d’envoyer un signal clair et cohérent à chaque modification d’URL.
Comparaison des codes HTTP courants utilisés avec header Location
Pour visualiser rapidement quel code HTTP choisir avec header(« Location: … »), le tableau ci-dessous résume les usages typiques dans une application PHP :
| Code HTTP | Usage typique en PHP | Impact SEO et comportement |
|---|---|---|
| 301 | Déplacement définitif d’une page, changement de structure d’URL figé. | Transfert du signal SEO vers la nouvelle URL, les moteurs finissent par ne plus crawler l’ancienne. |
| 302 | Redirection temporaire, test de fonctionnalité, bascule courte pendant une maintenance. | Les robots considèrent en général l’ancienne URL comme référence, utile pour des tests limités. |
| 303 | Redirection après un POST pour forcer un GET sur la page de résultat (formulaire, paiement). | Réduit les re-soumissions de formulaires, clarifie le comportement des navigateurs après un refresh. |
| 307 | Redirection temporaire en conservant la méthode HTTP d’origine. | Signal explicite de temporarité, utile quand un service est déplacé provisoirement. |
Une bonne façon de ne pas casser un site lors d’une migration consiste à cartographier d’abord toutes les URL critiques, puis à définir pour chacune le type de redirection attendu. Le code PHP devient alors l’implémentation d’une décision préalable, et non un choix au fil de l’eau mis en dur dans un contrôleur surchargé.
Alternative ou complément : quand basculer la redirection hors du PHP
Toute Redirection URL n’a pas vocation à être pilotée par le code applicatif. Pour des changements massifs ou des règles structurelles, confier la logique au serveur web ou au proxy inverse soulage PHP et simplifie le debug. Les règles d’URL rewriting dans un fichier .htaccess ou dans la configuration de Nginx restent mieux adaptées aux scénarios où chaque requête vers un ancien chemin doit être redirigée, même sans exécuter une seule ligne de PHP.
Sur le site de Clara, la règle est simple : pour les contenus éditoriaux anciens, la redirection passe côté serveur, car elle suit des motifs d’URL systématiques. Pour les cas métier (utilisateur banni, abonnement expiré, validation de commande), le redirect reste dans PHP, car il dépend de la logique applicative. Cette séparation évite de transformer le code en fourre-tout et réduit les risques d’effets de bord en cas de changement d’infrastructure.
Checklist rapide pour des redirections PHP propres en production
Pour terminer ce tour d’horizon sans perdre la dimension opérationnelle, voici une courte liste de points que Clara s’est imposés sur ses projets :
- Centraliser les redirections dans une ou deux fonctions utilitaires plutôt que d’éparpiller du header(« Location: … »).
- Vérifier systématiquement la présence de exit() ou die() juste après une redirection côté PHP.
- Contrôler les codes HTTP avec un curl ou un outil de debug réseau, surtout après une refonte d’URL.
- Sortir les redirections purement structurelles dans la configuration du serveur ou du reverse proxy.
- Documenter les choix de codes (301, 302, 307) pour éviter les modifications au hasard en phase de maintenance.
Ce genre de discipline, appliquée dès les premiers sprints, évite le grand ménage forcé quand le site aura pris de l’ampleur et que chaque URL commencera à peser dans l’équilibre global du projet.
Comment faire une redirection 301 propre en PHP avec header Location ?
Pour une redirection 301 propre en PHP, il faut envoyer l’en-tête Location avant tout contenu HTML et préciser le code 301 dans l’appel à header. Un exemple minimal est : . Le exit() coupe le script et évite que du code inutile ou sensible ne soit exécuté après la redirection.
Pourquoi ma redirection URL en PHP ne fonctionne pas toujours ?
Dans la majorité des cas, une redirection PHP qui ne fonctionne pas est due à un contenu déjà envoyé au navigateur avant l’appel à header. Un espace, un BOM ou un var_dump peuvent suffire à bloquer l’envoi d’en-têtes supplémentaires. Vérifiez aussi que headers_sent() retourne false, que votre script ne lance pas d’erreur fatale avant le header Location, et que le navigateur ou un proxy intermédiaire ne met pas en cache une ancienne réponse.
Quand utiliser une redirection PHP plutôt qu’un .htaccess ou un reverse proxy ?
Une redirection PHP a du sens quand la décision dépend de la logique métier : rôle utilisateur, état d’une commande, abonnement expiré, langue détectée, etc. Pour des changements de structure d’URL, des migrations massives ou des règles purement syntaxiques, un .htaccess ou la configuration du reverse proxy sont plus adaptés. Cela évite de charger PHP inutilement et facilite la maintenance des règles globales.
Faut-il préférer exit ou die après une redirection en PHP ?
Dans la plupart des projets, exit et die offrent le même résultat perçu côté utilisateur : le script s’arrête après la redirection. Die ferme la connexion alors qu’exit peut la laisser ouverte en mode persistant. Pour un site classique, cette différence reste marginale. L’essentiel est de choisir une des deux fonctions et de l’appliquer systématiquement après chaque header(‘Location: …’) pour garantir que le script ne continue pas à s’exécuter en arrière-plan.
Comment tester facilement mes redirections PHP et leurs codes HTTP ?
Pour tester vos redirections PHP, utilisez des outils en ligne de commande comme curl avec l’option -I pour n’afficher que les en-têtes. Par exemple : curl -I https://votre-site/ex-url.php. Vous verrez le code HTTP renvoyé et la valeur du champ Location. Des extensions de navigateur et les outils de développement intégrés (onglet Réseau) permettent aussi de vérifier le comportement, en particulier si un proxy ou un CDN intervient dans la chaîne.
