Checklist para lançar uma loja WooCommerce: o que conferir antes de publicar

A loja está de pé: hospedagem, instalação, adaptações brasileiras, pagamentos, frete, tema, plugins, segurança e performance — tudo pronto. Falta a última inspeção antes de abrir as portas.

Você está na Etapa 9, a etapa final do guia completo de como criar uma loja WooCommerce no Brasil. Este é o checklist de lançamento de loja WooCommerce: a conferência que separa uma loja pronta de uma loja que abre com configuração de teste, página incompleta ou e-mail que não chega.

A promessa é objetiva: conferir, testar, limpar e abrir. Você revisa cada bloco — backup, catálogo, pagamentos, frete, checkout, e-mails, segurança, SEO e analytics — e testa o fluxo de compra inteiro sem gastar um real, no modo de teste do gateway.

Nada aqui reensina as etapas anteriores: cada seção confere um ponto e aponta para o artigo da série que aprofunda. Ao final, loja verificada, conteúdo provisório removido e um roteiro claro para as primeiras 72 horas.

Neste guia

• Checklist de lançamento de loja WooCommerce: a última inspeção antes de abrir
• Backup e restauração: a garantia de voltar atrás
• Domínio, HTTPS e acesso público
• WordPress, WooCommerce, tema e plugins: versões em dia
• Dados da loja: o básico que aparece em tudo
• Produtos e catálogo: nada de teste na vitrine
• Estoque: quantidades, avisos e produtos virtuais
• Adaptação ao Brasil: CPF, CNPJ, CEP e endereço
• Pagamentos: produção, testes e status de pedido
• Frete: zonas, métodos e cenários reais
• Impostos: configuração coerente
• Carrinho e checkout: o teste central
• E-mails transacionais: o que precisa chegar
• Conta do cliente: o ciclo completo
• Páginas institucionais e legais
• Menus, links e busca
• Mobile e navegadores: o teste no aparelho real
• Performance: a linha de base confirma
• Segurança: administradores, senhas e 2FA
• SEO técnico: o Google precisa encontrar a loja
• Analytics: medir desde o primeiro dia
• Remover conteúdo e configurações de teste
• Teste final ponta a ponta
• O momento do lançamento
• As primeiras 24 a 72 horas
• Sinais de que a loja ainda não está pronta
• Checklist mestre final
• Erros comuns
• Quando chamar um especialista
• Perguntas frequentes

Checklist de lançamento de loja WooCommerce: a última inspeção antes de abrir

Este checklist segue uma ordem: primeiro a garantia de voltar atrás, depois o que o cliente vê e usa, por fim a limpeza e o momento de abrir. Percorra as seções na ordem — cada uma prepara a seguinte.

Três regras para a conferência valer de verdade:

• Separe de 1 a 2 horas e percorra o checklist inteiro de uma vez, sem pressa.
• Use um aparelho real — de preferência o celular, onde grande parte dos clientes compra — e uma janela anônima (ou privativa), para simular um visitante de verdade, sem cache e sem sessão logada.
• Não faça mudanças grandes agora. Atualização de versão, troca de tema ou plugin novo ficam para depois do lançamento, com backup e teste. A véspera de abrir é hora de conferir, não de experimentar.

Backup e restauração: a garantia de voltar atrás

Um backup que nunca foi restaurado é uma esperança, não uma garantia. Como vimos no guia de segurança e backup da série, backup não é só existir — é ser restaurado.

• Backup recente: feito depois da última mudança na loja, guardado fora do servidor (no mínimo em dois lugares).
• Restauração testada: você, ou o provedor, já restaurou a partir dele em algum momento — só assim sabe que funciona.
• Backup novo antes de qualquer mudança: qualquer ajuste feito durante esta conferência começa com uma cópia nova.

Se o backup está em dia, cada item deste checklist pode ser corrigido sem medo. Se não está, pare aqui: a restauração testada é o item que não fica para depois.

Domínio, HTTPS e acesso público

O cliente precisa chegar à loja pelo endereço certo, com conexão segura e sem barreiras no caminho.

• Domínio certo: o endereço público (com ou sem www, como você definiu) abre a loja — e não uma página de staging (ambiente de testes) ou uma cópia provisória.
• HTTPS válido: o cadeado aparece no navegador, sem alerta de certificado. Qualquer erro aqui afasta o cliente na primeira tela.
• Sem senha bloqueando: se a loja ainda está protegida por senha, plugin de manutenção ou modo “coming soon”, o visitante não entra. Lojas novas que concluem o assistente de configuração do WooCommerce nascem em modo “Coming soon” — a documentação oficial da Visibilidade do site mostra onde conferir: WooCommerce > Configurações > Visibilidade do site deve estar em “Live”.
• Acesso de fora: teste a loja de outra rede — dados móveis, por exemplo — como um cliente de verdade faria.

A base disso foi definida na escolha de hospedagem da série; aqui o papel é conferir que nada bloqueia o acesso.

WordPress, WooCommerce, tema e plugins: versões em dia

