Idiomas

Conteúdo Misto

O que é conteúdo misto, por que o conteúdo misto ativo é bloqueado enquanto o passivo é apenas avisado, e como detectar e corrigir sub-recursos inseguros em escala — o console do navegador, relatórios de CSP, upgrade-insecure-requests, block-all-mixed-content, e como CMSs e tecnologia de anúncios o reintroduzem.

Publicado pela primeira vez: 3 de jul. de 2026 · Última atualização: 3 de ago. de 2026 · Avançado
Idiomas
AIEscrito porAI v2

Conteúdo misto é uma página HTTPS carregando um sub-recurso via HTTP. A taxonomia atual dos navegadores é atualizável versus bloqueável; a divisão antiga ativo/passivo ainda acompanha isso para a maioria dos tipos, com exceções (imagens com CORS habilitado, srcset/picture e solicitações para hosts IP são bloqueáveis, não atualizáveis). Conteúdo misto ativo — scripts, folhas de estilo, iframes, XMLHttpRequest/fetch — é bloqueado diretamente porque um script adulterado pode reescrever a página inteira, então é isso que realmente quebra um site após uma migração HTTP→HTTPS; corrija isso primeiro. Conteúdo misto passivo — imagens, áudio, vídeo — historicamente carregava com um cadeado rebaixado e agora é cada vez mais atualizado automaticamente ou também bloqueado. Links de âncora e outra navegação HTTP de nível superior não são conteúdo misto, assim como downloads inseguros (uma fronteira relacionada, mas separada). Encontre isso no código-fonte buscado, no estado renderizado/em tempo de execução e em sessões de usuários reais: rastreie o site HTTPS, observe o console do Chrome DevTools (a redação exata é específica do navegador/versão) ou colete violações de Content-Security-Policy-Report-Only; corrija confirmando primeiro que o equivalente HTTPS realmente funciona, depois aponte cada sub-recurso para https:// (caminhos relativos/relativos ao protocolo somente após verificar a propriedade e o comportamento da URL base). O cabeçalho Content-Security-Policy: upgrade-insecure-requests reescreve solicitações de sub-recursos http:// no escopo — incluindo as de origem cruzada — para https:// antes de serem enviadas e antes que as verificações de conteúdo misto/CSP sejam executadas; não tem fallback HTTP se a atualização falhar, é uma rede de segurança em vez de um substituto para limpar a fonte, NÃO atualiza a navegação de nível superior para origens de terceiros (portanto, não é um substituto para HSTS), e definir a diretiva em modo somente relatório é um no-op — monitore com uma política separada somente relatório. Bancos de dados de CMS (faça backup e teste substituições — substituição ingênua de strings pode corromper dados serializados), plugins/temas, service workers/caches e tags de anúncios/análises são os reincidentes usuais; audite em escala com um rastreador e relatórios de CSP em vez de página por página.

TL;DR — Conteúdo misto é uma página HTTPS carregando um sub-recurso via HTTP. A taxonomia atual do navegador/W3C classifica isso em conteúdo atualizável e bloqueável; a divisão mais antiga ativo/passivo (usada abaixo como uma estrutura de raio de explosão) ainda acompanha essa divisão para a maioria dos tipos de recurso, com exceções — imagens habilitadas para CORS, candidatos srcset/picture e solicitações de host IP são bloqueáveis, embora um img src simples seja atualizável. Ativo (scripts, folhas de estilo, iframes, XMLHttpRequest/fetch e qualquer coisa que o navegador execute) é bloqueado — um script adulterado pode reescrever a página — então é a regressão do dia do lançamento para corrigir primeiro. Passivo (imagens, áudio, vídeo) historicamente carregava com um indicador rebaixado e agora é cada vez mais atualizado automaticamente ou bloqueado. Âncoras e outra navegação HTTP de nível superior não são conteúdo misto; nem são downloads inseguros, que são um limite relacionado, mas separado. Detecte isso em três camadas — fonte buscada, estado renderizado/em tempo de execução e sessões reais de usuário — rastreando o site HTTPS, lendo o console do Chrome DevTools (a redação exata é específica do navegador/versão) ou coletando violações de Content-Security-Policy-Report-Only; corrija confirmando que um equivalente HTTPS realmente funciona, então aponte cada sub-recurso para https:// (caminhos relativos/relativos ao protocolo são aceitáveis depois que você verificar a propriedade e o comportamento da URL base, não um padrão universal). Content-Security-Policy: upgrade-insecure-requests reescreve solicitações de sub-recursos http:// no escopo (incluindo as de origem cruzada) para https:// antes de serem enviadas e antes das verificações de conteúdo misto/CSP serem executadas — uma rede, não um substituto para corrigir a fonte, com nenhum fallback HTTP se a atualização falhar, e isso não atualiza a navegação de nível superior para origens de terceiros, então não substitui o HSTS. Colocar a diretiva em modo somente relatório é um no-op — monitore com uma política separada somente relatório. Bancos de dados CMS (faça backup e teste qualquer substituição — substituição ingênua de strings pode corromper dados serializados), plugins, temas, service workers/caches e tags de anúncios/analytics são os reincidentes recorrentes — audite em escala, não página por página.

