Bloqueio de 'bons' bots no nginx com múltiplas condições para certas URLs fora dos limites onde os humanos podem ir

1

Após 2 dias pesquisando / tentando / falhando resolvi postar isso aqui, não encontrei nenhum exemplo de alguém fazendo o mesmo nem o que tentei parece estar funcionando OK. Eu estou tentando enviar um 403 para bots não respeitando o arquivo robots.txt (mesmo depois de baixá-lo várias vezes). Especificamente o Googlebot. Ele suportará a seguinte definição de robots.txt.

User-agent: *
Disallow: /*/*/page/

A intenção é permitir que o Google pesquise o que encontrar no site, mas retorne um 403 para o seguinte tipo de solicitação. O Googlebot parece continuar aninhando esses links eternamente, adicionando bloco de paginação após o bloqueio:

my_domain.com:80 - 66.x.67.x - - [25/Apr/2012:11:13:54 +0200] "GET /2011/06/
page/3/?/page/2//page/3//page/2//page/3//page/2//page/2//page/4//page/4//pag
e/1/&wpmp_switcher=desktop HTTP/1.1" 403 135 "-" "Mozilla/5.0 (compatible; G
ooglebot/2.1; +http://www.google.com/bot.html)"

É um site wordpress btw. Não quero que essas páginas sejam exibidas, mesmo depois que as informações do robots.txt passaram, elas pararam por um tempo e começaram a engatinhar novamente mais tarde. Isso nunca pára ... Eu quero que pessoas reais vejam isso. Como você pode ver, google obter um 403, mas quando eu tente isso sozinho em um navegador recebo um 404 de volta. Quero que os navegadores passem.

root@my_domain:# nginx -V
nginx version: nginx/1.2.0

Eu tentei abordagens diferentes, usando um mapa e um nono antigo simples, e ambos agem da mesma forma: (na seção http)

map $http_user_agent $is_bot {
default 0;
~crawl|Googlebot|Slurp|spider|bingbot|tracker|click|parser|spider 1;
}

(na seção do servidor)

location ~ /(\d+)/(\d+)/page/ {
if ($is_bot) {
return 403; # Please respect the robots.txt file !
}
}

Recentemente, precisei aprimorar minhas habilidades com o Apache para um cliente, onde fiz a mesma coisa assim:

# Block real Engines , not respecting robots.txt but allowing correct calls to pass
# Google
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/5\.0\ \(compatible;\ Googlebot/2\.[01];\ \+http://www\.google\.com/bot\.html\)$ [NC,OR]
# Bing
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/5\.0\ \(compatible;\ bingbot/2\.[01];\ \+http://www\.bing\.com/bingbot\.htm\)$ [NC,OR]
# msnbot
RewriteCond %{HTTP_USER_AGENT} ^msnbot-media/1\.[01]\ \(\+http://search\.msn\.com/msnbot\.htm\)$ [NC,OR]
# Slurp
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/5\.0\ \(compatible;\ Yahoo!\ Slurp;\ http://help\.yahoo\.com/help/us/ysearch/slurp\)$ [NC]

# block all page searches, the rest may pass
RewriteCond %{REQUEST_URI} ^(/[0-9]{4}/[0-9]{2}/page/) [OR]

# or with the wpmp_switcher=mobile parameter set
RewriteCond %{QUERY_STRING} wpmp_switcher=mobile

# ISSUE 403 / SERVE ERRORDOCUMENT
RewriteRule .* - [F,L]
# End if match

Isso faz um pouco mais do que eu pedi ao nginx para fazer, mas é sobre o mesmo princípio, estou tendo dificuldade em descobrir isso para o nginx.

Então, minha pergunta seria: por que o nginx serviria meu navegador como 404? Por que não está passando? O regex não está correspondendo ao meu UA:

"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.30 Safari/536.5"

Existem muitos exemplos para bloquear com base apenas no UA, e isso é fácil. Parece também que a localização do matchin é final, por ex. não está "caindo" para o usuário regular, estou certo de que isso tem alguma correlação com o 404 que recebo no navegador.

Como uma cereja no topo das coisas, eu também quero que o google desconsidere o parâmetro wpmp_switcher = mobile, wpmp_switcher = desktop é bom, mas eu não quero que o mesmo conteúdo seja rastreado várias vezes.

Mesmo assim, acabei adicionando o wpmp_switcher = mobile por meio das páginas de ferramentas do Google Webmaster (solicitando que eu me inscrevesse ...). que também parou por um tempo, mas hoje eles estão voltando para as seções móveis.

Então, em suma, preciso encontrar uma maneira de o nginx impor as definições do robots.txt. Alguém pode desembolsar alguns minutos de suas vidas e me empurrar na direção certa, por favor?

Eu realmente aprecio QUALQUER resposta que me faça pensar mais difícil; -)

    
por Glenn Plas 25.04.2012 / 14:15

3 respostas

1

Acho que a melhor solução para esse problema envolverá várias coisas. Nenhum deles envolve o bloqueio de bots.

  1. Evite que o WordPress gere os URLs inválidos em primeiro lugar.

    Descubra o que causou a geração desses URLs e corrija o problema.

  2. Determine se as URLs podem ser reescritas corretamente. Em caso afirmativo, mande o WordPress enviar um redirecionamento 301.

    Para alguns desses URLs, você pode enviar um 301 para redirecionar para o URL canônico. Para outros, no entanto, não será tão fácil, pois a URL não faz sentido algum.

    Enquanto versões recentes do WordPress enviam redirecionamentos 301 para algumas páginas, plugins como Permalink Redirect podem ajudar a cobrir as coisas que o WordPress não faz. (Este plugin pode precisar de uma atualização ou alguma personalização; teste cuidadosamente primeiro.)

  3. Para URLs sem sentido, veicule em 410 .

    A resposta HTTP 410 Gone informa ao solicitante que o URL não existe e nunca vai voltar, então pare de perguntar por ele. Os mecanismos de pesquisa podem usar esses dados para remover URLs inválidos de seus índices.

    Uma configuração de amostra que deve fazer isso é (teste isso primeiro!):

    location ~ #/page/\d+/page/# {
        return 410;
    }
    
por 12.09.2012 / 09:24
0

Tente usar isso no seu mapa:

~(crawl|Googlebot|Slurp|spider|bingbot|tracker|click|parser|spider)$ 1;

Pelo que me lembro, você precisa usar $ para encerrar o regex, a menos que você esteja usando o local - vale a pena tentar.

    
por 26.04.2012 / 10:20
0

Acredito que sua primeira definição não funcionou porque você a colocou sob User-agent: * em vez de em User-agent: Googlebot. Pelo menos isso parece ter feito a diferença com a minha declaração de não permitir; vai figura.

Adicionei o seguinte no meu robots.txt, em User-agent: Googlebot

Não permitir: / *?

Isso supostamente bloqueia qualquer URL contendo um ponto de interrogação, pois todos contêm um ponto de interrogação e nenhuma URL legitima, pelo menos no meu caso.

Recentemente encontrei um problema muito semelhante e também tive o "& wpmp_switcher = desktop" ou "& wpmp_switcher = mobile", mas também "mobile? pw_post_layout" nestes rastreamentos de URL aninhados sem sentido (mais detalhes em < um href="http://deputycio.com/8013/googlebot-gone-crazy-maybe-not-its-fault"> link espero que eu não estou quebrando nenhuma política com este link aqui porque é relacionado) . Essa correção foi sintomática, então ainda estou intrigado com a verdadeira causa. Alguém descobriu alguma coisa sobre esse problema desde?

    
por 27.07.2012 / 06:05