Como usar o staging da Hostinger para testar plugins do WordPress antes de atualizar o site

Fala aí, beleza? Sabe aquele plugin pedindo atualização faz semanas, e você com medo de clicar e o site cair bem na hora do movimento? 😛

O caminho aqui é usar o staging nativo do painel da Hostinger como laboratório: cópia do site, atualização do plugin, roteiro de testes e decisão consciente de como levar isso pro site publicado

Esse fluxo vale pra quem está em plano de hospedagem web Business ou superior e tem uma instalação WordPress comum, porque Multisite fica de fora da ferramenta

O que você precisa antes de criar o staging na Hostinger

Você precisa de um plano compatível, de um WordPress que não seja Multisite e de um backup conferido

Se liga na lista:

• Plano de hospedagem web Business ou superior: a Hostinger reserva a ferramenta de staging a esse grupo de planos; em planos de entrada, o painel mostra um aviso pedindo upgrade
• WordPress comum, não Multisite: a documentação de staging da Hostinger avisa que a ferramenta não é compatível com Multisite
• Acesso ao painel da Hostinger (hPanel): é por ele que o staging é criado, publicado e apagado, e o WordPress precisa estar detectado na seção Websites do painel
• Um nome de subdomínio pensado: o staging vive em um subdomínio que você escolhe na hora da criação
• Backup recente conferido: no hPanel, os backups ficam em Files > Backups

Se o seu plano atual não inclui staging, dá pra ver os planos de hospedagem WordPress da Hostinger (este é um link de afiliado da Hostinger) e confirmar no próprio painel se o plano escolhido já vem com a ferramenta antes de contratar

Sobre o backup, um detalhe que muita gente esquece: segundo a documentação de backups do WordPress.org, backup do WordPress tem DUAS partes

O banco de dados (posts, comentários e etc) e os arquivos (core, plugins, temas, imagens e código)

E quem depende de backup automático deve fazer um backup manual de vez em quando, só pra confirmar que o processo funciona mesmo

Backup que nunca foi testado é só esperança… 🙂

Passo a passo: como testar a atualização de um plugin no staging da Hostinger

O fluxo é criar a cópia, proteger, atualizar o plugin nela, testar e só então publicar com backup feito

Bora ver na prática?

1. Crie o staging: no painel da Hostinger, vá em Websites, abra o Dashboard do site WordPress, clique em WordPress na barra lateral, depois em Staging e em Create staging, escolha o nome do subdomínio e clique em Create (passo descrito no artigo de suporte da Hostinger)

– Resultado esperado: o novo site de staging aparece na lista, e a criação pode levar até 15 minutos, dependendo do tamanho do site – Erro comum: começar a mexer antes de a criação terminar, espera o processo concluir

2. Proteja o staging contra indexação e acesso: no wp-admin do staging, vá em Configurações > Leitura (em inglês: Settings > Reading) e marque a opção de não indexar o site nos mecanismos de busca (em inglês: Search Engine Visibility)

– Essa caixinha faz o WordPress editar automaticamente o arquivo robots.txt do staging, pedindo que os mecanismos de busca não indexem o site – Proteção extra: o hPanel tem a ferramenta Password Protect Directories, e crawlers não acessam conteúdo protegido por senha; confira no painel qual diretório corresponde ao seu staging antes de aplicar – Erro comum: confiar só na caixinha do WordPress e deixar uma cópia inteira do site aberta por aí

3. Abra o wp-admin do staging e atualize o plugin lá: clique em Manage staging, que abre o painel administrativo do WordPress no site de staging, e faça a atualização do plugin nesse ambiente

– Resultado esperado: o plugin atualizado no staging, com a produção intacta – Erro comum: atualizar na aba errada, então olha a URL do navegador e confirma que é o subdomínio do staging antes de clicar em atualizar

4. Rode o seu roteiro de regressão: escreve antes uma lista do que não pode quebrar e passa item por item; um checklist sugerido para começar:

