Mixed content WordPress: como corrigir imagens e links HTTP depois do SSL

Você ativou SSL, o site já abre com https://, mas o navegador ainda mostra aviso de “site não seguro” ou o cadeado não aparece? Em muitos casos, o problema não é o certificado em si. O problema é mixed content WordPress.

Mixed content, ou conteúdo misto, acontece quando uma página carregada por HTTPS tenta carregar algum recurso por HTTP ou por outro protocolo inseguro. Pode ser uma imagem antiga, um arquivo CSS, um script, uma fonte, um iframe, um widget, um embed ou uma URL salva no banco de dados.

Na prática, é como reforçar a porta de entrada do site, mas deixar algumas janelas abertas. O HTTPS está ativo, porém partes da página ainda vêm por uma conexão insegura.

Neste guia, você vai ver como diagnosticar e corrigir mixed content no WordPress com segurança, sem sair trocando URLs no escuro e sem mexer no banco antes de fazer backup.

Antes de começar: confirme o básico e faça backup

Antes de corrigir mixed content, confirme estes pontos:

• você tem acesso de administrador ao WordPress;
• o certificado SSL está ativo e válido para o domínio correto;
• o site abre em https://seudominio.com.br;
• você consegue acessar o painel do WordPress;
• você sabe qual hospedagem, CDN ou serviço de cache está em uso;
• você tem acesso para limpar cache de plugin, cache da hospedagem e CDN, se existirem.

E o mais importante: faça um backup completo antes de qualquer alteração sensível.

Isso inclui arquivos e banco de dados. Trocar URLs em massa, alterar plugins de SSL, mudar configurações de CDN, editar tema ou rodar search/replace no banco pode quebrar imagens, links, layout ou até o acesso ao site se for feito sem cuidado.

Se ainda não tem um backup confiável, veja o guia de backup do WordPress na nuvem antes de seguir.

Sempre que possível, teste em staging antes de aplicar em produção, principalmente em lojas WooCommerce, sites com muitos acessos, portais, áreas de membros e sites com formulários importantes.

O que é mixed content no WordPress?

Mixed content no WordPress é o carregamento de recursos HTTP dentro de uma página HTTPS.

Exemplo simples:

• a página abre em https://seudominio.com.br/sobre/;
• mas uma imagem dentro dessa página aponta para http://seudominio.com.br/wp-content/uploads/foto.jpg.

O navegador percebe que a página principal está em HTTPS, mas parte do conteúdo vem por HTTP. Dependendo do tipo de recurso, ele pode:

• mostrar alerta de site não seguro;
• bloquear o carregamento do arquivo;
• tentar atualizar automaticamente alguns tipos de recurso para HTTPS;
• quebrar layout, scripts, fontes ou imagens;
• impedir que o cadeado apareça corretamente.

Navegadores modernos costumam tratar recursos de formas diferentes. Imagens, áudio e vídeo podem ser atualizados automaticamente de HTTP para HTTPS em alguns cenários. Já scripts, folhas de estilo, iframes, fontes e chamadas mais sensíveis tendem a ser bloqueados com mais rigor. Mesmo quando o navegador tenta fazer o upgrade automaticamente, o melhor é corrigir a URL na origem.

No WordPress, o problema costuma aparecer depois de:

• ativar SSL pela hospedagem;
• migrar de HTTP para HTTPS;
• trocar de domínio;
• migrar de servidor;
• ativar Cloudflare ou outra CDN;
• importar conteúdo antigo;
• restaurar backup antigo;
• instalar tema ou plugin que chama arquivos externos por HTTP.

Se você ainda está na etapa de ativar SSL, comece pelo guia principal sobre HTTPS WordPress grátis e SSL. Este artigo parte do cenário em que o HTTPS já foi ativado, mas ainda restaram URLs HTTP dentro do site.

Mixed content não é a mesma coisa que certificado SSL inválido

Antes de corrigir, separe três problemas diferentes.

1. Certificado SSL inválido ou ausente

Nesse caso, o navegador pode mostrar um aviso forte antes mesmo de carregar o site. Isso pode acontecer quando:

• o certificado expirou;
• o certificado foi emitido para outro domínio;
• a versão com www ou sem www não está coberta corretamente;
• a cadeia do certificado está mal configurada;
• o SSL ainda não foi instalado na hospedagem ou na CDN.

