Codes HTTP 300 : comprendre et utiliser toutes les redirections 3xx

Les codes HTTP 300 à 308 indiquent qu’une ressource doit être choisie, retrouvée ailleurs ou validée sans être renvoyée intégralement. Pour déplacer définitivement une page Web, utilisez généralement une redirection 301 ou 308 vers l’URL équivalente.

Pour un déplacement temporaire, choisissez 302 ou 307. La différence essentielle tient à la méthode HTTP : 307 et 308 demandent au client de conserver la méthode et le corps de la requête, tandis que la pratique autorise 301 et 302 à transformer un POST en GET. Le code 303 sert précisément à consulter en GET une autre ressource après une opération. Le 304, lui, n’est pas une redirection vers une nouvelle URL : il valide une copie en cache.

Chaque réponse de redirection doit être testée avec son en-tête Location, sa méthode, ses règles de cache et son URL finale. Pour le SEO, une redirection permanente côté serveur vers une page réellement équivalente est généralement le meilleur signal lors d’une migration. Elle ne corrige cependant ni une boucle, ni une chaîne excessive, ni une destination sans rapport.

Que signifie un code de statut HTTP de la série 300 ?

La classe 3xx regroupe les réponses HTTP liées à la redirection et à certains mécanismes de cache. Selon la RFC 9110, le premier chiffre du statut définit sa classe ; les deux suivants n’ont pas de sous-catégorie automatique. Il faut donc lire la définition de chaque code au lieu de supposer que tous les 3xx « redirigent » de la même façon.

Une redirection classique associe un statut à l’en-tête Location, par exemple :

HTTP
HTTP/1.1 301 Moved Permanently
Location: https://example.com/nouvelle-page

Le client peut alors effectuer une nouvelle requête vers l’URI indiquée. Cette seconde requête explique pourquoi une redirection ajoute un aller-retour réseau. Le choix du code précise si le déplacement est permanent, si la méthode doit être conservée et si la réponse peut être mise en cache.

Une URL relative peut être résolue par rapport à l’URI de la requête, mais une URL absolue réduit les ambiguïtés lors de migrations entre domaines.

Le code 304 est un cas à part. Il répond à une requête conditionnelle et signifie que la représentation mise en cache reste valide. Il n’a pas vocation à contenir un nouveau Location ni à envoyer le contenu complet. Confondre 304 et redirection mène à de mauvais diagnostics dans les outils réseau.

Tableau comparatif des codes HTTP 300 à 308

Le registre IANA fournit les noms et références officielles. Les comportements normatifs détaillés viennent de la RFC 9110.

Code 300 Multiple Choices : plusieurs représentations possibles

Le statut 300 indique que la requête possède plusieurs réponses possibles et que l’utilisateur ou l’agent doit en choisir une. Le serveur peut fournir des métadonnées ou des liens vers les variantes. Il peut aussi mettre une préférence dans Location lorsqu’un choix privilégié existe.

La RFC ne définit pas un format universel de sélection automatique, ce qui limite l’emploi pratique du 300 sur le Web grand public.

Un cas théorique serait une ressource disponible en plusieurs langues ou formats sans négociation concluante. Dans la pratique, la négociation de contenu, une page de sélection explicite ou une logique applicative répondent souvent mieux au besoin.

Pour le SEO, laisser plusieurs URL concurrentes sans canonique ni stratégie de langue peut diluer les signaux. Le 300 ne remplace pas hreflang, les URL stables ou un sélecteur accessible.

Comme 300 est cacheable par défaut, une implémentation doit considérer la variation de la réponse. Une mauvaise clé de cache peut présenter le choix d’un utilisateur à un autre. Testez les en-têtes Vary, la négociation et le comportement du CDN avant d’utiliser ce statut.

Code 301 Moved Permanently : déplacer définitivement une URL

Le 301 signifie que la ressource cible a reçu une nouvelle URI permanente et que les références devraient utiliser la nouvelle adresse. Il convient aux changements de slug, aux fusions de pages, au passage d’un ancien domaine vers un nouveau et aux migrations HTTPS durables. La cible doit être l’équivalent le plus proche, pas la page d’accueil par défaut.

La réponse contient normalement Location. Pour une correspondance exacte avec Apache mod_alias, préférez RedirectMatch. Une directive Redirect simple fonctionne par préfixe et peut ajouter le suffixe de chemin restant à la cible, ce qui n’est pas toujours souhaité :