– Home e páginas principais carregando sem erro visual – Formulários enviando (contato, cadastro, newsletter e etc) – O fluxo que depende do plugin atualizado, do começo ao fim – Área administrativa: menus do plugin abrindo e configurações salvando – Resultado esperado: tudo da lista funcionando igual antes da atualização

5. Decida como levar isso pra produção e faça backup completo: o que acontece tecnicamente ao publicar está explicado na próxima seção, e a própria Hostinger recomenda backup do site WordPress inteiro antes de publicar mudanças do staging

– Mas a ferramenta já não faz backup sozinha? Faz, e ainda oferece o Revert (explico mais abaixo), só que esse é o backup DA FERRAMENTA. O seu backup manual é uma cópia independente, que você controla e confere, e vira a segunda rede de segurança se o caminho automático não resolver – Erro comum: pular o backup porque "é só um plugin"

6. Publique: clique nos três pontos ao lado do site de staging, escolha Publish, leia o aviso com calma e confirme em Publish

– Resultado esperado: a publicação pode levar cerca de 15 minutos – Checagem final: abre o site publicado e repete o MESMO roteiro de regressão do passo 4

O que acontece quando você publica (e por que isso pode derrubar dados recentes)

Segundo o artigo de suporte da Hostinger, publicar substitui os arquivos e o banco de dados do site publicado pela cópia do staging, e qualquer mudança feita na produção depois da criação do staging é sobrescrita e perdida

Vale um adendo honesto aqui: a documentação técnica da Hostinger também cita três modos de sincronização possíveis entre staging e produção (Files only, Database only e Full sync), mas associados a um fluxo que a própria documentação chama de "push to live / sync to production". Essa tela pode ou não coincidir com o botão Publish que você encontra nos três pontos do staging, e as duas fontes oficiais não deixam isso 100% alinhado no momento desta revisão

Na prática, a orientação mais segura é: confira no SEU painel, antes de publicar, quais opções aparecem na tela de confirmação, e trate a publicação como "substitui tudo" por padrão, salvo se o próprio painel te mostrar uma escolha diferente

Agora os cenários que importam pra decisão:

Site institucional que ficou parado durante o teste

Se ninguém publicou post, recebeu comentário ou cadastrou nada na produção enquanto você testava, publicar tende a não perder nada, porque não havia nada novo pra perder

Mesmo assim, backup antes, sempre

Loja, site com cadastros, comentários ou pedidos chegando

Aqui publicar é perigoso: pedidos, usuários e comentários que entraram na produção depois da criação do staging seriam sobrescritos pela cópia antiga, já que a publicação troca arquivos e banco do site publicado pelo conteúdo do staging

Se o seu site tem esse tipo de movimento, considere a alternativa prudente a seguir em vez de publicar direto

A alternativa prudente para site dinâmico

Usa o staging só pra VALIDAR a atualização

Deu tudo certo no roteiro? Faz backup completo da produção e repete a mesma atualização direto no site publicado, em horário de pouco movimento, e roda o roteiro de novo

Assim você ganha a segurança do teste sem sobrescrever nenhum pedido ou usuário que tenha entrado durante o período de testes 😀

Deu errado depois de publicar: como voltar com o Revert

Você volta pelos três pontos do staging, na opção Revert, que restaura a versão anterior à publicação

O sintoma clássico: o site publicado quebrou, ou sumiram dados que estavam lá

A causa provável é a publicação ter substituído arquivos e banco da produção pela cópia do staging, levando junto algo que tinha mudado depois da criação do ambiente de teste

A solução:

• Revert: segundo o tutorial de staging da Hostinger, a ferramenta faz backup automático do site WordPress inteiro, e nos três pontos do staging tem a opção Revert pra voltar ao estado anterior à publicação
• Segunda rede de segurança: os backups em Files > Backups no hPanel, e o backup manual que você fez no passo 5

E pra não precisar disso de novo:

• Backup manual completo antes de toda publicação
• Conferência, no seu painel, do que a tela de publicação vai efetivamente substituir
• Janela de baixa movimentação pra publicar

