Les redirections 301 peuvent être mises en cache. Cela signifie qu'une fois que l'utilisateur a cliqué sur la redirection 301, la prochaine fois qu'il demandera l'URL d'origine, le navigateur ira automatiquement à la cible de la redirection sans faire de demande au serveur.
Même si le cache du navigateur est effacé, les proxys transparents qui se trouvent sur le chemin peuvent également mettre en cache la réponse 301.
Les réponses 302 ne sont pas mises en cache.
Il existe d'autres réponses 3xx qui indiquent que la ressource doit être récupérée à partir d'une URL différente, mais je ne suis pas suffisamment familiarisé avec les réponses 3xx. les utiliser réellement pour savoir comment les navigateurs et les serveurs mandataires les traitent. Si vous choisissez d'utiliser l'un d'entre eux, testez-le avant de le déployer.
Lecture en cours le RFC peut être donc instructif.
Extrait de la section sur les 301 :
Les clients dotés de fonctions d'édition de liens devraient rétablir automatiquement les liens les références à l'URL de la demande à une ou plusieurs des nouvelles références renvoyées par le serveur, lorsque cela est possible. Cette réponse peut être mise en cache sauf indication contraire.
Cela signifie que les signets et les URL des flux RSS peuvent être modifiés dans les navigateurs et les lecteurs de flux RSS. Certains clients le font, d'autres non. Vous pourrait envoyer un en-tête de cache avec la page 301 qui indique explicitement aux clients de ne pas la mettre en cache, mais cela n'aurait pas d'incidence sur le comportement décrit ci-dessus.
Les réponses 303 et 307 ont été créées spécifiquement en réponse aux clients qui mettent en œuvre la redirection 302 de manière incorrecte. La méthode de requête est censée rester la même lors de la requête suivante, mais très peu de clients le font et passent toujours à une requête GET.
La réponse 303 indique au client qu'il doit utiliser une requête GET au prochain saut. Une requête 303 ne peut pas être mise en cache.
La réponse 307 indique au client qu'il doit continuer à utiliser la même méthode de requête pour le prochain saut. Une réponse 307 ne peut être mise en cache que si l'un des en-têtes de mise en cache l'indique explicitement.
Les adresses 303 et 307 ne sont normalement pas comprises par les clients pré-HTTP/1.1. Cela pourrait également être le cas des clients plus récents pour lesquels le développeur n'a pas mis en œuvre l'intégralité de la spécification. Ce problème ne se pose probablement que si vous savez que vous avez beaucoup de clients très anciens.
Pour ce qui est de vos préoccupations concernant l'optimisation des moteurs de recherche, la raison en est que blog.foo.com n'est pas mieux classée, c'est que vous indiquez qu'elle n'est pas bien classée. foo.com est l'URL correcte et qu'il s'agit seulement de temporairement sur blog.foo.com . Par conséquent, tous les liens pointant vers foo.com devrait améliorer le classement de foo.com y no blog.foo.com . Le trafic de recherche sera ensuite envoyé à foo.com et redirigé vers blog.foo.com au lieu d'envoyer le trafic directement à blog.foo.com .
Lorsque vous supprimer la réorientation, foo.com aura déjà un classement élevé et aucun trafic ne sera envoyé à blog.foo.com . Je suppose que c'est ce que vous vouloir à se produire.
Que faire ?
J'opterais pour la redirection 303, sauf si le site comporte des formulaires acceptant les requêtes POST. Dans ce cas, j'utiliserais des redirections 307, ce qui aurait pour effet de relancer le POST sur le site temporaire.
Je remplacerais également la réponse 303 par une redirection 302 pour toute demande indiquant qu'il s'agit de HTTP/1.0 y no HTTP/1.1 .
Si vous décidez d'opter pour les 301, il est fort probable que vous continuiez à voir le trafic augmenter. blog.foo.com pendant un certain temps après la suppression de la redirection. Le classement de blog.foo.com peut également perdurer pendant un certain temps.
