{"id":987,"date":"2026-10-01T11:06:21","date_gmt":"2026-10-01T11:06:21","guid":{"rendered":"https:\/\/100porcentowp.com.br\/central-de-ajuda\/cms\/deploy-de-tema-wordpress-acelerar-varios-sites-sem-ftp\/"},"modified":"2026-10-01T11:06:21","modified_gmt":"2026-10-01T11:06:21","slug":"deploy-de-tema-wordpress-acelerar-varios-sites-sem-ftp","status":"publish","type":"post","link":"https:\/\/100porcentowp.com.br\/central-de-ajuda\/performance\/deploy-de-tema-wordpress-acelerar-varios-sites-sem-ftp\/","title":{"rendered":"Deploy de tema WordPress: acelerar em v\u00e1rios sites sem FTP"},"content":{"rendered":"

Voc\u00ea terminou a altera\u00e7\u00e3o 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\u00e3o tem como voltar atr\u00e1s.<\/p>\n

O problema quase nunca \u00e9 a velocidade da conex\u00e3o. \u00c9 que FTP n\u00e3o versiona, n\u00e3o registra o que mudou e n\u00e3o avisa quando um arquivo chega corrompido. Publicar tema WordPress em v\u00e1rios sites por esse caminho funciona, mas cobra caro em tempo e em risco.<\/p>\n

Abaixo est\u00e1 uma ordem de decis\u00e3o: como escolher o m\u00e9todo conforme o n\u00famero 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.<\/p>\n

Antes de escolher o m\u00e9todo: o que sua hospedagem permite<\/h2>\n

A decis\u00e3o come\u00e7a por uma pergunta pr\u00e1tica: voc\u00ea tem SSH nesses servidores? A resposta elimina metade das op\u00e7\u00f5es.<\/p>\n\n\n\n\n\n\n\n\n
Recurso dispon\u00edvel<\/th>\nM\u00e9todo vi\u00e1vel<\/th>\nOnde costuma falhar<\/th>\n<\/tr>\n<\/thead>\n
SSH com WP-CLI<\/td>\nComandos de tema via terminal<\/td>\nUsu\u00e1rio do SSH sem permiss\u00e3o de escrita na pasta do tema<\/td>\n<\/tr>\n
Deploy por reposit\u00f3rio Git<\/td>\nPush para o reposit\u00f3rio, hospedagem puxa<\/td>\nPermiss\u00f5es de arquivo e arquivos ignorados pelo .gitignore<\/td>\n<\/tr>\n
S\u00f3 painel do provedor<\/td>\nUpload de ZIP pelo gerenciador ou pelo painel do WordPress<\/td>\nLimite de tamanho do upload e tema em uso sendo sobrescrito<\/td>\n<\/tr>\n
S\u00f3 FTP ou SFTP<\/td>\nCliente FTP com sincroniza\u00e7\u00e3o<\/td>\nN\u00e3o versiona, n\u00e3o valida e n\u00e3o tem rollback simples<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Se a hospedagem oferece SSH, o caminho mais direto costuma ser WP-CLI. Se oferece integra\u00e7\u00e3o com reposit\u00f3rio, Git resolve bem. Se n\u00e3o oferece nenhum dos dois, voc\u00ea ainda consegue acelerar com um cliente FTP que sincroniza apenas os arquivos alterados, mas aceite a limita\u00e7\u00e3o: sem hist\u00f3rico, cada deploy \u00e9 um salto no escuro.<\/p>\n

Deploy de tema WordPress com WP-CLI: o caminho mais r\u00e1pido quando h\u00e1 SSH<\/h2>\n

Com SSH e WP-CLI instalados, o deploy deixa de ser c\u00f3pia de arquivos e passa a ser comando. O fluxo b\u00e1sico \u00e9 enviar o tema para o servidor e ativ\u00e1-lo.<\/p>\n

    \n
  1. Compacte o tema localmente em um arquivo .zip<\/code>.<\/li>\n
  2. Envie o arquivo para o servidor com scp tema.zip usuario@servidor:\/caminho\/do\/site\/<\/code>.<\/li>\n
  3. Acesse por SSH e entre na pasta do WordPress.<\/li>\n
  4. Rode wp theme install tema.zip --force<\/code> para instalar ou sobrescrever o tema.<\/li>\n
  5. Confirme com wp theme list<\/code> e ative com wp theme activate nome-do-tema<\/code> se for o caso.<\/li>\n
  6. Limpe o cache com wp cache flush<\/code>.<\/li>\n<\/ol>\n

    O par\u00e2metro --force<\/code> sobrescreve a vers\u00e3o existente. Isso \u00e9 o que voc\u00ea quer em um deploy, mas \u00e9 tamb\u00e9m o motivo de nunca rodar o comando sem ter um backup do tema atual. Se algo quebrar, o rollback depende de voc\u00ea ter a vers\u00e3o anterior guardada.<\/p>\n

    O ponto em que esse m\u00e9todo falha \u00e9 permiss\u00e3o. Quando o usu\u00e1rio do SSH n\u00e3o \u00e9 o mesmo dono dos arquivos do WordPress, o comando instala mas o tema n\u00e3o carrega, ou o WordPress pede credenciais de FTP para atualizar. Nesse caso, ajuste o dono dos arquivos ou rode o comando como o usu\u00e1rio correto, conforme a documenta\u00e7\u00e3o do WP-CLI em developer.wordpress.org<\/a>.<\/p>\n

    Git para publicar tema WordPress em v\u00e1rios sites<\/h2>\n

    Git resolve o problema que o FTP cria: hist\u00f3rico. Cada deploy vira um commit, e voltar atr\u00e1s \u00e9 reverter o commit. Em hospedagens com integra\u00e7\u00e3o de reposit\u00f3rio, o fluxo \u00e9 enviar para o reposit\u00f3rio e a hospedagem publica.<\/p>\n

    Em hospedagem compartilhada sem integra\u00e7\u00e3o, d\u00e1 para usar Git via SSH, mas esbarra em dois pontos. O primeiro \u00e9 permiss\u00e3o: o git pull<\/code> cria arquivos com o dono do usu\u00e1rio que rodou o comando, e o servidor web pode n\u00e3o conseguir ler. O segundo \u00e9 o .gitignore<\/code>: se ele exclui a pasta de build, o tema chega sem os arquivos compilados.<\/p>\n

    Por isso, antes de adotar Git em v\u00e1rios sites, confirme se a hospedagem oferece deploy por reposit\u00f3rio de verdade. Quando oferece, \u00e9 o m\u00e9todo que menos d\u00e1 trabalho a longo prazo. Quando n\u00e3o oferece, for\u00e7ar Git via SSH costuma trocar um problema por outro.<\/p>\n

    Sem SSH e sem Git: como acelerar o deploy pelo painel<\/h2>\n

    Quando s\u00f3 existe painel, o ganho vem de reduzir o que voc\u00ea 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\u00e3o de milhares de arquivos pequenos por FTP.<\/p>\n

    Duas armadilhas comuns nesse caminho. A primeira \u00e9 o limite de upload do painel: se o ZIP passar do limite, o envio falha no meio e voc\u00ea fica com um tema parcial. A segunda \u00e9 sobrescrever um tema em uso: o site pode ficar sem estilo enquanto a extra\u00e7\u00e3o acontece. Em site com movimento, fa\u00e7a isso em janela de baixo tr\u00e1fego ou ative um tema padr\u00e3o temporariamente.<\/p>\n

    Se o objetivo \u00e9 deploy WordPress sem FTP, mas a hospedagem n\u00e3o oferece nem SSH nem reposit\u00f3rio, a sa\u00edda realista \u00e9 trocar de hospedagem ou aceitar o m\u00e9todo manual com sincroniza\u00e7\u00e3o. Vale medir o custo disso: um auditoria de performance WordPress em v\u00e1rios sites<\/a> mostra quanto tempo voc\u00ea gasta repetindo tarefas manuais que poderiam ser automatizadas.<\/p>\n

    O teste de 10 minutos antes de replicar em todos os sites<\/h2>\n

    Este \u00e9 o passo que separa um fluxo confi\u00e1vel de um problema descoberto na frente do cliente. Antes de rodar o deploy em todos os sites, valide em um s\u00f3.<\/p>\n

      \n
    1. Escolha um site de teste, de prefer\u00eancia um clone ou um ambiente de homologa\u00e7\u00e3o, nunca o site principal de um cliente.<\/li>\n
    2. Fa\u00e7a backup do tema atual e do banco. Sem isso, n\u00e3o h\u00e1 rollback.<\/li>\n
    3. Rode o deploy pelo m\u00e9todo escolhido e cronometre.<\/li>\n
    4. Abra o site em uma janela an\u00f4nima e confira home, uma p\u00e1gina interna e uma p\u00e1gina de arquivo.<\/li>\n
    5. Verifique o console do navegador em busca de erros 404 em CSS, JS ou imagens.<\/li>\n
    6. Confira o log de erros do PHP no painel da hospedagem.<\/li>\n
    7. Se o tema depende de build, confirme que os arquivos compilados chegaram.<\/li>\n
    8. Teste o rollback: restaure a vers\u00e3o anterior e veja se o site volta ao normal.<\/li>\n<\/ol>\n

      Se qualquer etapa falhar, corrija o fluxo antes de tocar no segundo site. Automatizar um deploy que n\u00e3o foi validado s\u00f3 multiplica o erro pela quantidade de sites.<\/p>\n

      Quando N\u00c3O usar cada m\u00e9todo<\/h2>\n

      WP-CLI n\u00e3o serve quando voc\u00ea n\u00e3o tem SSH est\u00e1vel ou quando o usu\u00e1rio do terminal n\u00e3o tem permiss\u00e3o de escrita. Nesse caso, insistir gera arquivos com dono errado e erros dif\u00edceis de rastrear.<\/p>\n

      Git n\u00e3o serve quando a hospedagem n\u00e3o tem integra\u00e7\u00e3o e voc\u00ea n\u00e3o quer manter um processo manual de git pull<\/code> em cada servidor. O ganho de versionamento n\u00e3o compensa o trabalho de resolver permiss\u00e3o em cada site.<\/p>\n

      Upload de ZIP pelo painel n\u00e3o serve para temas grandes ou sites com tr\u00e1fego alto, pelo risco de deixar o site sem estilo durante a extra\u00e7\u00e3o. E FTP puro n\u00e3o serve quando voc\u00ea precisa de hist\u00f3rico ou rollback r\u00e1pido: ele n\u00e3o oferece nenhum dos dois.<\/p>\n

      Erros comuns no deploy de tema em v\u00e1rios sites<\/h2>\n