Versões desatualizadas são risco de segurança e causa comum de erro inesperado. A conferência é rápida:

• Versões: WordPress, WooCommerce, tema e plugins em versões suportadas e compatíveis entre si, com as correções de segurança relevantes aplicadas — com atenção especial ao WooCommerce e aos plugins de pagamento e frete.
• Saúde do site: em Ferramentas > Saúde do site, a aba Status deve mostrar nenhum problema crítico. A documentação da tela explica cada item — versão do PHP, loopback, atualizações pendentes.
• Compatibilidade: os plugins que a loja usa declaram compatibilidade entre si e com a versão do WooCommerce — a régua de escolha está na escolha de tema e plugins essenciais.
• Sem atualização grande agora: nenhuma atualização crítica pendente — mas não é preciso instalar uma nova versão maior só para ficar “na mais recente” na véspera. Atualização de versão maior entra depois do lançamento: com backup, teste e validação antes da produção — a menos que seja uma correção de segurança.
• Plugins sem uso removidos: o que sobrou de testes sai antes de abrir.

Dados da loja: o básico que aparece em tudo

Informação de loja errada gera erro de frete, imposto e e-mail. Confira em WooCommerce > Configurações > Geral e > Produtos:

• Nome e endereço da loja, país e estado — base do cálculo de frete e impostos.
• Moeda em BRL, com formato brasileiro (R$ 10,00).
• Unidades de peso e dimensão em kg e cm, definidas na instalação conforme o guia de instalação e configuração.
• Fuso horário e e-mail administrativo do site — os destinatários dos e-mails administrativos do WooCommerce (novo pedido, cancelado, falhou) são configurados em WooCommerce > Configurações > E-mails (por padrão, o e-mail administrativo); confira os dois.
• Remetente dos e-mails: o nome e o endereço que aparecem como origem das mensagens.
• Dados de contato públicos: endereço, telefone, WhatsApp, redes sociais.

Produtos e catálogo: nada de teste na vitrine

A vitrine é o que o cliente vê primeiro. A conferência, produto por produto:

• Preços: corretos, com promoções conferidas — inclusive as datas de início e fim (uma promoção que não começa ou não termina é erro visível na loja).
• SKUs: únicos, sem duplicidade — importantes para estoque e integrações.
• Variações: todas as combinações com preço, imagem e estoque próprios, sem variação órfã.
• Imagens com texto alternativo descritivo — útil para acessibilidade e para o Google entender o produto.
• Descrições completas, sem texto provisório.
• Categorias e atributos organizados — facilitam menu, busca e filtros.
• Visibilidade: cada produto visível na vitrine — rascunhos incompletos e produtos de teste não podem aparecer.

Estoque: quantidades, avisos e produtos virtuais

Estoque errado gera dois problemas: vender o que não existe e recusar o que existe. A documentação oficial de produtos cobre as configurações em WooCommerce > Configurações > Produtos > Inventário:

• Gerenciar estoque ativado nos produtos físicos, com quantidades reais — o que está no sistema precisa bater com o que está na prateleira.
• Manter estoque reservado por X minutos (hold stock): o tempo que um pedido segura a unidade antes de devolvê-la — evita vender a mesma unidade duas vezes.
• Aviso de estoque baixo: o limite que dispara a notificação de reposição.
• Backorders (venda com estoque esgotado): a escolha entre permitir, avisar ou não permitir — e o comportamento que o cliente vê quando o produto esgota.
• Produtos virtuais e baixáveis (serviços, e-books, assinaturas): Virtual significa que o produto não requer envio; Downloadable adiciona os arquivos e as regras de download. Um produto marcado assim dispensa peso e dimensões — o frete não é calculado para ele —, mas o gerenciamento de estoque continua disponível e pode fazer sentido (uma vaga de consultoria, por exemplo). A conferência: cada produto marcado conforme o que realmente é, com o estoque ligado ou desligado de propósito.

Como vimos no guia de instalação e configuração, cada produto carrega as próprias medidas e controle — a conferência é item por item nos produtos que vendem.

Adaptação ao Brasil: CPF, CNPJ, CEP e endereço

A base disso está no guia de adaptações para o Brasil. Aqui, o teste de conferência:

• Campos de CPF/CNPJ aparecendo e validando no checkout — para pessoa física e jurídica, quando a loja atende as duas.
• CEP com validação de formato — e o preenchimento automático de endereço, se você usa, funcionando.
• Endereço com número e bairro: campos presentes no checkout — sem eles, o cliente não completa a compra e o frete calcula errado.
• Teste com três documentos: um CPF, um CNPJ numérico e um CNPJ alfanumérico — a Receita Federal iniciou a implantação gradual do CNPJ com letras em 2026, e a loja precisa aceitar o formato quando o cliente tiver um.

Um campo brasileiro que falha no teste é venda perdida na hora da compra.

Pagamentos: produção, testes e status de pedido

O guia de pagamentos da série mapeou os provedores e seus modos de teste. A conferência final:

• Gateway em produção (live): credenciais de produção ativas — nenhuma chave de teste esquecida na configuração.
• Métodos anunciados: Pix, cartão e boleto exatamente como a loja divulga — nada de prometer no site o que não está ativo no checkout.
• Webhook (notificação automática que o provedor envia ao WooCommerce quando um pagamento é confirmado): ativo, se o provedor exige — é ele que atualiza o pedido.
• Status de pedido: pagamento aprovado muda o pedido para Processing (processando) — exceto quando todos os itens são virtuais e baixáveis, caso em que o pedido pode ir direto para Concluído. A lista oficial de status explica o fluxo: pago = Processando, recusado = Falhou (e o estoque volta), reembolsado = Reembolsado.
• Falha, cancelamento e reembolso testados: não só o caminho feliz — o cliente que erra o cartão precisa de mensagem clara e de uma segunda tentativa que funcione.
• E-mails de pagamento: confirmação e falha chegam ao cliente.

E a regra de ouro: use o modo de teste. Teste no sandbox ou no modo de teste do gateway escolhido — os provedores brasileiros mapeados no guia de pagamentos da série têm, conforme o caso — usando os cartões, QR codes e dados de teste que ele fornece. É lá que os testes acontecem: sem gastar e sem poluir o histórico. Se depois da abertura você fizer uma compra real de validação, consulte antes a política do gateway sobre reembolso e tarifas — algumas taxas podem não ser devolvidas.

Frete: zonas, métodos e cenários reais

O guia de frete da série detalhou zonas, métodos e integrações — Correios e transportadoras. A conferência:

• CEP de origem correto (o endereço da loja em Configurações > Geral).
• Zonas e métodos como o negócio opera: PAC/SEDEX, transportadora, frete grátis (com o valor mínimo certo), retirada local.
• Peso e dimensões por produto preenchidos — sem eles, o cálculo falha ou cobra errado.
• Prazos exibidos ao cliente, em dias úteis — como os Correios calculam.
• Cenário fora da área: o que o cliente vê quando o CEP não é atendido — mensagem clara, não erro de página.
• Carrinho com múltiplos produtos: o cálculo combinado fecha — o frete de três itens não é a soma de três fretes individuais, a menos que a configuração diga isso.

Um frete que erra no teste é um pedido que não sai — ou um cliente reclamando antes de a loja completar uma semana.

Impostos: configuração coerente

Se a loja calcula impostos, a conferência é de coerência — não de lei:

• Cálculo ativado e configurado de forma condizente com o que a loja vende.
• Exibição de preços definida: com ou sem imposto — e igual em todo o fluxo (produto, carrinho, checkout).
• Produtos físicos × digitais: classes de imposto separadas quando o tratamento é diferente.
• Validação com contador: se o negócio exige emissão fiscal, a configuração do WooCommerce é uma coisa — a obrigação fiscal é outra. Quem valida é o contador, e este guia não substitui essa conversa.

A regra é simples: imposto mal configurado aparece como preço errado — e preço errado no checkout é abandono de compra.

Carrinho e checkout: o teste central

Este é o bloco que decide a venda: o fluxo inteiro de compra, do botão “Adicionar” ao pedido recebido. Faça em janela anônima, como visitante:

• Adicionar e remover produto; mudar a quantidade.
• Selecionar variação (cor, tamanho) e conferir preço e imagem atualizando.
• Aplicar cupom válido (desconto certo) e cupom inválido (mensagem de erro amigável).
• Calcular frete com CEP real e conferir os totais — subtotal, frete, desconto, imposto.
• Fazer o checkout como visitante (sem login) e como cliente logado — os dois fluxos existem.
• Criar conta no checkout, se a loja oferece.
• Testar campos obrigatórios e mensagens de validação — deixe um campo vazio de propósito.
• Finalizar com pagamento aprovado em modo de teste e com pagamento falho — os dois caminhos.
• Conferir a página de pedido recebido, com resumo e instruções claras.

Qualquer erro aqui — campo que não valida, cálculo errado, página que não avança — é venda perdida. É o teste que mais vale do checklist inteiro.

E-mails transacionais: o que precisa chegar

O WooCommerce envia e-mails em momentos-chave da compra. A documentação oficial de e-mails lista todos os e-mails nativos — entre eles, os do fluxo de compra: novo pedido (para o lojista), processando, concluído, cancelado, reembolsado, nota ao cliente, redefinição de senha e novo cadastro. A conferência:

• Cada e-mail chega — com o pedido de teste, você acompanha a sequência real.
• Remetente correto: nome e endereço configurados em WooCommerce > Configurações > E-mails — mensagem vinda de um remetente estranho derruba a confiança.
• Links funcionam: confirmar endereço, redefinir senha, ver pedido.
• Entrega real: confira também a caixa de spam. Se o envio atual não entrega com confiabilidade, um provedor de e-mail transacional/SMTP pode ajudar — mas a entrega também depende da configuração do domínio e da autenticação, e só se confirma testando: faça um pedido de teste e confira a chegada, inclusive no spam.

O e-mail de redefinição de senha também precisa ser testado — é o caminho de volta do cliente que esquece a senha na primeira compra.

