Como redirecionar HTTP para HTTPS no WordPress

Migrar o seu site WordPress de HTTP para HTTPS não é mais opcional. Os navegadores sinalizam sites HTTP como "Não Seguro", o Google usa o HTTPS como sinal de ranqueamento, e os dados dos seus visitantes são transmitidos em texto puro, sem criptografia. Após instalar um certificado SSL, é preciso redirecionar adequadamente todo o tráfego HTTP para HTTPS e corrigir quaisquer problemas remanescentes de conteúdo misto. Este guia cobre cada etapa do processo, desde a obtenção de um certificado até a depuração de loops de redirecionamento atrás de balanceadores de carga.

Por que o HTTPS importa além da segurança básica

A razão óbvia para o HTTPS é a criptografia. Sem ela, tudo entre o navegador do seu visitante e seu servidor (envios de formulários, credenciais de login, cookies, dados pessoais) pode ser interceptado por qualquer pessoa na mesma rede. Mas o HTTPS importa por várias outras razões que afetam diretamente o sucesso do seu site:

• Fator de ranqueamento de SEO: O Google confirmou em agosto de 2014 que o HTTPS é um sinal de ranqueamento. Embora seja um sinal leve, todo o resto sendo igual, a versão HTTPS de uma página será classificada acima da versão HTTP. Em nichos competitivos, cada sinal conta.
• Avisos do navegador: Chrome, Firefox, Safari e Edge exibem avisos "Não Seguro" para páginas HTTP, especialmente aquelas com entradas de formulário. Isso corrói a confiança do visitante e aumenta as taxas de rejeição. O Chrome vem tornando esses avisos mais proeminentes progressivamente desde o Chrome 68 (julho de 2018).
• Suporte a HTTP/2 e HTTP/3: Protocolos modernos como HTTP/2 e HTTP/3, que melhoram drasticamente a velocidade de carregamento das páginas por meio de multiplexação e compressão de cabeçalhos, exigem HTTPS na prática. Todos os principais navegadores só suportam HTTP/2 sobre TLS.
• Dados de referência: Quando um visitante clica em um link de uma página HTTPS para uma página HTTP, o navegador remove o cabeçalho Referer. Isso significa que você perde dados de análise sobre de onde vem seu tráfego. Se seu site está em HTTPS, você preserva os dados de referência de outros sites HTTPS.
• Service Workers e PWA: Recursos de Progressive Web App como cache offline, notificações push e o prompt "Adicionar à Tela Inicial" exigem HTTPS.

Obtendo um certificado SSL gratuito com Let's Encrypt

Você não precisa pagar por um certificado SSL. O Let's Encrypt fornece certificados gratuitos, automatizados e validados por domínio (DV) que são confiáveis por todos os principais navegadores. A maioria dos provedores de hospedagem integrou o Let's Encrypt em seus painéis de controle, mas se você gerencia seu próprio servidor, veja como configurá-lo com o Certbot:

# Instalar Certbot no Ubuntu/Debian
sudo apt update
sudo apt install certbot

# Para Apache
sudo apt install python3-certbot-apache
sudo certbot --apache -d example.com -d www.example.com

# Para Nginx
sudo apt install python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com

O Certbot configurará automaticamente seu servidor web para usar o certificado e configurará um cron job para renovação automática. Os certificados Let's Encrypt são válidos por 90 dias, mas o processo de renovação automática lida com isso de forma transparente. Para verificar se a renovação automática está funcionando:

# Testar o processo de renovação (não renova de fato)
sudo certbot renew --dry-run

# Verificar o timer de renovação
sudo systemctl status certbot.timer

Se seu provedor de hospedagem oferece SSL com um clique pelo painel de controle (SiteGround, Bluehost, HostGator, etc.), use isso. É o mesmo certificado Let's Encrypt, mas gerenciado pelo seu host, o que significa uma coisa a menos para manter.

Etapa 1: Atualize as URLs do WordPress

Antes de configurar redirecionamentos, diga ao WordPress que seu site agora usa HTTPS. Vá para Configurações > Geral e atualize ambos os campos:

• Endereço do WordPress (URL): Altere http://example.com para https://example.com
• Endereço do Site (URL): Altere http://example.com para https://example.com

