Saltar para o conteúdo 
WordPress HTTPS protege os dados de login, formulários de contacto e cookies e ajuda-me a aumentar a classificação e a conversão. Neste guia, vou mostrar-lhe a mudança completa de HTTP para HTTPS no WordPress - com certificado, conversão de URL, redireccionamentos 301, correção de conteúdo misto e passos de SEO limpos.
Pontos centrais
- SSL Ativar corretamente e cobrir o domínio
- URLs converter para WordPress
- 301 Forçar o reencaminhamento
- Conteúdo misto Retificação direcionada
- SEO voltar a apertar e verificar
Porque é que o HTTPS é importante para o WordPress
Sem encriptação, os atacantes podem desviar sessões ou ler formulários, razão pela qual protejo toda a Transmissão entre o browser e o servidor com TLS. O HTTPS evita avisos no navegador, aumenta a confiança e reforça os sinais que os motores de busca avaliam positivamente. De qualquer modo, muitas API, serviços de pagamento e funcionalidades do browser requerem ligações seguras. Também beneficio do HTTP/2 e HTTP/3, que carregam mais rapidamente com TLS e permitem a paralelização. Uma mudança limpa para HTTPS evita a duplicação de conteúdos, porque posso restringir todas as variantes a um único Canhão (Canónico).
Preparar cópia de segurança e certificado SSL
Antes de mexer em quaisquer definições, faço uma cópia de segurança completa dos ficheiros e da base de dados para poder aceder-lhes em qualquer altura. Cópia de segurança pode regressar. Em seguida, encomendo ou ativo um certificado - Let's Encrypt é muitas vezes suficiente sem custos adicionais, em alternativa, utilizo um certificado DV/OV/EV, dependendo das minhas necessidades. Muitos hosters fornecem um assistente que emite e renova certificados automaticamente. Se precisar de ajuda passo a passo, utilize este tutorial no sítio Configurar SSL gratuito. Em seguida, verifico se a cadeia de certificados está completa e se os domínios www e apex (sem www) estão cobertos pelo certificado; também tenho em conta subdomínios como staging ou cdn e mantenho os seus Validade num relance.
Seleção de certificados e gestão de chaves
Para além da ativação inicial, também noto alguns detalhes que faltam em muitas instruções: Preciso de um certificado wildcard (*.domain.tld) para muitos subdomínios ou é suficiente um certificado SAN com vários nomes de anfitrião explícitos? Por uma questão de desempenho, utilizo certificados ECDSA (curvas elípticas) em vez das chaves RSA clássicas sempre que possível - são mais pequenos e aceleram o aperto de mão TLS. Protejo estritamente a chave privada (permissões de ficheiro 600, apenas utilizadores do servidor) e documento a Renovação-chain: A renovação automática é realmente efectuada, mesmo que um CDN ou um proxy inverso esteja ligado a montante? Para os desafios ACME, verifico se os redireccionamentos, os limites de taxas ou as páginas de manutenção interferem com a validação. Também ativo o agrafamento OCSP e os protocolos modernos (TLS 1.2/1.3) diretamente no servidor Web, para que os navegadores possam processar as verificações de certificados mais rapidamente.
Alterar URLs do WordPress
Acedo ao painel de controlo e abro Definições → Geral, depois defino "Endereço do WordPress (URL)" e "Endereço do sítio Web (URL)" para https://. Depois de guardar, faço novamente o login se a sessão for reiniciada. De seguida, elimino a cache do navegador e, se disponível, a cache do meu plugin de cache, para que os visitantes recebam imediatamente a versão segura. Em seguida, dou uma vista de olhos aos widgets, menus e ligações rígidas, uma vez que podem ainda conter ligações http. Para os meios de comunicação nos posts, edito o conteúdo individual ou planeio uma limpeza Pesquisar na base de dados (ver abaixo).
Início de sessão e administração seguros
Para a área de administração, aplico o TLS com uma pequena adição no wp-config.php. Para o fazer, adiciono o seguinte acima da linha "/* That's all, stop editing! */" e carrego o ficheiro:
define('FORCE_SSL_ADMIN', true);
Isso significa que o login, os cookies e todo o back-end são executados estritamente via HTTPS. Se um proxy reverso ou uma camada CDN estiver ligada a montante, certifico-me de que o WordPress interpreta corretamente o cabeçalho "X-Forwarded-Proto: https". Caso contrário, a aplicação trata incorretamente a ligação como insegura e define os cookies sem Seguro-flag.
Constantes do WordPress mais seguras e deteção de proxy
Se não conseguir aceder aos URLs no backend (por exemplo, através de plugins), defino temporariamente constantes explícitas no wp-config.php e elimino assim definições incorrectas:
define('WP_HOME', 'https://deinedomain.de');
define('WP_SITEURL', 'https://deinedomain.de');
Também adiciono a deteção por trás de proxies para que is_ssl() corretamente:
se (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
$_SERVER['HTTPS'] = 'on';
}
Isto evita a geração incorrecta de conteúdo misto no backend e garante que os cookies de autenticação estão consistentemente ligados ao Seguro-atributo são entregues.
Configurar redireccionamentos 301 em .htaccess
Para garantir que todos os pedidos vão permanentemente para a versão segura, configurei um Reencaminhamento de http para https. Num ambiente Apache clássico, abro o .htaccess na raiz do WordPress e adiciono as regras acima do bloco do WordPress:
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Com o Nginx, o reencaminhamento tem lugar na configuração do servidor (servidor { listen 80; return 301 https://$host$request_uri; }). Para mais pormenores, variantes e resolução de problemas, pode encontrar um guia claro sobre o Reencaminhamento HTTPS. Importante: mantenho a cadeia de redireccionamento curta, ou seja, http→https e, se necessário, www→non-www ou vice-versa num único salto, para que não haja saltos desnecessários na cadeia de redireccionamento. Tempo de carregamento aumentar.
Estratégia de redireccionamento limpa sem loops
Para além do reencaminhamento básico, defino regras de consistência: Ou www ou não-www - nunca ambos. Com o Apache, resolvo isto num só passo com uma verificação do anfitrião:
RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} !^deinedomain\.de$ [NC]
RewriteRule ^ https://deinedomain.de%{REQUEST_URI} [L,R=301]
Recebo automaticamente as cadeias de consulta (parâmetros UTM), reduzo os redireccionamentos a um salto e evito loops não activando quaisquer regras concorrentes no plugin ou na CDN. Se um proxy de extremo utiliza "SSL flexível" (navegador→CDN encriptado, CDN→origem não encriptada), mudo para "Completo (estrito)" para que o TLS seja aplicado tanto para o visitante como para a origem - caso contrário, existe o risco de problemas de ciclos e protocolos mistos.
Reconhecimento e eliminação de conteúdos mistos
Após o redireccionamento, verifico a página com as ferramentas do navegador para "conteúdo misto", ou seja, conteúdo que ainda pode ser acedido através de http são carregados. Imagens, fontes, scripts ou folhas de estilo em temas, construtores de páginas ou widgets são frequentemente afectados. Corrijo os URLs codificados, alterando-os para https no editor, no personalizador ou nas definições do plugin. Ferramentas como o "Really Simple SSL" ajudam a curto prazo, mas uma limpeza permanente das fontes é melhor. O conteúdo bloqueado causa erros de estilo ou funções ocultas, por isso limpo tudo até o browser não bloquear qualquer conteúdo. Avisos mostra mais.
Lista de controlo profissional de conteúdo misto
- Activei a diretiva CSP como um teste
pedidos de atualização inseguraem modo só de relatório para ver o que o browser actualiza automaticamente para https - depois limpo permanentemente as fontes. - Os tipos de letra e os estilos externos requerem frequentemente cabeçalhos CORS; sem
Controlo de acesso - Permitir origemaparecem como bloqueados. - Reconheço imagens de fundo CSS com ligações http absolutas nas ferramentas de programação e substituo-as por caminhos relativos ou https.
- Os iframes (por exemplo, mapas, vídeos) também devem falar https, caso contrário o browser esconde-os.
- Nos temas, evito caminhos codificados e utilizo funções como
home_url(),site_url(),plugins_url()econtent_url()para que o WordPress forneça o URL de base correto.
Descrição geral passo a passo
O quadro seguinte resume todas as tarefas envolvidas na transição num formato compacto e ajuda-me a Sequência a cumprir.
| Etapa | Recomendação/explicação |
|---|---|
| Criar cópia de segurança | Antes de cada alteração, completar Cópia de segurança de ficheiros e base de dados |
| Configurar o certificado SSL | Ativar o Let's Encrypt ou a versão paga com o anfitrião |
| Personalizar URLs | Definir para https no backend em Definições → Geral |
| Definir redireccionamentos | Configurar o bloco de servidor .htaccess ou Nginx para 301 para HTTPS |
| Verificar o conteúdo misto | Substituir ligações http difíceis em conteúdos, temas e plug-ins |
| Substituir a base de dados | Substituir todas as ocorrências http por uma cópia de segurança e uma ferramenta fiável |
| Atualizar Google/SEO | Personalizar a propriedade, o mapa do site, a análise e os canónicos da Consola de Pesquisa |
Substituir URLs de bases de dados de forma limpa
Por vezes, as ligações http ficam inactivas em widgets, códigos de acesso ou campos definidos pelo utilizador, pelo que utilizo um método testado e comprovado Ferramenta como "Better Search Replace". Procuro por "http://deinedomain.de" e substituo-o por "https://deinedomain.de", primeiro num ensaio e depois a sério com cópia de segurança. Para renomear em série através do WP-CLI, utilizo "wp search-replace", que é muito mais rápido para páginas grandes. As matrizes e os objectos serializados têm de ser tratados corretamente, pelo que confio em ferramentas que tratam disso de forma adequada. Após a substituição, verifico amostras aleatórias no frontend e em importantes Layouts.
Base de dados: o que não substituo cegamente
Só toco na coluna GUID em wp_posts quando altero efetivamente o domínio. A alteração pura do protocolo para https geralmente requer nenhum Alterar os GUIDs, uma vez que servem principalmente como um identificador único. Antes de uma substituição global, também verifico se os plug-ins fazem referência a pontos de extremidade externos (webhooks, APIs) com http - prefiro actualizá-los especificamente e testar o canal de retorno. Para grandes projectos, planeio uma curta fase de congelamento de conteúdos para que não sejam criados novos posts com esquemas antigos durante a substituição da pesquisa. Utilizo o WP-CLI para garantir a rapidez e a reprodutibilidade:
wp search-replace 'http://deinedomain.de' 'https://deinedomain.de' --all-tables-with-prefix --precise --dry-run
wp search-replace 'http://deinedomain.de' 'https://deinedomain.de' --all-tables-with-prefix --precise
Controlos SEO após a transição
Após a alteração, crio uma nova propriedade com https na Consola de Pesquisa e submeto um Mapa do sítio sobre. Verifico as ligações internas, as etiquetas canónicas, as referências hreflang e as etiquetas de gráfico aberto para https. Os snippets de rastreio (analytics, tag manager, pixel) também devem utilizar o endereço seguro. Nos plugins de SEO, verifico as regras de redireccionamento e asseguro-me de que não existem "soft 404s". Se os contadores de partilhas sociais forem importantes, testo o funcionamento da ferramenta com o novo Endereço pegas.
Ajuste fino de feeds, robôs e canónicos
Verifico se os feeds RSS/Atom são acessíveis através de https e fornecem conteúdos válidos. Num robots.txt mantido estaticamente, adapto os caminhos do mapa do sítio para https, se necessário. Defino URLs canónicos consistentemente absolutos com https, para que os motores de busca interpretem os sinais sem ambiguidade. Os pares hreflang (sítios multilingues) não devem diferir no protocolo, caso contrário, surgem inconsistências.
Caching, CDN e desempenho em HTTPS
O HTTPS também vale a pena em termos de velocidade, uma vez que o HTTP/2/3 permite a multiplexagem e a compressão de cabeçalhos através de um Ligação. Presto atenção ao reinício da sessão TLS, ao agrafamento OCSP e aos conjuntos de cifras modernos, que aceleram os apertos de mão. Uma CDN fornece activos estáticos mais perto do visitante, mas tem de funcionar consistentemente em https. Nos plugins de cache, ativo a opção "Cache para HTTPS", se disponível, e limpo os artefactos antigos. Em seguida, faço medições com ferramentas como o Lighthouse e comparo o Tempos antes e depois da alteração.
Funcionalidades CDN/Proxy
Com uma CDN a montante, defino sempre "Full (strict)" para Origin, carrego o certificado para lá ou utilizo um certificado Origin e apenas permito a entrega de https. Verifico se o CDN armazena em cache os redireccionamentos (caso contrário, vejo estados antigos) e limpo os caches de borda após a mudança. A compressão Brotli, HTTP/3/QUIC e 0-RTT também podem ajudar - mas é importante que as regras de toda a página já não injectem recursos http. Por fim, envio a mensagem correta IP do cliente-(por exemplo, X-Forwarded-For) e configurar o servidor Web de modo a que os registos mostrem o verdadeiro IP do visitante.
HSTS e outros cabeçalhos de segurança
Se o sítio for inteiramente executado em HTTPS, ativo o HTTP Strict Transport Security (HSTS) para que os navegadores utilizem apenas o HTTPS-variante. Por exemplo, defino o cabeçalho desta forma: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload - mas apenas se todos os subdomínios forem realmente acessíveis de forma segura. Para oportunidades e armadilhas, recomendo o guia Ativar HSTS. Além disso, defino cabeçalhos de segurança como X-Content-Type-Options, X-Frame-Options e uma política de segurança de conteúdos rigorosa que permite fontes https. Estes cabeçalhos reforçam as camadas de proteção contra injeção de conteúdos, clickjacking e MIME-Farejamento.
Cabeçalho de segurança de ajuste fino
Para além do HSTS, adiciono uma configuração de cabeçalho pragmática: Política de referenciador: strict-origin-when-cross-origin limita a transferência de trajectórias sensíveis, Política de permissões restringe as API do navegador (por exemplo, câmara, microfone), e um PSC moderado com default-src 'self' https: evita fontes estrangeiras indesejadas. Começo com Apenas relatórioRecolho as violações e, em seguida, reforço as diretrizes. É assim que evito que os cabeçalhos de segurança "quebrem" involuntariamente o sítio.
Testes, monitorização e resolução de problemas
Estou a testar a mudança numa janela privada e em dispositivos móveis, de modo a que nenhum utilizador antigo Biscoitos ou caches. O registo da consola do navegador mostra rapidamente avisos de conteúdo misto e recursos bloqueados. Utilizo "curl -I http://deinedomain.de" para verificar se ocorre um 301 para a versão https e se ocorrem outras cadeias. Em seguida, monitorizo os registos de erros no servidor e os relatórios 404 no plug-in SEO ou na consola de pesquisa. Se os plug-ins individuais deixarem de ser carregados, verifico as suas ligações externas Dependências e actualizá-lo para a versão mais recente.
Controlo de entrada em funcionamento e monitorização contínua
- Opcionalmente, ativo um curto modo de manutenção antes de mudar para estabelecer redireccionamentos e caches consistentes.
- Monitorizo a expiração dos certificados (alarmes) para que não haja surpresas desagradáveis.
- Nos primeiros dias, monitorizo a taxa 404, as curvas de classificação, as estatísticas de rastreio e o Core Web Vitals, a fim de tomar medidas preventivas.
- Para as campanhas, verifico se os parâmetros UTM são totalmente preservados através do redireccionamento 301.
Caraterísticas especiais de multisite, proxy e staging
Para os vários sítios, altero o endereço de rede para https e ajusto os mapeamentos para que todos os sítios tenham um endereço uniforme Reencaminhamento uso. Atrás de balanceadores de carga ou CDNs, o servidor web deve observar o cabeçalho "X-Forwarded-Proto", caso contrário, o WordPress pensará que a conexão é insegura e definirá os URLs errados. Para sistemas de teste, utilizo os meus próprios certificados ou protejo-os com Basic Auth para que os motores de busca não os indexem. Após a alteração em tempo real, volto a ligar as caches, a aquecê-las e a monitorizar a carga. Em ambientes com seus próprios proxies ou firewalls, eu documento todas as alterações para que implantações posteriores possam usar o Configuração assumir o controlo.
Multisite e detalhes do comércio que muitas vezes faltam
Nas configurações de vários sítios, actualizo por sítio o siteurl e casa especialmente se o mapeamento de domínios estiver envolvido. Se um nascer do sol.php ou plugins de mapeamento especiais, verifico se são compatíveis com https. Nas lojas (por exemplo, WooCommerce), defino sistematicamente "Checkout" e "My account" para https, testo o pagamento e Webhook-páginas de devolução e de agradecimento. Os fornecedores de pagamentos e as APIs de envio exigem frequentemente URLs de retorno de chamada actualizados - eu personalizo-os e verifico a verificação da assinatura após a alteração.
Armadilhas comuns e soluções rápidas
Os certificados incorrectos causam sinais de alerta vermelhos - por isso, verifico o período de emissão, a cadeia e se todos os domínios estão incluídos no certificado para que o Ligação funciona sem interrupções. Redireccionamentos 301 em falta criam conteúdo duplicado; regulo isto com regras claras e curtas e evito múltiplos saltos. Os conteúdos misturados provêm frequentemente de ficheiros temáticos codificados; neste caso, substituo os esquemas http ou utilizo URLs sem esquema ("//...") nos locais apropriados. Serviços externos que ainda fazem referência a pedidos de blocos http; aqui actualizo webhooks, endpoints e chaves. Se um plugin não conseguir lidar com a mudança, testo uma atualização ou substituo-o por uma solução que suporte totalmente o HTTPS. Apoios.
Resumo: Mudou de forma segura para HTTPS
Começo com uma cópia de segurança completa, ativo o CertificadoMudo os URLs do WordPress para https, aplico redireccionamentos 301 e limpo consistentemente os conteúdos mistos. Em seguida, substituo quaisquer entradas http restantes na base de dados, actualizo as definições de SEO e meço o desempenho. O HSTS e os cabeçalhos de segurança aumentam ainda mais a segurança, desde que todos os subdomínios respondam corretamente a https. Para o alojamento, confio em fornecedores com bom suporte, renovação automática e aprovisionamento rápido de TLS, como o webhoster.de, o que facilita muito o meu trabalho. Isto mantém o sítio seguro, rápido e visível - que é exatamente o que eu espero de um sítio Web sustentável. HTTPS-mudança.