Se o certificado está inválido, corrigir imagens HTTP não resolve. Primeiro é preciso resolver o SSL na hospedagem, no CDN ou no painel do domínio.

2. Redirecionamento HTTP para HTTPS mal configurado

Aqui, o certificado pode estar correto, mas o site ainda permite acesso por http:// ou entra em loop de redirecionamento.

Isso pode envolver regras de .htaccess, Nginx, LiteSpeed, Cloudflare, plugin de SSL ou configuração da hospedagem.

Evite editar regras de servidor sem saber o ambiente usado. Apache, Nginx e LiteSpeed têm configurações diferentes. Se você não tem certeza, fale com a hospedagem.

3. Conteúdo misto dentro da página

Este é o foco do artigo: a página abre em HTTPS, mas algum recurso interno ou externo continua em HTTP.

É o caso clássico de:

• imagem antiga com URL http://;
• CSS chamando background por HTTP;
• JavaScript externo sem HTTPS;
• iframe antigo;
• fonte carregada por HTTP;
• logo ou ícone inserido no tema com URL absoluta antiga;
• widget HTML com link antigo;
• page builder com imagem salva antes da migração;
• CDN ainda servindo arquivo por HTTP.

Como diagnosticar mixed content no navegador

O primeiro passo é descobrir qual recurso está em HTTP. Não comece instalando plugin ou fazendo search/replace antes de encontrar a origem.

1. Abra a página com problema

Use uma aba anônima ou janela limpa, se possível. Acesse a URL em HTTPS:

https://seudominio.com.br/pagina-com-problema/

Teste mais de uma página. Às vezes o problema está só na home, em uma landing page, em um post antigo ou no checkout.

2. Abra as ferramentas do desenvolvedor

No Chrome, Edge e Firefox, normalmente você pode clicar com o botão direito na página e escolher “Inspecionar”. Depois, abra a aba “Console”.

Atualize a página com o Console aberto. Muitos avisos de mixed content só aparecem quando a página é carregada novamente.

Procure mensagens que mencionem termos como:

• Mixed Content;
• http://;
• blocked;
• insecure;
• nome de imagem, arquivo CSS, script ou domínio externo.

Não copie comandos do Console. Use o Console apenas para identificar o arquivo ou a URL que está causando o problema.

3. Verifique a aba Network ou Rede

A aba “Network” ou “Rede” ajuda a encontrar recursos carregados pela página. Recarregue a página e filtre por http:// ou procure recursos marcados como bloqueados.

Anote:

• URL exata do recurso HTTP;
• tipo do recurso: imagem, script, CSS, fonte, iframe, vídeo;
• domínio de origem: seu domínio, CDN ou terceiro;
• página onde o problema aparece.

Esse diagnóstico evita correções exageradas. Uma única imagem antiga em um post não exige a mesma solução de centenas de URLs HTTP espalhadas pelo banco.

Onde o HTTP pode estar escondido no WordPress

No WordPress, a URL HTTP pode estar em muitos lugares. Os mais comuns são os abaixo.

Posts e páginas antigas

Imagens inseridas antes da migração para HTTPS podem ter ficado com URL absoluta começando por http://.

Isso também pode acontecer com links internos para posts, botões, PDFs, iframes, galerias e embeds.

Biblioteca de mídia

O arquivo físico pode estar correto, mas o conteúdo do post pode apontar para a URL antiga. Em outros casos, o campo de imagem usado por um tema ou plugin pode ter armazenado a URL completa em HTTP.

Widgets, menus e blocos reutilizáveis

Widgets de HTML personalizado, rodapé, sidebar, cabeçalho, banners, menus com links personalizados e blocos reutilizáveis podem guardar links antigos.

Tema e personalizador

Logo, favicon, imagem de fundo, CSS personalizado, scripts adicionados no cabeçalho e opções do tema podem conter URLs antigas.

Page builders

Elementor, Beaver Builder, Divi, WPBakery e outros construtores podem salvar URLs em estruturas próprias. A correção pode depender do recurso de substituição de URL do próprio plugin, de limpeza de cache ou de regeneração de CSS.

Atenção: o caminho exato varia por plugin e versão. Consulte a documentação do construtor usado antes de fazer alteração em massa.

Plugins

Plugins de slider, formulário, popup, galeria, cookie banner, anúncios, chat, analytics, afiliados e embeds podem carregar arquivos ou imagens por HTTP.