Conta do cliente: o ciclo completo

Se a loja tem área do cliente, o ciclo funciona de ponta a ponta:

• Cadastro — e confirmação de e-mail, se ativa.
• Login e logout.
• Recuperação de senha — e-mail chega, link funciona.
• Meus pedidos, com histórico e status corretos.
• Endereços de entrega e cobrança editáveis.
• Downloads funcionando para produtos digitais.
• Dados pessoais acessíveis — o WordPress oferece ferramentas de exportação e apagamento de dados (detalhe na próxima seção).

Tudo isso no celular: grande parte dos clientes acessa a área do cliente pelo aparelho.

Páginas institucionais e legais

Páginas de confiança — a falta delas é motivo comum de desistência:

• Contato: formulário ou e-mail funcionando, com resposta chegando.
• Sobre a loja.
• Privacidade: o WordPress tem ferramentas nativas para criar a política e para exportar e apagar dados pessoais — a documentação oficial de privacidade explica cada uma. Importante: essas ferramentas não são um processo de conformidade em si — a política precisa refletir o que a loja realmente faz com os dados, e a validação com advogado ou contador é recomendável quando o negócio exige.
• Termos de uso e troca/devolução: prazos, condições e como o cliente aciona.
• Entrega e frete: prazos, regiões atendidas, custos.

Dois avisos honestos: banner de cookies sozinho não garante conformidade com a LGPD — e este guia não dá aconselhamento jurídico. O que a loja precisa é de páginas reais, corretas e acessíveis; a validação legal é conversa com profissional.

Menus, links e busca

• Menu desktop e mobile: categorias principais alcançáveis em até dois toques.
• Logo linkando para a home, em todas as páginas.
• Rodapé completo: páginas institucionais, contato, redes sociais.
• Links quebrados: clique em cada link importante — um 404 na página de troca é péssimo na primeira visita.
• Breadcrumbs (o caminho de navegação, como “Home > Categoria > Produto”) funcionando, se o tema usa.
• Busca: resultados certos para um produto conhecido — e resultado vazio tratado (mensagem amigável com sugestões, não tela em branco).
• Redes sociais e WhatsApp, se a loja divulga: links abrem e apontam para os perfis certos.

Mobile e navegadores: o teste no aparelho real

Grande parte das compras acontece no celular — e o teste precisa acontecer lá também, com dados móveis (desligue o Wi-Fi) e em aparelho real, não só no modo responsivo do navegador do computador:

• Fluxo completo no celular: menu, busca, produto, variações, carrinho, checkout, pagamento.
• Formulários, botões, popups e chat: nada sobreposto, nada cortado, nada que não responde ao toque.
• Fontes e áreas de toque confortáveis — o toque acidental que adiciona o produto errado ao carrinho é real.
• Navegadores: Chrome, Edge, Safari e Firefox, conforme os aparelhos disponíveis — no mínimo Chrome (desktop e celular) e Safari (iPhone).
• Desktop e celular: os dois fluxos, os dois ambientes.

O teste no aparelho real é o que separa a loja que “funciona no meu computador” da loja que funciona para o cliente.

Performance: a linha de base confirma

A performance foi preparada no guia de performance da série. Na véspera do lançamento, o papel é confirmar a linha de base — o registro datado da velocidade — e garantir que nada a quebrou:

• Linha de base registrada: datas, páginas e valores das medições — home, produto, checkout, desktop e mobile.
• Páginas principais testadas de novo: a comparação mostra se algo mudou desde a otimização.
• Cache com as exclusões certas: carrinho, checkout e minha conta fora do cache — uma cópia fixa dessas páginas mostra carrinho errado e dados de outra pessoa.
• Imagens tratadas e scripts controlados — sem serviço externo novo de última hora.
• Mobile medido: é onde a lentidão mais aparece.
• Cache, minificação e CDN não quebram o fluxo: depois de qualquer otimização, o teste de compra refaz — a funcionalidade do checkout vem antes de qualquer ganho de velocidade.

Se a loja está rápida na medição e o checkout flui no aparelho real, a performance está pronta.

Segurança: administradores, senhas e 2FA

O guia de segurança e backup da série preparou as camadas de proteção. A conferência final:

• Usuários administradores: apenas quem precisa — usuários de teste e contas esquecidas saem antes de abrir.
• Senhas fortes em todas as contas — ataques automatizados testam combinações comuns o tempo todo.
• 2FA (verificação em duas etapas) ativa nas contas administrativas — uma camada extra que vale especialmente no lançamento, quando a loja começa a aparecer na internet.
• Atualizações em dia — conferidas na seção de versões.
• Backup testado — conferido na primeira seção.
• HTTPS ativo em toda a loja.
• Nenhuma credencial exposta: senha, chave de API ou token em arquivo, código ou anotação pública — credenciais ficam em gerenciador de senhas, não em anotações.

Boa parte das invasões explora os mesmos três pontos: credencial fraca, plugin desatualizado ou backup inexistente. A loja que abre segura nasce segura.