O hub HTTPS apresenta conteúdo misto como um dos dois modos de falha do dia do lançamento de uma migração (o outro sendo redirecionamentos). Este é o mergulho profundo para o qual ele aponta — os níveis exatos de recursos, a pilha de detecção, as diretivas CSP e as razões operacionais pelas quais ele continua voltando.

O que conta como conteúdo misto — e o que não conta

Conteúdo misto é definido com precisão: trata-se de sub-recursos que a página carrega, não de links que a página contém. A definição do Google: “A page has mixed content when its initial HTML is loaded over a secure HTTPS connection, but other resources (such as images, videos, stylesheets, and scripts) are loaded over an insecure HTTP connection.” Evidence for this claim Mixed content occurs when a secure page loads resources over insecure HTTP, and browsers upgrade or block mixed-content requests by resource type. Scope: MDN documents current browser categories and behavior; individual browser versions may differ at the margins. Confidence: high · Verified: MDN: Mixed content (tradução) «Uma página tem conteúdo misto quando seu HTML inicial é carregado por uma conexão HTTPS segura, mas outros recursos (como imagens, vídeos, folhas de estilo e scripts) são carregados por uma conexão HTTP insegura.»

A armadilha que tranquiliza as pessoas falsamente é a tag de âncora. Um link <a href="http://…"> para uma página HTTP não é conteúdo misto — ele navega para um novo documento; ele não carrega um recurso inseguro no documento seguro atual. Isso é verdade para qualquer navegação de nível superior para uma página HTTP, não apenas cliques em âncoras.

Ainda vale a pena enviar links de saída para destinos HTTPS. Sob a política Referrer-Policy padrão moderna do navegador (strict-origin-when-cross-origin), um clique de uma página HTTPS para um destino HTTP de fato remove o cabeçalho Referer, o que pode prejudicar as análises de referência — mas esse comportamento é dependente de política e navegador, não uma regra universal: uma página (ou um proxy/CDN upstream) que define uma Referrer-Policy mais permissiva ainda pode enviar um referenciador nesse rebaixamento. Verifique a Referrer-Policy real em vigor antes de afirmar quantos dados de referência um determinado site perde — mas em qualquer caso, isso é um problema separado do conteúdo misto, não o próprio conteúdo misto.

Ativo vs. passivo: a distinção que define suas prioridades

A documentação moderna de navegadores e do W3C classifica o conteúdo misto principalmente como conteúdo atualizável versus bloqueável — tipos de recursos que o navegador tentará silenciosamente novamente por HTTPS versus aqueles que ele recusa totalmente — em vez da divisão mais antiga entre ativo/passivo. Ativo/passivo ainda é uma abreviação útil para por que os navegadores traçam essa linha (o quanto da página o recurso poderia comprometer), e é assim que o próprio explicador do Google o enquadra, então é mantido abaixo como o enquadramento principal de triagem — apenas não o trate como a taxonomia oficial atual quando você precisar raciocinar sobre um tipo específico de recurso; veja as exceções após as duas listas.

Os navegadores classificam o conteúdo misto pelo quanto da página o recurso inseguro poderia comprometer. Google: “Active mixed content poses a greater threat than passive mixed content.” (tradução) «O conteúdo misto ativo representa uma ameaça maior do que o conteúdo misto passivo.» Essa única frase deve orientar sua ordem de triagem.

