Une redirection PHP envoie le navigateur vers une autre adresse grâce à un en-tête HTTP généré par le serveur. Elle sert après la validation d'un formulaire, lors d'un changement d'URL ou pour réserver l'accès à certaines pages. Le code tient en quelques lignes ; le choix du statut HTTP, et la façon de sécuriser la destination, demandent davantage d'attention.
Comment faire une redirection en PHP avec header() ?
Placez la fonction header() avant tout contenu HTML, tout echo et même tout espace envoyé au navigateur. Indiquez l'adresse cible dans l'en-tête Location, précisez le code HTTP voulu, puis arrêtez le script avec exit. Sans code explicite, PHP renvoie normalement une redirection temporaire 302.
La syntaxe d'une redirection permanente
<?php
header('Location: https://www.example.com/nouvelle-page', true, 301);
exit;
?>Cette redirection 301 convient lorsqu'une ancienne URL est remplacée définitivement. Pour un déplacement provisoire, remplacez 301 par 302. L'instruction exit évite que le reste du fichier continue à s'exécuter après l'envoi de la réponse.
Rediriger selon une condition
La redirection n'est pas toujours fixe. Elle peut dépendre d'un état de session, d'un rôle ou d'un paramètre métier. Le principe reste le même : la condition se teste avant tout affichage, et le header() suit immédiatement le résultat.
<?php
session_start();
if (!isset($_SESSION['user_id'])) {
header('Location: https://www.example.com/connexion', true, 302);
exit;
}
?>Ce type de redirection protège une page réservée aux utilisateurs connectés. La condition doit rester simple et vérifiable : un test imbriqué dans plusieurs fonctions différentes est souvent le premier pas vers une boucle involontaire, un point traité plus loin dans cet article.
Quel code HTTP choisir pour une redirection PHP ?
Utilisez 301 ou 308 pour un déplacement permanent, 302 ou 307 pour une situation temporaire et 303 après le traitement d'un formulaire lorsque la page suivante doit être chargée en GET. Les codes 307 et 308 conservent la méthode HTTP et le corps de la requête, contrairement aux comportements historiques possibles avec 302 et 301.
| Code | Nature | Usage courant |
|---|---|---|
| 301 | Permanente | Nouvelle URL définitive d'une page |
| 302 | Temporaire | Maintenance, test ou déplacement provisoire |
| 303 | Temporaire | Redirection après un POST vers une page chargée en GET |
| 307 | Temporaire | Conservation de la méthode et du corps de la requête |
| 308 | Permanente | Déplacement définitif sans changement de méthode |
Le bon code décrit la réalité du déplacement. Employer systématiquement une 301 serait une erreur, notamment pour une page de test ou une indisponibilité limitée dans le temps.
Traiter un formulaire POST avec le code 303
Après l'envoi réussi d'un formulaire, recharger la page en POST expose à un problème classique : un rafraîchissement du navigateur renvoie le même formulaire une seconde fois. Le rôle du code 303 See Other est justement de forcer le navigateur à recharger la page suivante en GET, quelle que soit la méthode d'origine.
<?php
// Traitement du formulaire (validation, enregistrement en base...)
if ($formulaire_valide) {
header('Location: https://www.example.com/merci', true, 303);
exit;
}
?>Ce schéma, connu sous le nom de Post/Redirect/Get, évite les doublons d'enregistrement et le message d'avertissement du navigateur du type « Confirmer la soumission du formulaire ». À l'époque de l'agence, un client industriel avait un formulaire de devis qui créait deux lignes en base à chaque rafraîchissement accidentel de la page de confirmation : le correctif tenait en un seul changement de code HTTP, de 302 à 303.
PHP, .htaccess ou configuration du serveur ?
PHP convient aux redirections liées à la logique de l'application, par exemple après une authentification ou un formulaire. Pour déplacer des dizaines d'URL pendant une refonte, une règle centralisée dans le serveur, le CMS ou le fichier .htaccess d'Apache est souvent plus facile à maintenir. Les redirections JavaScript et meta refresh restent des solutions de repli lorsque la redirection côté serveur n'est pas accessible.
Pourquoi une redirection PHP ne fonctionne-t-elle pas ?
L'erreur la plus fréquente est le message Headers already sent. Il signifie qu'un contenu a déjà été transmis avant l'appel à header(). La cause peut être une balise HTML, un affichage PHP, une ligne vide dans un fichier inclus ou un caractère placé avant l'ouverture <?php.
Comment repérer l'origine de l'erreur ?
Le message indique normalement le fichier et la ligne où la sortie a commencé. La fonction headers_sent($fichier, $ligne) peut aussi aider au diagnostic. La mise en mémoire tampon de sortie peut masquer le problème, mais elle ne remplace pas une organisation propre du script : le traitement et les redirections doivent précéder l'affichage.
Un cas particulier mérite d'être signalé : le BOM (byte order mark), une poignée d'octets invisibles que certains éditeurs de texte ajoutent au tout début d'un fichier enregistré en UTF-8. Ce BOM constitue une sortie avant même la balise d'ouverture <?php, ce qui déclenche l'erreur alors que le code semble irréprochable à l'œil nu. La plupart des éditeurs modernes proposent une option « UTF-8 sans BOM » dans les réglages d'enregistrement ; c'est celle à retenir pour tous les fichiers PHP d'un même projet, y compris ceux inclus par require ou include.
Comment éviter une boucle de redirection ?
Une boucle survient quand une page redirige vers une autre qui, directement ou après plusieurs sauts, renvoie vers la page de départ. Le navigateur affiche alors une erreur du type ERR_TOO_MANY_REDIRECTS, et les robots d'indexation abandonnent la page au bout de quelques tentatives.
Le cas le plus fréquent touche les redirections conditionnelles : une condition mal écrite (rôle non reconnu, session expirée mal gérée, protocole http et https confondu) peut renvoyer un utilisateur vers une page qui le redirige à son tour vers la page initiale. Le test le plus fiable reste d'observer la chaîne réelle des réponses HTTP, par exemple avec curl -I -L https://www.example.com/page ou l'onglet réseau du navigateur, plutôt que de relire le code seul.
Sur une migration de grande ampleur, un tableau de correspondance URL par URL, tenu à jour au fur et à mesure, évite la plupart des boucles : elles apparaissent presque toujours quand deux règles se chevauchent sans que personne ne l'ait remarqué.
Comment sécuriser une redirection quand l'URL vient de l'utilisateur ?
Certaines pages redirigent vers une adresse transmise en paramètre, par exemple pour ramener l'utilisateur à l'endroit exact où il se trouvait avant de se connecter. Si cette adresse n'est pas contrôlée, n'importe qui peut construire un lien qui part bien du domaine de confiance mais qui termine sa course sur un site frauduleux. Cette faille porte un nom : la redirection ouverte, documentée par l'OWASP, l'organisation de référence en sécurité des applications web.
<?php
$destinations_autorisees = [
'/compte',
'/panier',
'/commande/confirmation',
];
$cible = $_GET['redirect'] ?? '/compte';
if (!in_array($cible, $destinations_autorisees, true)) {
$cible = '/compte';
}
header('Location: https://www.example.com' . $cible, true, 302);
exit;
?>Le principe est celui de la liste blanche : on compare la valeur reçue à un ensemble de destinations connues et autorisées, jamais l'inverse. Concaténer directement une adresse complète fournie par l'utilisateur dans le header(), ou se contenter de vérifier qu'elle « commence par » le bon domaine, laisse la porte ouverte à des contournements bien documentés. Pour un formulaire de connexion ou une API exposée à l'extérieur, cette vérification revient à un développeur ou à un prestataire qui suit les recommandations de sécurité à jour ; ce n'est pas un réglage à improviser en fin de projet.
Quel est l'impact d'une redirection PHP sur le SEO ?
Une redirection permanente 301 ou 308 indique à Google que la nouvelle URL doit remplacer l'ancienne, comme le précise la documentation de Google Search Central sur les redirections, qui recommande un redirect serveur permanent chaque fois qu'une page change d'adresse de façon définitive. Une redirection temporaire 302, 303 ou 307 laisse plutôt l'URL source comme candidate à l'indexation. Le choix du code a donc un impact réel sur l'indexation, mais la qualité du mapping entre les pages compte tout autant. Pour la syntaxe exacte de header() côté PHP, le manuel officiel du langage reste la référence à consulter en cas de doute.
Éviter les chaînes et les destinations approximatives
Chaque ancienne URL doit pointer directement vers la page qui reprend réellement son contenu. Une chaîne du type A vers B, puis B vers C, ralentit le parcours des robots et complique la maintenance, avec le même risque de boucle évoqué plus haut si une règle finit par se refermer sur elle-même. Rediriger toutes les pages supprimées vers l'accueil est également une mauvaise pratique lorsque cette destination ne répond pas à la demande initiale.
Avant de déployer une migration, testez le code HTTP renvoyé, l'URL finale et l'absence de boucle. Pour quelques cas conditionnels, PHP fait le travail. Pour une refonte complète, ou pour une redirection dont la destination dépend d'une URL fournie par l'utilisateur, faites relire le plan de redirection par la personne qui gère le serveur, la sécurité ou le référencement du site.