SEO técnico: o Google precisa encontrar a loja

O Google encontra a loja por sinais técnicos — e a referência aqui é o Search Central, a documentação oficial do Google. A conferência é de existência e coerência:

• Title e meta únicos por página: a home tem o título da marca; cada produto e categoria tem o próprio.
• Canonical: a tag rel=canonical — que indica a versão oficial de uma página — é gerada pelo WordPress para páginas de consulta singular (como produto e post), conforme a referência oficial da função; temas e plugins de SEO podem assumir ou ajustar essa emissão. A conferência é no resultado: veja o canonical realmente renderizado nas páginas importantes (home, produto e categoria) — e, se tema ou plugin de SEO gerencia o canonical, valide o resultado final. Não confunda com redirecionamento: se www e não-www (ou HTTP e HTTPS) respondem os dois, eles precisam redirecionar para uma única versão — isso é configuração de servidor, não de página.
• Sitemap (o mapa das páginas da loja): o WordPress normalmente expõe o arquivo em /wp-sitemap.xml, mas plugins de SEO podem substituir ou desativar o sitemap nativo e usar outro endereço. A conferência: identifique o sitemap efetivamente ativo na loja — o endereço real, que costuma aparecer nas configurações do plugin ou no robots.txt — e envie esse endereço no Search Console, onde o relatório Sitemaps mostra se o Google conseguiu ler.
• robots.txt (arquivo de instruções para os robôs de busca): sem bloqueio acidental de páginas importantes.
• noindex: páginas que não devem aparecer no Google marcadas como não indexáveis. O WooCommerce aplica X-Robots-Tag: noindex a endpoints internos — como a página de pedido recebido — e a downloads protegidos; já o tratamento das páginas-base de carrinho, checkout e minha conta pode depender do WordPress, do tema, de um plugin de SEO e da configuração. A conferência é no que cada página realmente entrega: use a Inspeção de URL do Search Console, mantenha fora do índice as páginas de transação e sessão que não fazem sentido em busca — e garanta que home, produtos e categorias que devem aparecer não estão com noindex.
• Indexáveis × não indexáveis: a loja (indexar) e as páginas dinâmicas de sessão (não indexar) na ordem certa — sem noindex esquecido na home.
• H1 único por página e URLs limpas, sem números e símbolos.
• Texto alternativo nas imagens — conferido na seção de produtos.
• Dados estruturados: se o tema ou um plugin gera marcação de Product e Breadcrumb (dados que ajudam o Google a exibir a loja com destaque nos resultados), confira que aparecem corretos.
• 404 real: uma URL inexistente mostra uma página de erro amigável — não uma tela branca.

O passo final: Google Search Console verificado como proprietário da loja, com a Inspeção de URL testando a home e o relatório Sitemaps confirmando a leitura do sitemap ativo — o endereço real da loja, que pode não ser o /wp-sitemap.xml quando um plugin de SEO assumiu o sitemap.

Analytics: medir desde o primeiro dia

O primeiro dia da loja é o dia zero dos dados — sem uma solução de medição, o lançamento é cego. A documentação oficial de e-commerce do GA4 (Google Analytics 4) define o padrão:

• GA4 ou equivalente instalado em todas as páginas — o evento page_view dispara a cada visita.
• Eventos de e-commerce: view_item (ver produto), add_to_cart (adicionar ao carrinho), begin_checkout (iniciar checkout) e purchase (compra concluída), com a moeda configurada em BRL.
• Compra sem duplicar: a deduplicação no GA4 usa o transaction_id do pedido — cada pedido é contabilizado uma única vez quando a implementação envia um transaction_id único, evita disparos duplicados da tag ou do evento e é testada em modo de depuração ou no relatório Realtime antes de abrir. A conferência é confirmar que cada pedido é contabilizado uma única vez — pedidos de teste repetidos são o motivo clássico de conversão duplicada (e é por isso que eles saem, como você verá adiante).
• Consentimento: se a loja usa banner de cookies, o carregamento do analytics respeita a escolha do visitante. Banner não é conformidade LGPD — é uma peça da conversa, não a conversa inteira.
• Pixels de Ads e Meta, se a loja anuncia: instalados e testados, com o evento de compra disparando.
• Search Console vinculado ao GA4 (opcional): a busca e o comportamento de compra se enxergam no mesmo lugar — útil, mas não é requisito de lançamento.

Com analytics testado e eventos conferidos, o primeiro dia da loja já nasce com dados — e os primeiros problemas aparecem no relatório, não na reclamação do cliente.

Remover conteúdo e configurações de teste

A loja está quase pronta — agora a limpeza. Cada item de teste deixado para trás é risco: um pedido de teste pode ser expedido por engano, e dado de teste contamina o Analytics.

