Checklist Black Friday WordPress e WooCommerce: O Guia Técnico Completo por Prazo

Checklist técnico completo para preparar WordPress e WooCommerce para a Black Friday, organizado por prazo: 60 dias antes, 30, 7, véspera, o dia e o pós. Com o que verificar e como.

A maioria das lojas que cai na Black Friday não cai por falta de aviso. Cai porque deixou a preparação para a última semana, quando já não dá tempo de corrigir o que precisa de tempo: teste de carga, ajuste de servidor, otimização de banco.

Este é um checklist operacional, organizado por prazo. A lógica é simples: cada item está no prazo em que ele precisa ser feito, não no prazo em que dá vontade de fazer. Coisa que exige tempo de resposta está no começo. Coisa de execução rápida está no fim.

Se você quer entender o raciocínio por trás de cada decisão, eu explico em Black Friday no WordPress: como preparar a loja para aguentar o pico . Aqui é a versão de execução: o que fazer, quando, e como saber se está certo.

📄 Baixe o checklist em PDF. Versão completa para imprimir, marcar item por item e compartilhar com a equipe ou com o cliente. Download livre, sem cadastro: Checklist Black Friday WordPress e WooCommerce (PDF) .


D-60: o que precisa de tempo

Estes itens não são urgentes hoje, mas se você deixar para depois, não dá mais tempo de corrigir o que eles revelarem.

  • [ ] Levantar o pico do ano passado. Visitas simultâneas, pedidos por hora e o momento exato do maior volume. Sem esse número, todo o dimensionamento vira chute. Se não tem histórico, use o maior pico já registrado e multiplique por 3.
  • [ ] Definir a meta deste ano. Quanto você espera vender e quanta gente precisa chegar para isso. É essa meta, não o movimento atual, que define a infraestrutura.
  • [ ] Auditar o estado atual do servidor. CPU, RAM, disco e banco sob carga normal. Se já está apertado no dia comum, não vai aguentar o pico.
  • [ ] Fazer o primeiro teste de carga. Simulando o pico esperado, com foco em checkout, não só na home. Detalho o porquê em checkout do WooCommerce sob carga .
  • [ ] Listar todos os pontos de integração. Gateway de pagamento, cálculo de frete, ERP, antifraude, e-mail transacional. Cada um é um ponto que pode travar sob carga.
  • [ ] Revisar o plano de hospedagem. Se o teste mostrou gargalo, é agora que dá tempo de migrar sem correria. Os critérios estão em melhor hospedagem para WooCommerce no Brasil .

D-30: infraestrutura e performance

Aqui você corrige o que o teste de carga apontou e prepara a base para escalar.

  • [ ] Dimensionar o servidor pelo pico, com folga. A régua prática: o servidor deve rodar a no máximo 50% de uso no pico esperado. O resto é margem para o que você não previu.
  • [ ] Limpar o banco de dados. Revisões antigas de post, transients expirados, tabelas de plugins desinstalados, logs acumulados. Banco inchado é lentidão que aparece justamente sob carga.
  • [ ] Auditar plugins. Desative o que não é essencial. Cada plugin ativo é código rodando a cada requisição. Loja com 60 plugins não sobrevive a pico.
  • [ ] Configurar o cache com critério. Vitrine e categoria em cache agressivo. Carrinho, checkout e minha conta nunca em cache. Se errar aqui, um cliente vê o carrinho do outro.
  • [ ] Otimizar imagens de produto. WebP, dimensões corretas, lazy loading abaixo da dobra. Em loja, imagem costuma ser o maior peso da página.
  • [ ] Medir Core Web Vitals nas páginas que importam. Home, categoria, produto e checkout. O que isso muda em conversão e custo de mídia está em Core Web Vitals no WordPress .
  • [ ] Configurar CDN. Estáticos servidos de perto do cliente aliviam o servidor para o que só ele pode fazer: processar pedido.
  • [ ] Validar backup automático e testar a restauração. Backup que nunca foi restaurado não é backup, é esperança. Veja como fazer backup do WordPress .