Se você não consegue acessar o painel administrativo (por exemplo, se já está preso em um loop de redirecionamento), pode definir esses valores diretamente em wp-config.php:

define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');

Ou atualize o banco de dados diretamente via WP-CLI:

wp option update siteurl 'https://example.com'
wp option update home 'https://example.com'

Etapa 2: Redirecionamento HTTP para HTTPS no nível do servidor

O redirecionamento deve acontecer no nível do servidor (não em PHP) por duas razões: é mais rápido porque não exige carregar o WordPress, e garante que todas as requisições (incluindo arquivos estáticos, imagens e chamadas de API) sejam redirecionadas, não apenas as URLs tratadas pelo WordPress.

Apache (.htaccess)

Adicione isto bem no início do seu arquivo .htaccess, antes das regras de reescrita do WordPress (antes do comentário # BEGIN WordPress):

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

A flag R=301 envia um redirecionamento permanente, que diz aos motores de busca para atualizarem seu índice para a versão HTTPS. Não use R=302 (redirecionamento temporário) porque os motores de busca não transferirão o capital de links para a nova URL.

Nginx

Em sua configuração do Nginx, crie um bloco de servidor separado para HTTP que redireciona tudo para HTTPS:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # ... resto da sua configuração
}

Usar return 301 no Nginx é mais eficiente do que usar rewrite porque não exige processamento de regex.

Etapa 3: Forçar HTTPS no wp-config.php

Adicione estas linhas ao seu arquivo wp-config.php, acima do comentário "That's all, stop editing!":

// Forçar SSL para a área administrativa do WordPress
define('FORCE_SSL_ADMIN', true);

// Lidar com SSL atrás de um proxy reverso ou balanceador de carga
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

A constante FORCE_SSL_ADMIN garante que a página de login do WordPress e o painel administrativo sempre usem HTTPS, mesmo se alguém tentar acessá-los via HTTP diretamente.

Corrigindo loops de redirecionamento atrás de balanceadores de carga e proxies reversos

Este é um dos problemas mais comuns com configurações HTTPS do WordPress, e atrapalha muita gente. Se seu site está atrás de um balanceador de carga, Cloudflare, um proxy reverso ou um CDN, a conexão entre o proxy e o seu servidor é frequentemente HTTP puro, mesmo que a conexão entre o visitante e o proxy seja HTTPS. Seu servidor vê uma requisição HTTP e tenta redirecionar para HTTPS, o proxy envia a requisição de volta como HTTP, e você acaba em um loop infinito de redirecionamento. O navegador mostra "ERR_TOO_MANY_REDIRECTS".

A correção é a verificação do cabeçalho X-Forwarded-Proto mostrada acima. O proxy adiciona este cabeçalho para informar ao seu servidor qual protocolo a requisição original usou. Quando o WordPress vê que o protocolo encaminhado é HTTPS, ele trata a conexão como segura e não dispara um redirecionamento.

Se a verificação de cabeçalho padrão não funcionar, seu proxy pode usar um cabeçalho diferente. Verifique com seu provedor de hospedagem. Variações comuns incluem:

// Para alguns balanceadores de carga que usam X-Forwarded-Ssl
if (isset($_SERVER['HTTP_X_FORWARDED_SSL']) && $_SERVER['HTTP_X_FORWARDED_SSL'] === 'on') {
    $_SERVER['HTTPS'] = 'on';
}

// Para Cloudflare (que também define X-Forwarded-Proto, mas por garantia)
if (isset($_SERVER['HTTP_CF_VISITOR'])) {
    $visitor = json_decode($_SERVER['HTTP_CF_VISITOR']);
    if (isset($visitor->scheme) && $visitor->scheme === 'https') {
        $_SERVER['HTTPS'] = 'on';
    }
}

Etapa 4: Substitua URLs HTTP no banco de dados

Seu banco de dados WordPress contém URLs HTTP fixas em conteúdo de posts, configurações de widgets, opções de tema e dados serializados. Você precisa substituí-las todas por versões HTTPS. A melhor ferramenta para isso é o comando search-replace do WP-CLI:

# Primeiro, faça uma execução de teste para ver o que mudaria
wp search-replace 'http://example.com' 'https://example.com' --all-tables --dry-run