APACHE
RedirectMatch 301 ^/ancien-guide$ https://example.com/nouveau-guide

Exemple Nginx :

NGINX
location = /ancien-guide {
    return 301 https://example.com/nouveau-guide;
}

Le 301 est cacheable par défaut. Pendant un test de migration, un navigateur peut donc conserver une ancienne cible ; utilisez curl, une fenêtre privée et un profil propre avant de conclure que la règle actuelle est ignorée. Côté méthode, la RFC permet au client de transformer un POST en GET. Si le corps doit impérativement être rejoué tel quel, le 308 est plus explicite.

Google recommande les redirections permanentes côté serveur lorsqu’une URL change définitivement. Le transfert des signaux et le remplacement dans l’index prennent du temps. Conservez les redirections suffisamment longtemps, mettez à jour les liens internes, le sitemap et les canoniques, puis surveillez les URL dans Search Console.

Code 302 Found : créer une redirection temporaire

Le 302 indique que la ressource réside temporairement sous une autre URI. Le client continue donc, en principe, à utiliser l’ancienne URL pour les requêtes futures. Ce statut correspond à une campagne temporaire, une page indisponible pendant une courte maintenance ou un test où l’URL d’origine doit rester la référence.

La pratique historique des navigateurs autorise un POST à devenir un GET lors du suivi d’un 302. Si cette transformation est souhaitée après un formulaire, 303 l’exprime plus clairement. Si elle ne l’est pas, 307 protège la méthode et le corps.

En SEO, Google distingue les redirections temporaires et permanentes comme des signaux différents, tout en évaluant le comportement sur la durée. Un 302 laissé pendant des mois peut créer une situation difficile à interpréter.

Ne l’utilisez pas pour « conserver le jus » d’une ancienne page définitivement supprimée. Choisissez le statut qui décrit honnêtement la durée du changement.

Code 303 See Other : rediriger une requête vers une lecture en GET

Le 303 indique que le serveur ne renvoie pas la représentation de la ressource demandée, mais invite le client à consulter une autre URI. Pour une requête autre que HEAD, le client effectue une requête GET vers la cible. C’est le code naturel du modèle POST/Redirect/GET.

Après la création d’une commande, le serveur peut répondre :

HTTP
HTTP/1.1 303 See Other
Location: /commandes/847/confirmation

Le navigateur charge alors la page de confirmation en GET. Un rafraîchissement ne renvoie pas le formulaire POST initial, ce qui réduit le risque de double soumission. La destination doit présenter le résultat ou son état, sans réexécuter silencieusement l’opération.

Le 303 convient aussi lorsqu’une API souhaite pointer vers une ressource descriptive différente. Il ne signifie pas que l’URI d’origine a déménagé définitivement et ne doit pas être traité comme un 301 SEO.

Code 304 Not Modified : valider le cache sans renvoyer le contenu

Le 304 répond à une requête conditionnelle GET ou HEAD lorsque la ressource n’a pas été modifiée selon les validateurs reçus, par exemple If-None-Match avec un ETag ou If-Modified-Since avec Last-Modified. Le client réutilise alors sa représentation enregistrée, ce qui économise la bande passante.

ETag identifie une version selon la logique du serveur ; Last-Modified repose sur une date. Si les deux sont mal générés ou divergent entre nœuds, les clients peuvent retélécharger inutilement le contenu ou conserver une version inattendue.

Exemple :

HTTP
GET /style.css HTTP/1.1
If-None-Match: "abc123"

HTTP/1.1 304 Not Modified
ETag: "abc123"

Une réponse 304 ne contient pas le corps complet de la représentation. Certains en-têtes de cache doivent néanmoins être cohérents avec ceux qui auraient accompagné un 200. Si un utilisateur voit un ancien fichier, contrôlez d’abord le bon niveau : navigateur, CDN, reverse proxy ou plugin. Le guide CritiquePlus sur la mise en cache d’un site Web détaille ces couches.

Le 304 n’annonce aucun changement d’URL. Il n’a donc pas l’impact SEO d’une redirection permanente et ne doit pas figurer dans un tableau de migration comme destination.

Codes 305 et 306 : pourquoi ils ne doivent plus être utilisés

