Luz da injeção acesa durante entrega: checklist do site antes de sair

Checklist completo para validar seu site antes do lançamento. Evite surpresas e garanta entrega tranquila com validações técnicas e visuais essenciais.

Você chega no cliente para a entrega final do site. Tudo aprovado no staging, design pixel-perfect, cliente sorrindo. Na hora de apontar o DNS para produção, o painel acende: erro 500, formulário não envia, analytics mudo, LGPD quebrada. A luz da injeção não mente — seu carro (o projeto) não está pronto para a estrada.

Esse cenário é mais comum do que parece. A euforia da aprovação visual cega a equipe para validações técnicas que só aparecem em produção. O resultado: madrugadas de hotfix, cliente insatisfeito, reputação arranhada. A solução não é trabalhar mais na véspera, mas ter um checklist rigoroso que transforme a entrega em rotina previsível.

Este artigo entrega o checklist que uso em todos os projetos da Betânia Web Designer. Não é teoria — é o que separa lançamentos tranquilos de pesadelos operacionais. Vamos direto ao que impede surpresas.

Validação técnica invisível: o que o cliente não vê, mas sente

O cliente aprova o visual. Ele não valida HTML semântico, headers de segurança ou Core Web Vitals. Isso é sua responsabilidade. Comece pelo código: rode validador W3C, axe-core para acessibilidade e Lighthouse em modo incógnito. Corrija todo erro e alerta crítico antes de mostrar qualquer coisa ao cliente.

Teste cross-browser real, não apenas Chrome DevTools device toolbar. Firefox, Safari (mobile e desktop), Edge. Verifique fontes, grids, animações, formulários. Um botão quebrado no Safari iOS perde conversão silenciosamente. Documente exceções aceitas por escrito com o cliente.

Performance não é opcional. LCP abaixo de 2,5s, CLS abaixo de 0,1, FID abaixo de 100ms em 3G throttled. Otimize imagens (WebP/AVIF, lazy loading), minifique CSS/JS, habilite compressão Brotli/Gzip, configure cache headers longos para assets estáticos. Se o staging roda em servidor fraco, teste em ambiente idêntico ao produção.

Segurança e conformidade: o que vira passivo jurídico

SSL válido é o mínimo. Configure HSTS, CSP restritiva, X-Frame-Options, Referrer-Policy. Elimine mixed content — um único script HTTP em página HTTPS quebra o cadeado e a confiança. Use securityheaders.com para auditar.

LGPD não é sugestão. Banner de cookies deve bloquear scripts não-essenciais até consentimento. Política de privacidade acessível no rodapé. Logs de consentimento armazenados. Teste: recuse todos os cookies e confirme que Google Analytics, Facebook Pixel, Hotjar param de disparar. Se não parou, está irregular.

Formulários são vetor de ataque. Valide server-side, rate-limit, honeypot, CAPTCHA invisível. Teste injeção SQL, XSS, CSRF. E-mails transacionais (confirmação, recuperação de senha, notificação admin) devem chegar na inbox, não no spam. Configure SPF, DKIM, DMARC no domínio do cliente.

SEO técnico e arquitetura de informação: base para tráfego orgânico

Redirecionamentos 301 de URLs antigas para novas — mapeie todas no Screaming Frog antes do lançamento. Sitemap.xml atualizado, robots.txt permitindo rastreamento, meta robots index/follow nas páginas certas, noindex em obrigado/admin/login.

Dados estruturados Schema.org: Organization, WebSite, BreadcrumbList, Article/Service conforme o tipo de página. Teste no Rich Results Test do Google. Canonical tags auto-referenciadas. Hreflang se houver multilíngue.

Arquitetura de informação valida se o usuário encontra o que busca. Como a arquitetura da informação guia o usuário naturalmente explica o método que aplico: card sorting, tree testing, rótulos claros, profundidade máxima de 3 cliques. Se o cliente não entende a navegação no staging, não vai entender em produção.

Integrações e dados: o site não vive sozinho

CRM, ERP, e-mail marketing, WhatsApp Business API, gateways de pagamento — cada integração tem sandbox e produção. Teste em produção com dados reais (mesmo que seja seu CPF, seu cartão de teste). Webhooks devem responder 2xx em < 3s. Logs de erro monitorados.

Analytics e pixels: GA4 configurado com enhanced measurement, eventos customizados (scroll 90%, download, click_tel, click_email), conversões marcadas. Facebook Pixel, Google Ads, LinkedIn Insight Tag — todos disparando nos eventos certos. Use Tag Assistant e network tab para confirmar.