• Pedidos de teste: a documentação oficial do WooCommerce é direta — pedidos de teste não têm marcação visual própria, disparam e-mails e entram no Analytics, e a recomendação é excluí-los para que não sejam tratados ou expedidos por engano. Se o gateway registra pedidos de teste próprios, use a ferramenta que ele oferece — alguns provedores disponibilizam em WooCommerce > Status > Ferramentas (confira o manual do seu).
• Produtos de teste: removidos — não apenas escondidos.
• Cupons de teste: um cupom “TESTE10” esquecido ativo é um desconto que alguém vai achar.
• Banners e avisos provisórios de qualquer tipo.
• Usuários de teste — contas administrativas que sobraram de testes (como visto na seção de segurança).
• Chaves de teste e sandbox: credenciais de desenvolvimento fora da configuração de produção.
• Conteúdo provisório: lorem ipsum, páginas exemplo, widgets vazios, imagens provisórias, contatos falsos.
• Coming soon desligado — a loja em “Live”, como conferido na seção de acesso público.

Uma regra de ouro: nunca apague dados reais indiscriminadamente. Pedidos de teste saem; pedidos reais, clientes e histórico ficam. E a retenção fiscal ou legal de documentos é conversa com o contador — não decida sozinho o que apagar.

Teste final ponta a ponta

Com tudo conferido e limpo, o ensaio geral — o fluxo completo, como um cliente real faria:

1. Produto → carrinho, com variação quando houver.
2. Cupom aplicado — e um cupom inválido, para conferir a mensagem de erro.
3. Frete calculado com CEP real.
4. Checkout preenchido com dados de teste.
5. Pagamento aprovado em modo de teste.
6. Página de pedido recebido com resumo correto.
7. E-mail de confirmação chegando — o do cliente e o do lojista.
8. Pedido aparecendo no painel com o status certo.
9. Cancelamento e reembolso, quando aplicável — e o estoque voltando.

Faça esse roteiro duas vezes: em janela anônima (visitante) e logado. Se os dois passarem, o fluxo de compra está validado.

O momento do lançamento

A hora de abrir tem ordem — sete passos:

1. Backup final da loja como está — a última cópia antes de abrir.
2. Monitoramento pronto: logs ativos, analytics testado, Search Console verificado.
3. Remover o bloqueio: Visibilidade do site em “Live” — e qualquer plugin de manutenção ou coming soon desativado.
4. Abrir: a loja pública para o mundo.
5. Compra de validação: com a loja aberta, uma compra pequena sua — ou de alguém de confiança — confirma o fluxo real de ponta a ponta. Reembolse em seguida — consulte antes a política do gateway sobre reembolso e tarifas, porque algumas taxas podem não ser devolvidas.
6. Acompanhar erros e pedidos de perto: os primeiros pedidos reais, os e-mails, os status — olho clínico nas primeiras horas.
7. Evitar mudanças grandes: nada de atualização de tema, plugin novo ou reconfiguração na primeira semana — mudança grande entra com backup, teste e calma.

O lançamento de uma loja virtual é um momento de transição: a loja sai do seu controle direto e passa a ser testada pelo mercado. A ordem acima garante que ela chegue inteira a esse teste.

As primeiras 24 a 72 horas

A loja aberta, o trabalho muda de fase: de preparação para operação. O roteiro dos primeiros três dias:

• Pedidos: cada pedido real aparece no painel, com e-mail chegando e status correto.
• Pagamentos: confirmações do gateway batendo com os pedidos — nada de pedido “pendente” que já foi pago.
• E-mails: novo pedido, processando, concluído — todos chegando, inclusive sem cair no spam.
• Frete: o primeiro pedido expedido sem tropeço — etiqueta, código de rastreio, aviso ao cliente.
• Checkout: sem erro reportado — e o teste de compra refeito no segundo dia.
• Tarefas agendadas: em WooCommerce > Status, o relatório de sistema mostra o ambiente (em “production”) e o estado do WP-Cron — a documentação oficial do relatório explica a tela. Ações agendadas sem pendências acumuladas.
• Logs: o WooCommerce registra erros em WooCommerce > Status > Logs — uma olhada diária nos primeiros dias.
• Performance e disponibilidade: a loja responde — uma checagem rápida por dia basta.
• Mensagens e contato: formulário, WhatsApp e e-mail de contato respondidos — o primeiro cliente que chega precisa de resposta.
• Analytics: os primeiros dados reais aparecendo — e a compra de validação sem duplicar a conversão, conferido no Realtime.

As primeiras 72 horas são o período de adaptação. Os problemas que aparecem nelas são os mais baratos de resolver — a loja ainda tem poucos pedidos e o histórico ainda é pequeno.

Sinais de que a loja ainda não está pronta

Se qualquer um destes sinais aparecer na conferência, a loja ainda não abre:

• Gateway em sandbox ou modo de teste — nenhum cliente vai conseguir pagar.
• Checkout sem teste completo — o fluxo de compra inteiro ainda não foi percorrido.
• Frete sem cenário real — nenhum cálculo com CEP de verdade foi conferido.
• E-mail que não chega — nem o seu, nem o do cliente.
• HTTPS com erro — alerta de certificado no navegador.
• Sem backup testado — a restauração nunca foi validada.
• Páginas importantes ausentes — contato, privacidade, troca/devolução.
• Produtos incompletos — sem preço, sem imagem, sem estoque.
• Mobile quebrado — o fluxo falha no aparelho real.
• Cache servindo carrinho e checkout — páginas dinâmicas guardadas como cópia fixa.
• noindex ou coming soon ativo — a loja invisível para o Google ou para o cliente.
• Admin compartilhado — senha de administrador na mão de quem não precisa.
• Erros recorrentes — o mesmo erro aparece em testes repetidos.

