Milhares de erros do robots.txt 404 de bots tentando rastrear multisite antigo

Question

A situação atual é que estamos recebendo milhares e milhares de erros 404 de bots procurando por robots.txt em lugares diferentes em nosso site devido a redirecionamentos de domínio.

Nosso antigo site era um multi-site labiríntico desenvolvido pela dotnetnuke com vários nomes de domínio. Nós mudamos para um único site no Wordpress com um nome de domínio. Os nomes de domínio restantes agora apenas redirecionam para categorias no site. Isso fez com que o googlebot, o bingbot e muitos outros tentassem repetidamente indexar os domínios que costumavam ser sites completos e serem redirecionados.

www.EXAMPLE.co.uk redireciona para www.EXAMPLE.co.uk/challenge /

e, portanto, /challenge/robots.txt tem mais de mil 404s

o mesmo com outros redirecionamentos que acabam em /walktoschool/robots.txt etc etc

Existe uma maneira inteligente de redirecionar bots? Ou uma maneira diferente que isso deveria ter sido tratado ou fazer com que os bots parassem? Nosso novo site nem usa o robots.txt, ele usa o htaccess em conjunto com o Better WP Security. Eu fiz solicitações com o Google e o Bing para rastrear novamente o novo site, mas esse foi o resultado.

Eu sou um webmaster amador em uma organização sem fins lucrativos e eu realmente tive que me esforçar, qualquer ajuda seria recebida com gratidão!

    

Answer 1

Ao fazer o tipo de redirecionamento que você está fazendo, há apenas um código de resposta HTTP aplicável, a saber, 301 Moved Permanently . RFC 2616 , o padrão que define o protocolo HTTP, define o código de resposta 301 assim (minha ênfase):

The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. 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.

The new permanent URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).

If the 301 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

Compare isso com um redirecionamento 302 Found do HTTP, que é usado com muita frequência quando simplesmente configuramos um "redirecionamento" e o qual é definido como (mais uma vez, minha ênfase):

The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.

The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).

If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

Assim, a maneira correta de redirecionamento de HTTP em seu cenário é configurar o servidor da Web para retornar uma resposta 301 indicando o novo local, em vez de uma resposta 302 . Clientes capazes, em seguida, irão armazenar o novo URL e usá-lo para futuras solicitações.

    

Answer 2

Acho que seria melhor não redirecionar solicitações para /robots.txt e, ao mesmo tempo, redirecionar todo o resto. Se o site antigo costumava ter um arquivo /robots.txt , você provavelmente deveria mantê-lo. Caso contrário, um arquivo vazio faria. Mas você também pode decidir que é hora de um pouco de limpeza e colocar /robots.txt arquivos nos domínios antigos, que não permitem o rastreamento de páginas, que foram excluídos durante ou após a consolidação.