Antes de dar publish, rode 30 itens em 5 categorias: SEO técnico (sitemap, robots, canonical, JSON-LD, OG, hreflang), performance (LCP, INP, CLS, FCP, TTFB, bundle), tracking (GA4, GTM, Pixel, Consent Mode v2, dataLayer, server-side), legal/LGPD (política, banner granular, termos, DPO, RAT, aviso ANPD 3 dias) e smoke tests (200 em todos slugs, 404 custom, sitemap aceito no GSC, Rich Results sem erro, mobile real). Cada item leva 5-30 minutos. Pular categoria queima 60-90 dias de SEO.
A Huios usa exatamente esse checklist em todo lançamento desde 2021. Nos últimos 12 meses, mais de 250 launches saíram dessa sequência — zero rollback por erro de go-live em 2025-2026. Esse texto é o checklist real, com as fontes externas que justificam cada threshold.
Por que checklist e não "vou ver depois"
Site lançado com canonical errado, GTM esquecido em staging ou sitemap apontando pra localhost queima 60 a 90 dias de recuperação no Google. O sintoma chega na sexta — métrica não bate — e o time gasta 3 semanas entendendo que a causa foi o launch.
O Google trata sinal ruim no go-live como sinal real. Se o Googlebot vê 500, schema quebrado ou title duplicado por 7 dias, ele recalibra a confiança no domínio. A documentação oficial é direta:
"Manter a continuidade dos sinais de classificação durante uma alteração de URL ou migração é fundamental. Sinais como links, conteúdo e indexabilidade precisam estar preservados no momento do go-live, ou o Google pode levar semanas pra reestabilizar o ranqueamento."
Checklist resolve pelo motivo trivial: você não esquece. A Huios rodou essa sequência em mais de 250 sites e nenhum precisou de hotfix de SEO no D+1 nos últimos 12 meses. Antes do checklist, dois rollbacks em três anos. A matemática fechou.
1. SEO técnico — 6 itens (antes do go-live)
O Google precisa ler o site sem ambiguidade. Cada item aqui é binário: passou ou não passou.
1.1 sitemap.xml dinâmico, com URLs absolutas e lastmod real. Acesse seu-dominio.com.br/sitemap.xml. Tem que retornar XML válido com https:// e datas reais. Em Next.js 16, o sitemap é gerado por app/sitemap.ts — confirme que lê dados de produção, não fixture. Pelo Web Almanac 2024 (HTTPArchive), só 57% dos sites no top 1M tem sitemap acessível — e essa lacuna explica boa parte dos atrasos de indexação. Submeta no Google Search Console imediatamente após o launch.
1.2 robots.txt sem Disallow: / e com matriz pra bots de IA. Pegadinha clássica: robots de staging bloqueia tudo e ninguém troca antes do deploy. Em produção, confirme User-agent: * Allow: /. Em 2026, adicione também GPTBot, ClaudeBot, PerplexityBot, OAI-SearchBot e GoogleOther — distinguindo bots de Search/Answer (permitir) de bots de Training (decisão caso-a-caso). Bloquear OAI-SearchBot ou PerplexityBot = sumir do ChatGPT Search e Perplexity. Avalie antes.
1.3 canonical explícito em cada rota. Toda página precisa de <link rel="canonical" href="https://seu-dominio.com.br/rota-exata" /> apontando pra si mesma. Faça view source de 3 rotas (home, serviço, blog post) e confirme. Não confie no framework. Páginas paginadas, filtros e variações de UTM são onde a coisa quebra mais.
1.4 JSON-LD por tipo de página, validado. Home tem Organization com sameAs (Instagram, LinkedIn, GitHub). Posts têm Article/BlogPosting com author (Person estendido), datePublished, dateModified e wordCount. Serviços têm Service. Páginas com perguntas têm FAQPage. Cole cada rota no Rich Results Test do Google e no Validator do Schema.org. Zero erro. Warnings, aceitáveis se documentados.
1.5 OG image 1200×630 absoluta em todas rotas. Compartilhe a URL no WhatsApp, LinkedIn e X. Se a imagem some, conserte. Caminho relativo (/og.png) em vez de absoluto (https://...og.png) faz LinkedIn e X falharem silenciosamente. Use https:// no og:image sempre. Site multilíngue ou multi-região? Adicione hreflang em cada rota apontando pras variantes (pt-BR, pt-PT, en) — sem isso, o Google escolhe a versão errada pro user.
1.6 página 404 customizada retornando HTTP 404 (não 200!). URL inventada (/abc123) tem que retornar status 404 com layout do site e link pra home. Next.js servindo 200 em rota desconhecida quebra sinal pro Googlebot e infla o índice com lixo. No App Router, o arquivo not-found.tsx do route group resolve. Teste com curl -I https://seu-dominio.com.br/abc123 — espere HTTP/2 404. Mesma coisa pra erro 500: tenha error.tsx por route group, não a tela genérica do Next.
2. Performance — 6 itens (Core Web Vitals verdes)
Métrica que o Google usa pra ranqueamento desde 2021. Site lento perde tráfego mesmo com conteúdo bom. Os thresholds vêm publicados em web.dev/articles/vitals — não são opinião:
"Para fornecer uma boa experiência ao usuário, os sites devem se esforçar pra ter LCP de 2,5 segundos ou menos, INP de 200 milissegundos ou menos e CLS de 0,1 ou menos. Esses limites refletem o 75º percentil de carregamentos de página, segmentado em dispositivos móveis e desktop."
2.1 LCP ≤ 2,5s em mobile. Largest Contentful Paint mede o render do maior elemento visível. Entre 2,5s e 4s = "Needs Improvement"; acima de 4s = "Poor". Rode em PageSpeed Insights em modo mobile — não confie no desktop. Causa #1: hero image grande sem priority ou sem dimensões. Conserte com next/image + priority no LCP element.
2.2 INP ≤ 200ms. Interaction to Next Paint substituiu FID em março/2024 como Core Web Vital oficial. Mede latência de resposta a clique, tap ou tecla. Acima de 200ms = experiência travada; acima de 500ms = "Poor". Bundle JS grande é a causa mais comum. Code splitting + Server Components do Next 16 resolvem.
2.3 CLS ≤ 0,1. Cumulative Layout Shift mede o quanto o layout pula durante o carregamento. Causa principal: imagem sem width/height, fonte sem font-display: swap, anúncio injetado ou banner de cookies sem reserva de espaço. Conserto típico: 1-2 horas. Detalhe em como melhorar Core Web Vitals.
2.4 FCP ≤ 1,8s e TTFB ≤ 800ms. First Contentful Paint e Time to First Byte são as métricas-suporte. FCP mede quando o primeiro pixel aparece; TTFB mede a latência do servidor. Vercel + ISR resolve TTFB pra rotas estáticas; rotas dinâmicas pedem cache de fetch e edge runtime quando faz sentido. Rode no Chrome DevTools → Network → Throttling: Slow 4G.
2.5 Lighthouse: Performance ≥ 85, Accessibility ≥ 95, SEO 100, Best Practices ≥ 95. Rode na home, num serviço e num post. Se cair abaixo, identifique o item no relatório. Limite de bundle Huios: rota crítica abaixo de 200KB de JS comprimido. Acima disso, npm run build + análise de bundle (@next/bundle-analyzer) pra achar o que tá inchando.
2.6 CDN com Cache-Control correto e imagens otimizadas. Assets estáticos via CDN (Vercel Edge, Cloudflare, CloudFront). Pegue um .jpg, confira o header cache-control na DevTools — espere public, max-age=31536000, immutable. Toda imagem fora do viewport inicial precisa de loading="lazy"; LCP image precisa de priority. Fontes via next/font (mesma origin elimina round-trip DNS). Pra ajustes específicos de mobile, como aprovar no PageSpeed mobile cobre os 8 ajustes que mais movem o ponteiro.
3. Tracking e Analytics — 6 itens (medir desde o minuto zero)
Site sem tracking é site cego. Cada dia sem GA4 funcionando é dia sem dado pra otimizar depois. O princípio aqui é simples:
"Se você não consegue medir, você não consegue otimizar. E a pior hora pra descobrir que o tracking está quebrado é três meses depois do launch, quando o cliente pergunta por que a campanha não gerou nada."
— princípio operacional Huios, formado após auditar 40+ contas onde o tracking estava errado desde o launch
3.1 GA4 instalado, com validação em Tempo Real. Cole o G-XXXXXXXX no GTM ou direto via next/third-parties/google. Abra o site em janela anônima e confirme no Tempo Real do GA4 que aparece page_view. Configure os eventos-chave (lead, purchase, click_whatsapp) como conversão no painel. Sem isso, GA4 reporta tráfego mas não converte em métrica de negócio.
3.2 GTM com container de produção (não de teste). Pegadinha clássica: container de dev (GTM-AAAA111) sobe pra produção e o de produção (GTM-BBBB222) fica engavetado. View source da home, busque gtm.js — confirme o ID. Use GTM Preview Mode pra debugar antes de publicar o container.
3.3 Meta Pixel + Conversions API server-side. Use a extensão Meta Pixel Helper e confirme PageView disparando com o pixel ID certo. Pra anúncio rodando, Pixel browser sozinho atribui ~60% dos eventos pós-iOS 14 — adicione Conversions API server-side via GTM Server-Side ou função Vercel. Sem isso, atribuição cai.
3.4 Consent Mode v2 do Google + banner granular (LGPD). Cookies de tracking só disparam após consentimento explícito. Implemente Google Consent Mode v2 com sinais ad_storage, analytics_storage, ad_user_data e ad_personalization. O banner precisa permitir aceitar essencial e recusar marketing/analytics separadamente — exigência ANPD. Cookiebot, Iubenda ou solução custom resolvem; "aceitar" único como botão não basta.
3.5 dataLayer customizado com eventos de negócio. Formulário enviado dispara lead no dataLayer com form_type e source. Clique em WhatsApp dispara click_whatsapp. Compra dispara purchase com value e currency. Não confie em "GA pega sozinho" — configure cada um no GTM. Schema padronizado em dataLayer.push({...}) evita drift entre páginas.
3.6 Search Console + Bing Webmaster Tools + sitemap enviado. Adicione propriedade no Google Search Console e no Bing Webmaster Tools, envie o sitemap.xml, confirme verificação por DNS. Bing alimenta ChatGPT Search e Copilot — não pular. Configure também alertas de cobertura no GSC pra ser avisado se algum erro 5xx ou Soft 404 aparecer nas primeiras 48h.
4. Legal e LGPD — 6 itens (sem multa ANPD)
LGPD virou multa real em 2024 e a Autoridade Nacional de Proteção de Dados vem executando desde então. A Resolução CD/ANPD nº 15, de 24 de abril de 2024 estabelece o regulamento de comunicação de incidente de segurança — incluindo o prazo de 3 dias úteis pra notificar a ANPD e os titulares afetados. Site no ar sem essas peças é exposição jurídica direta.
"O controlador deverá comunicar à ANPD e ao titular a ocorrência de incidente de segurança que possa acarretar risco ou dano relevante aos titulares no prazo de 3 (três) dias úteis, contado da data do conhecimento do incidente."
4.1 Política de Privacidade publicada e linkada no footer de TODAS as páginas. Documento descrevendo quais dados são coletados, finalidade, base legal LGPD (Art. 7º), prazo de retenção, compartilhamento com terceiros e direitos do titular (Art. 18). Template genérico não basta — tem que listar especificamente o que SEU site coleta. Se trata dado pessoal sensível (saúde, religião, biometria, dado de criança/adolescente), Art. 11 da LGPD exige base legal específica e consentimento destacado.
4.2 Banner de cookies com opções granulares. "Aceitar" ou "Continuar usando" não basta. O banner precisa permitir aceitar essencial e recusar marketing/analytics separadamente, com botão de "Rejeitar tudo" igualmente proeminente — interpretação consolidada da ANPD desde o Guia Orientativo sobre Cookies e Proteção de Dados Pessoais (2022). Categorias: estritamente necessários, analytics, marketing, preferências.
4.3 Termos de Uso publicados. Condições de uso, propriedade intelectual, limitação de responsabilidade, foro. Crucial em sites com cadastro, e-commerce, área restrita ou conteúdo gerado por usuário. Linkado no footer junto com a política.
4.4 Encarregado de Proteção de Dados (DPO) com canal público. Art. 41 da LGPD exige Encarregado com contato divulgado no site. E-mail dpo@empresa.com.br ou encarregado@empresa.com.br no footer e/ou na política resolve. Empresa sem DPO em 2026 não é mais detalhe — a ANPD verifica isso primeiro em fiscalização.
4.5 Aviso de coleta em cada formulário + base de consentimento auditável. Ao lado do botão de submit: "Ao enviar, você concorda com nossa [Política de Privacidade]." Com link clicável. Sem isso, base de consentimento fica frágil em auditoria. Para newsletter, double opt-in com log de IP, data e versão da política aceita — exigência prática pra defesa em fiscalização.
4.6 Registro de Atividade de Tratamento (RAT) interno e processo de incidente. Art. 37 da LGPD obriga o controlador a manter registro das operações de tratamento. Planilha listando: dado tratado, finalidade, base legal, retenção, compartilhamento. Não vai no site, mas tem que existir. Junto: playbook escrito de resposta a incidente — quem aciona DPO, prazo de 3 dias úteis da Resolução 15/2024, modelo de comunicação ao titular. Auditoria ANPD começa pedindo esses dois documentos.
5. Smoke tests — depois do go-live (primeiras 4 horas)
Site no ar não significa site funcionando. Após o deploy, rode esta sequência — leva 30 a 60 minutos e pega 80% dos erros de produção. Esta é a categoria onde a Huios mais economizou rollback nos últimos 12 meses.
5.1 Todos os slugs do menu retornam HTTP 200 em produção. Use curl -I em cada URL principal. Status tem que ser 200. Se vier 301 inesperado, 404, 500 ou 502, conserte antes do Googlebot crawlar. Comando útil: extrair URLs do sitemap e rodar curl -o /dev/null -s -w "%{http_code} %{url_effective}\n" em batch.
5.2 Sitemap aceito no GSC, sem erros de cobertura. Envie sitemap.xml no Search Console e aguarde 5-15 minutos. Status "Sucesso" significa que o Google leu. Volte em 24h e cheque Indexação → Páginas: zero "Soft 404", zero "Servidor (5xx)", zero "Redirecionamento" inesperado. Erros aparecidos no primeiro mês têm peso desproporcional, conforme Web Almanac 2024 — capítulo SEO.
5.3 Rich Results Test e Schema.org Validator sem erros em cada tipo de página. Cole home, serviço, post e contato no Rich Results Test e no Schema.org Validator. Zero erros. Warnings aceitáveis (propriedade recomendada faltando) ficam pra próxima sprint; erros (tipo inválido, valor enum errado, hierarquia quebrada de BreadcrumbList) bloqueiam o launch.
5.4 Página 404 custom e página 500 servindo corretamente. URL inventada → 404 com layout. Force um erro de servidor numa rota controlada (ex: throw num Server Component temporário em staging) → error.tsx do route group renderiza. Em produção, 500 sem error.tsx é tela branca do Next — péssima experiência e sinal ruim de saúde.
5.5 Emulação mobile real em 5 rotas no mínimo. O Mobile-Friendly Test foi descontinuado em dez/2023, mas o Chrome DevTools com emulação iPhone/Android resolve. Teste home, serviço, post, contato e formulário. Tap targets 48×48px mínimo (WCAG 2.2 nível AA), texto legível sem zoom, botões alcançáveis com polegar. Bônus: teste num celular físico, não só emulador — toque real revela quebras que o DevTools esconde.
5.6 Formulários enviam, chegam no CRM, WhatsApp abre certo. Teste cada formulário (contato, newsletter, orçamento) com dado real. Confirme: chega no e-mail/Pipedrive/RD, usuário vê mensagem de sucesso, campo obrigatório bloqueia submit, evento lead dispara no dataLayer. Link de WhatsApp em mobile real (não emulador) — tem que abrir o app com mensagem pré-formatada e número correto. Formulário quebrado no launch é leak de lead que nunca volta.
48 horas pós-launch — monitoramento ativo
Não é "deploy e esquecer". As primeiras 48 horas mostram se o site vai estabilizar ou se vai precisar de hotfix.
- GSC — Cobertura. Indexação → Páginas a cada 12h. Erro novo aparecendo = investigar na hora.
- GA4 — Tempo Real.
page_view,lead,purchasechegando? Volume zero em alguma rota = tracking quebrado. - Sentry / Vercel Logs. Errors em produção? 500s recorrentes em rota específica? Conserte antes que vire padrão.
- Formulários. Submeta 1 a cada 6h no primeiro dia. Algum não chegou no CRM? Conserte o webhook antes que leads reais entrem.
- WhatsApp clicks. Eventos aparecendo no GA4. Zero pode significar botão quebrado.
Erros mais comuns no launch (vistos em campo)
Os cinco erros mais frequentes nas auditorias de migração que a Huios fez nos últimos 12 meses:
- GTM esquecido em produção. Deploy do
stagingcom GTM comentado pra não poluir métricas de teste sobe igual. Site fica sem tracking 3-7 dias até alguém perceber. Sempre confirme no view source da home. - OG image com path relativo.
/og.pngem vez dehttps://...og.pngfaz LinkedIn e X falharem. Sempre URL absoluta noog:image. - Sitemap apontando pra
localhost. Geração em build time pegaprocess.env.NEXT_PUBLIC_SITE_URLerrado. Sitemap com URLshttp://localhost:3000/.... Confira manualmente. - JSON-LD com aspas curvas.
"texto"em vez de"texto"quebra o JSON. CMS com autoformat faz isso silenciosamente. Use o Schema.org Validator. - Cache stale do CDN. Após push, o CDN às vezes mantém versão antiga em cache por horas. Force purge na Vercel/Cloudflare — não confie em invalidação automática.
Perguntas frequentes
Quanto tempo leva pra rodar o checklist inteiro?
Entre 4 e 8 horas pra site institucional médio (10-20 páginas): pré-launch leva 3-5 horas, smoke tests pós go-live 30-60 minutos, monitoramento de 48 horas é acompanhamento em segundo plano. Site grande com sistema interno ou e-commerce pode chegar a 12 horas. Time experiente roda mais rápido porque já tem ferramental — Screaming Frog, PageSpeed, Schema validator e GSC em abas separadas.
Posso pular categorias se o site é simples?
Não. Site simples também precisa de canonical, sitemap, GA4 e LGPD. Muda a profundidade dentro de cada categoria — 5 páginas têm menos rotas pra validar, não menos categorias. Pular LGPD em particular é exposição jurídica direta, independente de tamanho do site, porque a Resolução 15/2024 da ANPD não distingue site grande de pequeno na obrigação de notificar incidente em 3 dias úteis.
Lighthouse mostrou Performance 75 — pode lançar mesmo assim?
Depende do que está puxando pra baixo e em qual rota. INP em modal pouco usado pode esperar. LCP da home conserte antes — é a página com maior peso de ranqueamento e primeira impressão. Critério Huios: Performance ≥ 85 em mobile como mínimo na home e em rotas comerciais (serviços) pra liberar launch. Posts de blog em 75 são aceitáveis se os Core Web Vitals (LCP, INP, CLS) estiverem verdes.
Site precisa cumprir todos os Core Web Vitals pra ranquear?
Sim, dentro do limite de "Good" em 75% dos carregamentos (LCP ≤ 2,5s, INP ≤ 200ms, CLS ≤ 0,1), como definido pela equipe Chrome em web.dev/vitals. Não cumprir não tira o site do índice, mas reduz ranqueamento em queries competitivas — especialmente em mobile, onde o Google usa o dado do Chrome User Experience Report (CrUX). Páginas em "Needs Improvement" perdem pra concorrente equivalente que está em "Good".
Schema.org com warning (não erro) é problema?
Geralmente não, mas leia cada um. Aceitáveis: propriedade recomendada faltando em FAQPage (upvoteCount), image.width/height em Article. Preocupantes: tipo incorreto, valor enum inválido, hierarquia quebrada de BreadcrumbList, author faltando em BlogPosting. Em dúvida, pergunte pro dev qual foi a decisão e documente — auditoria E-E-A-T futura cobra isso de volta.
Preciso pagar advogado pra criar política de privacidade?
Em projeto pequeno sem dado sensível, política gerada por ferramenta (Iubenda, TermsFeed, Privacy Tools) cobre o básico. Em projeto que coleta dado pessoal sensível (Art. 11 LGPD: saúde, biometria, religião, dado de criança/adolescente), processa pagamento, tem cadastro de usuário ou compartilha dado com terceiros, vale revisar com advogado especialista em LGPD. Custo médio de revisão: R$ 800-2.500 pra documento existente; redação do zero, R$ 2.500-6.000.
Quando vale rodar o checklist de novo?
Sempre que tiver redesign grande, troca de stack (WordPress → Next.js), migração de domínio ou consolidação de URLs. Em sites maduros, revisão trimestral pega itens que degradaram: tracking que quebrou após mudança de pixel ID, schema desatualizado após troca de CMS, política de privacidade velha em relação a nova base de dados coletada. Em ano de novo Core Web Vital (INP entrou em 2024, próximo provável em 2026-2027), revisão imediata.
Próximos passos
Pra refazer ou criar site novo, a página de criação de sites da Huios cobre o processo completo, e o sub-pillar de site com SEO técnico embutido detalha exatamente quais peças deste checklist entregamos de fábrica no código. Pra entender faixa de investimento real em 2026, o guia de quanto custa criar um site profissional tem tabela honesta por porte.
Se o problema é só performance, como aprovar no PageSpeed mobile e como melhorar Core Web Vitals cobrem os ajustes específicos. Pra critério de escolha de fornecedor que vai operar o site depois, como escolher agência de criação de sites lista os 12 pontos de avaliação.
"O melhor momento pra rodar o checklist foi antes do primeiro launch. O segundo melhor é hoje, antes do próximo deploy."
Atualizado em maio de 2026. Próxima revisão prevista: agosto de 2026, ou quando Google publicar nova métrica Core Web Vital.
Publicado em 26 de maio de 2026 · Por Equipe Huios