O conteúdo misto ativo interage com — e pode assumir o controle de — toda a página. O Google o descreve como “scripts, stylesheets, iframes, and any other code the browser can download and execute.” (tradução) «scripts, folhas de estilo, iframes e qualquer outro código que o navegador possa baixar e executar.» Na prática, a lista ativa é:

  • <script src="http://…"> — o pior caso; um script interceptado pode reescrever todo o DOM, exfiltrar dados de formulários ou injetar conteúdo.
  • <link rel="stylesheet" href="http://…"> — o CSS pode ocultar, reposicionar ou sobrepor qualquer coisa, então é tratado como ativo.
  • <iframe src="http://…"> — um documento inseguro incorporado dentro do seu documento seguro.
  • XMLHttpRequest / fetch() para http:// — dados inseguros sobre os quais a página então age.
  • Fontes da web, recursos <object>/<embed> e as variantes <link> que trazem conteúdo executável ou que controla o layout.

Como um recurso ativo adulterado pode reescrever a página, “Most browsers already block this type of content by default to protect users.” (tradução) «A maioria dos navegadores já bloqueia esse tipo de conteúdo por padrão para proteger os usuários.» É por isso que o conteúdo misto ativo é o que visivelmente quebra as coisas após uma migração — uma folha de estilo bloqueada remove seu CSS, um script bloqueado mata a interatividade, um iframe bloqueado deixa um buraco. Corrija o ativo primeiro. É um bug funcional, não apenas um aviso de segurança.

Conteúdo misto passivo (de exibição) — Google: “including images, video, and audio” (tradução) «incluindo imagens, vídeo e áudio» — “doesn’t interact with the rest of the page.” (tradução) «não interage com o resto da página.» Uma imagem interceptada pode ser trocada, mas não pode tomar o documento. Então, historicamente, os navegadores o carregavam e apenas rebaixavam o indicador: “Until recently, passive mixed content was loaded in all browsers, because blocking it would have broken many websites. This is now beginning to change.” (tradução) «Até recentemente, o conteúdo misto passivo era carregado em todos os navegadores, porque bloqueá-lo teria quebrado muitos sites. Isso agora está começando a mudar.» A direção do movimento nos navegadores é para atualizar automaticamente recursos passivos para HTTPS quando possível e bloquear o que não pode ser atualizado, então “passivo = inofensivo” não é mais uma suposição segura para se basear.

Exceções que a divisão ativo/passivo não captura

A linha atualizável/bloqueável tem várias exceções que não seguem o padrão geral “imagens atualizam, scripts bloqueiam” acima — estes são os casos que realmente pegam as pessoas na prática:

  • Solicitações de imagem com CORS ativado falham, não são atualizadas. Um <img src="http://…"> comum é atualizável, mas uma solicitação de imagem feita com crossorigin definido é tratada de forma diferente pelo algoritmo de conteúdo misto e falha em vez de ser atualizada silenciosamente.
  • Candidatos de srcset e <picture> são bloqueáveis, não atualizáveis. A mesma imagem, solicitada por meio de um mecanismo de imagem responsiva em vez de um src simples, cai na categoria bloqueável — não presuma que toda referência de imagem se comporta da mesma forma.
  • Hosts com endereço IP são bloqueados, não atualizados, mesmo para um tipo de recurso que seria atualizável. Uma referência como http://203.0.113.5/logo.png não recebe o tratamento de atualização automática que um equivalente hospedado em domínio receberia.
  • Contextos aninhados e workers estão no escopo. As verificações de conteúdo misto se aplicam dentro de iframes e dentro de service/shared workers também, não apenas no documento principal — um worker buscando um script inseguro ainda é conteúdo misto.
  • Origens locais e de loopback têm suas próprias nuances. localhost, endereços de loopback e contextos file:// são “origens potencialmente confiáveis” de acordo com a especificação, mesmo sem TLS, então uma heurística simples de HTTP vs. HTTPS não se aplica diretamente a ambientes de desenvolvimento local.
  • Downloads inseguros são um limite relacionado, mas separado. Um download iniciado de uma página segura via http:// é um risco real, mas é regido pelo próprio tratamento de segurança de download, não pelas regras de conteúdo misto de sub-recursos desta seção.
  • Navegação HTTP de nível superior ainda não é conteúdo misto, incluindo o caso de link de âncora acima — isso é uma propriedade da navegação, não de um sub-recurso carregado, não importa quantas dessas outras exceções se apliquem.

