Erros de QA em pedidos de links: sete relatórios de bug com correções

Por que as correções são pequenas

Observe que nenhuma delas exige uma segunda assinatura. O QA de links comprados é principalmente contabilidade, e a contabilidade que importa acontece na data de entrega.

O que custa dinheiro é a descoberta tardia. Sempre. Um lote de 40 links pagos antecipadamente, encontrado quebrado três meses depois, deixa você discutindo sobre uma janela de garantia que pode já ter expirado. Execute as verificações no dia 0, dia 30 e dia 60 e a janela funciona a seu favor.

Para um cronograma concreto com números inventados, mas plausíveis, veja o exemplo prático de pedido de 40 links. Para os termos usados nesta lista, o glossário está a um clique de distância.

Onde nossa API entra no loop

Após o loop em shell, chame refdomains uma vez para o domínio do cliente e faça diff da lista de hosts contra a planilha. Isso são 2 créditos, $0.0002, e uma solicitação cobre até 1.000 linhas.

Hosts presentes na planilha e ausentes na lista recebem o rótulo pending até a próxima atualização mensal. Hosts presentes em ambos são cruzados e confirmados. Uma lista curta, limpa e rotulada, é o entregável que seu gerente realmente lê. Ninguém abre o JSON bruto, e ninguém deveria ter que fazer isso. Mantenha o dump no armazenamento caso um fornecedor dispute uma linha seis semanas depois.

Quanto tempo deve levar uma verificação de QA de pedido de links

A verificação de QA de pedidos de links leva menos tempo do que a maioria das pessoas assume. O tempo vai para um único lugar. Ele escala com o número de URLs de origem e com quantas delas você lê à mão, enquanto o tamanho do próprio site do cliente importa muito menos.

Conte as URLs de origem, não as páginas do cliente

Imagine um site de pequeno porte com cerca de 200 páginas que recebeu 40 links de fora. O trabalho são as 40 páginas de origem mais as URLs de destino. As outras 200 páginas do lado do cliente não fazem parte de uma verificação de link. Digamos que esses 40 links venham de 12 hosts distintos. O loop de busca então executa 40 vezes, uma vez por URL, e o diff de refdomains executa uma vez por cliente. Contando dessa forma, a estimativa se torna aritmética.

Se alguém cotar vários dias de trabalho para uma verificação de link, pergunte quais tarefas a cotação cobre. Uma auditoria completa do site e uma verificação de link são trabalhos diferentes, e apenas um deles precisa de um crawler de todo o domínio.

Automatize a busca, depois leia as exceções

O loop em shell neste guia busca cada página de origem e faz grep pelo link. Uma pessoa lê apenas as linhas que o script não pôde confirmar, como um anchor ausente ou um valor rel inesperado.

Isso move o esforço de ler cada página para decidir sobre um punhado de linhas.

O que uma revisão manual ainda adiciona

Uma revisão manual captura o que um script não pode. Exemplos são um link injetado por JavaScript, um paywall ou um layout que oculta o anchor. Orçente isso nas linhas que mais importam, não em toda a planilha.

Escreva o orçamento antes do trabalho começar, para que a revisão tenha um ponto final. Um hábito útil é amostrar três ou quatro linhas à mão após cada lote, não todas as linhas, e registrar quais linhas foram lidas.

Qual dos sete bugs aparece primeiro

Nem todo bug aparece no dia 0. Alguns esperam por um redirecionamento, uma atualização de plugin ou uma mudança na regra de staging. Saiba quais são tardios. Isso molda o segundo e o terceiro checkpoints.

Redirecionamentos e regras de staging aparecem cedo

Se a URL de destino redirecionar duas vezes ou uma regra de staging bloquear bots, o problema geralmente aparece na primeira semana. É por isso que o bug 5 pertence ao script do dia 0 e não a um posterior.

Execute curl -I na sua própria URL no mesmo dia em que o link é relatado como no ar.

A deriva de rel chega após atualizações de plugin

Uma atualização de plugin pode reescrever um atributo rel muito tempo após a entrega. Um link que era seguido no dia 0 pode ser lido como sponsored no dia 60, sem ninguém tocar no artigo.

Então a verificação de rel pertence a todas as re-verificações, não apenas à primeira. Analise o atributo no HTML carregado cada vez e compare-o com o pedido.

URLs erradas e classificações erradas são encontradas na etapa da planilha

Bug 2, a página inicial em vez do artigo pago, e bug 4, comparar classificações entre ferramentas, geralmente são capturados antes que qualquer busca seja executada. Ambos vêm da própria planilha, então são baratos de corrigir nesse ponto.

Corrija-os antes da primeira execução do script. Cada etapa posterior herita o que a planilha diz, e uma busca da URL errada retorna uma resposta limpa sobre a página errada.

Uma planilha que nomeia uma URL de origem exata para cada linha, e uma métrica para a classificação, remove dois dos alarmes falsos mais comuns em todo o processo.

Substituições precisam das mesmas sete verificações

Um link de substituição é um novo link. Ele merece as mesmas sete verificações do primeiro lote, e inicia seu próprio relógio. Trate a troca como uma nova linha de pedido. Não um patch.

Por que a linha antiga não é transferida

A evidência antiga descreve uma página que já não carrega seu link. Ela não prova nada sobre a nova. Mantenha-a para o arquivo de disputa e inicie um novo conjunto de evidências para a substituição.

Registre ambas as URLs de origem na mesma linha, para que o rastro seja lido limpo mais tarde.

Testando dentro da janela de substituição

Se o contrato nomeia uma janela para trocar um link morto, teste a troca dentro dessa janela. Uma substituição testada no último dia não deixa margem para corrigir um segundo problema.

Use a janela como um prazo para verificar, e agende a verificação antes que ela feche.

Classificando o novo domínio novamente

Uma substituição frequentemente vem de um domínio diferente, e esse domínio pode ter uma classificação menor do que a que substituiu. Execute a verificação de piso novamente no novo host antes de aceitar a troca.

Uma única chamada bulk_dr cobre toda a lista de substituições, então há pouco motivo para pular isso.

O que a planilha do gerente deve mostrar

Uma planilha de QA de pedidos de links é o entregável. Cada linha carrega um status e algumas datas, e a evidência fica atrás da linha no armazenamento. A evidência fica fora da vista. O gerente lê o resumo.

Um status por linha

Use pass, pending ou fail, e nada entre eles. Uma linha que está no ar, mas ainda não indexada, é pending, não um meio-pass. Meios-passos fazem a revisão mensal voltar para uma discussão sobre redação.

Se você precisar de um quarto estado, nomeie-o no contrato primeiro.

Datas ao lado de cada status

Cada linha precisa do dia em que você buscou a página, o dia da última atualização que você conhecia e o dia da próxima verificação. Essas três datas respondem à maioria do que um gerente pergunta.

Uma linha sem datas convida à pergunta de se a verificação aconteceu de fato.

Mantendo o dump bruto para uma disputa

Armazene o HTML salvo, os dumps de cabeçalho e as respostas da API em uma pasta nomeada após o lote. Mantenha a pasta pelo tempo que uma disputa ainda puder ser aberta, já que um fornecedor pode questionar uma linha bem depois que o resumo foi fechado.

Torne a pasta somente leitura quando o lote for fechado, para que a evidência corresponda ao que você relatou.