Como enviar o staging do WordPress para o ambiente de produção sem perder dados
John Turner
John Turner
Já movi alterações de staging para produção mais vezes do que consigo contar, e as vezes em que deu errado tiveram a mesma causa raiz: apressei o push sem verificar o que estava prestes a sobrescrever.
Se você passou as últimas horas (ou dias) desenvolvendo alterações em um site de staging, provavelmente está pronto para colocá-las no ar. Novo tema, plugins atualizados, uma página redesenhada. Seja o que for, você testou e funcionou.
Enviá-lo para o seu site principal é onde as coisas ficam arriscadas.
Eu uso o Duplicator para isso porque ele me dá controle total sobre o processo. Posso criar um pacote de migração a partir do staging, escolher exatamente quais tabelas do banco de dados serão incluídas e instalá-lo sobre a produção em meus próprios termos, em vez de confiar em um único botão para tomar a decisão certa.
Esse controle importa. Um push descuidado pode apagar novos pedidos, desconectar todos os usuários ou quebrar seu site principal na frente dos visitantes enquanto você se apressa para consertá-lo.
Este tutorial detalha o que você fará para enviar um site WordPress de staging para produção, incluindo os erros que pegam as pessoas de surpresa.
Aqui estão os principais pontos:
- Existem dois caminhos principais, dependendo do seu host: use o push integrado do seu provedor de hospedagem, se disponível, ou use o método de backup e migração do Duplicator quando não estiver, pois ele funciona independentemente do seu host.
- Um push completo do banco de dados pode apagar a atividade ao vivo. Quaisquer pedidos, comentários ou cadastros adicionados ao seu site após a criação do staging serão sobrescritos, a menos que você exclua essas tabelas antes de enviar.
- O tempo é mais importante do que as pessoas esperam. Quanto maior o intervalo entre a criação do staging e o push, mais dados ao vivo estarão em risco, então envie o quanto antes.
Sumário
- Quando você precisa enviar o Staging para Produção?
- O Que Você Precisa Antes de Começar
- Diferentes Métodos para Enviar Staging para Produção
- Como Enviar um Site WordPress de Staging para Produção
- Passo 1: Faça Backup do Seu Site Principal Primeiro
- Passo 2: Decida Quais Dados Você Está Enviando
- Passo 3: Crie um Pacote de Migração a Partir do Staging
- Passo 4: Transfira os Arquivos de Staging para o Servidor de Produção
- Passo 5: Execute o Instalador no Site Principal
- Passo 6: Verifique o Site Principal
- Solução de Problemas: Erros Comuns ao Enviar Staging para Produção
- Perguntas Frequentes (FAQs)
- Trate Cada Push Como uma Migração, Porque É
- Proteja Seu Site Antes do Próximo Push
Quando você precisa enviar o Staging para Produção?
Nem toda alteração que você faz no staging precisa ir para produção. Saber a diferença evita que você assuma riscos desnecessários.
Você precisará de um push real quando:
- Você testou uma atualização importante de tema ou plugin e confirmou que funciona
- Criou novas páginas ou conteúdo que está pronto para publicar
- Fez alterações estruturais ou de código
- Execute uma atualização do core do WordPress e verificou que nada quebrou
Provavelmente você não precisa de um push completo quando estava apenas verificando a aparência de algo, executando um teste de compatibilidade que você refará de qualquer maneira, ou fazendo alterações que não planeja manter.
Eu trato o staging como o lugar para quebrar coisas de propósito.
Enviar para o ambiente de produção é diferente. É o momento em que você se compromete.
Cada envio carrega algum risco: dados sobrescritos, alguns minutos de inatividade ou incompatibilidades de URL que levam tempo para serem rastreadas. Nada disso vale a pena para uma alteração que você ainda não terminou de testar.
Portanto, antes de tocar em qualquer coisa, certifique-se de que o que está no ambiente de staging está realmente pronto.
O Que Você Precisa Antes de Começar
Antes de enviar qualquer coisa, tenha estes itens prontos. Pular esta etapa é o motivo pelo qual uma tarefa de 20 minutos se transforma em uma correria de várias horas.
- Um backup atualizado do seu site em produção, feito logo antes de você iniciar o envio
- Acesso FTP ou SFTP, ou o gerenciador de arquivos da sua conta de hospedagem, caso você precise enviar arquivos manualmente ou corrigir algo à mão
- Acesso ao banco de dados através do phpMyAdmin ou da ferramenta de banco de dados do seu host, como um plano de contingência se algo precisar de uma correção manual
- Uma lista clara do que mudou no ambiente de staging, para que você saiba exatamente o que está enviando e possa verificar se tudo foi aplicado corretamente
- Duplicator Pro instalado no seu site de staging, pois é o que você usará para criar o pacote de migração na próxima seção
Esse backup do seu site em produção é o único item desta lista que você não pode pular. Já vi pessoas pularem porque "o envio sempre funciona". Ele não funciona sempre.
Quando não funciona, esse backup é a única coisa que impede você de reconstruir seu site do zero.
Diferentes Métodos para Enviar Staging para Produção
Nem toda configuração do WordPress tem as mesmas ferramentas disponíveis, e o que funciona para um site pode não existir em outro. Veja o que está disponível, dependendo do seu host e plugins, antes de entrarmos no passo a passo.
Envio de staging fornecido pela hospedagem
Hosts como WP Engine, Kinsta, SiteGround e Flywheel integram ferramentas de envio de staging diretamente em seus painéis. Se o seu host oferece isso, geralmente é a opção mais rápida, pois é construída em torno da configuração do servidor deles.
A desvantagem é que você fica limitado ao que o nível do plano do seu host inclui, e alguns planos não oferecem isso de forma alguma.
Envio via plugin de staging dedicado
Plugins criados especificamente para staging (como o WP Staging) incluem seu próprio botão de envio com seleção de arquivos e banco de dados. Isso funciona bem se o staging já era seu principal caso de uso.
A desvantagem é que você está adicionando outro plugin especificamente para esta única tarefa.
Método de backup e migração
Este é o método que eu uso, e o que este tutorial detalha.
Você cria um pacote de migração a partir do seu site de staging, escolhe exatamente o que incluir e o instala sobre a produção. Uma ferramenta como o Duplicator lida bem com isso.
Leva alguns passos a mais do que um único botão de envio, mas funciona independentemente do seu host. Também lhe dá o máximo controle sobre o que será sobrescrito.
Método manual (FTP e phpMyAdmin)
Copiar arquivos e tabelas de banco de dados manualmente, um por um. Este é o último recurso quando nenhuma outra ferramenta está disponível. Funciona, mas é lento e propenso a erros.
Eu prefiro o método de backup e migração porque ele não depende do meu host oferecer envios de staging, e eu decido tabela por tabela o que é seguro sobrescrever.
Como Enviar um Site WordPress de Staging para Produção
Veja o que você fará, passo a passo:
- Faça backup do seu site principal primeiro: Crie uma rede de segurança para que você possa restaurar a produção em minutos se algo der errado.
- Decida o que você vai enviar: Determine se você fará um envio completo do site ou um envio seletivo que protege dados importantes como pedidos e comentários.
- Crie um pacote de migração do staging: Empacote os arquivos e o banco de dados do seu site de staging em arquivos que o Duplicator pode instalar na produção.
- Transfira os arquivos do pacote para o servidor principal: Obtenha o instalador e o arquivo compactado no seu servidor de produção para que a instalação possa ser executada.
- Execute o instalador no site principal: Instale as alterações de staging na produção e atualize o banco de dados para corresponder.
- Verifique o site principal: Confirme se tudo funciona corretamente antes de sair.
Passo 1: Faça Backup do Seu Site Principal Primeiro
Backups não são opcionais. Antes de mexer na produção, você precisa de um caminho de volta caso algo quebre.
Minha ferramenta favorita para essa tarefa é o Duplicator. Como ele também é um plugin de migração, ele ajudará você a proteger seu site, configurar uma área de staging e migrar as alterações de volta sempre que precisar.