Detectando conteúdo misto — toda a pilha

Não existe um único botão, e cada camada abaixo responde a uma pergunta diferente — um resultado limpo em uma camada não elimina as outras. Diagnostique fonte buscada (o que o HTML bruto realmente referencia), estado renderizado/em tempo de execução (o que o navegador solicita depois de analisar a página e executar seus scripts) e sessões reais de usuários (o que acontece para um visitante atrás de um banner de consentimento, um redirecionamento geográfico, um muro de login ou um script de terceiros que só é acionado sob condições específicas) separadamente. Sobreponha essas camadas de “uma página” a “site inteiro”:

  1. O console do Chrome DevTools (estado renderizado/em tempo de execução). Carregue a página HTTPS e abra o console. Conteúdo misto ativo bloqueado registra uma mensagem como “Mixed Content: The page … was loaded over HTTPS, but requested an insecure … This request has been blocked; the content must be served over HTTPS.” (tradução) «Conteúdo misto: a página … foi carregada via HTTPS, mas solicitou um … inseguro. Esta solicitação foi bloqueada; o conteúdo deve ser servido via HTTPS.» Passivo que é carregado registra um aviso em vez de um bloqueio. O painel Security (ou a aba Issues) agrupa isso por página. Rápido para verificações pontuais e para confirmar uma correção específica — mas trate a redação exata da mensagem, o layout do painel e até mesmo quais tipos de recurso são bloqueados como específicos do navegador e da versão; isso foi confirmado no Chrome em julho de 2026 e você deve verificar a redação atual no navegador/versão real que está diagnosticando, em vez de citá-la como uma string de interface fixa, e espere que Firefox, Safari e Edge sejam diferentes.

  2. Um rastreador de site (fonte buscada, em escala). DevTools é por página; um rastreamento é em todo o site. Ahrefs Site Audit e Screaming Frog sinalizam páginas que referenciam sub-recursos http:// em um site HTTPS — a única maneira realista de encontrar conteúdo misto em milhares de URLs. Esta é a principal ferramenta para uma auditoria, mas ainda está lendo a fonte: um rastreamento limpo não prova que a página renderizada ou uma sessão real também está limpa — registre qual navegador/ferramenta/versão produziu um determinado resultado em vez de relatar um único passar/falhar sem qualificação.

  3. Relatórios de violação de CSP (sessões reais de usuários). Você pode fazer com que os navegadores de visitantes reais relatem conteúdo misto de volta para você, o que captura recursos que só carregam em determinadas páginas, para determinados usuários, sob determinados estados de consentimento, ou de tags de terceiros que você não controla — a camada que nem um rastreamento nem uma única verificação no DevTools conseguem alcançar. web.dev: “You can use content security policy to collect reports of mixed content on your site. To enable this feature, set the Content-Security-Policy-Report-Only directive by adding it as a response header for your site.” (tradução) «Você pode usar a política de segurança de conteúdo para coletar relatórios de conteúdo misto no seu site. Para ativar esse recurso, defina a diretiva Content-Security-Policy-Report-Only adicionando-a como um cabeçalho de resposta para o seu site.» O modo Report-Only relata violações sem aplicar a política, então você pode medir o problema em produção antes de ativar o bloqueio. (O mecanismo é o cabeçalho moderno report-to / Reporting-Endpoints, ou o mais antigo report-uri. Observe que esta é uma política somente de relatório diferente e de propósito geral do que o próprio upgrade-insecure-requests — colocar essa diretiva específica em modo somente de relatório não funciona, como abordado abaixo.)

Evidence for this claim upgrade-insecure-requests in a Content-Security-Policy-Report-Only header is ignored. Scope: Content Security Policy upgrade-insecure-requests processing Confidence: high · Verified: Upgrade Insecure Requests

Use os três: DevTools para verificar uma página renderizada, um rastreador para inventariar o código-fonte buscado, relatórios de CSP para capturar a cauda longa de sessões reais que só aparece no mundo real. Uma passagem de rastreamento é evidência sobre o código-fonte, não uma garantia de que cada estado de consentimento, variante de ad-tech, ramo de personalização ou worker esteja limpo.

Corrigindo na origem