Le 305 portait le nom Use Proxy. La RFC 9110 le marque comme déprécié en raison de préoccupations de sécurité liées à la configuration en bande d’un proxy. Un serveur moderne ne doit pas l’utiliser pour forcer un client à passer par un intermédiaire. Les politiques de proxy se gèrent au niveau du réseau, du client ou d’une passerelle contrôlée.

Le 306 est enregistré par l’IANA comme Unused. Il avait été réservé dans une version antérieure de HTTP et n’a pas de sémantique active. L’émettre avec une signification inventée créerait un comportement imprévisible chez les clients, caches et robots.

Lorsqu’un journal affiche 305 ou 306, vérifiez s’il provient réellement du serveur HTTP, d’un équipement propriétaire, d’un test ou d’une mauvaise lecture. Ne remplacez pas ces codes au hasard : identifiez l’objectif, puis utilisez un statut enregistré approprié.

Code 307 Temporary Redirect : conserver la méthode HTTP

Le 307 décrit un déplacement temporaire tout en interdisant au client de changer la méthode lors du suivi automatique. Un POST reste un POST, un PUT reste un PUT et le corps est renvoyé à la cible. Cette propriété est utile pour une API, un point d’entrée temporairement déplacé ou une bascule où la sémantique de la requête doit rester intacte.

HTTP
HTTP/1.1 307 Temporary Redirect
Location: https://api.example.com/v2/import

Le serveur cible doit être prêt à recevoir la même méthode, le même type de contenu et les mêmes mécanismes d’authentification. Rediriger un POST contenant des données sensibles vers un autre domaine exige une revue de sécurité. N’exposez pas un jeton ou un corps à une origine qui ne devrait pas les recevoir.

Le 307 n’est pas cacheable par défaut, sauf indication explicite autorisant le cache. Pour un déplacement définitif avec la même garantie de méthode, utilisez 308.

Code 308 Permanent Redirect : redirection définitive sans changer la méthode

Le 308 annonce une nouvelle URI permanente et demande au client de conserver la méthode et le corps. Il combine donc la permanence du 301 avec la garantie de méthode du 307. Il convient à la migration durable d’une route API ou d’un endpoint recevant des requêtes autres que GET.

NGINX
location = /api/v1/envoi {
    return 308 https://api.example.com/v2/envoi;
}

Comme 308 est cacheable par défaut, corrigez la cible avant la mise en production et testez avec des clients représentatifs. Tous les outils modernes comprennent généralement 308, mais un environnement ancien ou propriétaire mérite une validation. Pour une simple page Web consultée en GET, 301 reste largement compris et suffisant.

Google Search Central considère 301 et 308 comme des redirections permanentes. Le choix SEO dépend moins du numéro entre ces deux codes que de la stabilité, de la pertinence de la cible, de l’absence de chaîne et de la cohérence des autres signaux.

301, 302, 303, 307 ou 308 : quel code choisir selon le scénario ?

Commencez par deux questions : le changement est-il permanent et la méthode doit-elle être conservée ? Pour une page définitivement déplacée et essentiellement consultée en GET, choisissez 301. Pour une route API permanente qui doit recevoir le même POST ou PUT, choisissez 308. Pour un déplacement temporaire où un éventuel passage en GET est acceptable, 302 convient. Si la méthode doit rester intacte, prenez 307.

Après un formulaire, 303 est souvent le meilleur choix lorsque l’opération est terminée et que le navigateur doit afficher une page de résultat en GET. Il évite de présenter une redirection temporaire comme si le POST devait être rejoué.

Ne choisissez pas le code selon une recette SEO isolée. Décrivez le comportement réel du système. Testez la méthode reçue par la cible, les cookies, l’authentification et les caches. Les clients intégrés et applications mobiles doivent également être testés avec leur vraie bibliothèque HTTP.

Quel impact les redirections 3xx ont-elles sur le SEO ?

Une redirection permanente côté serveur aide Google à comprendre qu’une ancienne URL a été remplacée. Google recommande 301 ou 308 pour un déplacement permanent et 302 ou 307 pour un changement temporaire. Une balise canonical n’est pas une redirection : elle suggère une URL représentative tout en laissant la page accessible.

Les redirections JavaScript ou meta refresh peuvent être comprises par Google, mais elles sont moins directes et dépendent du rendu ou d’un délai ; utilisez d’abord une réponse HTTP serveur quand vous contrôlez l’hébergement.