No seu site principal, abra o Duplicator e vá para a tela Backups. Clique no botão Adicionar Novo.

Nomeie o backup com algo que você reconhecerá mais tarde, como "backup-antes-do-envio-staging". Escolha a predefinição de backup Site Completo para fazer backup de tudo.

Clique em Avançar. Depois de revisar quaisquer avisos da verificação, crie o backup.

Baixe ambos os arquivos de backup. Armazene-os em algum lugar fora do seu servidor, como armazenamento em nuvem ou seu computador local.
Eu prefiro usar o Duplicator Cloud, pois ele pode restaurar seu site mesmo que ele esteja offline devido a um erro grave.

Etapa 2: Decida Quais Dados Você Está Enviando
Um envio completo substitui tudo: arquivos, temas, plugins e todo o banco de dados. Use isso quando você fez grandes alterações, como um novo tema ou atualizações estruturais significativas.
Um envio seletivo atualiza apenas arquivos ou tabelas de banco de dados específicos. Use isso quando você alterou apenas algumas coisas, pois ele protege dados importantes que seu site de staging não possui, como novos pedidos, comentários ou cadastros de usuários feitos na produção desde que você iniciou o staging.
Se você fizer um envio completo do banco de dados, tudo o que aconteceu no seu site principal após você criar o staging será apagado e substituído pelos dados mais antigos do staging.
Antes de criar seu pacote de migração na próxima etapa, decida quais tabelas são importantes.
Se você não tem certeza do que mudou na produção desde que iniciou o staging, verifique agora. É muito mais fácil perguntar "Eu preciso desta tabela?" antes do envio do que recuperá-la depois.
Passo 3: Crie um Pacote de Migração a Partir do Staging
No seu site de staging, crie um novo backup com o Duplicator. É o mesmo processo que você usou na Etapa 1, apenas no staging desta vez.
Na seção Backups, use as predefinições de backup para personalizar quais dados são incluídos. Você também pode usar filtros de arquivos e tabelas de banco de dados.