Backup não é opcional. Snapshot completo do banco e arquivos 1h antes do DNS switch. Plano de rollback testado: “se der ruim, volto o DNS e restauro o snapshot em 15 min”. Se não testou o restore, não tem backup — tem esperança.

Homologação com cliente: transformando subjetivo em objetivo

Entregue checklist de validação ao cliente: “Aprove estes 47 itens para eu lançar”. Itens: textos revisados (jurídico + marketing), imagens com alt text, cores/tipografia conforme brandbook, fluxos de compra/contato funcionando, responsividade nos dispositivos dele, aprovação do DPO para LGPD.

Agende sessão de 60 min compartilhando tela. Cliente navega, você anota. Não aceite “depois a gente acerta”. O que não está aprovado não sobe. Use ferramenta tipo Notion ou Planilha com colunas: Item, Status (OK/Pendente/Bloqueador), Responsável, Prazo.

Se o cliente pressiona para lançar com pendências críticas, aplique o termo de ciência: documento assinado listando riscos conhecidos, prazos de correção e isenção de responsabilidade por consequências. Protege ambos os lados.

O dia do lançamento: protocolo de voo

  1. Congela código 24h antes — apenas hotfixes de bloqueadores.
  2. Backup completo verificado.
  3. DNS TTL baixado para 300s (5 min) na véspera.
  4. Switch DNS em horário de baixo tráfego (madrugada ou domingo 6h).
  5. Monitora: uptime (UptimeRobot), logs de erro (Sentry), Core Web Vitals (PageSpeed), formulários (teste real), analytics (eventos chegando).
  6. Checklist pós-lançamento nas primeiras 2h: SSL, redirecionamentos, sitemap indexado (Search Console), integrações, e-mails.
  7. Só avisa cliente “está no ar” após item 6 verde.
  8. Plantão de 4h pós-lançamento para correções imediatas.

Fechamento: entrega é processo, não evento

A luz da injeção acesa não é azar — é sinal de que a revisão foi pulada. Checklist rigoroso transforma lançamento em rotina chata (no bom sentido): previsível, silenciosa, profissional. Seu cliente lembra do site no ar, não da madrugada que você passou corrigindo formulário.

Adote este checklist, adapte à sua stack, torne obrigatório. A diferença entre amador e profissional não é o design — é a entrega.

Pronto para profissionalizar suas entregas? Etapas do briefing ao protótipo validado com o cliente mostra como começar certo desde o dia zero. Elementos de persuasão que transformam visitantes em leads garante que o site convertido. Manutenção preventiva evita falhas no site corporativo mantém o carro rodando depois da entrega.

Checklist prático

0 de 8 concluídos

Perguntas frequentes

Por que a luz da injeção acesa serve como metáfora para lançamento de site?

Assim como o painel do carro alerta sobre problemas no motor antes de uma viagem, o checklist revela falhas invisíveis no código, performance ou conteúdo que só aparecem em produção. Ignorar esses sinais garante retrabalho e estresse no dia do go-live.

Qual a diferença entre homologação interna e validação com o cliente?

A homologação interna foca em requisitos técnicos: performance, acessibilidade, segurança e compatibilidade cross-browser. A validação com o cliente verifica se o negócio está representado corretamente: textos, fluxos de conversão, identidade visual e aprovações legais. Ambas são obrigatórias.

Como priorizar correções quando o checklist revela muitos itens?

Classifique em três níveis: bloqueadores (que impedem o lançamento), críticos (que degradam a experiência mas permitem ir ao ar com plano de correção) e melhorias (para o backlog pós-lançamento). Negocie com o cliente apenas os dois primeiros antes do go-live.

O que fazer se o cliente quiser lançar mesmo com itens críticos pendentes?

Documente os riscos por escrito, assine um termo de ciência com o cliente e defina prazos curtos para correção pós-lançamento. Nunca lance sem registro formal — isso protege sua reputação e evita disputas futuras sobre responsabilidade.

Com que frequência devo revisar este checklist?

Atualize a cada projeto relevante: novas integrações, mudanças de legislação (LGPD, acessibilidade), evolução de navegadores ou feedbacks de pós-venda. Um checklist estático vira burocracia; um vivo vira garantia de qualidade.

Quem busca confiança leva o carro até alinhamento 3D em São Paulo para troca de óleo, freios, suspensão e alinhamento com garantia.