Você terminou a alteração no tema, testou no ambiente local e agora precisa publicar em cinco sites de clientes. Abre o gerenciador de arquivos, baixa a pasta do tema, sobe por FTP, espera, confere. Repete. Na terceira vez, percebe que esqueceu um arquivo no segundo site e que o deploy de tema WordPress feito por FTP não tem como voltar atrás.
O problema quase nunca é a velocidade da conexão. É que FTP não versiona, não registra o que mudou e não avisa quando um arquivo chega corrompido. Publicar tema WordPress em vários sites por esse caminho funciona, mas cobra caro em tempo e em risco.
Abaixo está uma ordem de decisão: como escolher o método conforme o número de sites e o tipo de hospedagem, onde cada um costuma falhar e um teste de 10 minutos para validar o fluxo antes de replicar.
Antes de escolher o método: o que sua hospedagem permite
A decisão começa por uma pergunta prática: você tem SSH nesses servidores? A resposta elimina metade das opções.
| Recurso disponível | Método viável | Onde costuma falhar |
|---|---|---|
| SSH com WP-CLI | Comandos de tema via terminal | Usuário do SSH sem permissão de escrita na pasta do tema |
| Deploy por repositório Git | Push para o repositório, hospedagem puxa | Permissões de arquivo e arquivos ignorados pelo .gitignore |
| Só painel do provedor | Upload de ZIP pelo gerenciador ou pelo painel do WordPress | Limite de tamanho do upload e tema em uso sendo sobrescrito |
| Só FTP ou SFTP | Cliente FTP com sincronização | Não versiona, não valida e não tem rollback simples |
Se a hospedagem oferece SSH, o caminho mais direto costuma ser WP-CLI. Se oferece integração com repositório, Git resolve bem. Se não oferece nenhum dos dois, você ainda consegue acelerar com um cliente FTP que sincroniza apenas os arquivos alterados, mas aceite a limitação: sem histórico, cada deploy é um salto no escuro.
Deploy de tema WordPress com WP-CLI: o caminho mais rápido quando há SSH
Com SSH e WP-CLI instalados, o deploy deixa de ser cópia de arquivos e passa a ser comando. O fluxo básico é enviar o tema para o servidor e ativá-lo.
- Compacte o tema localmente em um arquivo
.zip. - Envie o arquivo para o servidor com
scp tema.zip usuario@servidor:/caminho/do/site/. - Acesse por SSH e entre na pasta do WordPress.
- Rode
wp theme install tema.zip --forcepara instalar ou sobrescrever o tema. - Confirme com
wp theme liste ative comwp theme activate nome-do-temase for o caso. - Limpe o cache com
wp cache flush.
O parâmetro --force sobrescreve a versão existente. Isso é o que você quer em um deploy, mas é também o motivo de nunca rodar o comando sem ter um backup do tema atual. Se algo quebrar, o rollback depende de você ter a versão anterior guardada.
O ponto em que esse método falha é permissão. Quando o usuário do SSH não é o mesmo dono dos arquivos do WordPress, o comando instala mas o tema não carrega, ou o WordPress pede credenciais de FTP para atualizar. Nesse caso, ajuste o dono dos arquivos ou rode o comando como o usuário correto, conforme a documentação do WP-CLI em developer.wordpress.org.
Git para publicar tema WordPress em vários sites
Git resolve o problema que o FTP cria: histórico. Cada deploy vira um commit, e voltar atrás é reverter o commit. Em hospedagens com integração de repositório, o fluxo é enviar para o repositório e a hospedagem publica.
Em hospedagem compartilhada sem integração, dá para usar Git via SSH, mas esbarra em dois pontos. O primeiro é permissão: o git pull cria arquivos com o dono do usuário que rodou o comando, e o servidor web pode não conseguir ler. O segundo é o .gitignore: se ele exclui a pasta de build, o tema chega sem os arquivos compilados.
Por isso, antes de adotar Git em vários sites, confirme se a hospedagem oferece deploy por repositório de verdade. Quando oferece, é o método que menos dá trabalho a longo prazo. Quando não oferece, forçar Git via SSH costuma trocar um problema por outro.
Sem SSH e sem Git: como acelerar o deploy pelo painel
Quando só existe painel, o ganho vem de reduzir o que você envia. Em vez de subir a pasta inteira, gere um ZIP do tema, envie pelo gerenciador de arquivos do provedor e extraia no servidor. Isso evita a lentidão de milhares de arquivos pequenos por FTP.
Duas armadilhas comuns nesse caminho. A primeira é o limite de upload do painel: se o ZIP passar do limite, o envio falha no meio e você fica com um tema parcial. A segunda é sobrescrever um tema em uso: o site pode ficar sem estilo enquanto a extração acontece. Em site com movimento, faça isso em janela de baixo tráfego ou ative um tema padrão temporariamente.
Se o objetivo é deploy WordPress sem FTP, mas a hospedagem não oferece nem SSH nem repositório, a saída realista é trocar de hospedagem ou aceitar o método manual com sincronização. Vale medir o custo disso: um auditoria de performance WordPress em vários sites mostra quanto tempo você gasta repetindo tarefas manuais que poderiam ser automatizadas.
O teste de 10 minutos antes de replicar em todos os sites
Este é o passo que separa um fluxo confiável de um problema descoberto na frente do cliente. Antes de rodar o deploy em todos os sites, valide em um só.
- Escolha um site de teste, de preferência um clone ou um ambiente de homologação, nunca o site principal de um cliente.
- Faça backup do tema atual e do banco. Sem isso, não há rollback.
- Rode o deploy pelo método escolhido e cronometre.
- Abra o site em uma janela anônima e confira home, uma página interna e uma página de arquivo.
- Verifique o console do navegador em busca de erros 404 em CSS, JS ou imagens.
- Confira o log de erros do PHP no painel da hospedagem.
- Se o tema depende de build, confirme que os arquivos compilados chegaram.
- Teste o rollback: restaure a versão anterior e veja se o site volta ao normal.
Se qualquer etapa falhar, corrija o fluxo antes de tocar no segundo site. Automatizar um deploy que não foi validado só multiplica o erro pela quantidade de sites.
Quando NÃO usar cada método
WP-CLI não serve quando você não tem SSH estável ou quando o usuário do terminal não tem permissão de escrita. Nesse caso, insistir gera arquivos com dono errado e erros difíceis de rastrear.
Git não serve quando a hospedagem não tem integração e você não quer manter um processo manual de git pull em cada servidor. O ganho de versionamento não compensa o trabalho de resolver permissão em cada site.
Upload de ZIP pelo painel não serve para temas grandes ou sites com tráfego alto, pelo risco de deixar o site sem estilo durante a extração. E FTP puro não serve quando você precisa de histórico ou rollback rápido: ele não oferece nenhum dos dois.
Erros comuns no deploy de tema em vários sites
- Deploy sem backup do tema anterior, o que elimina a possibilidade de rollback.
- Esquecer de limpar o cache depois de publicar, fazendo o site continuar exibindo a versão antiga.
- Enviar o tema sem os arquivos de build, deixando o site sem estilo.
- Rodar o mesmo comando em todos os sites sem validar em um primeiro.
- Ignorar o log de erros do PHP e só perceber o problema quando o cliente reclama.
- Não registrar qual versão do tema está em cada site, o que dificulta saber o que foi publicado onde.
Esse último erro fica pior conforme a carteira cresce. Se você administra vários sites, manter um registro de versão por site é tão importante quanto o deploy em si. Um painel como o 100% WP ajuda a acompanhar o que está publicado em cada site, porque o problema de deploy se multiplica pela quantidade de clientes.
Prevenção: transforme o deploy em processo
Depois que o fluxo funciona em um site, documente os passos exatos: comando, caminho, ordem e o que fazer se falhar. Isso permite que outra pessoa da equipe repita o processo sem depender de você.
Vale também medir o efeito do deploy na performance. Um tema novo pode trazer CSS ou JS mais pesados, e a diferença só aparece quando você compara antes e depois. Para isso, use uma forma de medir a velocidade de carregamento WordPress e comparar sites logo após publicar.
Por fim, mantenha o tema em um repositório versionado, mesmo que o deploy final seja manual. Ter o histórico é o que permite voltar atrás quando algo quebra, independentemente do método de publicação.
Quando chamar alguém
Se o deploy quebra o site e você não consegue restaurar a versão anterior, pare e peça ajuda antes de tentar mais comandos. Cada tentativa sem backup aumenta o risco de perda de dados.
O mesmo vale quando o problema é permissão de arquivo em vários servidores ao mesmo tempo. Ajustar dono e permissão errado pode deixar o site inteiro inacessível, e corrigir isso exige acesso que talvez você não tenha.
Na prática, o deploy de tema WordPress em vários sites deixa de ser problema quando o método combina com o que a hospedagem oferece e quando existe um teste antes de replicar. O resto é disciplina de processo.