O Duplicator permite que você exclua tabelas específicas, como wp_woocommerce_orders ou wp_comments, da criação do banco de dados.
Finalize a criação do backup e faça o download dele. Você terá dois arquivos: um instalador (installer.php) e um arquivo compactado (um zip contendo os arquivos e o banco de dados do seu site).

Passo 4: Transfira os Arquivos de Staging para o Servidor de Produção
Conecte-se ao seu servidor principal usando FTP, SFTP ou o gerenciador de arquivos do seu provedor.
Faça o upload do arquivo installer.php e do arquivo compactado para o diretório raiz do seu site principal. Esta é a mesma pasta onde o arquivo principal wp-config.php do seu site está localizado.

Se o seu site de staging estiver em uma subpasta do mesmo servidor, como seusite.com/staging/, essa transferência geralmente é apenas uma cópia de arquivos em vez de um upload completo, o que economiza tempo.
Confirme se ambos os arquivos aparecem no diretório raiz do site principal antes de prosseguir.

Passo 5: Execute o Instalador no Site Principal
No seu navegador, acesse seusite.com/installer.php, substituindo "seusite.com" pelo seu domínio principal.
Verifique novamente os detalhes de conexão do banco de dados. Eles devem apontar para o banco de dados do seu site principal, não para o de staging.

Continue com a instalação. Quando terminar, faça login novamente com o botão Login de Administrador.