# Se a execução de teste estiver boa, execute a substituição real
wp search-replace 'http://example.com' 'https://example.com' --all-tables

# Trate também variações com/sem www, se aplicável
wp search-replace 'http://www.example.com' 'https://www.example.com' --all-tables

A flag --dry-run é importante. Ela mostra exatamente quantas substituições serão feitas em cada tabela sem realmente modificar nada. Revise a saída antes de executar a substituição real. A flag --all-tables garante que tabelas personalizadas (de plugins como WooCommerce, ACF ou page builders) sejam incluídas.

O WP-CLI lida corretamente com dados serializados, o que é crítico. Se você tentar fazer uma simples busca e substituição em SQL, quebrará arrays serializados, porque os valores de comprimento da string não corresponderão mais. Nunca execute uma consulta SQL REPLACE() bruta para essa finalidade.

Corrigindo problemas de conteúdo misto

Conteúdo misto ocorre quando sua página HTTPS carrega recursos (imagens, scripts, folhas de estilo, iframes) por HTTP. Os navegadores bloqueiam conteúdo misto ativo (scripts, folhas de estilo) inteiramente e podem avisar sobre conteúdo misto passivo (imagens). Isso resulta em funcionalidade quebrada ou ícones de aviso amarelos na barra de endereços.

Para encontrar problemas de conteúdo misto:

1. Console do navegador: Abra as DevTools (F12) e olhe a aba Console. Avisos de conteúdo misto aparecem como mensagens amarelas ou vermelhas listando as URLs exatas dos recursos ofensores.
2. InspectWP: Execute uma varredura e verifique a seção HTML. O InspectWP detecta recursos inseguros (HTTP) carregados em páginas HTTPS e lista cada um.
3. Why No Padlock: O site whynopadlock.com analisa sua página e relata todos os recursos de conteúdo misto com suas URLs de origem.

Fontes comuns de conteúdo misto e como corrigi-las:

• URLs fixas em arquivos do tema: Procure nos arquivos PHP e CSS do seu tema por referências a http://. Substitua-as por https://, ou melhor ainda, use URLs relativas ao protocolo (//) ou funções WordPress como esc_url().
• Imagens em conteúdo de posts: O comando search-replace do WP-CLI (Etapa 4) lida com a maioria delas. Para casos teimosos, verifique o HTML bruto no editor de Texto.
• Configurações de widgets e do Customizer: URLs de imagens em widgets, cabeçalhos personalizados e configurações do Customizer são armazenadas como dados serializados. O WP-CLI search-replace lida corretamente com elas.
• Conteúdo de page builder: Elementor, Beaver Builder, Divi e outros page builders armazenam seu conteúdo em formatos personalizados. WP-CLI com --all-tables geralmente captura esses, mas verifique carregando páginas construídas com seu page builder.
• Recursos externos: Se você carrega fontes, scripts ou imagens de domínios externos por HTTP, atualize essas URLs. A maioria dos CDNs e serviços de fontes (Google Fonts, cdnjs, etc.) suporta HTTPS.

Usando o Really Simple SSL como alternativa

Se a abordagem manual parecer esmagadora, o plugin Really Simple SSL automatiza a maior parte do processo. Instale-o, ative-o e ele irá:

• Detectar seu certificado SSL automaticamente.
• Atualizar a URL do Site WordPress e a URL Inicial para HTTPS.
• Configurar um redirecionamento 301 de HTTP para HTTPS via PHP (ou .htaccess se possível).
• Corrigir conteúdo misto substituindo URLs HTTP em tempo real.

A desvantagem do Really Simple SSL é que ele corrige conteúdo misto dinamicamente em cada carregamento de página, o que adiciona uma pequena sobrecarga de processamento. É melhor corrigir as causas-raiz (URLs no banco de dados, referências fixas) e depois remover o plugin. Pense nele como uma ponte útil durante a migração, não uma solução permanente.

Etapa 5: Adicione o cabeçalho HSTS

HTTP Strict Transport Security (HSTS) diz aos navegadores para sempre usarem HTTPS para seu domínio, mesmo se o usuário digitar http:// na barra de endereços. Após confirmar que o HTTPS funciona corretamente em seu site (sem conteúdo misto, sem loops de redirecionamento), adicione o cabeçalho HSTS:

Apache (.htaccess)

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

Nginx

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

O valor max-age=31536000 (um ano) diz aos navegadores para lembrarem da política HSTS por 12 meses. Comece com um valor menor como max-age=86400 (um dia) durante o teste, depois aumente quando estiver confiante de que tudo funciona. A diretiva includeSubDomains estende a política a todos os subdomínios. Adicione preload apenas se você planeja enviar seu domínio à lista de pré-carregamento HSTS (hstspreload.org), que codifica permanentemente o requisito HTTPS do seu domínio nos próprios navegadores.

Configuração HTTPS de CDN e Cloudflare

Se você usa Cloudflare ou outro CDN, a configuração HTTPS tem uma camada extra de complexidade:

• Cloudflare Flexible SSL: O tráfego é criptografado entre o visitante e o Cloudflare, mas a conexão entre o Cloudflare e seu servidor é HTTP puro. Esta é a mais fácil de configurar (sem necessidade de certificado SSL no servidor), mas oferece segurança incompleta. Os dados entre o Cloudflare e o seu servidor são descriptografados.
• Cloudflare Full SSL: O tráfego é criptografado em ambos os lados, mas o Cloudflare não verifica o certificado do seu servidor. Você precisa de um certificado SSL no seu servidor, mas pode ser autoassinado.
• Cloudflare Full (Strict) SSL: A configuração recomendada. O tráfego é criptografado em ambos os lados e o Cloudflare verifica o certificado do seu servidor. Use um certificado Let's Encrypt válido ou um Cloudflare Origin Certificate.

Se você mudar de Flexible para Full (Strict), certifique-se de que seu servidor tenha um certificado SSL válido instalado primeiro. Caso contrário, seu site ficará fora do ar porque o Cloudflare não conseguirá estabelecer uma conexão segura com o seu servidor.

O Cloudflare também oferece "Always Use HTTPS" em SSL/TLS > Edge Certificates, que executa o redirecionamento de HTTP para HTTPS na borda do Cloudflare. Isso é mais rápido do que um redirecionamento no seu servidor de origem porque o visitante nunca alcança o seu servidor para a requisição HTTP.

Verificando expiração e renovação automática do certificado SSL

Um certificado SSL expirado é pior do que nenhum certificado. Os navegadores exibem um aviso de página inteira que a maioria dos visitantes não clicará para passar, e seu site fica efetivamente fora do ar. Veja como monitorar seu certificado:

# Verificar a data de expiração do certificado
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

# Verificar dias até a expiração
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -enddate

Se você usa Let's Encrypt com Certbot, a renovação automática deve estar configurada automaticamente. Mas verifique se está realmente funcionando, conferindo os logs de renovação do Certbot:

# Verificar log de renovação do Certbot
cat /var/log/letsencrypt/letsencrypt.log | tail -20

# Listar todos os certificados e suas datas de expiração
sudo certbot certificates

Para sites em produção, configure monitoramento que alerte você quando seu certificado estiver se aproximando da expiração. Serviços como UptimeRobot, StatusCake ou até mesmo um cron job simples que verifica a data do certificado podem te poupar de quedas inesperadas.

Verifique a sua configuração HTTPS com o InspectWP

Após concluir a migração, execute uma varredura do InspectWP para verificar se tudo está funcionando corretamente. O InspectWP verifica vários aspectos relacionados ao HTTPS:

• Detecção SSL/TLS: Confirma que seu site é servido por HTTPS.
• Conteúdo misto: Detecta quaisquer recursos HTTP (imagens, scripts, folhas de estilo) carregados em suas páginas HTTPS.
• Cabeçalho HSTS: Verifica se o cabeçalho Strict-Transport-Security está presente e configurado corretamente.
• Redirecionamento HTTP: Verifica se a versão HTTP do seu site redireciona corretamente para HTTPS.
• Cabeçalhos de segurança: Revisa outros cabeçalhos relacionados à segurança que complementam a sua configuração HTTPS.

Se o InspectWP relatar avisos de conteúdo misto, use o console do navegador para identificar os recursos específicos e corrigi-los usando os métodos descritos acima. Execute outra varredura após cada correção até que o relatório volte limpo.