La destination doit être pertinente. Rediriger des centaines de pages sans équivalent vers l’accueil peut être traité comme une erreur logique ou un soft 404. Conservez la relation sujet à sujet, mettez à jour les liens internes, rel=canonical, les sitemaps, les balises de langue et les données structurées. Évitez de laisser l’ancienne URL dans les menus après la migration.

Une chaîne A → B → C gaspille du crawl et ralentit l’utilisateur. Redirigez A directement vers C. Une boucle A → B → A bloque l’accès. Google peut suivre plusieurs sauts, mais sa documentation recommande une destination finale directe et limite le nombre de redirections suivies. L’objectif opérationnel doit rester un seul saut.

La surveillance ne s’arrête pas à la mise en ligne. Vérifiez les pages indexées, les inspections d’URL et les logs. Lors d’un passage durable vers HTTPS, contrôlez aussi la cohérence décrite dans le guide HTTP ou HTTPS.

Configurer une redirection sur Apache, Nginx et WordPress

Sur Apache, RedirectMatch de mod_alias convient aux redirections simples et exactes. Une directive Redirect classique compare un préfixe et peut reporter le suffixe restant vers la cible ; employez-la seulement si ce comportement est voulu. Placez les règles spécifiques avant les règles générales. Pour des conditions complexes, mod_rewrite offre davantage de contrôle, mais une expression imprécise peut créer une boucle.

APACHE
RedirectMatch 301 ^/ancien-dossier/guide$ https://example.com/nouveau-guide

Avec mod_rewrite, conservez la chaîne de requête seulement si elle reste utile et échappez correctement les valeurs. Testez la configuration avant le rechargement du serveur.

Dans un fichier .htaccess, le préfixe de répertoire et le slash initial sont retirés avant la comparaison. Une règle exacte s’écrit donc sans slash initial :

APACHE
RewriteEngine On
RewriteRule ^ancien-guide$ /nouveau-guide [R=301,L]

Dans un contexte serveur ou VirtualHost, le chemin testé commence par un slash :

APACHE
RewriteEngine On
RewriteRule ^/ancien-guide$ https://example.com/nouveau-guide [R=301,L]

Sur Nginx, return est clair pour une redirection directe :

NGINX
server {
    server_name ancien.example.com;
    return 301 https://example.com$request_uri;
}

Validez avec nginx -t avant le rechargement. Attention à $request_uri, qui conserve le chemin et la query string : ne l’utilisez pas si la nouvelle architecture exige une correspondance contrôlée.

Sur WordPress, une extension de redirection ou le serveur peuvent gérer les règles. Pour une logique métier réellement nécessaire dans un plugin ou mu-plugin, construisez une URL interne avec home_url(), utilisez wp_safe_redirect() et terminez l’exécution :

PHP
add_action( 'template_redirect', function () {
    if ( is_page( 'ancien-guide' ) ) {
        wp_safe_redirect( home_url( '/nouveau-guide/' ), 301 );
        exit;
    }
} );

wp_safe_redirect() valide que l’hôte est autorisé et revient vers une URL sûre si nécessaire. Ne produisez pas de sortie avant les en-têtes. Évitez de définir la même règle dans le CDN, l’hébergeur, .htaccess, WordPress et une extension.

Purgez les caches WordPress, serveur et CDN après une modification ciblée. Une seule source de vérité facilite le diagnostic. Sauvegardez la configuration, exportez la table des correspondances et testez en staging. Pour le contexte d’extension, consultez aussi le guide sur l’installation et le rôle d’un plugin WordPress.

Tester un code 3xx avec curl, le navigateur et Search Console

curl permet de voir la première réponse sans suivre la redirection. Avec -I, curl envoie une requête HEAD : c’est rapide, mais une application peut répondre différemment à HEAD et GET. Comparez donc aussi une vraie requête GET sans télécharger inutilement un gros corps, par exemple avec -o /dev/null -D – :

BASH
curl -I https://example.com/ancienne-url
curl -o /dev/null -D - https://example.com/ancienne-url

Contrôlez le statut, Location, Cache-Control, Expires, Vary et la présence éventuelle de cookies. Pour suivre toute la chaîne :

BASH
curl -I -L --max-redirs 10 https://example.com/ancienne-url
curl -L -o /dev/null -sS \
  -w 'final=%{url_effective} code=%{http_code} redirects=%{num_redirects}\n' \
  https://example.com/ancienne-url

Pour vérifier un POST sans envoyer de données réelles, utilisez un environnement de test et une charge fictive. Affichez les détails avec -v et comparez la méthode sur chaque saut.

