Como configurar um ambiente de teste (staging) separado do site em produção

Como criar um ambiente de teste (staging) separado do site em produção

Oi! Aqui é a Sensei da GeHost 🧡 Vamos falar de um hábito que separa quem só "mexe no site" de quem cuida do site com carinho: ter um ambiente de testes (staging) antes de mudar qualquer coisa no site que os seus visitantes veem (produção).

Pensa assim: o site em produção é a loja aberta, com clientes dentro. O staging é uma réplica da loja, fechada pro público, onde você pode trocar a vitrine, testar um plugin novo ou uma atualização do WordPress sem nenhum risco de quebrar o que já está funcionando.

💡 Dica do Sensei: a regra de ouro é simples — nunca teste em produção. Toda atualização de tema, plugin ou do próprio WordPress deveria passar primeiro pelo staging.

Passo 1 — Faça um backup antes de começar

Antes de criar qualquer coisa, garanta que você tem um backup recente do site atual. No cPanel, acesse a área de Backup e gere (ou confira) um backup completo da conta ou dos backups parciais (arquivos e banco de dados).

💡 Dica do Sensei: backup não é frescura, é seguro de vida do seu site. Faça sempre antes de qualquer mudança grande.

Passo 2 — Crie um subdomínio para o staging

O jeito mais simples de ter um ambiente separado é usar um subdomínio, por exemplo staging.seudominio.com.br. No painel do cPanel, procure a ferramenta de Subdomínios (fica no grupo "Domínios") e crie um novo subdomínio apontando para uma pasta separada, como public_html/staging.

Assim o WordPress "de teste" fica isolado do WordPress "de verdade" — cada um na sua pasta, sem se misturar.

Passo 3 — Copie os arquivos do site para a pasta do staging

Com o subdomínio criado, use o Gerenciador de Arquivos do cPanel para copiar todos os arquivos do seu WordPress atual (a pasta do site em produção) para a nova pasta do staging.

1. Selecione a pasta do site em produção (ex.: public_html).
2. Use a opção de Copiar para duplicar todo o conteúdo para a pasta do subdomínio (ex.: public_html/staging).
3. Aguarde a cópia terminar — dependendo do tamanho do site, pode levar alguns minutos.

Passo 4 — Crie um banco de dados novo para o staging

O WordPress guarda praticamente todo o conteúdo do site (posts, páginas, configurações) no banco de dados. Por isso, o staging precisa do seu próprio banco, separado do banco usado em produção.

1. Na área Bancos de Dados MySQL, crie um novo banco (ex.: usuario_staging).
2. Crie um usuário para esse banco e associe os dois, dando todos os privilégios.
3. Exporte o banco de dados do site em produção (pelo phpMyAdmin) e importe esse arquivo no banco novo do staging.

Passo 5 — Aponte o WordPress do staging para o novo banco

Agora é preciso avisar ao WordPress copiado que ele deve usar o banco novo, e não o de produção. Isso é feito no arquivo wp-config.php, dentro da pasta do staging:

• Abra o wp-config.php da pasta do staging pelo Gerenciador de Arquivos.
• Troque DB_NAME, DB_USER e DB_PASSWORD pelos dados do banco novo que você criou no Passo 4.
• Salve o arquivo.

💡 Dica do Sensei: se depois de trocar o banco o site do staging aparecer redirecionando sozinho para o domínio de produção, é porque o endereço do site (siteurl/home) ainda está gravado como o antigo dentro do banco. Isso pode ser ajustado direto pelo phpMyAdmin, nas tabelas de opções do WordPress — se tiver dúvida, chame o suporte que a gente te ajuda.

Passo 6 — Esconda o staging dos visitantes e dos buscadores

Como o staging é só pra teste, ele não deve aparecer no Google nem ficar aberto pra qualquer um acessar. Algumas formas simples de proteger:

• Bloquear indexação: em Configurações > Leitura do WordPress do staging, marque a opção "Desencorajar mecanismos de busca de indexar este site".
• Proteger com senha: use um plugin de proteção por senha, ou proteja a pasta do staging por senha diretamente pelo cPanel.

Passo 7 — Teste tudo à vontade

Com o ambiente pronto, é nele que você deve:

• Atualizar o WordPress, temas e plugins;
• Testar um plugin novo antes de instalar em produção;
• Experimentar mudanças de layout ou de tema.

Se algo der errado, nenhum problema — é só o ambiente de teste. O site real continua no ar, intocado.

Passo 8 — Levando as mudanças aprovadas para produção

Depois de validar tudo no staging, repita o processo em ordem inversa: copie os arquivos alterados e/ou exporte o banco do staging e importe no site de produção. Como esse é um passo mais delicado (pode sobrescrever conteúdo real, como pedidos ou comentários novos feitos enquanto você testava), faça sempre com calma e, de preferência, fora do horário de pico do site.

💡 Dica do Sensei: se o seu site recebe pedidos, formulários ou comentários o tempo todo (como uma loja), tome cuidado: como o staging usa uma cópia "parada no tempo" do banco, migrar o banco de volta pode apagar coisas novas que aconteceram em produção durante o teste. Nesses casos, o ideal é migrar só os arquivos (tema, plugins) e ajustar o conteúdo manualmente.

Resumindo

Ambiente de staging é criar uma cópia do site — arquivos e banco de dados — em um subdomínio separado, testar tudo por lá com segurança e só depois replicar as mudanças aprovadas para o site que os seus clientes visitam. Simples assim, e evita muita dor de cabeça!

Ficou com alguma dúvida no meio do caminho? É só chamar o suporte da GeHost pelo painel.gehost.com.br que a gente te guia passo a passo. 🧡