Se o Console mostra um arquivo vindo de um plugin específico, atualize o plugin e revise suas configurações antes de alterar o banco inteiro.

CSS e JavaScript

Um arquivo CSS pode chamar uma imagem de fundo por HTTP. Um script pode carregar outro script externo inseguro. Uma fonte pode vir de um domínio sem HTTPS.

Nesse caso, trocar só a imagem dentro do editor do WordPress não resolve. É preciso corrigir o CSS, o tema, o plugin ou a configuração que gera aquela chamada.

CDN, Cloudflare e cache

Às vezes o WordPress já foi corrigido, mas o CDN ainda entrega uma versão antiga do HTML, CSS ou imagem. Também pode haver regra de SSL incorreta no CDN.

Se você usa Cloudflare, CDN da hospedagem ou plugin de performance, inclua cache e CDN no diagnóstico. Uma hospedagem WordPress com bom suporte e ferramentas claras de cache, SSL e staging facilita bastante esse tipo de correção.

Correção 1: confira as URLs principais do WordPress

No painel do WordPress, vá em:

Configurações > Geral

Em instalações em inglês, o caminho costuma aparecer como Settings > General.

Confira estes campos:

• Endereço do WordPress (URL), ou WordPress Address (URL);
• Endereço do site (URL), ou Site Address (URL).

Depois de ativar HTTPS, em um site comum, esses campos normalmente devem começar com https://, não http://.

Exemplo:

https://seudominio.com.br

Não adicione barra final se o WordPress remover automaticamente. E não altere domínio, pasta ou estrutura do site sem entender a instalação.

Se os campos estiverem bloqueados ou não puderem ser editados, pode haver constantes definidas no wp-config.php, como WP_HOME ou WP_SITEURL. Nesse caso, a correção exige acesso técnico aos arquivos do site. Não edite o wp-config.php sem backup e sem saber exatamente o que está fazendo.

Depois de salvar, limpe cache e teste novamente.

Correção 2: ajuste imagens e links HTTP em posts e páginas

Se o Console mostra uma imagem HTTP dentro de um post ou página específica, comece pelo editor.

Para imagens

1. Abra o post ou página no editor.
2. Clique na imagem com problema.
3. Verifique se a imagem vem da biblioteca de mídia ou de uma URL externa.
4. Remova e reinsira a imagem a partir da biblioteca, se necessário.
5. Atualize o conteúdo.
6. Limpe cache e teste a página.

Se a URL antiga aparece no HTML do bloco, pode ser necessário editar o bloco em modo HTML ou substituir a imagem.

Para links internos

Links internos em HTTP não costumam causar o mesmo bloqueio de recursos que imagens, scripts, CSS e iframes. Ainda assim, vale corrigir para manter consistência, evitar redirecionamentos desnecessários e reduzir sinais confusos para usuários e mecanismos de busca.

Procure botões, menus, chamadas para ação, links em tabelas e links antigos inseridos manualmente.

Troque:

http://seudominio.com.br/pagina/

por:

https://seudominio.com.br/pagina/

Faça isso com cuidado, principalmente se o site usa subdomínios, instalações em subpastas ou multisite.

Correção 3: revise tema, widgets, CSS e page builder

Se a URL HTTP não está dentro do conteúdo do post, ela pode estar no tema, no construtor visual ou em algum widget.

Verifique:

• Aparência > Personalizar;
• Aparência > Widgets;
• menus com links personalizados;
• cabeçalho e rodapé criados por tema ou page builder;
• campos de scripts no header/footer;
• CSS adicional;
• templates de landing pages;
• configurações do plugin de page builder;
• sliders, banners e popups.

Em CSS, procure padrões como:

background-image: url("http://...")

ou chamadas de fontes e imagens antigas.

Se o tema foi desenvolvido sob medida, evite editar arquivos diretamente pelo editor do WordPress. O ideal é corrigir em ambiente de desenvolvimento ou staging, com controle de versão quando possível.

Correção 4: use plugin de mixed content com cautela

Plugins de SSL e mixed content podem ajudar, principalmente quando o site tem muitas URLs antigas e você precisa de uma correção rápida.

Exemplos conhecidos no diretório do WordPress incluem:

• SSL Insecure Content Fixer;
• Really Simple Security, anteriormente conhecido como Really Simple SSL.

Esses plugins podem aplicar correções automáticas, redirecionamentos, ajustes de SSL ou recursos para reduzir alertas de conteúdo inseguro. Porém, não trate plugin como garantia de correção definitiva.