Évitez d’ajouter machinalement -X POST avec -L : forcer explicitement la méthode peut la conserver sur des sauts où curl aurait normalement appliqué la sémantique du statut, et provoquer des requêtes inattendues. Utilisez –data dans un bac à sable, lisez la trace et ne lancez aucun test pouvant créer une commande ou déclencher un paiement.

Dans les DevTools du navigateur, ouvrez Réseau, activez la conservation du journal, rechargez la page et examinez la colonne Statut. La vue montre les redirections internes, le cache et la destination. Si une extension bloque la requête, essayez un profil propre ; le guide ERR_BLOCKED_BY_CLIENT explique ce scénario.

Dans Search Console, inspectez l’ancienne et la nouvelle URL. Vérifiez la page canonique sélectionnée, l’indexation et les sitemaps. L’outil d’inspection n’est pas un moniteur temps réel de toutes les redirections ; complétez-le avec les logs serveur et un crawl contrôlé.

Tableau de diagnostic des erreurs de redirection

Pour un service qui exige une authentification, vérifiez aussi la session, les cookies, le domaine et le protocole. Un changement d’hôte peut empêcher l’envoi d’un cookie sans que la redirection elle-même soit invalide.

Éviter les chaînes, boucles et redirections vers des pages non pertinentes

Inventoriez toutes les règles avant une migration. Pour chaque ancienne URL, notez la cible finale, le statut et la justification. Réduisez A → B → C en A → C. Supprimez les règles historiques qui se chevauchent, mais conservez celles encore utilisées par des backlinks ou des favoris.

Les boucles naissent souvent de couches qui ne partagent pas la même information : le CDN force HTTPS, le reverse proxy termine TLS, le serveur croit recevoir HTTP, WordPress réécrit vers son URL configurée et un plugin impose www.

Définissez quelle couche normalise le protocole, l’hôte et le slash final. Transmettez correctement les informations de protocole et d’hôte, puis n’accordez votre confiance qu’aux proxys connus. Testez séparément HTTP/HTTPS, www/sans www, slash final et query string.

Une redirection non pertinente est parfois pire qu’un 404 clair. Si un produit n’existe plus et qu’aucune catégorie ou alternative proche ne répond à l’intention, retourner 404 ou 410 peut être plus honnête. Ne redirigez pas toutes les erreurs vers l’accueil.

Protégez aussi les paramètres de retour tels que redirect, next ou returnUrl. Une redirection ouverte permettrait d’envoyer l’utilisateur vers un domaine malveillant. Validez les destinations côté serveur, privilégiez des chemins relatifs et bloquez les schémas ou hôtes non autorisés.

Ne construisez pas Location à partir d’un en-tête Host non validé : une injection d’hôte peut fabriquer un lien de réinitialisation ou une destination externe crédible. Utilisez une origine configurée ou une liste d’hôtes approuvés.

Cas pratiques : migration, changement de domaine, maintenance et formulaire

Pour une migration de slug, établissez une correspondance un pour un, renvoyez 301 vers la nouvelle page, actualisez les liens internes et soumettez le sitemap final. Sur un changement de domaine, conservez le chemin lorsque la structure reste la même, mais testez les pages clés, les ressources, les langues et les paramètres.

Utilisez l’outil Change of Address de Search Console lorsque la migration répond à ses conditions. Google recommande généralement de conserver les redirections au moins un an ; gardez-les ensuite tant que les anciennes URL reçoivent du trafic, des liens ou des requêtes utiles.

Le guide CritiquePlus sur le fonctionnement d’un nom de domaine et celui sur le DNS aident à préparer la bascule. Ne redirigez pas vers le nouveau domaine avant qu’il soit prêt à répondre.

Pour une maintenance courte, un 302 ou 307 peut envoyer temporairement vers une page d’information. Si des POST doivent continuer vers un autre nœud, 307 conserve la méthode, mais la cible doit accepter la requête. Pour une indisponibilité serveur sans destination fonctionnelle, un statut 503 avec Retry-After décrit mieux la situation qu’une fausse redirection.

Après un formulaire, traitez le POST, enregistrez l’opération une seule fois, puis retournez 303 vers une page de confirmation. Ajoutez une clé d’idempotence pour les opérations sensibles. Ne comptez pas uniquement sur la redirection pour empêcher les doublons.

