Deploy Guard
Cada deploy de produção, verificado contra danos ao SEO.
O build pode passar, todas as páginas podem abrir, e ainda assim o Google pode receber a ordem de tirar a sua página de preços. O Deploy Guard lê o site como um buscador lê, logo depois de cada deploy, e diz o que mudou para a busca.
Do deploy ao e-mail.
O que acontece cada vez que a produção muda. Os tempos são do exemplo da página inicial.
- 0:00
O deploy chega
Pela integração da Vercel, uma notificação de deploy da Netlify, Cloudflare Pages e Workers, ou os deployment statuses do GitHub. Uma sincronização a cada 10 minutos pega qualquer evento que tenha se perdido.
- +1:00
A produção serve o novo build
O HawkDelta espera até a nova versão realmente responder no seu domínio, para nunca verificar a antiga por engano.
- +1:01
Ele planeja o rastreamento
A página inicial, as páginas com mais cliques na busca, as páginas linkadas a partir da inicial e uma amostra do sitemap por seção, além do robots.txt e do próprio sitemap. HTML bruto, e a página renderizada quando o site depende de JavaScript.
- +1:30
Ele compara com a sua base
Cada página é comparada com a última versão que você aceitou, campo a campo: indexação, canonical, redirecionamentos, conteúdo, títulos, dados estruturados, links e mais.
- +3:00
Problemas sérios são buscados de novo
Achados altos e críticos são lidos uma segunda vez para descartar uma falha momentânea. Se o problema sumiu, ninguém é incomodado.
- +3:07
Você recebe um e-mail
Cada problema com as suas páginas, os cliques em jogo, o que os buscadores provavelmente vão fazer e como corrigir, enviado às pessoas que você escolheu para o site.
O que ele pega.
Seis das regressões que passam em qualquer build. Escolha uma para ver a mudança e como o HawkDelta a pesa.
Antes do deploy
<meta name="robots" content="index, follow">Depois
<meta name="robots" content="noindex">- O que os buscadores fazem
- Tira a página dos resultados, em geral em poucos dias. O tráfego dela vai a zero e nada dá erro.
- Como o HawkDelta avalia
- Crítico. Reduzido só para páginas sem impressões na busca, nunca para a página inicial.
Antes do deploy
<link rel="canonical" href="https://yoursite.com/blog/launch">Depois
<link rel="canonical" href="https://yoursite-git-main.vercel.app/blog/launch">- O que os buscadores fazem
- Recebe a informação de que a página real é uma cópia de um host de preview. Pode indexar a URL errada ou nenhuma delas.
- Como o HawkDelta avalia
- Alto, e mais alto em páginas com 10% ou mais dos cliques do site.
Antes do deploy
<title>Pricing that grows with you | Acme</title>Depois
<title>Acme</title>- O que os buscadores fazem
- Reescreve o snippet de todas as páginas afetadas. A taxa de cliques cai antes das posições.
- Como o HawkDelta avalia
- Sinalizado quando um título é removido, duplicado ou alterado em uma página com 5% ou mais dos cliques.
Antes do deploy
<main><h1>Pricing</h1><p>Start free, then…</p> … 1.840 palavrasDepois
<main><div id="__next"></div></main> … 0 palavras antes do JavaScript- O que os buscadores fazem
- Vê uma página vazia na primeira busca. A renderização vem depois, se vier, e as posições caem.
- Como o HawkDelta avalia
- Compara o HTML bruto com a página renderizada. Conteúdo principal reduzido à metade ou mais é sinalizado.
Antes do deploy
sitemap.xml: 214 URLsDepois
sitemap.xml: 131 URLs (83 removidas, 9 com cliques de busca)- O que os buscadores fazem
- Rastreia as URLs que sumiram com menos frequência. Páginas que ganharam links saem do índice aos poucos.
- Como o HawkDelta avalia
- Com o Search Console conectado, só contam as URLs removidas que recebem tráfego de busca. Limpezas de páginas mortas passam em silêncio.
Antes do deploy
User-agent: *
Allow: /Depois
User-agent: *
Disallow: /blog/- O que os buscadores fazem
- Para de rastrear o diretório inteiro. Um 5xx no robots.txt pode pausar o rastreamento do site todo.
- Como o HawkDelta avalia
- Crítico para páginas bloqueadas que recebem tráfego de busca. Se o próprio robots.txt começar a falhar, crítico para o site inteiro.
Também verificado a cada deploy: redirecionamentos e cadeias de redirecionamento, códigos de status, H1, meta descriptions, dados estruturados, hreflang, links internos, peso da página, cabeçalhos de segurança e prévias de link: as tags Open Graph e de card do X, e se a imagem de prévia ainda carrega.
Todas as regras, em cada deploy.
Regras que não servem para um site podem ser desligadas, site a site. As marcadas como sempre ativas não: são as que tiram páginas da busca.
Indexação
- Página passa a ter noindexsempre ativa
- robots.txt bloqueia páginas ou falhasempre ativa
- Página quebra (4xx ou 5xx)sempre ativa
- Canonical removido, alterado ou apontando para um host de prévia
- Sitemap quebrado ou perdendo páginas com tráfego
- hreflang removido, quebrado ou sem o link de volta
Conteúdo e renderização
- Conteúdo principal cai pela metade ou mais
- Conteúdo que só aparece depois do JavaScript
- Título removido, duplicado ou reescrito
- H1 alterado, meta description removida
- Dados estruturados (JSON-LD) removidos ou quebrados
Links e redirecionamentos
- Novos redirecionamentos, 301 virando 302, cadeias de três ou mais
- Links internos caem pela metade ou mais
Velocidade e segurança
- JavaScript no carregamento sobe 50% e 300 KB ou mais
- Um cabeçalho de segurança que a página inicial deixou de enviar
Prévias de links
- Tags Open Graph ou X card perdidas
- Imagem de prévia que não carrega mais
A gravidade acompanha o seu tráfego.
A mesma mudança pesa mais numa página que traz 18% dos seus cliques do que numa que ninguém encontra. Com o Search Console conectado, cada achado é pesado pelos cliques que cada página recebeu nos últimos 28 dias.
- robots.txt, o sitemap e a página inicial nunca são rebaixados.
- Mudanças de apresentação (títulos, descrições, cabeçalhos, links) ficam em Baixa em páginas com menos de 5 cliques.
- Prévias de links são pesadas pelas visitas vindas de redes sociais, não pelo Google.
- Sem o Search Console, cada regra mantém o próprio nível e o e-mail avisa isso.
/pricing14% dos cliquesCrítica Um nível acima: uma página com 10% ou mais dos cliques do site.
/blog/launch2% dos cliquesAlta O nível da própria regra.
/old-promosem impressõesBaixa Dois níveis abaixo: nenhuma impressão em 28 dias.
Dados de exemplo.
Silencioso, a não ser que importe.
Verificado duas vezes
Achados sérios são buscados uma segunda vez antes de qualquer e-mail. Um timeout ou um cold start não acordam ninguém.
Você escolhe o limite
Por padrão, só problemas altos e críticos geram e-mail. Os achados menores esperam no app.
Intencional em um clique
Marque uma mudança como intencional, ou como alarme falso, e aquele campo vira a nova base. Os outros achados da página continuam abertos.
Precisão à vista
O app mostra quantos alertas dos últimos 28 dias eram reais, para você confiar no próximo.
Antes, entre e depois dos deploys.
Verifique uma prévia antes do merge
Cole qualquer endereço de prévia (Vercel, com o bypass de proteção, um deploy preview da Netlify ou uma prévia do Pages) e compare com a produção. Nunca envia alertas e nunca altera a base.
Uma verificação diária para o resto
Mudanças que nunca passam por um deploy, de uma edição no CMS a uma regra da Cloudflare, são pegas por uma verificação da produção uma vez por dia.
Uma base no primeiro dia
A primeira verificação registra o site como ele está e lista só o que já estava quebrado. A partir daí, cada deploy é comparado com ela.
Corrigido é corrigido
Um achado fica aberto até uma verificação posterior não vê-lo mais, e então é marcado como corrigido. Nada é fechado só porque deixou de ser olhado.
Veja no seu próprio site.
O beta é gratuito até 28 de fevereiro de 2027. Os primeiros 50 sites na Vercel, Netlify ou Cloudflare entram na hora; membros fundadores mantêm 40% de desconto para sempre.
Como funciona o betaConfira seu e-mail.
Enviamos um link para . Abra para confirmar: você vê na hora se entrou, e uma primeira olhada no seu site.
Duas perguntas opcionais, um toque cada.
Quantos sites você mantém?
Você é…
Nada depois de alguns minutos? Veja no spam, ou .