---
title: "Proteger senha todo WordPress: Guia essencial em 5 passos"
description: "Proteger senha todo WordPress é exigir uma chave para acessar o site inteiro, não apenas uma página: o servidor responde com um formulário de login."
url: https://full.services/proteger-senha-todo-wordpress/
date: 2026-06-27
author: "Clayton Margiotti"
---
# Proteger senha todo WordPress: Guia essencial em 5 passos
**Proteger senha todo WordPress** exige bloquear o site inteiro antes do PHP, com autenticação HTTP via .htpasswd, não a visibilidade de um post. Segundo a [documentação do Apache](https://httpd.apache.org/docs/current/howto/auth.html) (2026), o mod_auth_basic barra a requisição no servidor. Esse muro fica fora do banco, antes do tema carregar. Use staging para validar.
Proteger senha todo WordPress é exigir uma chave para acessar o site inteiro, não apenas uma página: o servidor responde com um formulário de login antes de o WordPress sequer iniciar. A técnica certa é a autenticação HTTP básica via arquivos .htpasswd e .htaccess no Apache, ou um plugin que cubra todas as URLs, ou um ambiente de staging fechado. É diferente de marcar um post como protegido por senha, que só esconde um conteúdo. Aqui você barra visitantes, robôs e crawlers de uma vez. Este guia mostra o caminho completo em cinco passos, com os limites técnicos reais de cada método. Veja os [guias de segurança WordPress da FULL](https://full.services/seguranca-wordpress/) para aprofundar cada camada.
---
## Visão geral: Proteger senha todo WordPress em uma tabela
Proteger senha todo WordPress leva de 5 a 15 minutos, dependendo do método, e o caminho mais sólido roda fora do WordPress. A autenticação HTTP via .htpasswd intercepta a requisição no Apache antes de qualquer plugin carregar, o que protege até a tela de login e os arquivos estáticos. Um plugin de proteção total cobre as URLs do WordPress, mas depende do PHP já estar rodando.
A tabela abaixo resume os três caminhos, o esforço e o que cada um realmente bloqueia, porque o nível de proteção muda bastante entre eles. São opções com graus distintos de cobertura.
Proteger senha todo WordPress: métodos, esforço e cobertura
| Método |
Esforço |
O que bloqueia |
| Autenticação HTTP (.htpasswd + .htaccess) |
10 a 15 minutos, edita 2 arquivos |
Tudo, antes do PHP: páginas, login e arquivos estáticos |
| Plugin de proteção total (Password Protected) |
5 minutos, sem código |
As URLs do WordPress; o login admin fica liberado |
| Ambiente de staging fechado |
1 clique no painel da hospedagem |
O site em teste inteiro, com URL separada |
A escolha depende de quem você precisa barrar e de onde o site está hospedado.
---
## Por que proteger todo o site, e não só uma página
Proteger senha todo WordPress faz sentido quando o site inteiro não pode aparecer para ninguém: um projeto em desenvolvimento, um ambiente de homologação ou uma área restrita a clientes. A visibilidade nativa de post resolve um conteúdo, mas deixa o resto do site aberto. A decisão muda conforme o estágio do projeto.
A confusão entre esconder um post e fechar o site aparece com frequência nos tickets da FULL, em 10 anos de WordPress. A diferença é de escopo. A autenticação HTTP barra a requisição no servidor Apache, então o WordPress nem carrega para quem não tem a senha, o que economiza processamento e esconde a versão do CMS. Já o post protegido por senha continua exibindo o cabeçalho do tema e o restante da navegação. Para um site que vai ao ar em breve, a opção de fechar tudo também ajuda a bloquear ataques de força bruta no [login do WordPress contra força bruta](https://full.services/como-proteger-wordpress-contra-ataques-de-forca-bruta/) antes mesmo de eles chegarem ao PHP. Escolha pelo escopo, não pelo hábito.
---
## Onde a autenticação HTTP entra na pilha de segurança
Para proteger senha todo WordPress, a autenticação HTTP básica age na camada do servidor web, acima de qualquer [firewall de aplicação WordPress](https://full.services/glossario/firewall-wordpress/). Quando o Apache lê a diretiva no .htaccess, devolve um status 401 e o navegador mostra a caixa de senha nativa. Nada do WordPress roda nesse momento, então o método cobre também o wp-login.php e o wp-admin.
Esse posicionamento tem um efeito prático forte. Um bot que tenta adivinhar senhas no login nunca alcança o formulário do WordPress, porque o muro do servidor responde primeiro. A FULL costuma recomendar essa camada para sites em pré-lançamento, somada à proteção do [painel admin do WordPress](https://full.services/proteger-wp-admin-wordpress/). O detalhe técnico é que o .htpasswd guarda a senha com hash, em geral bcrypt ou APR1-MD5, e fica fora da raiz pública sempre que possível. É uma trava simples, mas solida para o cenário certo.
---
## Passo a passo: Proteger senha todo WordPress com .htpasswd
Para proteger senha todo WordPress pelo servidor, configurar a autenticação HTTP no Apache leva 5 passos e mexe em dois arquivos: o .htpasswd, que guarda usuário e senha com hash, e o .htaccess, que ativa a regra. O processo não toca em nenhum código do WordPress e funciona em qualquer hospedagem que rode Apache com AllowOverride habilitado. Antes de começar, faça um [backup do WordPress](https://full.services/glossario/backup-wordpress/) completo.
Legenda: os dois arquivos que controlam a autenticação HTTP no Apache, na raiz do site.
### Passo 1: Gere o arquivo .htpasswd
Crie o arquivo .htpasswd com o par usuário e senha já em hash, nunca em texto puro. A forma mais segura usa o utilitário htpasswd do Apache no terminal, com o comando htpasswd -c /caminho/.htpasswd seuusuario, que aplica hash bcrypt. Se você não tem acesso a terminal, um gerador online confiável produz a linha no formato usuário:hash. O arquivo deve conter uma linha por usuário e nada mais.
### Passo 2: Coloque o .htpasswd fora da pasta pública
Suba o .htpasswd para um diretório acima da pasta public_html, de modo que ele não seja acessível por URL. Anote o caminho absoluto no servidor, algo como /home/seusite/.htpasswd, porque o .htaccess vai apontar para ele. Guardar o arquivo fora da raiz evita que alguém baixe o hash das senhas direto pelo navegador.
### Passo 3: Edite o .htaccess da raiz
No .htaccess da raiz do WordPress, antes das regras de reescrita do CMS, adicione o bloco de autenticação. As quatro diretivas são AuthType Basic, AuthName com o texto da caixa de login, AuthUserFile com o caminho absoluto do .htpasswd e Require valid-user. Salve em UTF-8 e mantenha as regras originais do WordPress intactas logo abaixo, dentro do marcador BEGIN WordPress.
### Passo 4: Libere o admin-ajax se precisar
Alguns recursos do WordPress e do WooCommerce chamam o admin-ajax.php sem sessão autenticada, e a senha HTTP pode quebrar essas chamadas. Para evitar erro 401 em formulários e checkout, adicione uma exceção que libere o arquivo admin-ajax.php da exigência de senha. Isso preserva a proteção do site e mantém os scripts internos funcionando.
### Passo 5: Teste em uma janela anônima
Abra o site em uma aba anônima e confirme que a caixa de usuário e senha aparece antes de qualquer página, inclusive no wp-login.php. Valide o login com a credencial criada no Passo 1 e verifique se o site carrega normal depois. Teste primeiro em um [ambiente de staging no WordPress](https://full.services/como-criar-ambiente-de-staging-no-wordpress/) para não derrubar o site em produção por um erro de sintaxe no .htaccess.
---
## Quando um plugin de proteção total é a escolha certa
Para proteger senha todo WordPress sem mexer em arquivo, um plugin de proteção total resolve quando você não tem acesso ao .htaccess ou roda em Nginx, que ignora os arquivos do Apache. Plugins como o Password Protected, o WP Force Login ou o My Private Site redirecionam visitantes não autenticados para uma tela de senha única, em uma instalação de cerca de 5 minutos.
O limite é claro: como a checagem acontece no PHP, o WordPress precisa carregar para aplicá-la, então a proteção não cobre arquivos estáticos servidos direto pelo servidor. Um [plugin de WordPress](https://full.services/glossario/plugin-wordpress/) de proteção também deixa o wp-login.php acessível por padrão, porque o admin precisa entrar. Para a maioria dos sites em construção, isso basta. Mas se o objetivo é esconder até a versão do CMS de scanners, a camada de servidor do passo anterior continua sendo mais forte.
---
## A camada de hospedagem: Staging e proteção pela FULL
Fechar um ambiente de staging com senha é outra forma de proteger senha todo WordPress em desenvolvimento, porque ele já nasce isolado em uma URL separada. A maioria das boas hospedagens cria o staging com proteção por login em um clique, sem você tocar em .htpasswd. O ambiente espelha o site real, recebe as alterações em teste e só vai ao ar quando você promove a versão para produção.
Quem precisa proteger senha todo WordPress em vários projetos sente o custo da gestão avulsa de plugins de segurança. O All in One Security, por exemplo, soma firewall, proteção de login e força de senha em um só painel, e está disponível no plano PRO da FULL por R$849, o que equivale a cerca de R$85 por site quando você gerencia uma carteira inteira. A gente vê no suporte que centralizar essas travas num bundle reduz o trabalho de quem cuida de vários WordPress. Conheça os [planos da FULL](https://full.services/planos) para ativar a camada de segurança em todos os seus sites de uma vez.
---
## Erros comuns ao proteger senha todo WordPress
Ao proteger senha todo WordPress, o erro mais frequente é deixar o admin-ajax.php travado pela senha HTTP, o que quebra formulários, checkout do WooCommerce e o editor de blocos com falhas 401 silenciosas. A correção é a exceção do Passo 4, que libera só esse arquivo. Outro tropeço comum é apontar o AuthUserFile para um caminho relativo: o Apache exige o caminho absoluto do .htpasswd, senão devolve erro 500.
Um terceiro problema aparece em hospedagem Nginx, onde o .htaccess simplesmente não funciona porque o servidor não lê esses arquivos. Nesses casos, a regra precisa ir na configuração do Nginx ou você parte para o plugin. Por fim, esquecer de proteger os arquivos sensíveis pelo [htaccess](https://full.services/glossario/htaccess/) deixa brechas mesmo com a senha ativa. Para uma trava extra de privacidade, vale também saber [como tornar o blog WordPress completamente privado](https://full.services/como-tornar-seu-blog-wordpress-completamente-privado/), que age na camada de conteúdo.
---
## Perguntas frequentes sobre proteger senha em todo o WordPress
É possível proteger todo o WordPress com senha sem instalar plugin?
Sim. A autenticação HTTP básica via .htpasswd e .htaccess no Apache fecha o site inteiro sem nenhum plugin, e ainda cobre o wp-login.php e os arquivos estáticos. Você edita dois arquivos no servidor e o Apache passa a exigir usuário e senha antes de o WordPress carregar. O método só não funciona em hospedagem Nginx, que ignora o .htaccess.
Por que a senha em um post não protege o site todo?
Porque a visibilidade Password Protected age só naquele conteúdo específico. O resto do site, a tela de login wp-login.php e os arquivos de mídia continuam abertos ao público e aos crawlers. Para fechar tudo, você precisa de uma trava na camada do servidor, com .htpasswd, ou de um plugin que cubra todas as URLs do WordPress de uma vez.
A senha HTTP atrapalha o Google a indexar o site depois?
Não, desde que você remova a proteção antes do lançamento. Enquanto o site está fechado por .htpasswd, o Googlebot recebe um status 401 e não rastreia nada, o que é exatamente o esperado em um ambiente de pré-lançamento. Ao publicar, basta apagar o bloco de autenticação do .htaccess e enviar o sitemap pelo Search Console para o rastreamento começar.
Qual a diferença entre .htpasswd e um plugin de proteção total?
O .htpasswd age no servidor Apache, antes do PHP, então bloqueia tudo, inclusive o login e os arquivos estáticos, e esconde a versão do WordPress. O plugin age dentro do PHP, depois que o WordPress carrega, e cobre as URLs do site, mas deixa o wp-login.php acessível. O .htpasswd é mais forte; o plugin é mais simples e funciona em Nginx.
Como proteger um WordPress hospedado em Nginx, sem .htaccess?
No Nginx, o .htaccess é ignorado, então você tem dois caminhos. O primeiro é adicionar a diretiva auth_basic com um arquivo .htpasswd direto no bloco server da configuração do Nginx, o que exige acesso ao servidor. O segundo, mais acessível, é usar um plugin de proteção total como o Password Protected ou fechar o acesso por um ambiente de staging com login da própria hospedagem.
---
## Próximos passos para fechar seu site com segurança
Proteger senha todo WordPress é uma decisão de escopo: a autenticação HTTP via .htpasswd fecha o site inteiro antes do PHP, o plugin cobre as URLs com menos esforço e o staging isola o ambiente de teste numa URL própria. Resumindo, proteger senha todo WordPress depende de onde o site roda e de quem você precisa barrar. Para um site em pré-lançamento ou homologação, a camada de servidor é a mais sólida, porque barra até robôs e scanners de versão. Sempre teste a configuração em staging antes de aplicar em produção, com um backup recente à mão. Para continuar aprendendo a blindar cada camada do seu WordPress, o [FULL Academy](https://full.services/academy/) reúne tutoriais, guias e reviews de segurança em um só lugar.
---
## Metadados Estruturados (Schema.org)
```json-ld
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "TechArticle",
"@id": "https://full.services/proteger-senha-todo-wordpress/#article",
"headline": "Proteger senha todo WordPress: Guia essencial em 5 passos",
"description": "Proteger senha todo WordPress é exigir uma chave para acessar o site inteiro, não apenas uma página: o servidor responde com um formulário de login antes de o WordPress sequer iniciar.",
"url": "https://full.services/proteger-senha-todo-wordpress/",
"datePublished": "2026-06-27T09:00:00-03:00",
"dateModified": "2026-06-27T09:00:00-03:00",
"inLanguage": "pt-BR",
"articleSection": "Seguranca WordPress",
"keywords": [
"proteger senha todo wordpress",
"WordPress",
"Web Development"
],
"author": {
"@id": "https://full.services/#person-clayton"
},
"publisher": {
"@id": "https://full.services/#org"
},
"about": [
{
"@type": "Thing",
"name": "WordPress",
"@id": "https://www.wikidata.org/wiki/Q13166",
"sameAs": "https://www.wikidata.org/wiki/Q13166"
},
{
"@type": "Thing",
"name": "Web Development",
"@id": "https://www.wikidata.org/wiki/Q386275",
"sameAs": "https://www.wikidata.org/wiki/Q386275"
}
],
"mentions": [
{
"@type": "Organization",
"name": "WordPress",
"url": "https://wordpress.org/",
"@id": "https://www.wikidata.org/wiki/Q13166",
"sameAs": "https://www.wikidata.org/wiki/Q13166"
}
],
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://full.services/proteger-senha-todo-wordpress/"
},
"wordCount": 2238
},
{
"@type": "FAQPage",
"@id": "https://full.services/proteger-senha-todo-wordpress/#faq",
"isPartOf": {
"@id": "https://full.services/proteger-senha-todo-wordpress/#article"
},
"mainEntity": [
{
"@type": "Question",
"@id": "https://full.services/proteger-senha-todo-wordpress/#faq-q1",
"name": "É possível proteger todo o WordPress com senha sem instalar plugin?",
"inLanguage": "pt-BR",
"acceptedAnswer": {
"@type": "Answer",
"text": "Sim. A autenticação HTTP básica via .htpasswd e .htaccess no Apache fecha o site inteiro sem nenhum plugin, e ainda cobre o wp-login.php e os arquivos estáticos. Você edita dois arquivos no servidor e o Apache passa a exigir usuário e senha antes de o WordPress carregar. O método só não funciona em hospedagem Nginx, que ignora o .htaccess.",
"author": {
"@id": "https://full.services/#org"
}
}
},
{
"@type": "Question",
"@id": "https://full.services/proteger-senha-todo-wordpress/#faq-q2",
"name": "Por que a senha em um post não protege o site todo?",
"inLanguage": "pt-BR",
"acceptedAnswer": {
"@type": "Answer",
"text": "Porque a visibilidade Password Protected age só naquele conteúdo específico. O resto do site, a tela de login wp-login.php e os arquivos de mídia continuam abertos ao público e aos crawlers. Para fechar tudo, você precisa de uma trava na camada do servidor, com .htpasswd, ou de um plugin que cubra todas as URLs do WordPress de uma vez.",
"author": {
"@id": "https://full.services/#org"
}
}
},
{
"@type": "Question",
"@id": "https://full.services/proteger-senha-todo-wordpress/#faq-q3",
"name": "A senha HTTP atrapalha o Google a indexar o site depois?",
"inLanguage": "pt-BR",
"acceptedAnswer": {
"@type": "Answer",
"text": "Não, desde que você remova a proteção antes do lançamento. Enquanto o site está fechado por .htpasswd, o Googlebot recebe um status 401 e não rastreia nada, o que é exatamente o esperado em um ambiente de pré-lançamento. Ao publicar, basta apagar o bloco de autenticação do .htaccess e enviar o sitemap pelo Search Console para o rastreamento começar.",
"author": {
"@id": "https://full.services/#org"
}
}
},
{
"@type": "Question",
"@id": "https://full.services/proteger-senha-todo-wordpress/#faq-q4",
"name": "Qual a diferença entre .htpasswd e um plugin de proteção total?",
"inLanguage": "pt-BR",
"acceptedAnswer": {
"@type": "Answer",
"text": "O .htpasswd age no servidor Apache, antes do PHP, então bloqueia tudo, inclusive o login e os arquivos estáticos, e esconde a versão do WordPress. O plugin age dentro do PHP, depois que o WordPress carrega, e cobre as URLs do site, mas deixa o wp-login.php acessível. O .htpasswd é mais forte; o plugin é mais simples e funciona em Nginx.",
"author": {
"@id": "https://full.services/#org"
}
}
},
{
"@type": "Question",
"@id": "https://full.services/proteger-senha-todo-wordpress/#faq-q5",
"name": "Como proteger um WordPress hospedado em Nginx, sem .htaccess?",
"inLanguage": "pt-BR",
"acceptedAnswer": {
"@type": "Answer",
"text": "No Nginx, o .htaccess é ignorado, então você tem dois caminhos. O primeiro é adicionar a diretiva auth_basic com um arquivo .htpasswd direto no bloco server da configuração do Nginx, o que exige acesso ao servidor. O segundo, mais acessível, é usar um plugin de proteção total como o Password Protected ou fechar o acesso por um ambiente de staging com login da própria hospedagem.",
"author": {
"@id": "https://full.services/#org"
}
}
}
]
},
{
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "Home",
"item": "https://full.services/"
},
{
"@type": "ListItem",
"position": 2,
"name": "Seguranca WordPress",
"item": "https://full.services/seguranca-wordpress/"
},
{
"@type": "ListItem",
"position": 3,
"name": "Proteger senha todo WordPress: Guia essencial em 5 passos",
"item": "https://full.services/proteger-senha-todo-wordpress/"
}
]
},
{
"@type": "Organization",
"@id": "https://full.services/#org",
"name": "FULL Services",
"url": "https://full.services",
"logo": {
"@type": "ImageObject",
"url": "https://full.services/wp-content/uploads/full-services-logo.png",
"width": 200,
"height": 60
},
"sameAs": [
"https://www.instagram.com/fullservicesbr",
"https://www.facebook.com/fullservices.br",
"https://www.linkedin.com/company/fullservicesbr/"
],
"knowsAbout": [
"WordPress",
"WordPress Hosting",
"Web Development",
"Performance Optimization",
"WordPress Security",
"SEO para WordPress"
],
"award": [
"Gold Medal - The WP Weekly Awards 2023 (https://thewpweekly.com/awards-2023/)",
"Gold Medal - The WP Weekly Awards 2024 (https://thewpweekly.com/awards-2024/)"
],
"hasCredential": {
"@type": "EducationalOccupationalCredential",
"credentialCategory": "certification",
"name": "CVE Numbering Authority (CNA)",
"description": "Autoridade de numeração de vulnerabilidades (CVE) para o ecossistema WordPress, autorizada a atribuir IDs CVE. Certificação válida desde 2022-05-03, com abrangência global.",
"url": "https://www.cve.org/PartnerInformation/ListofPartners/partner/FULL",
"recognizedBy": {
"@type": "Organization",
"name": "CISA — Cybersecurity and Infrastructure Security Agency",
"url": "https://www.cisa.gov/",
"sameAs": "https://www.cisa.gov/"
}
}
},
{
"@type": "Person",
"@id": "https://full.services/#person-clayton",
"name": "Clayton Margiotti",
"givenName": "Clayton",
"familyName": "Margiotti",
"jobTitle": "Fundador e CEO da FULL Services",
"description": "Fundador e CEO da FULL Services, plataforma WordPress SaaS com 50 mil clientes e 150 mil sites conectados, e anchor do ecossistema Elevor Global. Em 2024 conduziu a FULL a se tornar a primeira e unica empresa brasileira aprovada como CVE Numbering Authority sob a CISA (DHS/EUA). Mais de 20 anos construindo empresas digitais, com 13+ reconhecimentos internacionais (Facebook, GPTW, ONU, RD Summit).",
"url": "https://full.services/sobre-nos/",
"image": "https://full.services/wp-content/uploads/2026/05/clayton-margiotti.jpg",
"sameAs": [
"https://www.linkedin.com/in/cmargiotti/"
],
"knowsAbout": [
"Artificial Intelligence",
"Cybersecurity",
"CVE Program",
"WordPress Enterprise",
"SaaS Platforms",
"Digital Infrastructure",
"Technology Entrepreneurship",
"Company Building",
"Business Leadership",
"Digital Growth"
],
"hasOccupation": {
"@type": "Occupation",
"name": "Fundador e CEO",
"occupationalCategory": "11-1011.00"
},
"knowsLanguage": [
{
"@type": "Language",
"name": "Portuguese",
"alternateName": "pt-BR"
},
{
"@type": "Language",
"name": "English",
"alternateName": "en"
}
],
"memberOf": {
"@type": "Organization",
"name": "CVE Numbering Authorities",
"url": "https://www.cve.org/",
"sameAs": "https://www.cve.org/"
},
"alumniOf": [
{
"@type": "EducationalOrganization",
"name": "Global Scaling Academy (Blitzscaling Program)",
"url": "https://www.blitzscalingacademy.com"
},
{
"@type": "EducationalOrganization",
"name": "Esade",
"url": "https://www.esade.edu"
},
{
"@type": "EducationalOrganization",
"name": "Business School Sao Paulo (BSP)",
"url": "https://bsp.edu.br/"
},
{
"@type": "EducationalOrganization",
"name": "Tera",
"url": "https://somostera.com"
},
{
"@type": "EducationalOrganization",
"name": "Le Wagon",
"url": "https://www.lewagon.com"
},
{
"@type": "EducationalOrganization",
"name": "FIAP",
"url": "https://www.fiap.com.br"
},
{
"@type": "EducationalOrganization",
"name": "PUCRS",
"url": "https://online.pucrs.br/"
}
],
"award": [
"Digital Disruptor – Engaging Experiences Master (Globant, 2021)",
"Maior ROI do e-commerce brasileiro – Letrissimas (Facebook, 2019)",
"1º lugar – Melhores Empresas para Trabalhar no Brasil – Eleva Digital (Great Place to Work, 2018)",
"Case global de educacao no Facebook – Metodo SUPERA (Facebook, 2017)",
"Maquina de Geracao de Leads, Agencia do Ano (RD Summit / RD Station, 2015)",
"Monthly Recurring Revenue, top performance (RD Summit / RD Station, 2015)",
"Quality/Efficiency – Entrepreneurship Training (UNCTAD / PNUD-ONU, 2010)"
],
"subjectOf": [
{
"@type": "NewsArticle",
"url": "https://www.globant.com/news/globant-reveals-inaugural-digital-disruptors-award-winners",
"publisher": {
"@type": "Organization",
"name": "Globant"
}
},
{
"@type": "NewsArticle",
"url": "https://www.prnewswire.com/news-releases/letrissimas-com-e-destaque-do-e-commerce-brasileiro-com-maior-roi-de-2018-877517801.html",
"publisher": {
"@type": "Organization",
"name": "PR Newswire"
}
},
{
"@type": "NewsArticle",
"url": "https://www.segs.com.br/seguros/102599-gestao-de-pessoas-garante-mais-lucro-as-empresas",
"publisher": {
"@type": "Organization",
"name": "Segs"
}
},
{
"@type": "NewsArticle",
"url": "https://franquiaeducacional.com/negocios-inovadores-facebook-elege-supera-case-mundial-de-educacao",
"publisher": {
"@type": "Organization",
"name": "Franquia Educacional"
}
},
{
"@type": "NewsArticle",
"url": "https://acontecendoaqui.com.br/marketing/resultados-digitais-divulga-vencedores-do-premio-agencias-de-resultados-2015-durante-o-rd",
"publisher": {
"@type": "Organization",
"name": "Acontecendo Aqui"
}
}
],
"worksFor": {
"@type": "Organization",
"@id": "https://full.services/#org"
}
},
{
"@type": "HowTo",
"@id": "https://full.services/proteger-senha-todo-wordpress/#howto",
"isPartOf": {
"@id": "https://full.services/proteger-senha-todo-wordpress/#article"
},
"name": "Passo a passo: proteger senha todo wordpress",
"description": "Guia passo a passo sobre proteger senha todo wordpress para WordPress.",
"url": "https://full.services/proteger-senha-todo-wordpress/",
"totalTime": "PT30M",
"author": {
"@type": "Organization",
"@id": "https://full.services/#org"
},
"step": [
{
"@type": "HowToStep",
"position": 1,
"name": "Passo 1: Gere o arquivo .htpasswd",
"text": "Crie o arquivo .htpasswd com o par usuário e senha já em hash, nunca em texto puro. A forma mais segura usa o utilitário htpasswd do Apache no terminal, com o comando htpasswd -c /caminho/.htpasswd seuusuario, que aplica hash bcrypt. Se você não tem acesso a terminal, um gerador online confiável produz a linha no formato usuário:hash. O arquivo deve conter uma linha por usuário e nada mais."
},
{
"@type": "HowToStep",
"position": 2,
"name": "Passo 2: Coloque o .htpasswd fora da pasta pública",
"text": "Suba o .htpasswd para um diretório acima da pasta public_html, de modo que ele não seja acessível por URL. Anote o caminho absoluto no servidor, algo como /home/seusite/.htpasswd, porque o .htaccess vai apontar para ele. Guardar o arquivo fora da raiz evita que alguém baixe o hash das senhas direto pelo navegador."
},
{
"@type": "HowToStep",
"position": 3,
"name": "Passo 3: Edite o .htaccess da raiz",
"text": "No .htaccess da raiz do WordPress, antes das regras de reescrita do CMS, adicione o bloco de autenticação. As quatro diretivas são AuthType Basic, AuthName com o texto da caixa de login, AuthUserFile com o caminho absoluto do .htpasswd e Require valid-user. Salve em UTF-8 e mantenha as regras originais do WordPress intactas logo abaixo, dentro do marcador BEGIN WordPress."
},
{
"@type": "HowToStep",
"position": 4,
"name": "Passo 4: Libere o admin-ajax se precisar",
"text": "Alguns recursos do WordPress e do WooCommerce chamam o admin-ajax.php sem sessão autenticada, e a senha HTTP pode quebrar essas chamadas. Para evitar erro 401 em formulários e checkout, adicione uma exceção que libere o arquivo admin-ajax.php da exigência de senha. Isso preserva a proteção do site e mantém os scripts internos funcionando."
},
{
"@type": "HowToStep",
"position": 5,
"name": "Passo 5: Teste em uma janela anônima",
"text": "Abra o site em uma aba anônima e confirme que a caixa de usuário e senha aparece antes de qualquer página, inclusive no wp-login.php. Valide o login com a credencial criada no Passo 1 e verifique se o site carrega normal depois. Teste primeiro em um ambiente de staging no WordPress para não derrubar o site em produção por um erro de sintaxe no .htaccess. --- Para proteger senha todo WordPress sem mexer em arquivo, um plugin de proteção total resolve quando você não tem acesso ao .htaccess ou roda em Nginx, que ignora os arquivos do Apache. Plugins como o Password Protected, o WP Force Login ou o My Private Site redirecionam visitantes não autenticados para uma tela de senha única, em uma instalação de cerca de 5 minutos. O limite é claro: como a checagem acontece no PHP, o WordPress precisa carregar para aplicá-la, então a proteção não cobre arquivos estáticos servidos direto pelo servidor. Um plugin de WordPress de proteção também deixa o wp-login.php acessível por padrão, porque o admin precisa entrar. Para a maioria dos sites em"
}
]
}
]
}
```