Pour une API déplacée définitivement, 308 conserve POST, PUT ou PATCH. Prévenez les clients, maintenez une période d’observation, journalisez les appels sur l’ancienne route et documentez toujours le contrat serveur.

Checklist avant et après la mise en ligne d’une redirection

Avant la mise en ligne, confirmez la permanence du changement, le code choisi, la méthode attendue et la cible exacte. Vérifiez que la destination retourne 200 ou la réponse finale prévue, qu’elle correspond au contenu d’origine et qu’elle ne redirige pas à nouveau sans nécessité. Sauvegardez la configuration et testez-la sur un environnement représentatif.

Contrôlez les variantes HTTP/HTTPS, avec et sans www, les majuscules, slashs finaux, paramètres, langues, appareils et user agents. Pour une API, testez GET, HEAD, POST et les méthodes réellement prises en charge avec des données fictives. Pour un site, crawlez un échantillon d’URL et recherchez boucles, chaînes, 404 finales et redirections vers l’accueil.

Après publication, relancez curl, vérifiez les DevTools, les logs, Search Console, le sitemap, les canoniques et les liens internes. Surveillez les erreurs 404 et le trafic de l’ancien domaine. Les rapports et l’inspection Search Console peuvent refléter les changements avec un délai ; une absence immédiate de mise à jour n’est pas une preuve d’échec.

Conservez un plan de retour, mais n’alternez pas fréquemment une redirection permanente : les caches et robots ne suivent pas instantanément vos changements.

Enfin, documentez le propriétaire de chaque règle, sa date, son objectif et sa durée. Une redirection temporaire doit avoir une date de retrait. Une redirection permanente doit rester disponible tant que l’ancienne URL reçoit des requêtes utiles.

FAQ

Tous les codes 3xx redirigent-ils vers une nouvelle URL ? Non. Le 304 valide une réponse en cache et le 300 peut présenter plusieurs choix. Pour comparer avec d’autres familles, consultez les guides des codes HTTP 200, codes HTTP 400 et codes HTTP 500.

Quelle différence entre 301 et 308 ? Les deux sont permanents. Le 308 exige la conservation de la méthode et du corps ; le 301 permet historiquement au client de transformer un POST en GET.

Quelle différence entre 302 et 307 ? Les deux sont temporaires. Le 307 conserve la méthode, tandis que 302 peut entraîner un passage de POST à GET.

Pourquoi utiliser 303 après un formulaire ? Il demande au client de lire la page de résultat en GET, ce qui applique clairement le modèle POST/Redirect/GET.

Une 301 transmet-elle immédiatement tous les signaux SEO ? Non. Google doit explorer, traiter et consolider les signaux. La pertinence de la cible et la cohérence de la migration comptent davantage qu’une promesse de délai.

Combien de redirections peut-on chaîner ? La bonne cible opérationnelle est une seule. Google peut suivre plusieurs sauts, mais les chaînes ralentissent le crawl et l’utilisateur.

Faut-il rediriger une page supprimée vers l’accueil ? Non, sauf si l’accueil répond réellement à la même intention, ce qui est rare. Choisissez un équivalent proche ou retournez 404/410.

Le navigateur et Google suivent-ils toujours `Location` ? Le comportement dépend du statut, de la méthode et du client. Les redirections automatiques ordinaires utilisent Location, mais les règles de sécurité et les limites peuvent interrompre le suivi.

Sources officielles

• RFC Editor — RFC 9110, HTTP Semantics : https://www.rfc-editor.org/rfc/rfc9110.html
• IANA — Hypertext Transfer Protocol Status Code Registry : https://www.iana.org/assignments/http-status-codes
• Google Search Central — Redirects and Google Search : https://developers.google.com/search/docs/crawling-indexing/301-redirects
• Google Search Central — Site moves with URL changes : https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes
• Apache HTTP Server — mod_alias Redirect directive : https://httpd.apache.org/docs/2.4/mod/mod_alias.html#redirect
• Apache HTTP Server — mod_rewrite : https://httpd.apache.org/docs/2.4/rewrite/
• Nginx — ngx_http_rewrite_module : https://nginx.org/en/docs/http/ngx_http_rewrite_module.html
• WordPress Developer Resources — wp_redirect() : https://developer.wordpress.org/reference/functions/wp_redirect/
• WordPress Developer Resources — wp_safe_redirect() : https://developer.wordpress.org/reference/functions/wp_safe_redirect/