Nenhum desses itens é motivo para desespero — todos têm solução documentada na série. São o sinal de que falta uma etapa, não de que a loja é ruim.

Checklist mestre final

Checklist mestre de lançamento

Infraestrutura

• Backup recente com restauração testada
• Backup novo antes de cada mudança
• Domínio certo e HTTPS sem erros
• Visibilidade do site em “Live” — sem senha ou coming soon
• Versões suportadas e compatíveis, com correções de segurança aplicadas
• Saúde do site sem problemas críticos
• Plugins sem uso removidos

Catálogo

• Dados da loja corretos (nome, endereço, moeda BRL, unidades, fuso, e-mails)
• Produtos com preço, SKU, variações, imagens com texto alternativo e visibilidade certa
• Estoque real, aviso de estoque baixo, hold stock e backorders definidos

Brasil

• CPF, CNPJ numérico e CNPJ alfanumérico aceitos no checkout
• CEP validado e endereço com número e bairro

Pagamentos e frete

• Gateway em produção, sem chave de teste
• Pix, cartão e boleto testados em modo de teste
• Status de pedido correto após o pagamento
• Zonas, métodos, pesos e prazos de frete conferidos
• Impostos com configuração coerente

Checkout e e-mails

• Fluxo completo testado — produto → pagamento → pedido recebido
• Cupom válido e inválido testados
• E-mails transacionais chegando, inclusive redefinição de senha
• Conta do cliente funcionando no celular

Páginas, segurança e performance

• Páginas institucionais e legais publicadas
• Menus, links, busca e 404 funcionando
• Mobile e navegadores testados em aparelho real
• Administradores, senhas e 2FA em dia
• Linha de base de performance registrada e confirmada
• Cache sem tocar em carrinho e checkout

SEO, analytics e limpeza

• Títulos, canonical, sitemap, robots e noindex conferidos
• Search Console verificado e sitemap enviado
• Solução de analytics, se utilizada, configurada e com os eventos principais de e-commerce testados
• Pedidos, produtos, cupons e usuários de teste removidos
• Teste final ponta a ponta aprovado

Erros comuns

1. Lançar com o gateway em modo de teste. A loja abre, o cliente tenta pagar e não consegue — e ninguém descobre antes do primeiro pedido perdido.
2. Não testar o checkout. A página mais importante da loja segue sem um único pedido de teste concluído.
3. Deixar pedidos de teste no painel. Podem ser expedidos por engano e contaminam o Analytics — a documentação oficial recomenda removê-los.
4. Abrir com chave de teste ou sandbox na configuração. Credencial de desenvolvimento no meio da produção.
5. E-mail que nunca foi testado. A loja abre e ninguém descobre que os e-mails de pedido caem no spam — ou nem saem.
6. Coming soon ou senha esquecidos ativos. A loja “abre” e o cliente vê uma página de manutenção.
7. Cache guardando carrinho e checkout. O cliente vê carrinho errado ou dados de outra pessoa.
8. Lançar sem backup testado. A primeira atualização ou erro vira crise — e o backup que nunca foi restaurado não ajuda.
9. Produto de teste ou “lorem ipsum” na vitrine. O primeiro cliente vê o que não deveria ver.
10. Fazer mudança grande na véspera. Atualizar o tema ou trocar plugin horas antes de abrir é a receita clássica do lançamento quebrado.
11. Testar só no desktop, logado e com Wi-Fi. O cliente real compra no celular, anônimo e com dados móveis.
12. Abrir sem analytics e sem Search Console. O primeiro dia da loja vira um buraco negro de dados — e os primeiros problemas passam despercebidos.

Quando chamar um especialista

Alguns cenários passam do que o painel resolve — e é melhor resolver antes de abrir:

• Revisão técnica pré-lançamento: você quer um par de olhos experiente na loja antes do dia D.
• Diagnóstico de checkout: campo que não valida, cálculo errado, página que não avança — e o checklist não resolveu.
• Integrações sensíveis: gateway, frete, ERP ou e-mails com comportamento estranho que você não consegue explicar.
• Performance fora do esperado: a loja segue lenta mesmo com o processo do guia de performance aplicado.
• Segurança: suspeita de acesso indevido, usuário desconhecido ou plugin com comportamento estranho.

Se a loja ainda não está no ar, o momento de trazer ajuda é agora — antes de abrir, não depois do primeiro problema:

Lançar com confiança: revisão técnica antes do dia D.

• Conferência de checkout, pagamentos, frete e e-mails
• Segurança, backup e performance verificados
• Ajustes finais sem quebrar o que já funciona

Solicitar análise inicial da minha loja