A correção real começa antes de você tocar em uma única referência: verifique se o equivalente HTTPS realmente existe, apresenta um certificado válido e retorna o conteúdo que você espera — não presuma que trocar o esquema é seguro só porque o domínio resolve. Depois de confirmado, toda referência de sub-recurso deve resolver via HTTPS. As opções abaixo estão em ordem aproximada de preferência, mas cada uma ainda depende de titularidade e contexto, não apenas da string que você digita:

  • URLs HTTPS absolutas — altere http://cdn.example.com/app.js para https://cdn.example.com/app.js. Explícito e inequívoco; o padrão mais seguro quando você não tem certeza sobre o contexto de serviço abaixo.
  • Caminhos relativos à raiz ou relativos — para recursos que você possui no mesmo site, /assets/app.js herda o esquema da página automaticamente. A orientação HTTPS do Google: “Make sure intrasite URLs and external URLs don’t depend on a specific protocol. Use relative paths or leave out the protocol as in //example.com/something.js.” (tradução) «Garanta que URLs internas e externas não dependam de um protocolo específico. Use caminhos relativos ou omita o protocolo como em //example.com/something.js.» Trate isso como condicional, não como uma recomendação universal: só se aplica depois que você confirmou que realmente possui o recurso (um caminho relativo para um ativo de terceiros não faz sentido), que a URL base real da página resolve da maneira que você espera (uma tag <base>, um caminho com proxy ou um contexto incorporado/AMP pode mudar o que “relativo” significa), e que nada downstream reconstrói a URL de uma forma que reintroduza http:// — código no lado do cliente construindo uma URL a partir de window.location ou um valor absoluto armazenado, por exemplo.
  • URLs relativas ao protocolo (//example.com/something.js) ainda funcionam, mas não são a correção universal preferida — condicione-as às mesmas verificações de titularidade/URL base acima, não apenas ao hábito. Em uma web totalmente HTTPS, um https:// explícito geralmente é mais claro e evita surpresas se o arquivo for aberto em um contexto não HTTP; use relativo ao protocolo apenas onde você tiver um motivo específico para não codificar o esquema.

Em escala, você quase nunca edita modelos um a um — mas também não execute uma substituição de string não protegida no banco de dados de produção. http://yourdomain → https://yourdomain parece uma simples localizar e substituir, e para campos de texto simples muitas vezes é seguro, mas o conteúdo do CMS pode ser serializado ou estruturado (arrays serializados em PHP, blobs JSON, dados do editor de blocos) onde uma troca ingênua de substring corrompe o registro em vez de corrigi-lo. Use ferramentas cientes do aplicativo que entendam o formato de serialização, faça backup do banco de dados primeiro e execute um teste da substituição para que você possa revisar as linhas afetadas antes de confirmar. Em seguida, corrija o punhado de arquivos de modelo/configuração que emitem as URLs; o rastreador e os relatórios de CSP limpam os retardatários.

upgrade-insecure-requests: a rede de segurança (e seus limites)

O reforço proativo é uma diretiva de Content-Security-Policy. web.dev: “The upgrade-insecure-requests CSP directive instructs the browser to upgrade insecure URLs before making network requests.” Defina o cabeçalho:

Content-Security-Policy: upgrade-insecure-requests

Per MDN, it “instructs user agents to treat all of a site’s insecure URLs (those served over HTTP) as though they have been replaced with secure URLs (those served over HTTPS).” Concretely, MDN says it upgrades: “requests to load resources (such as images, scripts, or fonts),” “navigation requests (such as link targets) which are same-origin with the document,” “navigation requests in nested browsing contexts, such as iframes,” and “form submissions.” Evidence for this claim The upgrade-insecure-requests CSP directive rewrites insecure URLs as secure URLs before requests are made. Scope: MDN documents the directive's rewriting behavior and limits; it does not guarantee that an HTTPS version of every resource exists. Confidence: high · Verified: MDN: CSP upgrade-insecure-requests

Dois detalhes operacionais importam além dessa citação. Primeiro, a atualização de sub-recursos não se limita a solicitações de mesma origem — é a atualização de navegação que é apenas de mesma origem, conforme a citação acima; solicitações comuns de sub-recursos são reescritas entre origens também, então um script hospedado em CDN ou uma fonte de terceiros é atualizado, não apenas ativos do mesmo site. Segundo, a reescrita acontece antes de o navegador avaliar as verificações de conteúdo misto e CSP, e é por isso que um recurso que de outra forma seria bloqueado diretamente como conteúdo misto pode carregar limpo depois de atualizado — a atualização antecipa o bloqueio.

Três limites que você não deve ignorar:

  • Não atualiza a navegação de nível superior de terceiros. MDN: “However, top-level navigation requests whose target is a different origin will not be upgraded.” Por causa disso, é explicitamente não um substituto para HSTS: “The upgrade-insecure-requests directive will not ensure that users visiting your site via links on third-party sites will be upgraded to HTTPS for the top-level navigation and thus does not replace the Strict-Transport-Security (HSTS) header.” (Mais sobre essa divisão abaixo.)
  • É uma rede, não uma correção, e não tem fallback. Se o recurso genuinamente não estiver disponível via HTTPS, a solicitação atualizada simplesmente falha — ela não volta para a versão original http://. Limpar a fonte ainda é o trabalho; a diretiva cobre o que você perdeu, não o que está genuinamente quebrado.
  • O modo somente relatório não executa a atualização — é um no-op. Colocar upgrade-insecure-requests dentro de um cabeçalho Content-Security-Policy-Report-Only é ignorado pelo navegador: nada é reescrito, e nada é relatado para ele também. Se você quiser visibilidade sobre o que a atualização afetaria antes de aplicá-la, execute uma política separada de somente relatório de propósito geral que relate destinos http:// não permitidos (a mesma abordagem default-src https: somente relatório usada para detecção acima) — você não pode obter essa visibilidade tornando o próprio upgrade-insecure-requests somente relatório.

block-all-mixed-content — principalmente histórico

Existe uma diretiva complementar, block-all-mixed-content, que — segundo o MDN — “impede o carregamento de qualquer recurso por HTTP quando a página usa HTTPS,” incluindo “tanto conteúdo misto bloqueável quanto atualizável,” e também se aplica a iframes. Na prática, ela foi superada. O MDN a marca como obsoleta e “obsoleta na especificação,” observando: “O conteúdo que não é bloqueado agora é sempre atualizado para uma conexão segura, então esta diretiva não é necessária.” Recorra a upgrade-insecure-requests; trate block-all-mixed-content como legado que você pode herdar, não algo para implantar do zero. Se você já envia upgrade-insecure-requests, block-all-mixed-content não tem mais nada a fazer para solicitações atualizadas — a reescrita de atualização acontece primeiro, então, quando uma verificação de bloqueio fosse executada, a solicitação já teria sido atualizada (ou já teria falhado). Não é apenas legado; é redundante onde quer que o UIR já esteja implantado.

Evidence for this claim block-all-mixed-content is deprecated and obsolete for new deployment. Scope: legacy CSP directives Confidence: high · Verified: CSP: block-all-mixed-content

Por que seu CMS continua reintroduzindo isso

Conteúdo misto não é uma limpeza única — ele recorre, porque vários sistemas silenciosamente reinjetam URLs http:// depois que você pensa que terminou:

  • O banco de dados de conteúdo. No WordPress, Drupal e na maioria dos CMS, editores colam imagens e incorporações com URLs absolutas http:// diretamente nos corpos das postagens. Elas ficam no banco de dados, não em um template, então uma correção no nível do código nunca as alcança — daí a busca e substituição no banco de dados.
  • Temas e plugins. Um tema ou plugin que codifica uma URL de recurso http:// (uma fonte, um script, uma imagem de fundo) reintroduz conteúdo misto em cada página que renderiza, e uma atualização de plugin pode trazê-lo de volta depois que você o limpou.
  • Tecnologia de anúncios, analytics e tags de terceiros. Gerenciadores de tags, redes de anúncios, widgets de chat e snippets de analytics carregam seus próprios sub-recursos — e se a tag de um fornecedor ainda chama http://, é conteúdo misto que você não pode corrigir no seu próprio código. Este é exatamente o longo rabo que o relatório de CSP é para; a correção durável é pressionar o fornecedor a servir por HTTPS (ou remover a tag). Se um fornecedor não tem um endpoint HTTPS funcional, as escolhas duráveis são as mesmas três: fazê-lo corrigir, substituir a dependência, ou removê-la — não há uma quarta opção que mantenha a versão insegura funcionando com segurança.
  • Service workers e caches. Um service worker pode armazenar em cache uma resposta (ou a própria solicitação) que ainda aponta para http://, e continuará servindo essa referência desatualizada em visitas repetidas mesmo depois que você corrigir a fonte. Reproduza uma correção suspeita em uma sessão anônima/sem cache antes de concluir que não funcionou, e certifique-se de que uma implantação que altera URLs de recursos também aumente a versão do service worker/cache para que entradas desatualizadas sejam removidas em vez de reproduzidas.
  • http:// codificado em conteúdo antigo e templates de e-mail/impressão que são reutilizados.

A conclusão operacional: incorpore a detecção em uma auditoria recorrente (crawler + relatórios de CSP), não em uma lista de verificação de lançamento executada uma única vez.

Como o conteúdo misto interage com HSTS

Conteúdo misto e HSTS resolvem problemas adjacentes, mas diferentes, e confundi-los é um erro comum:

  • upgrade-insecure-requests corrige sub-recursos que sua própria página segura solicita — ele atualiza as imagens/scripts/iframes que a página carrega.
  • HSTS (Strict-Transport-Security) força a navegação de nível superior para o seu site para HTTPS — até mesmo a primeira solicitação, antes de qualquer redirecionamento — e defende contra stripping de SSL. O Google enquadra o HSTS como uma forma de “evitar o custo do redirecionamento 301” e de “derrotar ataques como SSL Stripping.”

Eles não se substituem. Como o MDN explica, upgrade-insecure-requests “não garantirá que usuários que visitam seu site por meio de links em sites de terceiros sejam atualizados para HTTPS na navegação de nível superior e, portanto, não substitui o cabeçalho Strict-Transport-Security (HSTS).” Uma configuração totalmente protegida usa ambos: upgrade-insecure-requests (ou URLs de origem limpas) para que a página segura não tenha carga insegura, e HSTS para que ninguém alcance o site por HTTP em primeiro lugar. E o aviso usual sobre HSTS ainda se aplica — Google: “Não ative o HSTS até ter certeza de que a operação do seu site é robusta o suficiente para evitar a implantação de HTTPS com erros de validação de certificado,” e o pré-carregamento é quase uma porta de mão única.

O conteúdo misto prejudica o SEO diretamente?

Comece pelos efeitos diretos, porque são os que você realmente controla: o conteúdo misto é primeiro um problema de segurança e funcionalidade. O conteúdo misto ativo bloqueado quebra a renderização e a interatividade por completo — uma folha de estilo ou script ausente é uma regressão real, independentemente do que um mecanismo de busca achar disso. Isso é motivo suficiente para corrigi-lo antes mesmo de pensar em ranqueamento.

As consequências para SEO são reais, mas condicionais, não diretas ou garantidas. A guia oficial atual do Google não estabelece a correção de conteúdo misto como um impulso direto de ranqueamento — o sinal de ranqueamento de HTTPS em si é baseado em esquema (se a URL começa com https://), não uma verificação de limpeza de sub-recursos, então uma imagem insegura isolada não custa, por si só, “o sinal de HTTPS”. Mas efeitos posteriores ainda podem aparecer dependendo do que está realmente quebrado: se o Googlebot renderizar uma página cujo CSS ou JS foi bloqueado como conteúdo misto, ele pode indexar uma versão quebrada ou incompleta; um indicador de segurança rebaixado pode prejudicar a confiança do usuário, o engajamento e as conversões mesmo sem nenhuma mudança de ranqueamento; e a preferência geral do Google por canônicos HTTPS é ela mesma condicional — certificados inválidos, dependências inseguras, redirecionamentos de HTTPS para HTTP ou sinais canônicos conflitantes em outros pontos da página podem todos alterar qual URL é escolhida, independentemente do conteúdo misto especificamente. Trate os efeitos de renderização, indexação, canonização e análise como coisas a verificar em suas próprias páginas, não como resultados universais a prometer — e corrija o conteúdo misto pelas razões de segurança e funcionalidade primeiro.

Isso se insere no tópico mais amplo HTTPS para SEO, que cobre o manual de migração, o peso do sinal de ranqueamento e o HSTS em detalhes; se você também estiver depurando o próprio certificado (erros de cadeia, expiração, DV/OV/EV), esse é um mergulho profundo irmão.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.