Staging nativo ou staging manual: quando cada um faz sentido

O nativo é o caminho pra quem tem plano compatível, e o manual fica pra quem não tem a ferramenta e topa mais trabalho

O staging nativo é esse fluxo todo pelo painel: cria, gerencia, publica e reverte sem você copiar nada na mão

O método manual monta um subdomínio em Domains > Subdomains e copia os arquivos pelo File Manager, e a própria Hostinger avisa que ele exige mais conhecimento técnico e mais tempo

Agora, tome cuidado com uma confusão comum: montar um staging do WordPress na VPS é OUTRO procedimento, porque em VPS a administração do servidor é sua

Se ainda não está claro o que muda nesse modelo, vale entender antes o que é uma VPS e como ela funciona

WordPress ainda vale a pena pra quem cria sites?

Na minha visão, vale sim, principalmente pra quem cria e mantém sites de clientes, desde que tu trate manutenção como parte do serviço e não como um extra

E é aí que o staging entra: testar atualização antes de mexer na produção é o que separa o freela que entrega com segurança daquele que reza antes de clicar em atualizar haha

Neste vídeo do canal eu aprofundo esse papo sobre criação de sites como freelance e o WordPress hoje:

Depois do teste: manutenção do staging

Apaga o staging que já cumpriu o papel e cria um novo na próxima rodada de atualizações, ou atualiza o mesmo ambiente com uma cópia fresca da produção

Pra excluir, abre a lista de sites de staging no painel da Hostinger, clica nos três pontos e escolhe Delete

Precisa mesmo recriar do zero? Nem sempre: a ferramenta tem a opção Pull from live, que atualiza o staging com uma cópia nova da produção sem precisar apagar e criar outro ambiente. Use ela quando só quer dados mais recentes pra testar; apague e crie um staging novo quando quiser começar de uma configuração limpa

O hábito que fecha o ciclo: backup validado antes de cada atualização, roteiro de regressão escrito e decisão consciente de como levar o teste pra produção

E se o seu plano atual não inclui staging, dá pra conferir os planos de hospedagem WordPress da Hostinger e confirmar no painel qual opção já vem com a ferramenta antes de contratar

Até o próximo post! 🙂

Perguntas frequentes

Quais planos da Hostinger têm staging nativo para WordPress?

A ferramenta de staging da Hostinger está disponível a partir do plano de hospedagem web Business. Em planos de entrada, o painel exibe um aviso pedindo upgrade. Confirme no seu hPanel se o plano contratado já inclui a ferramenta antes de depender dela.

O staging da Hostinger funciona com WordPress Multisite?

Não. A documentação oficial da Hostinger informa que a ferramenta de staging não é compatível com instalações Multisite, e o WordPress precisa estar detectado na seção Websites do painel.

Publicar o staging sobrescreve os dados do site que já está no ar?

Sim. Segundo o artigo de suporte da Hostinger, publicar substitui os arquivos e o banco de dados do site publicado pela cópia do staging, e qualquer mudança feita na produção depois da criação do staging é perdida. Por isso a Hostinger recomenda fazer backup completo da produção antes de publicar, e vale conferir no seu próprio painel exatamente o que a tela de publicação vai substituir.

Dá para desfazer uma publicação de staging que deu errado?

Sim. A ferramenta faz backup automático do site inteiro, e a opção Revert nos três pontos ao lado do staging restaura o estado anterior à publicação. Ainda assim, vale manter um backup manual próprio como segunda rede de segurança.

Dá para atualizar o staging com dados mais recentes da produção sem recriá-lo?

Sim, usando a opção Pull from live dentro da ferramenta de staging, que atualiza o ambiente de teste com uma cópia nova da produção sem precisar apagar e criar um staging do zero.

Quer aprender mais sobre inteligência artificial e programação na prática? Conheça o canal Hora de Codar no YouTube e acompanhe os próximos vídeos.