Antes de instalar ou ativar:

1. Faça backup completo.
2. Leia a descrição e avaliações recentes do plugin.
3. Verifique compatibilidade com sua versão do WordPress.
4. Teste em staging, se possível.
5. Ative apenas os recursos necessários.
6. Limpe cache e teste páginas importantes.

Um plugin pode corrigir sintomas na saída HTML, mas a URL antiga pode continuar salva em um post, tema, widget, opção do plugin ou banco de dados. Em alguns sites, isso basta. Em outros, é melhor corrigir a origem.

Também evite instalar vários plugins de SSL ao mesmo tempo. Eles podem duplicar redirecionamentos, alterar regras parecidas e dificultar o diagnóstico.

Correção 5: search/replace no banco de dados, só com segurança

Quando o site tem muitas URLs antigas, pode ser necessário trocar http://seudominio.com.br por https://seudominio.com.br em massa.

Essa é uma etapa sensível.

Não faça search/replace manual direto no phpMyAdmin sem saber lidar com dados serializados. Muitos plugins, temas e page builders salvam configurações em formatos que podem quebrar se a substituição for feita de forma errada.

A abordagem mais segura é:

1. Fazer backup completo de arquivos e banco.
2. Testar em staging.
3. Usar uma ferramenta confiável que respeite dados serializados.
4. Rodar dry-run quando a ferramenta oferecer essa opção.
5. Revisar o que será alterado.
6. Aplicar em produção apenas quando tiver confiança.
7. Limpar cache e testar.

Se você usa WP-CLI e tem experiência técnica, um search/replace com dry-run pode ser uma opção. Mas este não deve ser o primeiro caminho para usuários iniciantes.

Para a maioria dos donos de site, é mais seguro usar:

• recurso de migração da hospedagem;
• ferramenta de search/replace de plugin confiável;
• suporte técnico da hospedagem;
• desenvolvedor responsável pelo site.

Evite trocar simplesmente todo http:// por https:// no banco. Isso pode afetar URLs externas, integrações, webhooks, conteúdos de terceiros e registros que não deveriam mudar.

Se o problema surgiu depois de migração, troca de domínio ou troca de servidor, revise também o guia sobre como migrar WordPress para outro servidor ou hospedagem, porque URLs antigas e cache de DNS podem aparecer junto com problemas de HTTPS.

E se o recurso HTTP vier de outro domínio?

Nem todo mixed content vem do seu domínio.

O problema pode estar em:

• imagem externa antiga;
• script de terceiro;
• iframe incorporado;
• fonte hospedada fora;
• banner de afiliado;
• widget de chat;
• player de vídeo;
• selo, badge ou contador antigo.

Se o domínio externo oferece HTTPS, troque a URL para https:// e teste.

Se o domínio externo não oferece HTTPS, o melhor caminho é remover ou substituir o recurso. Não vale manter um script inseguro só para preservar um widget antigo.

Em sites profissionais, formulários, checkout e páginas de login, qualquer recurso externo em HTTP deve ser tratado com prioridade. Para organizar outras camadas de proteção, veja também o guia de segurança WordPress.

Depois de corrigir: limpe cache e CDN

Depois de ajustar URLs, o navegador ainda pode mostrar o erro se uma camada de cache estiver servindo versão antiga.

Limpe, nessa ordem quando aplicável:

1. cache do plugin de performance;
2. cache da hospedagem;
3. cache do CDN ou Cloudflare;
4. cache do navegador ou teste em aba anônima.

Também confira se o plugin de otimização está combinando ou minificando CSS e JavaScript antigos. Em alguns casos, é preciso regenerar CSS do page builder ou limpar arquivos otimizados.

Não desative todos os plugins em produção sem necessidade. Se precisar testar conflito de plugin, prefira staging ou uma janela de baixa movimentação, com backup pronto.

Sobre CSP e upgrade-insecure-requests

A diretiva upgrade-insecure-requests em uma Content Security Policy pode instruir o navegador a tratar URLs HTTP como HTTPS antes de fazer a requisição. Isso pode ajudar em migrações com muitas URLs legadas.

Mas ela não substitui a correção da origem do problema. Se o recurso não existir em HTTPS, a requisição pode falhar. Além disso, CSP, HSTS e regras de servidor têm impacto técnico e devem ser configuradas por alguém que entenda o ambiente.