D-7: validação e ensaio

Semana de conferir se o que foi feito funciona de verdade. Nada de mudança estrutural aqui.

  • [ ] Repetir o teste de carga com a configuração final. Mesmo cenário do D-60, agora com tudo ajustado. Compare os números e confirme a melhora.
  • [ ] Testar o fluxo de compra ponta a ponta. Do produto ao pagamento aprovado, com cartão, PIX e boleto. Em desktop e celular. Mais gente compra pelo celular do que você imagina.
  • [ ] Testar os cupons e as regras de desconto. Inclusive as combinações que você não planejou: cupom em cima de promoção, frete grátis com desconto, carrinho no limite da regra.
  • [ ] Conferir estoque e sincronização. Se o estoque não baixa em tempo real sob carga, você vende o que não tem, e o problema do dia 28 vira problema do mês inteiro.
  • [ ] Validar e-mails transacionais. Confirmação de pedido, pagamento aprovado, código de rastreio. Sob volume, servidor de e-mail mal configurado entope ou cai em spam.
  • [ ] Configurar monitoramento com alerta real. Uptime, tempo de resposta e erro no checkout, com aviso chegando no celular de alguém que pode agir. Monitorar sem alerta é diário de bordo, não defesa.
  • [ ] Congelar mudanças. A partir daqui, nada de plugin novo, tema atualizado ou "ajuste rapidinho". A maior causa de queda em pico é mudança de última hora.

D-1: véspera

Dia de conferência, não de trabalho novo.

  • [ ] Backup completo, feito no dia. Site e banco. Guardado fora do servidor.
  • [ ] Conferir se o congelamento foi respeitado. Nenhuma atualização automática pendente. Desative update automático de plugin e core.
  • [ ] Checar validade de SSL e domínio. Parece bobagem até acontecer. Certificado vencendo no dia 28 já derrubou muita loja.
  • [ ] Confirmar limites de recurso. Memória do PHP, tempo de execução, conexões simultâneas do banco. O padrão da instalação costuma ser baixo demais para pico.
  • [ ] Deixar o plano de contingência escrito. Quem faz o quê se cair, em que ordem, com que acesso. Escrito, não combinado de cabeça.
  • [ ] Definir quem está de plantão. Com acesso ao servidor, ao painel e ao gateway. Plantão sem acesso é só alguém ansioso olhando o site cair.

Dia D: operação

Durante o pico, sua função é observar e reagir rápido, não otimizar.

  • [ ] Acompanhar o funil em tempo real. Não só visita: carrinho criado, checkout iniciado e pedido aprovado. Queda entre checkout e aprovação é sinal de problema técnico, não de preço.
  • [ ] Monitorar recurso do servidor de hora em hora. CPU, memória e conexões de banco. Subida sustentada avisa antes da queda.
  • [ ] Vigiar a taxa de erro do gateway. Pagamento que falha em volume costuma ser timeout de comunicação, e isso é infraestrutura, não gateway.
  • [ ] Não mexer no que está funcionando. Nenhuma otimização durante o pico. Se está de pé, deixa de pé.
  • [ ] Se cair, seguir o plano escrito. Diagnóstico na ordem definida, sem tentativa e erro. O mapa dos erros mais comuns e como identificar cada um está em erros do WordPress: guia completo .

D+1 a D+7: o pós que quase todo mundo pula

A Black Friday não acaba na sexta. O que acontece depois define se o resultado se sustenta.

  • [ ] Registrar os números reais do pico. Visitas simultâneas, pedidos por hora, tempo de resposta no momento mais pesado. É o insumo do dimensionamento do ano que vem.
  • [ ] Revisar o que travou. Mesmo o que não derrubou a loja. Lentidão pontual no checkout é aviso de gargalo que vai crescer.
  • [ ] Conferir a fila de pedidos e o estoque. Pedido preso, pagamento pendente, estoque estourado. Achar isso no dia 1 é problema pequeno; no dia 15 é problema de reputação.
  • [ ] Confirmar que os e-mails transacionais saíram. Volume alto costuma revelar limite de envio que ninguém sabia que existia.
  • [ ] Descongelar com calma. Reative atualizações e mudanças de forma gradual, não tudo de uma vez.
  • [ ] Calcular o custo do que deu errado. Se houve queda ou lentidão, quanto custou em venda perdida. Esse número é o que justifica investir na infraestrutura antes do próximo pico. A conta está em quanto você perde quando o site cai durante a campanha .

