À medida que a web se torna mais complexa, com a estrutura JavaScript e bibliotecas front-ends nos sites, web apps progressivos, Single Page Application (SPA), JSON-LD e assim por diante, cada vez mais estamos diante de um cenário para que as coisas deem errado. Quando tudo o que você tem é HTML e CSS e links, há tanta coisa que você pode estragar e bagunçar. Contudo, nos dias de hoje, dos sites gerados dinamicamente com interfaces JS universais, há muito espaço para que os erros se arrastem.

O segundo problema que enfrentamos é que é difícil saber quando algo deu errado, ou quando o Google mudou a forma como eles estão lidando com alguma coisa. Isso só é agravado quando você considera situações como migrações de site ou redesign, onde você pode arquivar de repente um monte de conteúdo antigo ou remapear uma estrutura de URL. Então, como enfrentamos esses desafios?

A maneira antiga

Historicamente, a forma como você iria analisar coisas como esta seria olhando seus arquivos de log usando o Excel ou, se você é hardcore, Log Parser. Esses são ótimos, mas eles exigem que você saiba que tem um problema, ou que você está buscando e ocorra de você pegar uma seção de logs que contém os problemas que você precisa resolver. Não é impossível, e escrevemos sobre como fazer isso tanto no nosso blog quanto em nosso guia de análise de arquivo de log.

O problema com isso, porém, é bastante óbvio. Exige que você olhe, ao invés de fazê-lo estar ciente de que há algo para procurar. Com isso em mente, pensei que eu gostaria de passar algum tempo investigando se há algo que poderia ser feito para fazer todo o processo levar menos tempo e agir como um sistema de alerta antecipado.

Uma mãozinha

A primeira coisa que precisamos fazer é configurar o servidor para enviar arquivos de log para algum local. Minha solução padrão para isso foi utilizar rotação de log. Dependendo do seu servidor, você vai usar diferentes métodos para conseguir isso, mas no Nginx ele se parece com isto:

# time_iso8601 looks like this: 2016-08-10T14:53:00+01:00
if ($time_iso8601 ~ "^(\d{4})-(\d{2})-(\d{2})") {
set $year $1;
set $month $2;
set $day $3;
}
access_log /var/log/nginx/$year-$month-$day-access.log;

Isso permite que você exiba logs para qualquer data específica ou para um conjunto de datas, simplesmente puxando os dados de arquivos relacionados a esse período. Depois de configurar a rotação de log, podemos então configurar um script, que será executado à meia-noite usando o Cron, para puxar o arquivo de log que se relaciona com os dados do dia anterior e analisá-lo. Se você quiser, pode olhar várias vezes ao dia, uma vez por semana ou em qualquer intervalo, conforme seu nível de volume de dados.

A próxima pergunta é: O que queremos procurar? Bem, uma vez que temos os logs para o dia, isso é o que recebo do meu sistema:

Códigos de status 30*

Gerar uma lista de todas as páginas que atingem os usuários que resultaram em um redirecionamento. Se a página que linka a esse recurso está em seu site, redirecione-o para o real ponto final. Caso contrário, entre em contato com quem está linkando para você para classificar o link para onde ele deve ir.

Códigos de status 404

História semelhante. Qualquer recurso 404ing deve ser verificado para certificar-se que eles devem estar ausentes. Qualquer coisa que estiver lá pode ser investigado por que ele não está resolvendo, e links para qualquer coisa que realmente falta também podem ser tratados da mesma forma que um código 301/302.

Códigos de status 50*

Algo de ruim aconteceu e você não vai ter um bom dia se você está vendo muitos códigos 50*. Seu servidor está morrendo em solicitações de recursos específicos, ou possivelmente todo o seu site, dependendo exatamente o quão ruim isso é.

Crawl budget

Uma lista de cada recurso que o Google rastreou, quantas vezes ele foi solicitado, quantos bytes foram transferidos e o tempo necessário para resolver essas solicitações. Compare isso com o mapa do site para localizar páginas que o Google não irá rastrear, ou que está acessando repetidamente e corrija conforme necessário.

Recursos mais/menos solicitados (Top/least-requested resources)

Semelhante ao anterior, mas detalhando as coisas mais e menos solicitadas pelos mecanismos de busca.

Bad actors

Muitos bots que procuram vulnerabilidades farão pedidos para coisas como wp_admin, wp_login, 404’s, config.php e outras URLs de recursos comuns semelhantes. Qualquer endereço IP que faça solicitações repetidas para esses tipos de URLs podem ser adicionados automaticamente a uma blacklist de IPs.

Relatórios de URLs compatíveis com padrões

É simples usar regex para combinar URLs solicitadas com padrões pré-definidos, para informar áreas específicas de seu site ou tipos de páginas. Por exemplo, você pode relatar pedidos de imagens, arquivos JavaScript sendo chamados, paginação, envio de formulários (via solicitações POST), fragmentos escapados, parâmetros de consulta ou praticamente qualquer outra coisa. Desde que esteja em uma URL ou solicitação HTTP, você pode configurá-lo como um segmento a ser relatado.

Comportamento de rastreamento de pesquisa espelhado

Registre o número de solicitações feitas pelo Googlebot todos os dias. Se ele aumenta em mais de x%, isso é algo de interesse. Como uma nota lateral, com a maioria das séries de números, um cálculo para detectar pontos extremos não é difícil de criar e provavelmente vale o seu tempo.

Produzindo dados

Dependendo da importância de qualquer seção em particular, você pode definir os dados para serem registrados em um par de maneiras. Em primeiro lugar, com grandes quantidades de códigos de status 40* e 50* ou solicitações de bad actor, vale a pena acionar um e-mail para tal. Isso pode deixar você saber rapidamente se algo está ocorrendo e que potencialmente pode indicar um grande problema. Você pode então ficar em cima de tudo o que pode ser e resolvê-lo como uma questão de prioridade.

Os dados como um todo também podem ser configurados para serem relatados através de um painel. Se você não tem muitos dados em seus logs em uma base diária, você pode simplesmente querer consultar os arquivos em tempo de execução e gerar o relatório a cada vez que você visualizá-lo. Por outro lado, os sites com muito tráfego e, portanto, com maiores arquivos de log, podem querer armazenar em cache a saída diária para um arquivo separado, para que os dados não precisem ser computados. Obviamente, o tipo de abordagem que você usa para fazer isso depende muito da escala em que você estará operando e do quão poderoso é o hardware de seu servidor.

Conclusão

Graças ao servidor de logs e scripts básicos, não há razão para você ter uma situação onde algo está errado em seu site e você não sabe sobre ele. As notificações pró-ativas de problemas técnicos são necessárias em um mundo onde o Google rastreia a um ritmo cada vez mais rápido, o que significa que eles poderiam começar a puxar seus rankings para baixo devido ao tempo de inatividade (downtime) ou erros em seu site em questão de horas.

Configure o monitoramento adequado e certifique-se para que você não seja pego desprevenido!

Publicado originalmente no blog do Moz em 22 de novembro de 2016.

Este conteúdo foi traduzido com permissão. SEOmoz não é afiliado com este site.

Tradução por Tiago Souza