Passo 6: Verifique o Site Principal
Abra seu site principal e verifique a página inicial primeiro.
Navegue por algumas páginas importantes: as que você alterou no staging, mais algumas que você não mexeu, apenas para confirmar que nada não relacionado foi quebrado.
Tente fazer login no wp-admin com suas credenciais habituais. Teste quaisquer formulários ou fluxos de checkout, se o seu site os tiver.
Limpe seu cache (tanto o cache em nível de servidor quanto qualquer plugin de cache que você use), pois páginas em cache podem exibir conteúdo antigo mesmo após uma transferência bem-sucedida.
Última coisa: se o seu site de staging ainda estiver ativo, verifique novamente se ele ainda está configurado para não ser indexado nas configurações de visibilidade. É fácil esquecer, e você não quer que os motores de busca rastreiem um site duplicado.
Solução de Problemas: Erros Comuns ao Enviar Staging para Produção
Tela Branca Logo Após a Transferência
Você carrega seu site principal e recebe uma página em branco sem mensagem de erro.
Isso geralmente significa que um plugin que funcionava bem no staging é incompatível com o ambiente do seu servidor principal, muitas vezes uma diferença de versão do PHP.
Verifique a versão do PHP do seu provedor em comparação com o que o staging estava executando. Se não corresponderem, atualize a produção para corresponder à versão do PHP do staging, ou reverta o plugin que está causando o conflito usando seu backup do Passo 1.
Não é possível fazer login no wp-admin Após a Transferência
Você insere suas credenciais de login habituais e recebe "nome de usuário ou senha incorretos", mesmo sabendo que estão corretos.
Uma transferência completa do banco de dados substitui a tabela de usuários do seu site principal pela do staging, então seu login principal não corresponde mais ao que está no banco de dados.
Redefina a senha do administrador diretamente através do phpMyAdmin ou da ferramenta de banco de dados do seu provedor, ou restaure seu backup do Passo 1 e refaça a transferência como uma transferência seletiva que exclui a tabela de usuários.
Erros da API REST ou um Editor de Blocos Quebrado
O editor de blocos não carrega, ou você vê erros da API REST no console do navegador.
Os dados serializados no seu banco de dados ainda referenciam sua URL de staging em vez do seu domínio principal, e a substituição de URL do Duplicator não capturou todas as instâncias.
O Duplicator fará uma busca e substituição para você. No entanto, você pode direcionar quaisquer URLs de staging remanescentes em campos serializados com um plugin como Search & Replace Everything.
Pedidos, Comentários ou Novos Cadastros Ausentes
Clientes relatam que seus pedidos recentes sumiram, ou que comentários dos últimos dias desapareceram.
Isso acontece quando um push completo do banco de dados sobrescreve tabelas ativas que tiveram novas atividades porque essa atividade ocorreu após a criação do staging.
Restaure seu backup inicial imediatamente, em seguida, refaça o push como um push seletivo que exclui wp_woocommerce_orders, wp_comments e quaisquer outras tabelas com atividade ativa.
O Processo Trava ou Excede o Tempo Limite no Meio da Transferência
A instalação trava em algum ponto, ou seu navegador mostra um erro de tempo limite sem uma mensagem de falha clara.
Arquivos de pacote grandes podem exceder os limites de upload do seu servidor ou os limites de tempo de execução, especialmente em hospedagem compartilhada.
Verifique o tamanho máximo de upload e as configurações de tempo de execução do PHP do seu host, divida o pacote em partes menores se o seu plugin suportar, ou entre em contato com seu host para aumentar temporariamente os limites durante o push.
O Botão de Push do Seu Host Está Cinza ou Ausente
Você procura uma opção de push de staging no painel da sua hospedagem, e ela está desativada ou não está lá.
Isso geralmente significa que o nível do seu plano de hospedagem não inclui recursos de push de staging, mesmo que a criação de staging em si esteja incluída.
Use o método de backup e migração do Duplicator em vez disso, pois ele não depende do que o plano do seu host suporta.
Perguntas Frequentes (FAQs)
O Duplicator tem um recurso de push para produção com um clique?
Não, mas não precisa. As ferramentas de backup e migração do Duplicator permitem que você crie um pacote a partir do staging e o instale em produção com controle total sobre o que é incluído, o que funciona independentemente da configuração ou nível do seu plano de hospedagem.
O push do staging para produção excluirá meus pedidos ou comentários recentes?
Pode excluir, se você fizer um push completo do banco de dados e seu site em produção tiver atividade que ocorreu após a criação do staging. Evite isso fazendo um push seletivo que exclua tabelas como wp_woocommerce_orders e wp_comments antes de criar o pacote.
Como faço para enviar apenas arquivos específicos sem sobrescrever todo o banco de dados?
Ao criar o backup do site de staging, exclua as tabelas específicas que você deseja proteger antes de construir o pacote. Isso mantém essas tabelas intocadas na produção enquanto ainda atualiza os arquivos e tabelas que você realmente alterou.
Preciso de acesso FTP para enviar o staging para produção?
Você precisa dele como um fallback, mesmo que seu método principal não o exija. Se o staging e a produção compartilharem o mesmo servidor, você pode pular a transferência manual completamente, mas o FTP ou o gerenciador de arquivos do seu host é essencial se algo precisar de um reparo manual.
O que acontece se o push falhar no meio do caminho?
Seu site ativo pode acabar em um estado parcialmente atualizado. Restaure o backup que você fez na Etapa 1 imediatamente para que seu site volte a funcionar, em seguida, solucione a causa (geralmente um problema de tamanho de arquivo ou tempo limite do servidor) antes de tentar novamente.
Devo tirar o staging offline depois de enviar para o site ativo?
Você não precisa tirá-lo do ar, mas certifique-se de que ele ainda esteja configurado como noindex para que os mecanismos de busca não o rastreiem. Muitas pessoas mantêm o staging em execução para a próxima rodada de alterações em vez de recriá-lo a cada vez.
Qual método devo usar se meu host não oferecer push de staging?
Use o método de backup e migração do Duplicator. Ele não depende do seu plano de hospedagem incluir um recurso de push, já que você mesmo está construindo e instalando o pacote.
Trate Cada Push Como uma Migração, Porque É
Agora você tem um processo completo para colocar as alterações do staging no seu site ativo sem adivinhar se algo vai quebrar.
Continue atento a algumas coisas daqui para frente.
Atividade ao vivo continua acontecendo enquanto você trabalha no staging, então quanto mais tempo você esperar entre a criação do staging e o envio das alterações, mais dados você corre o risco de sobrescrever com um push completo. Verifique o que mudou no site ativo antes de cada push, não apenas no primeiro.
Uma dica que não vejo coberta em outros lugares: agende seu push durante suas horas de menor tráfego, mesmo para um site pequeno. Menos visitantes ativos significam menos chances de sobrescrever um pedido ou comentário que chegou durante os poucos minutos que o push leva.
Proteja Seu Site Antes do Próximo Push
Cada push do staging para o site ativo carrega riscos, mesmo quando você segue todos os passos cuidadosamente. Um backup feito pouco antes de você começar é a diferença entre um conserto rápido e reconstruir seu site do zero.
Duplicator Pro foi criado exatamente para isso: backups completos do site, controle seletivo do banco de dados e um processo de migração que funciona independentemente do que seu host suporta. Mais de 1,5 milhão de profissionais de WordPress já o utilizam para proteger seus sites durante alterações como esta.
Não espere até que um push dê errado para descobrir que seu último backup foi de uma semana atrás.
Se este tutorial ajudou, estes guias também valem a pena ser marcados.
- Você Precisa de um Site de Staging?
- Como Criar um Site de Staging no WordPress
- Como Converter o WordPress em um Site de Staging
- Como Criar um Site de Staging WooCommerce (+ O Que Testar Antes de Entrar em Produção)
- Como fazer backup do site de staging do seu site antes de cada push
- 9 Melhores Plugins de Staging WordPress (+ Nossas Análises Especializadas)