| Camada | Objetivo | Check de validação |
|---|---|---|
| Certificado SSL | Emitir e instalar o certificado no domínio | Nota A no SSL Labs Test |
| Redirecionamento 301 | Enviar todo HTTP para HTTPS sem loop | curl -I retorna 301 para HTTPS |
| Conteúdo misto | Limpar URLs HTTP no banco e nos assets | Console do navegador sem warning |
| HSTS | Instruir o navegador a só usar HTTPS | Header Strict-Transport-Security presente |
Legenda: o certificado válido é a base. Sem ele, forçar HTTPS gera erro de conexão não privada no navegador.
Instalar o certificado é a camada zero: sem um certificado válido, qualquer redirecionamento para HTTPS gera o aviso "sua conexão não é privada" e derruba o tráfego. A maioria das hospedagens emite um certificado gratuito da Let's Encrypt em poucos minutos pelo painel, com renovação automática a cada 90 dias. Confirme a emissão antes de seguir, porque as próximas 3 camadas pressupõem um certificado ativo. O passo a passo está no tutorial de certificado SSL gratuito para WordPress, e a alternativa via Let's Encrypt no guia de SSL grátis. Segundo a documentação oficial da Let's Encrypt, o protocolo ACME renova o certificado sem intervenção manual, o que elimina a falha clássica de certificado expirado. --- ## Por que o redirecionamento 301 precisa ser forçado no servidor O redirecionamento 301 é a camada que envia todo acesso HTTP para HTTPS de forma permanente, e ele precisa rodar antes de qualquer plugin carregar. Um redirecionamento por PHP funciona, mas adiciona até 50 ms de latência; o ideal é forçar no servidor, via .htaccess no Apache ou bloco server no Nginx. A regra clássica no .htaccess usa `RewriteCond %{HTTPS} off` seguida de `RewriteRule` para HTTPS com flag R=301. O risco real aparece atrás de proxy reverso: redirecionamento 301 forçado no .htaccess sem checar o header `X-Forwarded-Proto` em servidor atrás de proxy reverso resulta em loop infinito de redirecionamento, com o navegador retornando ERR_TOO_MANY_REDIRECTS. Nesses casos, a condição correta passa a ser `RewriteCond %{HTTP:X-Forwarded-Proto} !https`. Teste sempre com `curl -I` antes de confiar no resultado, e nunca empilhe regras de 301 de plugin e de servidor ao mesmo tempo, porque a dupla camada gera redirecionamento conflitante e intermitente em parte das requisições. --- ## Como forçar HTTPS no WordPress passo a passo Forçar HTTPS no WordPress de ponta a ponta leva de 10 a 30 minutos em um site pequeno, e os quatro passos abaixo cobrem desde a configuração da URL até a ativação do HSTS. Execute na ordem: alterar a URL antes de redirecionar evita que o WordPress gere links absolutos em HTTP e recrie conteúdo misto. Cada passo tem um check objetivo de validação. ### Passo 1: Configure a URL do site para HTTPS Acesse Configurações, Geral e altere "Endereço do WordPress" e "Endereço do Site" de HTTP:// para https://. Em sites com acesso travado, edite o wp-config.php e defina `WP_HOME` e `WP_SITEURL` com a URL HTTPS. Esse passo faz o WordPress gerar todos os novos links em HTTPS e é pré-requisito para os próximos. ### Passo 2: Force o redirecionamento 301 no .htaccess Adicione a regra de RewriteCond e RewriteRule no topo do .htaccess, acima do bloco do WordPress. Se o site estiver atrás de Cloudflare ou proxy, use a condição com `X-Forwarded-Proto`. Valide com `curl -I http://seusite.com` e confirme o retorno `301` apontando para o destino HTTPS. ### Passo 3: Limpe o conteúdo misto no banco de dados Rode um search-replace para trocar `http://seusite.com` por `https://seusite.com` em todas as tabelas. Via WP-CLI, o comando é `wp search-replace 'http://seusite.com' 'https://seusite.com' --all-tables --dry-run` antes de aplicar. Isso elimina URLs absolutas hardcoded de imagens e CSS que mantêm o cadeado quebrado. ### Passo 4: Ative o cabeçalho HSTS Adicione `Strict-Transport-Security: max-age=31536000; includeSubDomains` no .htaccess ou no Nginx. Só ative depois que os passos 1 a 3 estiverem validados, porque o HSTS instrui o navegador a recusar HTTP por um ano. Confirme o header com o Mozilla Observatory. --- ## Conteúdo misto: Por que o cadeado quebra mesmo com SSLLegenda: o aviso de mixed content no console é a causa nº 1 do cadeado quebrado após migração para HTTPS.
Conteúdo misto acontece quando uma página em HTTPS carrega recursos via protocolo inseguro, e é a causa que aparece em cerca de metade dos chamados de "SSL não funciona" no suporte da FULL. O navegador exibe o cadeado quebrado e, em scripts, bloqueia o recurso por completo, sem erro visível no admin. A relação técnica é direta: assets inseguros hardcoded no banco, somados a uma página segura, resultam em cadeado quebrado e bloqueio de scripts pelo navegador. A correção definitiva é o search-replace do Passo 3, não um plugin que reescreve a saída em tempo real, porque esse tipo de plugin tende a mascarar o problema sem limpar a origem. Para diagnosticar rápido, abra o console (F12) e procure os warnings de "Mixed Content". O tutorial de cabeçalhos de segurança HTTP no WordPress complementa a limpeza com a política Content-Security-Policy. --- ## Plugins SSL: Vulnerabilidades reais e o que isso ensina O plugin de SSL mais usado, o Really Simple SSL, já teve 4 CVEs catalogados ao longo dos anos, sendo 1 deles crítico, segundo o perfil público do WPVulnerability. O dado importa pela lição de processo, não pelo alarme: todas estão corrigidas nas versões atuais. Um histórico de CVEs corrigidas sinaliza auditoria ativa, não fragilidade. A FULL fala disso com autoridade direta porque é a única empresa brasileira reconhecida como CNA (CVE Numbering Authority) sob a CISA desde maio de 2022, ou seja, está autorizada a atribuir IDs CVE oficiais. O risco real está sempre na versão desatualizada, nunca na falha já corrigida. O caso mais sério foi a CVE-2024-10924, com CVSS 9.8 (crítico), que permitia bypass de autenticação e afetava as versões 9.0.0 a 9.1.1.1 do Really Simple SSL. Outra foi a CVE-2025-24623, CVSS 4.3, corrigida na 9.2.0. A leitura defensiva é direta: forçar HTTPS sem manter o plugin atualizado troca um risco por outro. Mantenha atualizações automáticas ativas, como no hardening de segurança no WordPress. --- ## Como manter o HTTPS sem gerenciar plugin por plugin Manter o HTTPS travado e os plugins de segurança atualizados em escala é onde o tempo do administrador some. O plano PRO da FULL sai por R$849,90 e cobre até 10 sites, o que dá cerca de R$85 por site, com os plugins de segurança e SSL gerenciados de forma centralizada. A gente vê no suporte que o site não cai por falta de certificado, e sim por plugin de SSL desatualizado meses depois da migração. O bundle resolve a manutenção, não a hospedagem: a FULL gerencia a camada de segurança e os plugins, complementando a sua hospedagem atual. Conheça os planos da FULL e o All in One Security incluso no pacote. Antes de fechar, rode uma verificação independente. Escaneie seu WordPress gratuitamente e descubra se algum plugin de SSL ou segurança está em versão vulnerável com o FULL Scan, sem instalar nada. --- ## Decisão rápida: Qual camada priorizar primeiroSim, é possível e até recomendado em servidores próprios. Você força HTTPS editando o .htaccess no Apache com uma regra RewriteCond e RewriteRule de 301, mais o cabeçalho HSTS, sem nenhum plugin. Esse método é mais rápido que o redirecionamento por PHP porque roda antes do WordPress carregar. O plugin Really Simple SSL só é mais prático para quem não tem acesso ao servidor ou quer evitar editar arquivos manualmente.
O cadeado quebra por conteúdo misto: a página carrega em HTTPS, mas puxa imagens, CSS ou scripts em http://. Isso acontece quando o banco de dados guarda URLs absolutas em HTTP, comum em sites migrados sem search-replace. O navegador detecta o recurso inseguro e quebra o cadeado, e em scripts ele bloqueia o recurso. A correção é rodar o search-replace em todas as tabelas, trocando HTTP:// por https://, e não confiar só na ativação do certificado.
O redirecionamento 301 envia o usuário de HTTP para HTTPS a cada acesso, mas o navegador ainda tenta HTTP primeiro. O HSTS é um cabeçalho que instrui o navegador a nunca mais tentar HTTP por um período definido, como `max-age=31536000` (um ano). O 301 corrige o acesso; o HSTS previne o acesso inseguro na origem. Ative o HSTS só depois que o 301 e a limpeza de conteúdo misto estiverem validados, porque ele é difícil de reverter.
Em um site pequeno, forçar HTTPS leva de 10 a 30 minutos no total: poucos minutos para emitir o certificado pelo painel, alguns para o redirecionamento 301 e o restante para o search-replace e o HSTS. Sites grandes, com muitas URLs hardcoded no banco, podem levar mais por causa da limpeza de conteúdo misto. O gargalo quase nunca é o certificado, e sim encontrar e corrigir todos os recursos servidos em HTTP no conteúdo antigo.
Conteúdo misto é quando uma página servida em HTTPS carrega recursos em http://, como imagens, fontes ou scripts. Isso afeta o HTTPS de duas formas: o navegador quebra o cadeado de segurança e, no caso de scripts e iframes, bloqueia o recurso por completo, o que pode quebrar o layout. A causa raiz costuma ser URLs absolutas em HTTP salvas no banco de dados. A solução é o search-replace em todas as tabelas, não um plugin que mascara a saída em tempo de execução.