Os cinco erros que mais derrubam loja na Black Friday

Se você só tiver tempo para evitar cinco coisas, evite estas:

  1. Preparar na última semana. Os itens que salvam a loja precisam de tempo de resposta. Na véspera, só dá para conferir.
  2. Testar só a home. Home em cache voa sob qualquer carga. O que cai é o checkout, e ele não é cacheável.
  3. Cachear o checkout. Resolve o teste de velocidade e cria um problema muito pior: vazamento de dados entre clientes.
  4. Mexer no site durante o pico. Atualização, plugin novo ou ajuste "rápido" no dia é a causa mais evitável de queda.
  5. Dimensionar pela média. Servidor que aguenta o movimento normal com folga curta não aguenta um pico de 10x.

Perguntas frequentes

Com quanto tempo de antecedência devo começar a preparar a loja?

Idealmente 60 dias. Não porque a execução leva dois meses, mas porque o primeiro teste de carga pode revelar que você precisa migrar de hospedagem ou reescrever alguma integração, e isso não se faz em uma semana. Com 30 dias ainda dá para fazer um bom trabalho. Com 7, dá para conferir e torcer.

Preciso mesmo de teste de carga ou dá para confiar no plano da hospedagem?

O plano diz o que o servidor tem, não como a sua loja se comporta nele. Duas lojas no mesmo servidor aguentam volumes completamente diferentes dependendo de plugin, tema, banco e integração. Teste de carga é o único jeito de saber o seu número.

O que exatamente não pode entrar em cache numa loja WooCommerce?

Carrinho, checkout, minha conta e qualquer página com conteúdo específico do visitante. O resto — home, categoria, produto, conteúdo institucional — pode e deve ser cacheado agressivamente, justamente para liberar recurso do servidor para o que não é cacheável.

Quanto de folga o servidor precisa ter no pico?

Uma régua prática: no pico esperado, o uso de CPU e memória não deve passar de 50%. A outra metade é margem para o que você não previu, que na Black Friday é sempre mais do que você imagina.

Vale a pena contratar infraestrutura extra só para o período?

Vale, se você conseguir escalar e reduzir com previsibilidade. O erro comum é escalar na véspera sem testar a configuração nova, o que troca um risco conhecido por um desconhecido. Escale com pelo menos uma semana de antecedência e teste depois de escalar.

Minha loja é pequena. Isso tudo se aplica?

O princípio sim, a escala não. Loja pequena não precisa de teste de carga elaborado, mas precisa de backup testado, checkout validado ponta a ponta, cache configurado corretamente e congelamento de mudanças. Esses quatro itens resolvem a maior parte dos problemas em qualquer tamanho.


Se quiser levar este checklist para a reunião, para a equipe ou para o cliente, baixe a versão em PDF . É livre: pode imprimir, compartilhar e distribuir.

Sua loja vai aguentar o pico deste ano?

A Black Friday é o dia em que a infraestrutura da loja é testada de verdade, e o resultado do teste aparece direto no faturamento. Quem preparou com antecedência vende. Quem deixou para a última semana descobre o gargalo no pior momento possível.

A HOSTWP cuida da infraestrutura e da operação de lojas WooCommerce que dependem do pico: dimensionamento pelo volume real, teste de carga antes que o cliente teste, checkout blindado, monitoramento com alerta e plantão 24/7 para emergências.

Quer passar por essa Black Friday sem susto? Fala comigo no WhatsApp . Faço um diagnóstico da sua loja e te digo, com franqueza, o que ela precisa para aguentar.

Artigos relacionados