Aviso de conteúdo misto após ativar HTTPS

O que este erro significa e como reconhecê-lo

• O endereço da página usa HTTPS, mas as ferramentas de desenvolvedor do navegador informam a presença de conteúdo misto.
• Um script, uma folha de estilos, uma fonte, uma imagem, um vídeo, uma imagem de fundo ou um frame incorporado não é carregado ou se comporta de forma diferente após a ativação do HTTPS.
• As mensagens do Console identificam um recurso HTTP solicitado por uma página HTTPS.
• A funcionalidade da página fica incompleta porque conteúdos ativos, como JavaScript ou CSS, são bloqueados.
• O aviso aparece apenas em determinadas páginas, templates ou estados do usuário, sugerindo uma referência codificada diretamente ou gerada condicionalmente.
• O certificado do site parece válido para a página principal, embora recursos individuais ainda usem referências inseguras.

Causas principais, por probabilidade

1. Referências HTTP codificadas diretamente: O conteúdo da página, templates, arquivos do tema, widgets ou folhas de estilos ainda apontam para um recurso com endereço http://.
2. Conteúdo antigo armazenado: Imagens, incorporações, campos de mídia, scripts ou outros valores do banco de dados mantiveram referências HTTP de antes da migração para HTTPS.
3. Saída de tema ou plugin: Um componente gera uma URL insegura mesmo quando o endereço principal do site está configurado para HTTPS.
4. Recursos externos sem suporte a HTTPS: Um script, uma fonte, um frame, um arquivo de mídia ou outra dependência de terceiros pode não estar disponível de forma segura.
5. Arquivos em cache ou agrupados: Caches de página, bundles de assets, arquivos minificados, CDNs ou proxies reversos podem continuar servindo markup que contém uma referência antiga.
6. Configuração desatualizada da aplicação ou dos assets: A aplicação pode montar URLs absolutas a partir de um endereço base ou configuração de ambiente antigos.

Um aviso de conteúdo misto, por si só, não indica que o certificado do site é inválido. Um erro de certificado diz respeito à conexão segura com o site ou com o host do recurso; o conteúdo misto diz respeito a recursos inseguros solicitados dentro de uma página que, de outra forma, é segura.

Como corrigir

1. Confirme que o problema é conteúdo misto

Abra a página afetada em um navegador atualizado e abra as ferramentas de desenvolvedor. No Console, procure mensagens de conteúdo misto. No painel Network, examine a solicitação identificada no aviso e observe sua URL, tipo de recurso, status e — quando exibido — o arquivo ou componente que a iniciou.

Se o navegador não conseguir estabelecer uma conexão segura com o site principal e exibir um aviso de certificado, trate isso como um problema separado. Não altere as configurações do certificado para corrigir uma referência de recurso insegura.

2. Identifique todas as referências inseguras

Inspecione a página renderizada e, quando apropriado, seu código-fonte, folhas de estilos, scripts e arquivos de assets gerados em busca de referências HTTP. Verifique mais do que as imagens visíveis: JavaScript, CSS, fontes, frames, mídia e imagens de fundo em CSS também podem causar avisos ou falhas de carregamento.

Teste a página afetada em uma janela de navegação privada ou depois de limpar o cache relevante do navegador. Isso ajuda a diferenciar uma solicitação insegura atual de uma resposta antiga em cache, mas não substitui a correção da referência original.

3. Localize a origem que gera a referência

Use o tipo de recurso e as páginas afetadas para restringir o local de origem da URL:

• Um artigo ou uma página: inspecione seu conteúdo armazenado ou campo de mídia.
• Várias páginas que usam um layout: inspecione o template compartilhado, tema, widget ou componente reutilizável.
• Apenas páginas que usam um recurso: inspecione o plugin, a integração, a incorporação ou a configuração responsável.
• Uma solicitação de um asset combinado: inspecione a folha de estilos, o script, o processo de build, o cache ou o proxy de origem que produziu o bundle.
• Comportamento diferente para visitantes autenticados e não autenticados: compare as camadas de conteúdo e cache renderizadas para cada estado.

4. Atualize a referência na origem

Aplique a correção correspondente ao local onde a referência está armazenada:

• Altere o conteúdo da página ou do post para usar a versão HTTPS do recurso.
• Atualize a configuração do site, mídia, tema, plugin, incorporação ou integração que gera a URL.
• Corrija referências codificadas diretamente em templates, folhas de estilos, scripts ou arquivos de configuração.
• Para um recurso do mesmo site, use um caminho relativo compatível quando isso fizer sentido para a aplicação e a estrutura de implantação.
• Para um recurso externo, confirme se o host é compatível com HTTPS. Se não for, substitua a dependência por uma fonte segura ou remova-a, especialmente quando ela fornece conteúdo ativo.

5. Use a substituição em massa somente com proteções

A substituição em massa é apropriada quando o mesmo valor desatualizado está armazenado em muitos registros conhecidos. Antes de alterar dados de produção, obtenha autorização, crie um backup restaurável, defina o escopo exato e teste a operação em uma cópia de staging ou em registros representativos, quando possível.

Considere dados serializados ou estruturados e evite substituir cegamente todas as ocorrências de uma string de texto. Revise hosts externos, redirecionamentos, caminhos de arquivos, valores de configuração e registros cujo texto http:// talvez não seja uma URL de página. Se não conhecer a estrutura dos dados, peça ao responsável pela aplicação ou a um desenvolvedor que faça a alteração.

6. Limpe o conteúdo gerado e armazenado em cache

Depois de corrigir a origem, limpe os caches da aplicação, da página, da CDN, do proxy reverso e do navegador que ainda possam conter markup ou bundles de assets antigos. Gere novamente os assets combinados ou minificados, se o site os utilizar. Execute apenas invalidações de cache autorizadas para o ambiente afetado, pois elas podem aumentar temporariamente o tráfego para a origem ou alterar o comportamento do site.

7. Verifique o reparo

Recarregue as páginas afetadas e verifique novamente o Console e o painel Network. Confirme que o recurso sinalizado anteriormente é solicitado de forma segura, que scripts e estilos funcionam e que nenhuma nova referência insegura aparece.

Repita a verificação em templates relacionados e em visualizações relevantes de usuários autenticados e não autenticados. Se o aviso voltar após a atualização do cache, o template, plugin, configuração ou asset gerado subjacente ainda precisa ser corrigido.

Prevenção e como verificar a correção

• Adicione imagens, scripts, folhas de estilos, fontes, incorporações e mídia usando referências compatíveis com HTTPS.
• Mantenha o endereço do site da aplicação, as configurações de assets, o tema, os plugins e as integrações consistentes com HTTPS.
• Revise as dependências de terceiros antes da implantação e substitua provedores que não ofereçam entrega segura.
• Inclua verificações de conteúdo misto nos testes de staging e pós-migração.
• Inspecione templates compartilhados e componentes reutilizáveis, não apenas a página onde o aviso foi encontrado inicialmente.
• Mantenha backups testados antes de alterações em massa no conteúdo e limpe ou gere novamente os caches e bundles de assets afetados depois.
• Verifique novamente as páginas com diferentes estados de autenticação quando elas renderizarem recursos diferentes.

Perguntas frequentes