Perguntas frequentes

Como saber se minha loja WooCommerce está pronta para lançar?

Percorra este checklist de ponta a ponta, na ordem: backup testado, acesso público, versões, catálogo, pagamentos, frete, checkout, e-mails, segurança, SEO e analytics — e termine com o teste final em modo de teste e a remoção do conteúdo provisório. Se o fluxo de compra completo passou no aparelho real e nenhum dos sinais da seção “ainda não está pronta” apareceu, a loja está pronta. Não existe nota universal — existe inspeção completa.

Preciso fazer uma compra real antes de abrir?

Não — para isso existe o modo de teste: o sandbox ou o ambiente de testes do gateway escolhido, com os cartões e dados de teste que ele fornece. Os provedores brasileiros mapeados no guia de pagamentos da série oferecem, conforme o caso. A única compra real recomendada é a de validação, depois que a loja abre: pequena e reembolsada na sequência — consulte antes a política do gateway sobre reembolso e tarifas, porque algumas taxas podem não ser devolvidas.

Como testar Pix, cartão e boleto antes do lançamento?

No modo de teste do provedor: o gateway fornece cartões, QR codes e dados de teste próprios e permite simular aprovação e recusa. Pix e boleto são testados no mesmo ambiente, quando o provedor oferece suporte no sandbox. O passo a passo por provedor está no guia de pagamentos da série — a regra é a mesma: teste no ambiente de teste, nunca no real.

Preciso remover pedidos de teste?

Sim — a documentação oficial recomenda: pedidos de teste não têm marcação visual, disparam e-mails e entram no Analytics, e podem ser expedidos por engano. Exclua os de teste — se o gateway registra pedidos de teste próprios, use a ferramenta que ele oferece (alguns provedores disponibilizam em WooCommerce > Status > Ferramentas; confira o manual do seu). Nunca apague dados reais indiscriminadamente; a retenção fiscal é conversa com o contador.

O que conferir no checkout?

O fluxo completo, em janela anônima e logado: adicionar e remover produto, variação, cupom válido e inválido, frete com CEP real, totais, campos obrigatórios, pagamento aprovado e falho em modo de teste e página de pedido recebido. E no celular, com dados móveis — é onde o cliente real compra. A seção “Carrinho e checkout” deste guia tem o roteiro item por item.

Como saber se o Google pode indexar a loja?

Com o Search Console: verifique a propriedade, use a Inspeção de URL na home — ela mostra se a página está indexável e como o Google a vê — e confira o relatório Sitemaps com o sitemap ativo da loja (o endereço real, que pode não ser o /wp-sitemap.xml se um plugin de SEO assumiu o sitemap). Confira também que home, produtos e categorias não têm noindex acidental — e que as páginas de transação e sessão que não fazem sentido em busca continuam fora do índice.

Preciso instalar analytics antes de lançar?

Não é requisito do WooCommerce — mas é altamente recomendável ter uma solução de medição pronta antes de abrir. Se a loja usa GA4 ou outra solução de analytics, configure e teste antes do lançamento: eventos de e-commerce em modo de depuração — view_item, add_to_cart, begin_checkout e purchase — com cada pedido contabilizado uma única vez. A ausência de GA4 não impede tecnicamente a loja de vender; sem nenhuma medição, porém, você abre sem saber o que funciona — e o lançamento é exatamente o momento em que os dados mais importam.

O que monitorar nas primeiras 24 horas?

Pedidos (chegando e com status certo), pagamentos (confirmações batendo), e-mails (inclusive spam), frete (primeira etiqueta), tarefas agendadas e logs em WooCommerce > Status, performance e disponibilidade, mensagens de contato e os primeiros dados de analytics. O roteiro completo está na seção “As primeiras 24 a 72 horas”.

Posso lançar e configurar backup/performance depois?

Não é recomendado. Backup testado antes de abrir é inegociável — a primeira atualização ou erro sem restauração validada vira crise. Performance também se prepara antes: otimizar com a loja aberta significa mexer em uma loja que já vende, com cliente assistindo. A série preparou as duas etapas antes do lançamento por um motivo: depois, tudo fica mais caro e mais arriscado.

---

Com o checklist percorrido de ponta a ponta, a série chega ao fim: hospedagem, instalação, adaptações brasileiras, pagamentos, frete, tema e plugins, segurança e backup, performance — e agora a última inspeção. Nove etapas, uma loja pronta.

Se precisar revisitar qualquer uma delas, o guia completo da série continua sendo o ponto de partida da jornada.

O lançamento, porém, não é o fim — é o começo da operação. A partir de agora, a loja tem pedidos, clientes, dados e um ritmo próprio de manutenção: atualizações, backups, monitoramento e ajustes contínuos. As primeiras 72 horas têm roteiro, e os dias seguintes também. Se em algum momento a operação pedir um par de olhos experiente — um checkout que não valida, uma integração estranha, uma performance que não responde —, o especialista WooCommerce da Panacea está a uma análise inicial de distância. A loja foi construída com método; a operação merece o mesmo.