Os redirecionamentos 301 são armazenáveis em cache. Isso significa que, uma vez que um usuário acertar esse 301, na próxima vez que ele solicitar a URL original, o navegador irá automaticamente para o alvo de redirecionamento sem fazer uma solicitação ao servidor.
Mesmo se o cache do navegador estiver desmarcado, qualquer proxy transparente ao longo do caminho também pode armazenar em cache a resposta 301.
302 respostas não são armazenadas em cache.
Existem outras respostas 3xx que indicam que o recurso deve ser recuperado de uma URL diferente, mas não estou familiarizado o suficiente com realmente usá-las para saber como os navegadores e proxies as tratam. Se você optar por usar um desses, teste antes de implantar.
Na verdade, a RFC pode ser , então instrutivo.
Da seção em 301s:
Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise.
Isso significa que os favoritos e URLs de feeds RSS podem ser alterados em navegadores e leitores de feeds RSS. Alguns clientes fazem isso e outros não. Você poderia enviar um cabeçalho de cache com o 301 que explicitamente disse aos clientes para não fazer o cache, mas isso não afetaria o comportamento acima.
303 e 307 respostas foram criadas especificamente em resposta a clientes que implementam o redirecionamento 302 incorretamente. O método de solicitação deve permanecer o mesmo na solicitação subsequente, no entanto, muito poucos clientes realmente fazem isso e, em vez disso, sempre mudam para uma solicitação GET.
A resposta 303 diz ao cliente que eles devem usar uma solicitação GET no próximo salto. Uma solicitação 303 não pode ser armazenada em cache.
A resposta 307 diz ao cliente que eles devem continuar usando o mesmo método de solicitação para o próximo salto. Uma resposta 307 só pode ser armazenada em cache somente se for explicitamente informada de que está com um dos cabeçalhos de armazenamento em cache.
Tanto o 303 quanto o 307 normalmente não são compreendidos por clientes pré-HTTP / 1.1. Isso também pode ser verdade para clientes mais novos, onde o desenvolvedor não implementou toda a especificação. Isso provavelmente é apenas uma preocupação se você souber que tem muitos clientes antigos.
Quanto às suas preocupações sobre SEO, o motivo pelo qual blog.foo.com não está obtendo a classificação mais alta é que você está indicando que foo.com é a URL correta e que é apenas temporariamente em% código%. Portanto, todos os links que apontam para blog.foo.com devem aumentar a classificação de foo.com e não foo.com . O tráfego de pesquisa será enviado para blog.foo.com e redirecionado para foo.com , em vez de o tráfego ser enviado diretamente para blog.foo.com .
Quando você remover o redirecionamento, blog.foo.com já terá uma classificação alta e nenhum tráfego será enviado para foo.com . Espero que isso seja o que você deseja que aconteça.
O que você deve fazer?
Eu usaria o redirecionamento 303, a menos que eu tivesse formulários no site que aceitassem solicitações POST. Para aqueles eu usaria 307s o que faria com que o POST fosse feito novamente no site temporário.
Eu também alteraria a resposta 303 para um redirecionado 302 para qualquer solicitação, indicando que era blog.foo.com e não HTTP/1.0 .
Se você optar por usar os 301s, provavelmente ainda verá o tráfego atingindo HTTP/1.1 por algum tempo após remover o redirecionamento. A classificação de blog.foo.com pode permanecer por algum tempo também.