Auditoria de links pós-publicação com GitHub Actions ou cron simples
O post está no ar e o pipeline ainda não terminou. Este runbook adiciona uma auditoria agendada que registra dados de links por domínio e avisa uma pessoa apenas quando algo parece errado.
Equipe de pesquisa do SEOBlogBot ·
Por que auditar após publicar?
Um gate vê um rascunho. Uma auditoria vê o que o site ao vivo realmente faz. Plugins reescrevem links, editores colam redirecionamentos afiliados sobre URLs limpos, e uma migração de CDN pode transformar um host em outro. Nada disso existe no estágio de rascunho, por isso uma execução pós-publicação é o primeiro lugar onde isso pode aparecer.
Uma auditoria útil é entediante por design. Ela roda em um agendamento, grava uma linha e fica quieta, a menos que uma exceção seja acionada. Quietude é o objetivo. Um mês de logs silenciosos significa que o job funciona, não que está ocioso.
Não há uma API oficial de verificador de backlinks do Google para uso geral, por isso as equipes usam um índice de links de terceiros. É o nosso próprio crawler. O Search Console mostra a visão do Google sobre seus próprios links, e a auditoria complementa isso, não o substitui.
Onde o job roda
Registre o gatilho. Três configurações cobrem a maioria das equipes, e cada uma executa as mesmas chamadas. O log é mais importante que o gatilho, porque a data, a URL e os créditos usados devem chegar lá sempre.
GitHub Actions para um repositório
Se o site é construído a partir de um repositório, um workflow agendado adiciona o menor atrito. O job vive ao lado do código, e a chave fica na loja de segredos do repositório. O arquivo de workflow mais abaixo é o mínimo necessário. Mantenha-o no repositório, revisado como qualquer outro código, e fixe as versões das ações das quais você depende.
Um servidor simples com cron
Equipes que já mantêm uma máquina para sua build podem agendar os mesmos comandos lá. Uma ferramenta como n8n pode executá-los através de um passo Execute Command, ou uma linha crontab pode executá-los diretamente. De qualquer forma, o job deve rodar como um usuário que pode ler a chave e nada mais.
Um webhook do seu CMS
Algumas configurações de CMS disparam um webhook quando um post entra no ar, e esse evento pode iniciar a auditoria. A verificação então roda no momento em que o post é público. Mantenha também uma execução agendada, porque um único webhook perdido deixa um post sem verificação.
O runbook, em ordem
01
Gatilho na publicação e novamente 30 dias depois
Uma execução logo após o post estar no ar verifica os hosts de saída. Uma segunda execução um mês depois lê refdomains para o seu site, porque o índice é atualizado aproximadamente uma vez por mês e uma leitura anterior não mostraria nada de novo.
02
Chame o resumo gratuito primeiro
action=overview retorna os números principais do site sem custo. Armazene-os como a linha base para esta execução, com a data ao lado.
03
Puxe as listas pagas apenas na mudança
Se o resumo diferir do mês passado, chame refdomains (2 créditos) e anchors (2 créditos) e faça a diferença em relação às listas armazenadas.
04
Escreva uma linha em um log
Data, URL do post, chamadas feitas, saldo _credits. Um CSV simples commitado em um repositório privado é suficiente.
05
Alerte apenas em exceções
HTTP 401, HTTP 402, um resultado vazio para um domínio que tinha linhas no mês passado, ou uma queda de classificação de 10 pontos ou mais.
Quais domínios auditar
Comece com o domínio que hospeda o post. Depois, execute a mesma auditoria contra dois ou três pares que você deseja benchmarkear. Use compare para isso. Ele aceita até 20 domínios por 1 crédito, então a verificação de pares custa quase nada.
Pule a longa cauda. Cada domínio extra adiciona ruído a um log que uma pessoa precisa ler. Um benchmark de vinte domínios não relacionados diz muito pouco sobre o seu.
Mantendo a chave fora dos logs
Um job agendado lê sua chave em cada execução, então ele nunca precisa de um passo de login. A única coisa a proteger é a própria chave. Existem três vazamentos óbvios: um commit, um ambiente impresso e uma URL que um proxy registra. Feche cada um deles.
Use a loja de segredos, não um arquivo no repositório
Cole a chave na loja de segredos do seu provedor de CI, ou em um arquivo de ambiente que apenas o usuário do job possa ler. Nunca faça commit dele. Um passo que ecoa seu ambiente o imprimirá, então não escreva um.
Envie a chave em um header
O header Bearer mantém a chave fora da maioria dos logs de acesso, porque URLs são registrados e headers geralmente não são. A forma de query-string também funciona, mas deixa uma cópia em cada proxy que vê a solicitação.
Limite quem pode ler a loja
Dê acesso de leitura às pessoas que mantêm o job e a mais ninguém. Revise essa lista quando o job mudar de mãos.
Uma chave que muitas pessoas podem ler é uma chave que acabará colada em uma janela de chat um dia.
Valide a resposta antes de gravá-la
Uma resposta que chega ainda não é uma resposta que você pode usar. Use uma ordem sempre. Grave apenas o que passar e registre o resto. Uma resposta rejeitada é evidência, e a próxima pessoa que depurar o job vai querer vê-la.
Verifique o status e ok primeiro
Leia o código de status HTTP, depois o campo ok no corpo. Um 200 com ok definido como falso ainda é uma chamada falha, e o log deve dizer isso.
Analise o JSON antes de qualquer gravação
Confirme que o corpo é JSON válido antes de descompactar, analisar ou anexar qualquer coisa. Um download truncado pode acontecer em um runner instável. Um arquivo corrompido gravado no log parece bom até alguém abri-lo.
Trate uma lista vazia como uma pergunta
Um resultado vazio para um domínio que tinha linhas no mês passado é uma pergunta, não um fato. Verifique a ortografia do domínio, incluindo um www. à esquerda, antes que alguém receba um alerta.
Um arquivo de workflow para começar
Armazene a chave como um segredo de repositório chamado SBB_KEY. A expressão cron roda no primeiro de cada mês às 06:00 UTC.
Atualização do índice em andamento ou erro de digitação no domínio
Tente novamente em um dia; verifique www.
Classificação mudou alguns pontos
Atualização mensal
Não faça nada; observe a tendência
Classificação caiu 10+
Links perdidos ou mudança grande na atualização
Puxe refdomains e faça a diferença
Cron em um servidor simples
Os mesmos comandos executados de uma linha crontab. Mantenha a chave em um arquivo de ambiente que apenas o usuário do job possa ler, e faça log em um arquivo que você rotaciona.
Custos e onde lê-los
Uma auditoria mensal para um domínio custa 4 créditos quando você puxa ambas as listas, o que equivale a $0.0004. A chamada de resumo é gratuita. Um mês sem mudanças, portanto, não custa nada além disso.
Se sua equipe publica dez posts por dia em vários domínios, a auditoria ainda é um job mensal por domínio, não um job por post. Isso mantém a contagem pequena e o log legível.
Quando você adicionar um segundo domínio, copie o job em vez de ampliá-lo. Um workflow por domínio mantém o log por domínio e torna uma falha fácil de rastrear até seu responsável.
O custo maior geralmente são os minutos do seu provedor de CI, não nossos créditos. A tabela de custos coloca ambas as linhas lado a lado, para que você possa decidir qual ajustar primeiro.
Peça à primeira execução que imprima _credits. Confie na resposta acima de qualquer tabela. O guia de gate cobre a verificação no lado do rascunho que vem antes desta.
O agendamento do GitHub roda em UTC, então um início às 06:00 cai em um horário local diferente para cada equipe. Escreva o fuso horário no runbook para que ninguém se surpreenda com o log.
Perguntas sobre executar a auditoria
A maioria dessas perguntas vem de equipes que acabaram de agendar o job pela primeira vez.
Esta é uma API de verificador de backlinks do Google?
É uma auditoria construída sobre a nossa própria API, não um produto do Google. O Google não publica uma API geral de backlinks, então os números vêm do nosso próprio crawler e do nosso próprio índice.
A auditoria pode rodar com cada build?
Pode, mas uma puxada mensal de refdomains não precisa rodar em cada build. Execute o resumo gratuito em cada publicação, e as puxadas pagas uma vez por mês.
Ainda preciso da auditoria se tenho um gate?
Sim, se você publica através de plugins ou uma CDN. O gate vê seu rascunho, e a auditoria vê a página ao vivo. Cada um captura falhas que o outro não consegue ver.
E se o job falhar no meio?
Grave o resultado de cada passo em seu próprio arquivo, para que uma puxada falha deixe o resumo intacto. Reexecute a partir do passo falho em vez de do topo, o que evita pagar pela mesma puxada duas vezes.
Quantos créditos devo orçar para cada domínio?
Orce 4 créditos por domínio por mês para as duas puxadas pagas, mais o que seu gate gasta em rascunhos. O resumo gratuito não adiciona nada a essa figura, e o log mostra o total real.
Por que duas execuções alguns dias de diferença discordam?
O índice é atualizado aproximadamente uma vez por mês, então mudanças dia a dia são geralmente ruído. Compare a captura deste mês com a do mês passado antes de abrir um incidente.
Assinatura do Runbook
O segredo existe e o workflow já foi executado uma vez manualmente.
O arquivo de log registra data, URL, chamadas e _credits.
