{"id":899,"date":"2026-09-22T17:08:42","date_gmt":"2026-09-22T17:08:42","guid":{"rendered":"https:\/\/100porcentowp.com.br\/central-de-ajuda\/cms\/seguranca-wordpress-instalacao-hardening-varios-sites\/"},"modified":"2026-09-22T17:08:42","modified_gmt":"2026-09-22T17:08:42","slug":"seguranca-wordpress-instalacao-hardening-varios-sites","status":"publish","type":"post","link":"https:\/\/100porcentowp.com.br\/central-de-ajuda\/seguranca\/seguranca-wordpress-instalacao-hardening-varios-sites\/","title":{"rendered":"Seguran\u00e7a WordPress instala\u00e7\u00e3o: hardening em v\u00e1rios sites"},"content":{"rendered":"

Voc\u00ea acabou de subir um WordPress novo, ou assumiu a manuten\u00e7\u00e3o de v\u00e1rios, e sabe que a instala\u00e7\u00e3o padr\u00e3o sai com pontos abertos. A d\u00favida n\u00e3o \u00e9 se<\/em> precisa mexer, e sim em qual ordem, para n\u00e3o derrubar nada. Seguran\u00e7a WordPress instala\u00e7\u00e3o \u00e9 isso: decidir o que entra no pacote base aplicado em todos os sites e o que s\u00f3 vai para produ\u00e7\u00e3o depois de testado em um.<\/p>\n

A maioria dos tutoriais de instala\u00e7\u00e3o segura trata cada site como um caso isolado. Quem administra dez sites precisa do contr\u00e1rio: um pacote replic\u00e1vel, com o que \u00e9 seguro empilhar em lote e o que precisa de valida\u00e7\u00e3o individual. \u00c9 essa separa\u00e7\u00e3o que este texto entrega.<\/p>\n

O que d\u00e1 para aplicar em lote sem medo<\/h2>\n

Algumas medidas de hardening WordPress n\u00e3o dependem do tema, do page builder nem dos plugins instalados. Elas alteram comportamento do core ou da camada de acesso, e o efeito colateral costuma ser previs\u00edvel. S\u00e3o as primeiras a entrar no pacote.<\/p>\n

    \n
  1. For\u00e7ar HTTPS no painel e no front-end.<\/strong> Defina as URLs do site com https:\/\/<\/code> em Configura\u00e7\u00f5es \u2192 Geral e confirme o certificado. Se o site ainda mistura conte\u00fado, resolva antes de for\u00e7ar, sen\u00e3o voc\u00ea cria loop de redirecionamento. O passo a passo de instala\u00e7\u00e3o est\u00e1 em certificado SSL no WordPress<\/a>.<\/li>\n
  2. Desabilitar a edi\u00e7\u00e3o de arquivos pelo painel.<\/strong> No wp-config.php<\/code>, defina DISALLOW_FILE_EDIT<\/code> como true<\/code>. Isso bloqueia o editor de temas e plugins dentro do admin. Se um invasor conseguir uma conta de administrador, ele n\u00e3o edita PHP por ali. N\u00e3o afeta atualiza\u00e7\u00f5es nem instala\u00e7\u00e3o de plugins.<\/li>\n
  3. Limitar tentativas de login.<\/strong> Pode ser por plugin ou por regra no servidor. Em lote, prefira a camada de servidor (nginx ou .htaccess), porque n\u00e3o depende de plugin ativo e n\u00e3o some se algu\u00e9m desativar o plugin.<\/li>\n
  4. Revisar permiss\u00f5es de arquivo.<\/strong> Diret\u00f3rios em 755<\/code>, arquivos em 644<\/code>, e wp-config.php<\/code> em 600<\/code> ou 640<\/code> quando o servidor permitir. \u00c9 o item mais chato de corrigir depois, ent\u00e3o vale acertar na origem.<\/li>\n
  5. Remover temas e plugins que n\u00e3o ser\u00e3o usados.<\/strong> Instala\u00e7\u00e3o limpa \u00e9 instala\u00e7\u00e3o sem c\u00f3digo morto. Cada plugin inativo ainda \u00e9 um diret\u00f3rio com arquivos que podem ser lidos se algo der errado.<\/li>\n<\/ol>\n

    Na pr\u00e1tica, esses cinco itens formam o pacote base. Voc\u00ea aplica em todos os sites da carteira e o risco de quebra \u00e9 baixo, porque nenhum deles interfere na forma como o tema renderiza a p\u00e1gina.<\/p>\n

    O que precisa ser testado site a site<\/h2>\n

    Aqui est\u00e1 o recorte que os tutoriais de instala\u00e7\u00e3o segura costumam ignorar. Estas medidas mexem em tr\u00e1fego, em integra\u00e7\u00f5es ou no banco de dados. Aplicadas em lote, quebram plugins de terceiros de formas dif\u00edceis de diagnosticar depois.<\/p>\n\n\n\n\n\n\n
    Medida<\/th>\nO que costuma quebrar<\/th>\nComo testar<\/th>\n<\/tr>\n
    Regras de WAF<\/td>\nFormul\u00e1rios, checkout, APIs internas, pain\u00e9is de page builder<\/td>\nModo de detec\u00e7\u00e3o antes de bloqueio, por alguns dias<\/td>\n<\/tr>\n
    Bloqueio de XML-RPC<\/td>\nAplicativo oficial do WordPress, Jetpack, publicadores autom\u00e1ticos<\/td>\nVerificar se algum plugin ou app depende do endpoint antes<\/td>\n<\/tr>\n
    Troca de prefixo de tabela<\/td>\nPlugins que gravam nomes de tabela fixos, backups antigos, queries customizadas<\/td>\nFazer em ambiente de teste com o banco completo<\/td>\n<\/tr>\n
    Desabilitar REST API<\/td>\nEditor de blocos, WooCommerce, integra\u00e7\u00f5es headless<\/td>\nQuase nunca vale a pena bloquear por completo<\/td>\n<\/tr>\n<\/table>\n

    Por isso, a regra \u00e9: o que depende de tr\u00e1fego ou de banco vai para um site piloto primeiro. Voc\u00ea observa por alguns dias, confere os logs e s\u00f3 ent\u00e3o replica. Quando o problema aparece em dez sites ao mesmo tempo, a triagem vira um pesadelo, e \u00e9 exatamente o cen\u00e1rio descrito em plugins de seguran\u00e7a WordPress: como isolar conflitos<\/a>.<\/p>\n

    Como diagnosticar antes de espalhar a configura\u00e7\u00e3o<\/h2>\n

    Antes de replicar qualquer regra, levante o que cada site realmente usa. Isso evita bloquear algo leg\u00edtimo e depois passar horas descobrindo o motivo.<\/p>\n