Consultas DR gratuitas não exigem chave. Faça login para receber $100 em crédito.
Hipotético
Todos os valores aqui são fictícios para demonstrar o método. Não há descrição de cliente, fornecedor ou resultado real.
A agência, o fornecedor, os domínios e todos os números abaixo são fictícios. Eles existem para demonstrar a lógica e a estrutura. Seu lote será diferente.
Imagine uma agência que comprou 40 posições para um site de cliente, a um preço fixo por link, com um piso de DR garantido de 30 e uma janela de substituição de 60 dias. A planilha do fornecedor lista 40 URLs de origem e 40 âncoras.
Nada aqui é incomum. A questão é como transformar essa planilha em uma tabela de aprovação/reprovação. Usamos três pontos de verificação: dia 0, dia 30 e dia 60.
| Ponto de verificação | Página ao vivo buscada | Host na lista de refdomains | Rel conforme pedido | Observações |
|---|---|---|---|---|
| Dia 0 | 38 de 40 | 0 de 40 (ainda não indexado) | 36 de 38 | 2 URLs 404, 2 rel=sponsored adicionados |
| Dia 30 | 37 de 40 | 29 de 40 | 35 de 37 | 1 removido adicionalmente, index atualizado no dia 22 |
| Dia 60 | 36 de 40 | 34 de 40 | 35 de 36 | Substituições pendentes para 4 |
O dia 0 mostra zero hosts no índice. Isso é normal. Um zero na entrega não é um defeito; um zero após duas atualizações é.
No dia 60, quatro links foram removidos. Dois mudaram, porque possuem um rótulo sponsored que o pedido não mencionava. Note a diferença. Se o rótulo conta como defeito depende do contrato, então a planilha deve dizer o que foi pedido em palavras claras. O glossário lista os valores rel que você pode citar.
O piso de avaliação é verificado uma vez com bulk_dr. Uma chamada. No exemplo, 40 domínios em uma chamada custaram 1 crédito, e 3 domínios ficaram abaixo de 30 usando nossa fórmula. Esses três entram no ticket primeiro porque são objetivos e baratos de comprovar.
Uma avaliação abaixo do piso não é questão de gosto. Uma regra que se resolve com um número ganha confiança para as linhas subjetivas que vêm a seguir.
No dia 60, o lote fictício mostra 4 páginas ausentes e 2 rótulos sponsored. Os dois grupos precisam de tratamento diferente, e a ordenação é o passo que transforma uma lista de falhas em um ticket.
Das 4 páginas ausentes, assuma que 3 foram removidas pelo editor e 1 mudou para uma nova URL. A mudança é fácil de perder. Um redirecionamento do endereço antigo mostraria um 301 no dump de cabeçalho salvo, é por isso que os cabeçalhos vão para o armazenamento junto com o HTML.
Os 2 rótulos sponsored são uma classe diferente de problema. Os links funcionam. O fornecedor pode muito bem dizer que o rótulo é a opção honesta. Decida antecipadamente se um rótulo conta, porque uma disputa resolvida por gosto desperdiça uma semana.
| Etapa | Chamadas | Créditos | Dólares |
|---|---|---|---|
| bulk_dr em 40 domínios | 1 | 1 | $0.0001 |
| refdomains no dia 0, 30 e 60 | 3 | 6 | $0.0006 |
| âncoras no dia 60 | 1 | 2 | $0.0002 |
| Total | 5 | 9 | $0.0009 |
A coluna de página ao vivo vem de curl na máquina do testador, não da nossa API. Não oferecemos essa verificação, e fingir que sim esconderia a parte mais trabalhosa do trabalho.
Créditos são quase irrelevantes. O trabalho é ler 40 páginas. Se você quer cortar isso, automatize o grep da lista de erros e mantenha os olhos abertos para as 4 ou 5 linhas que falham.
Para uma visão mês a mês de todo o portfólio de clientes, vá para a tabela de custos. Se as posições mudaram após o lote, o runbook de queda de tráfego é a próxima parada.
As mesmas quatro ações foram executadas no dia 0, dia 30 e dia 60, para que cada ponto de verificação pudesse ser comparado com o anterior.
Todas as 40 páginas foram buscadas uma vez por ponto de verificação, com o HTML e os cabeçalhos salvos e datados. Uma busca falhada é uma linha na tabela, nunca uma célula em branco.
Uma chamada refdomains por ponto de verificação retornou a lista de hosts para o cliente. Uma lista fina no dia 0 era esperada, então a linha foi marcada e deixada para o próximo ponto de verificação.
Cada host e cada valor rel foram comparados com o ponto de verificação anterior, bem como com o pedido. Uma mudança então aparece como uma mudança, com uma data anexada.
As regras no final desta página foram aplicadas linha por linha. A evidência permaneceu ao lado de cada linha, para que um veredito contestado pudesse ser reaberto.
Cada ponto de verificação fez uma pergunta principal. Misturá-las é o motivo usual pelo qual um resultado do dia 0 é discutido no dia 60.
No dia 0, a pergunta é restrita. A página está ao vivo e a âncora existe no HTML salvo? O índice não deve saber ainda, então uma contagem zero de hosts não responde nada. Anote isso e deixe a questão do índice para depois.
Um teste útil no dia 0 é se o HTML buscado contém a string exata da âncora do pedido. Se contiver, a linha é aprovação-pendente. Se não contiver, a linha falha antes mesmo da questão do índice surgir.
No lote fictício, o índice foi atualizado no dia 22, então o dia 30 é o primeiro olhar honesto na lista de hosts. Hosts que aparecem agora confirmam a colocação. Hosts que ainda não aparecem são candidatos para a coluna pendente, e o próximo ponto de verificação decide.
O último ponto de verificação procura por derivação: um valor rel que mudou, uma âncora que se moveu, ou uma página que redireciona agora. Compare cada linha com o dia 30, não apenas com o pedido, para que uma mudança apareça como uma mudança.
O dia 60 também é o ponto natural para verificar se as substituições ainda estão dentro da janela, já que é quando um prazo não percebido tende a passar.
Um exemplo prático é organizado. Lotes reais são mais desorganizados de maneiras que uma tabela fictícia não pode mostrar, e vale a pena nomear isso antes de copiar o layout.
Um host pode mudar de proprietário entre os pontos de verificação, com novo conteúdo e um novo template. O link ainda pode estar ao vivo, mas não mais estar em um tipo de site que o pedido descrevia. Compare o título da página e o bloco de autor, não apenas a URL.
Uma mudança de proprietário não falha automaticamente a linha, mas muda o que a linha prova.
Adicione a verificação de propriedade às regras de veredito se seu lote for longo o suficiente para importar.
Algumas páginas mostram um link apenas em um módulo rotativo, uma barra lateral que muda por visita, ou uma lista cortada para os itens mais recentes. A busca pode perder a âncora em uma execução e pegá-la na próxima. Quando uma linha falha uma vez, busque-a duas vezes no mesmo dia e registre ambos os resultados. Mantenha uma nota da rotação na linha, pois um resultado pendente de um módulo rotativo não é o mesmo que um link ausente.
Um lote que mistura idiomas torna a verificação da âncora mais difícil, porque a âncora pode ser traduzida ou flexionada na página doador. Compare com a redação acordada no pedido e marque o idioma ao lado da linha para que um revisor saiba por que difere.
Este exemplo de auditoria de backlinks é um modelo, não um resultado. Sua estrutura se transfere para qualquer pedido. Seus números não, e ninguém deve lê-los como uma referência.
A tabela de pontos de verificação, a lista de créditos e as regras de veredito se transferem para um novo lote. As contagens não. Substitua todas as figuras fictícias pelas suas antes que alguém leia o resultado. Mantenha as datas dos pontos de verificação na forma dia 0, dia 30 e dia 60, para que um revisor possa combinar sua planilha com esta página à primeira vista.
Escreva as regras de veredito antes da primeira busca, e não as edite quando uma linha decepcionar. Uma regra alterada após o resultado é uma disputa esperando acontecer.
Se o contrato do fornecedor se referir às mesmas regras, ambos os lados leem o mesmo texto. Uma linha pendente então significa o que o contrato diz que significa, e a discussão move-se de interpretação para evidência.
Um pedido de 40 linhas custou 9 créditos no exemplo. Um pedido maior muda o número de chamadas, não o método. Conte as chamadas por ponto de verificação, multiplique e verifique se o total ainda cabe no orçamento que você definiu. A busca ainda é por link, então o tempo de leitura cresce com as linhas enquanto a linha de crédito mal se move.