Para a maioria dos sites WordPress pequenos, o caminho mais seguro é corrigir primeiro URLs, tema, plugins, cache e CDN. Use CSP apenas como medida técnica planejada, não como atalho para esconder mixed content.

Como validar se o mixed content foi corrigido

Depois das correções, teste pelo menos:

• home;
• uma página institucional;
• um post antigo com imagens;
• página de contato;
• página de login;
• carrinho e checkout, se for WooCommerce;
• landing pages importantes;
• páginas criadas por page builder;
• versão com www e sem www, se ambas existirem;
• versão mobile.

Em cada página:

1. abra em HTTPS;
2. confira se o navegador não mostra alerta;
3. abra o Console e recarregue;
4. procure mensagens de mixed content;
5. veja se imagens, fontes, CSS e scripts carregam corretamente;
6. teste formulários e botões importantes;
7. confirme se não há loop de redirecionamento.

Se o problema aparece só em uma página, foque naquela página. Se aparece no site inteiro, investigue tema, plugin global, configurações principais, cache ou CDN.

Quando chamar a hospedagem ou um desenvolvedor

Chame a hospedagem quando:

• o certificado SSL não está válido;
• o site entra em loop de redirecionamento;
• o painel mostra HTTPS, mas o servidor entrega HTTP;
• você usa CDN/cache da hospedagem e não sabe limpar;
• há erro envolvendo Nginx, Apache, LiteSpeed ou proxy reverso;
• o WordPress está atrás de load balancer ou Cloudflare com configuração complexa.

Chame um desenvolvedor quando:

• o mixed content vem de tema customizado;
• há URLs antigas dentro de arquivos PHP, CSS ou JS;
• o site usa multisite;
• há page builder com dados complexos;
• o banco precisa de search/replace com segurança;
• o site é uma loja, área de membros ou plataforma com dados sensíveis;
• você não tem staging e não pode arriscar indisponibilidade.

Em alguns casos, o custo de suporte técnico é menor do que o risco de quebrar layout, checkout ou acesso administrativo.

O que não fazer ao corrigir mixed content

Evite estes atalhos:

• trocar URLs no banco sem backup;
• rodar search/replace global sem dry-run;
• editar .htaccess copiando regra aleatória da internet;
• instalar vários plugins de SSL ao mesmo tempo;
• ativar recursos avançados de HSTS ou CSP sem entender impacto;
• ignorar recursos HTTP externos porque “parece que carregou normal”;
• testar apenas a home;
• limpar cache antes de anotar qual era o erro;
• culpar o certificado antes de verificar o Console do navegador.

Também evite depender apenas de upgrade-insecure-requests como solução única. Essa política pode ajudar em migrações com muitos recursos antigos, mas se um arquivo não existir em HTTPS, ele pode falhar. O ideal é corrigir a origem das URLs sempre que possível.

Checklist rápido para corrigir mixed content WordPress

Use esta ordem:

1. Confirme que o SSL está válido.
2. Acesse o site por HTTPS.
3. Abra o Console do navegador.
4. Anote a URL HTTP exata.
5. Identifique se o recurso vem do seu domínio, CDN ou terceiro.
6. Confira Configurações > Geral no WordPress.
7. Corrija posts, páginas, imagens e links manuais.
8. Revise widgets, menus, tema, CSS e page builder.
9. Verifique plugins que carregam scripts, imagens ou iframes.
10. Se necessário, use plugin de mixed content com backup.
11. Se necessário, faça search/replace com ferramenta segura e dry-run.
12. Limpe cache do plugin, servidor, CDN e navegador.
13. Teste home, posts antigos, páginas importantes e checkout.
14. Monitore se o erro volta após atualizações ou limpeza de cache.

Conclusão

Mixed content WordPress é comum depois de ativar SSL, principalmente em sites antigos, migrados ou com muitos plugins. A boa notícia é que o problema costuma ter solução quando você segue uma ordem segura: diagnosticar, identificar a origem, corrigir a URL, limpar cache e testar.

Não comece pelo banco de dados. Comece pelo Console do navegador e pelas configurações mais simples. Se a correção envolver search/replace, tema, CDN, Cloudflare, multisite ou loja WooCommerce, faça backup e prefira staging.

Se você ainda está configurando HTTPS, leia também o guia completo de SSL no WordPress. E, antes de qualquer mudança sensível, mantenha um backup recuperável do WordPress.