Contenido mixto

TL;DR — El contenido mixto aparece cuando una página segura https:// carga algo —una imagen, un script o una hoja de estilo— mediante el inseguro http://. Así combina una página segura con piezas inseguras y deshace parte de la protección de HTTPS. Los navegadores bloquean los tipos peligrosos (scripts, estilos e iframes) y advierten sobre los menos graves (imágenes y medios). Es una causa habitual de roturas justo después de pasar a HTTPS, y la solución es hacer que todos los recursos se carguen también mediante https://.

Qué es el contenido mixto

Cuando migras un sitio a HTTPS, la página se carga de forma segura. Pero nunca es solo HTML: incorpora imágenes, scripts, hojas de estilo, fuentes, vídeos y, a veces, marcos incrustados de otros lugares. Si alguna pieza todavía se solicita mediante http://, existe contenido mixto: una página segura que transporta recursos inseguros. 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: 2026-07-14 MDN: Mixed content

Como explica 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.” (traducción) «Una página tiene contenido mixto cuando su HTML inicial se carga mediante una conexión HTTPS segura, pero otros recursos —como imágenes, vídeos, hojas de estilo y scripts— se cargan mediante una conexión HTTP insegura».

Esto importa porque las piezas inseguras vuelven a abrir la brecha que HTTPS había cerrado. Cualquiera situado en la red entre el visitante y el servidor puede leer o manipular esas solicitudes http://, de modo que el candado promete más seguridad de la que la página ofrece en realidad.

Los dos tipos y cómo los tratan los navegadores

Los navegadores no tratan igual todo el contenido mixto. Lo clasifican según el daño que podría causar el recurso inseguro:

• Contenido mixto activo: scripts, hojas de estilo e iframes. Pueden controlar toda la página, por lo que uno manipulado podría reescribirla. Los navegadores lo bloquean. Es lo que rompe el diseño, la interactividad o un widget incrustado tras una migración.
• Contenido mixto pasivo: imágenes, audio y vídeo. No puede tomar la página, así que históricamente los navegadores lo cargaban, retiraban el candado y mostraban un aviso. Esto cambia: los navegadores modernos también lo actualizan o bloquean cada vez más.

Algo que no es contenido mixto: un enlace normal (<a href="http://…">) a una página HTTP. Solo te lleva a otro lugar; no carga una pieza insegura dentro de la página segura actual.

Cómo corregirlo

La solución casi siempre es la misma: hacer que el recurso inseguro se cargue mediante HTTPS. Cambia http:// por https:// en la referencia o usa una ruta que no fije el protocolo. Normalmente el recurso ya está disponible mediante HTTPS; alguien dejó una URL http:// antigua en una plantilla, un plugin o la base de datos.

Como red de seguridad, añade la cabecera upgrade-insecure-requests, que indica al navegador que reescriba solicitudes de recursos http:// como https:// antes de enviarlas. Es un buen respaldo, no una excusa para omitir la limpieza de la fuente. 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: 2026-07-14 MDN: CSP upgrade-insecure-requests

Para ver las listas exactas de recursos bloqueados, la detección a escala con DevTools e informes CSP, las directivas upgrade-insecure-requests y block-all-mixed-content, por qué el CMS lo reintroduce y su relación con HSTS, cambia a Advanced.

TL;DR — El contenido mixto es una página HTTPS que carga un subrecurso mediante HTTP. La taxonomía actual distingue entre contenido actualizable y bloqueable; la división anterior entre activo y pasivo, usada aquí para describir el radio de impacto, coincide en la mayoría de los tipos, con excepciones: imágenes con CORS, candidatos srcset/picture y hosts con dirección IP son bloqueables aunque un img src normal sea actualizable. Lo activo —scripts, hojas de estilo, iframes, XMLHttpRequest/fetch y todo lo que ejecuta el navegador— se bloquea porque puede reescribir la página, así que debe corregirse primero. Lo pasivo —imágenes, audio y vídeo— antes se cargaba degradando el indicador y ahora se actualiza o bloquea cada vez más. Enlaces y otras navegaciones HTTP superiores no son contenido mixto; tampoco las descargas inseguras, un límite relacionado pero separado. Diagnostica fuente obtenida, estado renderizado/en ejecución y sesiones reales mediante rastreo, Chrome DevTools —cuyo texto depende de navegador/versión— e infracciones Content-Security-Policy-Report-Only. Comprueba que el equivalente HTTPS funciona antes de apuntar cada subrecurso a https://; usa rutas relativas solo tras verificar propiedad y URL base. Content-Security-Policy: upgrade-insecure-requests reescribe solicitudes http:// incluidas en su ámbito, también entre orígenes, como https:// antes de enviarlas y de las comprobaciones CSP. No tiene fallback, no sustituye corregir la fuente, no actualiza navegación superior a terceros y no reemplaza HSTS. La propia directiva en report-only no hace nada. Haz copia y simulación al sustituir en bases de CMS, pues una operación ingenua corrompe datos serializados; audita también plugins, temas, service workers/cachés y etiquetas de terceros.

El hub de HTTPS presenta el contenido mixto como uno de los dos fallos de lanzamiento de una migración, junto con las redirecciones. Este análisis cubre niveles de recursos, detección, CSP y las causas operativas de recurrencia.

Qué se considera contenido mixto y qué no

El alcance es preciso: trata de los subrecursos que carga la página, no de los enlaces que contiene. 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.” (traducción) «Una página tiene contenido mixto cuando su HTML inicial se carga mediante una conexión HTTPS segura, pero otros recursos se cargan mediante una conexión HTTP insegura». 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: 2026-07-14 MDN: Mixed content

La trampa es la etiqueta de enlace. Un <a href="http://…"> a una página HTTP no es contenido mixto: navega a un documento nuevo, no carga un recurso inseguro en el actual. Lo mismo vale para cualquier navegación de nivel superior a HTTP.

Aun así, conviene dirigir enlaces salientes a HTTPS. Con la Referrer-Policy predeterminada moderna (strict-origin-when-cross-origin), un clic de HTTPS a HTTP elimina Referer, lo que puede distorsionar la analítica. Pero ese comportamiento depende de la política y el navegador: una página o CDN que defina una Referrer-Policy menos estricta puede enviarlo. Comprueba la Referrer-Policy aplicada antes de afirmar cuánto se pierde; es un problema distinto del contenido mixto.

Activo frente a pasivo: la distinción que fija prioridades

La documentación moderna clasifica el contenido como actualizable o bloqueable, no con la división histórica activo/pasivo. Esta sigue siendo útil para explicar por qué se traza la línea y Google la utiliza, pero consulta las excepciones al razonar sobre tipos concretos.

Google dice: “Active mixed content poses a greater threat than passive mixed content.” (traducción) «El contenido mixto activo supone una amenaza mayor que el pasivo». Esa frase determina el triaje.

El contenido mixto activo puede tomar toda la página. Google lo describe como “scripts, stylesheets, iframes, and any other code the browser can download and execute.” (traducción) «scripts, hojas de estilo, iframes y cualquier código que el navegador pueda descargar y ejecutar». La lista práctica incluye:

• <script src="http://…">: un script interceptado puede reescribir el DOM, extraer formularios o inyectar contenido.
• <link rel="stylesheet" href="http://…">: CSS puede ocultar, recolocar o superponer elementos.
• <iframe src="http://…">: documento inseguro incrustado en uno seguro.
• XMLHttpRequest / fetch() a http://: datos inseguros sobre los que actúa la página.
• Fuentes web, <object>/<embed> y variantes de <link> con contenido ejecutable o que controla el diseño.

Como puede reescribir la página, “Most browsers already block this type of content by default to protect users.” (traducción) «La mayoría de los navegadores ya bloquean este tipo de contenido de forma predeterminada para proteger a los usuarios». Por eso rompe visiblemente una migración: una hoja bloqueada elimina CSS, un script mata la interactividad y un iframe deja un hueco. Corrige primero el activo. Es un fallo funcional.

El contenido pasivo —“including images, video, and audio” (traducción) «incluidas imágenes, vídeo y audio»— “doesn’t interact with the rest of the page.” (traducción) «no interactúa con el resto de la página». Una imagen interceptada puede sustituirse, pero no tomar el documento. Históricamente se cargaba degradando el 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.” (traducción) «Hasta hace poco se cargaba en todos los navegadores, porque bloquearlo habría roto muchos sitios. Esto empieza a cambiar». Ahora se actualiza automáticamente cuando es posible y se bloquea en caso contrario.

Excepciones que no refleja la división activo/pasivo

La línea actualizable/bloqueable presenta excepciones importantes:

• Las imágenes con CORS fallan, no se actualizan. Un <img src="http://…"> normal es actualizable; con crossorigin, el algoritmo fuerza el fallo.
• srcset y <picture> son bloqueables. La misma imagen mediante un mecanismo adaptable no se comporta como un src simple.
• Los hosts con dirección IP se bloquean, incluso en tipos actualizables. http://203.0.113.5/logo.png no recibe el tratamiento de un dominio.
• Contextos anidados y workers están incluidos. Las comprobaciones se aplican en iframes y service/shared workers.
• Orígenes locales y loopback tienen matices. localhost, loopback y file:// son «potencialmente fiables» incluso sin TLS; la heurística HTTP/HTTPS no encaja limpiamente en desarrollo.
• Las descargas inseguras son un límite separado. Una descarga mediante http:// entraña riesgo, pero se rige por la seguridad de descargas, no por estas reglas de subrecursos.
• La navegación HTTP superior no es contenido mixto, incluido el enlace anterior.

Detectar contenido mixto en toda la pila

No existe un botón único. Diagnostica por separado la fuente obtenida, el estado renderizado/en ejecución y las sesiones reales detrás de consentimiento, georredirección, login o etiquetas condicionales:

1. Consola de Chrome DevTools. El contenido activo bloqueado registra algo parecido a “Mixed Content: The page … was loaded over HTTPS, but requested an insecure … This request has been blocked; the content must be served over HTTPS.” (traducción) «Contenido mixto: la página … se cargó mediante HTTPS, pero solicitó un recurso inseguro… La solicitud se bloqueó; el contenido debe servirse mediante HTTPS». Lo pasivo genera una advertencia. Security/Issues lo agrupa por página. El texto, el panel y los tipos bloqueados dependen del navegador y versión; se comprobó con Chrome en 2026-07, así que verifica el entorno real y espera diferencias en Firefox, Safari y Edge.

2. Rastreador de sitios. Ahrefs Site Audit y Screaming Frog señalan a escala páginas HTTPS con subrecursos http://. Es la herramienta principal, pero lee la fuente: un rastreo limpio no demuestra que el renderizado o una sesión real lo estén. Registra herramienta y versión.

3. Informes de infracciones CSP. Los navegadores de visitantes detectan recursos condicionados y terceros. La fuente oficial explica: “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.” (traducción) «La política de seguridad de contenido permite recopilar informes de contenido mixto en el sitio; para activar la función, configura Content-Security-Policy-Report-Only como cabecera de respuesta». El modo de solo informe comunica las infracciones sin aplicar la política. El mecanismo moderno usa report-to / Reporting-Endpoints; el anterior, report-uri. No confundas esta política general de solo informe con upgrade-insecure-requests en ese modo, porque la actualización no funciona.

Usa las tres: DevTools para una página renderizada, rastreo para la fuente de todo el sitio y CSP para la larga cola de sesiones reales. Un rastreo aprobado no garantiza cada estado de consentimiento, variante publicitaria, personalización o worker.

Corregirlo en la fuente

Antes de tocar una referencia, comprueba que el equivalente HTTPS existe, tiene certificado válido y devuelve el contenido esperado. Después, haz que cada subrecurso resuelva mediante HTTPS:

• URL HTTPS absolutas: cambia http://cdn.example.com/app.js por https://cdn.example.com/app.js. Es la opción explícita y segura por defecto.
• Rutas relativas o a la raíz: /assets/app.js hereda el esquema. 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.” (traducción) «Asegúrate de que las URL internas y externas no dependan de un protocolo concreto; usa rutas relativas u omite el protocolo, como //example.com/something.js». Es condicional: confirma que posees el recurso, que la URL base real —incluidos <base>, proxies y contextos incrustados— resuelve como esperas y que nada reconstruye http://, por ejemplo código basado en window.location.
• URL relativas al protocolo (//example.com/something.js) funcionan, pero no son la solución universal. Requieren las mismas comprobaciones; https:// suele ser más claro.

A escala no edites plantillas una por una, pero tampoco ejecutes una sustitución de cadenas sin protección. http://yourdomain → https://yourdomain suele funcionar en texto simple; en arrays PHP serializados, blobs JSON o datos de bloques puede corromper registros. Usa herramientas que entiendan el formato, haz copia de seguridad y una simulación. Después corrige plantillas/configuración y usa rastreo/CSP para los restos.

upgrade-insecure-requests: red de seguridad y límites

web.dev: “The upgrade-insecure-requests CSP directive instructs the browser to upgrade insecure URLs before making network requests.” (traducción) «La directiva CSP upgrade-insecure-requests indica al navegador que actualice URL inseguras antes de realizar solicitudes de red». Define esta cabecera:

Content-Security-Policy: upgrade-insecure-requests

MDN dice que “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).” (traducción) «indica a los agentes que traten todas las URL inseguras del sitio como si se hubieran sustituido por URL seguras». Actualiza “requests to load resources (such as images, scripts, or fonts),” (traducción) «solicitudes para cargar recursos como imágenes, scripts o fuentes», “navigation requests (such as link targets) which are same-origin with the document,” (traducción) «navegación del mismo origen», “navigation requests in nested browsing contexts, such as iframes,” (traducción) «navegación en contextos anidados como iframes», y “form submissions.” (traducción) «envíos de formularios». 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: 2026-07-14 MDN: CSP upgrade-insecure-requests

Los subrecursos se actualizan también entre orígenes; la restricción al mismo origen corresponde a la navegación. Además, la reescritura ocurre antes de las comprobaciones de contenido mixto y CSP, por eso evita el bloqueo.

Tres límites:

• No actualiza navegación superior a terceros. La documentación aclara: “However, top-level navigation requests whose target is a different origin will not be upgraded.” (traducción) «No se actualizarán las solicitudes de navegación de nivel superior cuyo destino sea otro origen». Por ello: “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.” (traducción) «La directiva no asegura la actualización HTTPS de la navegación superior iniciada desde enlaces de terceros y, en consecuencia, no reemplaza HSTS».
• Es una red de seguridad, no una solución, y no ofrece recurso alternativo. Si no existe HTTPS, la solicitud falla y no vuelve a http://.
• El modo de solo informe no realiza la actualización. upgrade-insecure-requests dentro de Content-Security-Policy-Report-Only se ignora. Para observar destinos http://, usa otra política de solo informe como default-src https:; configurar upgrade-insecure-requests en modo de solo informe no aporta visibilidad.

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

Según MDN, block-all-mixed-content “prevents loading any assets over HTTP when the page uses HTTPS,” (traducción) «impide cargar recursos mediante HTTP cuando la página usa HTTPS». Está deprecated y “obsolete in the specification,” (traducción) «obsoleta en la especificación», porque “Content that isn’t blocked is now always upgraded to a secure connection, so this directive is not needed.” (traducción) «El contenido no bloqueado ahora siempre se actualiza a una conexión segura, por lo que no se necesita». Usa upgrade-insecure-requests; considera block-all-mixed-content un legado. Si ya envías upgrade-insecure-requests, block-all-mixed-content es redundante porque la actualización ocurre antes.

Por qué tu CMS vuelve a introducirlo

Varios sistemas reinyectan URL http://:

• Base de datos. En WordPress, Drupal y otros CMS, imágenes e incrustaciones http:// absolutas viven en el contenido, no en plantillas; una corrección de código no las toca.
• Temas y plugins. Una URL de recurso http:// fija reaparece en cada página y una actualización puede devolverla.
• Anuncios, analítica y terceros. Si un proveedor llama a http://, no puedes corregirlo en tu repositorio. Usa CSP para detectar, presiona al proveedor, sustituye o elimina; no hay una cuarta opción segura.
• Service workers y cachés. Pueden repetir solicitudes antiguas que apuntan a http:// después de corregir la fuente. Prueba sin caché y aumenta la versión para expulsarlas.
• http:// fijo en contenido antiguo y plantillas de correo/impresión reutilizadas.

Incorpora detección a una auditoría periódica —rastreador + CSP—, no a una lista de lanzamiento única.

Cómo interactúa con HSTS

Resuelven problemas contiguos:

• upgrade-insecure-requests actualiza los subrecursos solicitados por la página segura.
• HSTS (Strict-Transport-Security) fuerza la navegación superior a tu sitio mediante HTTPS, incluso la primera solicitud, y combate SSL stripping. Google lo presenta para “avoid the cost of the 301 redirect” (traducción) «evitar el coste de la redirección 301» y “defeat attacks like SSL Stripping.” (traducción) «derrotar ataques como SSL Stripping».

No se sustituyen. MDN indica que upgrade-insecure-requests “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.” (traducción) «no garantiza HTTPS superior para usuarios procedentes de enlaces de terceros y no sustituye HSTS». Una configuración endurecida usa upgrade-insecure-requests y HSTS. Google advierte “Don’t enable HSTS until you’re certain your site operation is robust enough to avoid ever deploying HTTPS with certificate validation errors,” (traducción) «No habilites HSTS hasta estar seguro de que nunca desplegarás HTTPS con errores de certificado»; la precarga se acerca a una puerta de sentido único.

¿Perjudica directamente al SEO?

Es ante todo un problema de seguridad y funcionamiento. CSS o JS activo bloqueado rompe el renderizado y la interacción, con independencia del buscador.

Las consecuencias SEO son condicionales, no garantizadas. Google no documenta una mejora directa de ranking por corregirlo; la señal HTTPS se basa en que la URL comienza por https://, no en limpiar subrecursos. Pero Googlebot podría renderizar una versión rota si se bloquea CSS/JS, un indicador degradado reduce confianza y conversiones, y la preferencia por canonical HTTPS depende de certificados, dependencias, redirecciones y señales coherentes. Verifica renderizado, indexación, canonicalización y analítica en tus páginas y corrige primero por seguridad y función.

Forma parte del tema HTTPS para SEO, que cubre migración, señal y HSTS. Los errores de cadena, caducidad y DV/OV/EV pertenecen al análisis hermano del certificado.

Resumen de IA

Versión condensada del contenido avanzado:

• Contenido mixto = una página HTTPS que carga un subrecurso mediante HTTP. Trata de recursos que carga, no de enlaces: un enlace a HTTP o una navegación HTTP superior no es contenido mixto; tampoco una descarga insegura, que es un límite separado.
• La taxonomía actual es actualizable/bloqueable; activo/pasivo es el marco histórico del radio de impacto. Lo activo —scripts, estilos, iframes y XMLHttpRequest/fetch— se bloquea porque puede reescribir la página: corrígelo primero. Lo pasivo —imágenes, audio y vídeo— antes se cargaba degradando el candado y ahora se actualiza o bloquea. Excepciones: imágenes con CORS, srcset/<picture> (frente a un img src simple), hosts IP, contextos anidados/workers y orígenes locales.
• Detecta en tres capas: fuente obtenida —Ahrefs Site Audit o Screaming Frog—, estado renderizado/en ejecución —Chrome DevTools, con texto dependiente de versión— y sesiones reales —informes Content-Security-Policy-Report-Only, incluidos terceros y consentimiento—. Una capa limpia no exonera las demás.
• Corrige la fuente tras comprobar el equivalente HTTPS: apunta cada subrecurso a https://; usa rutas relativas solo tras verificar propiedad y URL base. Haz copia y simulación al sustituir en el CMS: una operación ingenua corrompe datos serializados. Vigila service workers/cachés que repitan referencias http:// antiguas.
• upgrade-insecure-requests reescribe subrecursos http:// incluidos en su ámbito como https://, también entre orígenes, antes de enviarlos y comprobar CSP. No vuelve a HTTP si falla, no actualiza navegación superior a terceros, no sustituye HSTS y no funciona por sí sola en report-only.
• block-all-mixed-content está obsoleta y es redundante una vez desplegada upgrade-insecure-requests.
• Reaparece por bases de CMS, temas/plugins, cachés y etiquetas que reintroducen URL http://; audita periódicamente.
• El efecto SEO es condicional: Google no documenta una mejora directa de ranking, pero recursos activos bloqueados pueden producir un renderizado roto, el indicador degradado reduce confianza y la preferencia por canonical HTTPS depende de otras condiciones.

Documentación oficial

Documentación primaria de Google y equipos de navegadores/estándares.

Google / web.dev

• ¿Qué es el contenido mixto?: definición y división activo/pasivo con comportamiento de navegadores.
• Corregir contenido mixto: detección, URL de subrecursos, upgrade-insecure-requests e informes CSP.
• Habilitar HTTPS en tus servidores: URL relativas/al protocolo, <iframe> HTTP y HSTS.
• Prevenir contenido mixto forma parte de la guía HTTPS de Google: contexto de migración.

MDN / estándares

• CSP: upgrade-insecure-requests: qué actualiza, qué no y por qué no sustituye HSTS.
• CSP: block-all-mixed-content: directiva de bloqueo obsoleta.
• MDN: contenido mixto: comportamiento bloqueable frente a actualizable.
• Content Security Policy (CSP): cabecera que contiene estas directivas e informes.

Citas de las fuentes

Definiciones registradas en web.dev y MDN. Cada enlace salta al pasaje citado cuando la plataforma lo permite.

Google / web.dev: qué es el contenido mixto

• “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.” (traducción) «Una página tiene contenido mixto cuando su HTML inicial se carga mediante una conexión HTTPS segura, pero otros recursos se cargan mediante HTTP inseguro». Fuente
• “Active mixed content poses a greater threat than passive mixed content.” (traducción) «El contenido mixto activo supone una amenaza mayor que el pasivo». Fuente
• El activo “includes scripts, stylesheets, iframes, and any other code the browser can download and execute,” (traducción) «incluye scripts, hojas de estilo, iframes y cualquier código que el navegador pueda descargar y ejecutar», y “Most browsers already block this type of content by default to protect users.” (traducción) «La mayoría de los navegadores ya bloquean este tipo de contenido de forma predeterminada para proteger a los usuarios». Fuente
• El pasivo, “including images, video, and audio,” (traducción) «incluidas imágenes, vídeo y audio», “doesn’t interact with the rest of the page.” (traducción) «no interactúa con el resto de la página». Además: “Until recently, passive mixed content was loaded in all browsers, because blocking it would have broken many websites. This is now beginning to change.” (traducción) «Hasta hace poco se cargaba en todos los navegadores porque bloquearlo habría roto muchos sitios. Esto empieza a cambiar». Fuente

Google / web.dev: detección y corrección

• “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.” (traducción) «Puedes usar una política de seguridad de contenido para recopilar informes de contenido mixto. Para habilitarla, añade Content-Security-Policy-Report-Only como cabecera de respuesta». Fuente
• “The upgrade-insecure-requests CSP directive instructs the browser to upgrade insecure URLs before making network requests.” (traducción) «La directiva CSP upgrade-insecure-requests indica al navegador que actualice las URL inseguras antes de realizar solicitudes de red». Fuente
• “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.” (traducción) «Haz que las URL del sitio y las externas sean independientes de un protocolo específico; emplea rutas relativas u omite el protocolo, como en //example.com/something.js». Fuente

MDN: upgrade-insecure-requests y sus límites

• “The HTTP Content-Security-Policy (CSP) upgrade-insecure-requests directive 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).” (traducción) «La directiva HTTP CSP UIR indica a los agentes que traten todas las URL inseguras como si hubieran sido sustituidas por URL seguras». Fuente
• “However, top-level navigation requests whose target is a different origin will not be upgraded.” (traducción) «No se actualizarán las solicitudes de navegación de nivel superior cuyo destino sea otro origen». Fuente
• “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.” (traducción) «La directiva no garantiza HTTPS superior para usuarios procedentes de enlaces de terceros y no sustituye HSTS». Fuente

MDN: block-all-mixed-content es legado

• “The HTTP Content-Security-Policy (CSP) block-all-mixed-content directive prevents loading any assets over HTTP when the page uses HTTPS.” (traducción) «La directiva impide cargar recursos mediante HTTP cuando la página usa HTTPS». Figura como deprecated y “obsolete in the specification,” (traducción) «ya retirada de la especificación», porque “Content that isn’t blocked is now always upgraded to a secure connection, so this directive is not needed.” (traducción) «Lo que no se bloquea se eleva siempre a una conexión segura, de modo que esta directiva ha dejado de ser necesaria». Fuente

Lista de comprobación

Úsala durante y después de migrar HTTP→HTTPS y de forma periódica:

Encontrarlo

• Cargaste plantillas clave —inicio, producto, artículo y pago— mediante HTTPS con la consola de Chrome DevTools abierta y anotaste cada «Mixed Content».
• Ejecutaste un rastreo completo —Ahrefs Site Audit o Screaming Frog— y extrajiste páginas con subrecursos http://.
• Configuraste Content-Security-Policy-Report-Only con endpoint para la larga cola de producción.

Corregirlo (activo primero)

• Corregiste referencias activas: <script>, <link rel="stylesheet">, <iframe>, fetch/XMLHttpRequest y fuentes; se bloquean y rompen la página.
• Corregiste referencias pasivas: <img>, <audio>, <video> y URL <source>/poster.
• Sustituiste en la base del CMS http://yourdomain → https://yourdomain con copia, simulación y herramienta consciente del formato, no sobre datos serializados sin procesar.
• Localizaste URL http:// fijadas en temas/plugins.
• Reprodujiste entradas de service worker/caché sin caché y aumentaste su versión para que no repitan referencias http://.
• Confirmaste que terceros —anuncios, analítica, chat, incrustaciones— cargan mediante HTTPS o presionaste/eliminaste la etiqueta.

Respaldo y verificación

• Definiste Content-Security-Policy: upgrade-insecure-requests como red, sabiendo que no sustituye HSTS.
• Repetiste rastreo y consola: cero recursos activos bloqueados y candado limpio.
• Añadiste la detección a la auditoría periódica, no solo al lanzamiento.

¿Qué solución necesita este caso?

Avanza desde el síntoma.

¿Es un recurso cargado o un enlace?

• Enlace (<a href="http://…">) → no es contenido mixto. Déjalo o pásalo a HTTPS por limpieza de referencias. Fin.
• Recurso cargado —script, estilo, iframe, imagen, fuente, medio, fetch— → continúa.

¿Está disponible mediante HTTPS?

• Sí, verificado (certificado válido y contenido previsto) → cambia a https:// o usa una ruta relativa solo si posees el recurso y comprobaste la URL base. Es la solución real.
• No / no sabes → ¿es propio?
  • Propio → sírvelo mediante HTTPS y corrige la referencia.
  • Tercero → pide endpoint HTTPS; si no existe, sustituye o elimina. upgrade-insecure-requests fallará si no hay versión HTTPS.

¿Activo o pasivo?

• Activo —script, hoja, iframe, fetch, fuente— → máxima prioridad: se bloquea y rompe la página.
• Pasivo —imagen, audio, vídeo— → corrígelo también, con menor urgencia inmediata.

¿Quieres red de seguridad?

• Define Content-Security-Policy: upgrade-insecure-requests. Es una red, no un sustituto, y no cubre navegación superior a terceros ni reemplaza HSTS.

¿Necesitas forzar HTTPS superior para primeras visitas/referencias?

• Eso es HSTS. Añade Strict-Transport-Security solo con una operación de certificados sólida; preload se acerca a una puerta de sentido único.

Modelos mentales

1. Recursos, no enlaces. Pregunta: ¿el navegador obtiene esto para construir la página actual? Sí → posible contenido mixto. ¿Solo lleva a otra página? → no.

2. Prioriza por el comportamiento del navegador. Lo activo se bloquea: fallo funcional, primero. Lo pasivo se advierte/actualiza: después. El comportamiento es la cola de prioridad.

3. Embudo de detección: verificar → inventariar → captar la cola. DevTools —una página—, rastreador —todo el sitio— y CSP —producción, terceros y usuarios—. Ninguna herramienta ve las tres capas.

4. Corrige la fuente; cubre el resto. Limpia URL en base, plantillas y etiquetas. Añade upgrade-insecure-requests como respaldo. Es un seguro, no una reparación.

5. Dos trabajos de «forzar HTTPS», dos herramientas. upgrade-insecure-requests actualiza subrecursos; HSTS fuerza navegación superior. No se sustituyen.

6. Auditoría periódica, no tarea única. CMS, actualizaciones y etiquetas reintroducen http://. Programa la detección.

Antipatrones

Errores que mantienen contenido inseguro o lo ocultan:

• Tratar upgrade-insecure-requests como solución. Si no hay HTTPS, falla. Limpia la fuente y usa la directiva para la cola.
• Suponer que un despliegue limpió la base. URL http:// antiguas viven en filas de contenido. Sustituye con seguridad.
• Restar prioridad al activo porque «solo es un aviso». Se bloquea: es una interrupción funcional.
• Comprobar la portada y terminar. Rastrea todo y usa CSP para rutas condicionadas.
• Ignorar terceros. Si una etiqueta llama a http://, presiona al proveedor, sustituye o elimínala.
• Usar block-all-mixed-content en una implementación nueva. Está obsoleta; usa upgrade-insecure-requests.
• Confundir upgrade-insecure-requests con HSTS. Una actualiza subrecursos; la otra fuerza HTTPS superior y combate SSL stripping.
• Excluir detección de la auditoría periódica. Un plugin o imagen pegada con http:// devolverá el problema.

Contenido mixto: chuleta

Activo frente a pasivo

Pila de detección

Directivas CSP

No las confundas

Solución CMS en una línea: base http://yourdomain → https://yourdomain, después plantillas/plugins y upgrade-insecure-requests.

Encontrar contenido mixto: fragmentos

1. Rastrear una página desde la línea de comandos

Obtén una página y señala subrecursos inseguros src/href del HTML.

macOS / Linux

# Flag insecure script/img/link/iframe/source references on a single URL
curl -s https://example.com/ \
  | grep -Eo '(src|href)="http://[^"]+"' \
  | sort -u

Windows (PowerShell)

(Invoke-WebRequest -Uri "https://example.com/").Content `
  | Select-String -Pattern '(src|href)="http://[^"]+"' -AllMatches `
  | ForEach-Object { $_.Matches.Value } | Sort-Object -Unique

Solo ve HTML sin procesar: lo inyectado por JavaScript no aparece. Por eso necesitas DevTools y un rastreador real.

2. Consola de Chrome DevTools: recursos inseguros renderizados

Pega esto en la consola de una página HTTPS para captar referencias insertadas por JS:

// Every element with an http:// resource attribute in the live DOM
[...document.querySelectorAll('[src],[href],[srcset],[data-src]')]
  .filter(el => /^http:\/\//.test(
    el.src || el.href || el.getAttribute('srcset') || el.getAttribute('data-src') || ''
  ))
  .map(el => ({ tag: el.tagName, url: el.src || el.href }));

El navegador también registra por sí mismo el contenido activo bloqueado con este mensaje exacto: “Mixed Content: … This request has been blocked; the content must be served over HTTPS.” (traducción) «Contenido mixto: … Esta solicitud se ha bloqueado; el contenido debe servirse mediante HTTPS». Revísalo primero.

3. Bookmarklet: volcado con un clic

Guárdalo como marcador y haz clic para registrar referencias http://:

javascript:(()=>{const h=[...document.querySelectorAll('[src],[href]')].filter(e=>/^http:\/\//.test(e.src||e.href)).map(e=>e.src||e.href);console.log('%cMixed content candidates:','font-weight:bold',h.length);h.forEach(u=>console.log(u));})();

4. Activar informes CSP

Añade report-only para que navegadores reales informen de infracciones, incluidos terceros:

Content-Security-Policy-Report-Only: default-src https:; report-uri /csp-report-endpoint

Informa sin aplicar; mide antes de activar upgrade-insecure-requests o enforcement. El equivalente moderno usa report-to con Reporting-Endpoints.

5. Cabecera de seguridad tras corregir la fuente

Content-Security-Policy: upgrade-insecure-requests

La directiva no actualiza navegación superior a terceros ni sustituye HSTS.

SOP de auditoría periódica

Ejecútalo tras lanzar HTTPS, cambios de CMS/tema/gestor de etiquetas y periódicamente.

1. Rastrea HTTPS en modos fuente y renderizado. Exporta URL inseguras de src, srcset, hojas, iframes, medios y fetch/XHR; enlaces HTTP normales no cuentan.
2. Recopila evidencia del navegador. Revisa DevTools en plantillas y usa Content-Security-Policy-Report-Only para visitantes y terceros.
3. Clasifica cada hallazgo. Activo/pasivo, propio/tercero, estático/JS; identifica plantilla, campo, plugin, etiqueta o proveedor.
4. Corrige la fuente. Apunta a un recurso HTTPS funcional o ruta segura. Verifica TLS; no supongas que cambiar http:// a https:// basta.
5. Usa CSP como red. Añade upgrade-insecure-requests tras revisar. No repara el CMS ni sustituye HSTS.
6. Vuelve a rastrear/renderizar. Cero errores activos; los pasivos resuelven mediante HTTPS sin fallback.
7. Evita recurrencia. Corrige el flujo de origen, conserva informes y asigna infracciones al propietario.

Síntoma → causa → solución

Pruebas de publicación

Prueba 1: barrido renderizado

• Objetivo: detectar activos/pasivos que omite el HTML fuente.
• Método: renderiza cada plantilla/estado e inspecciona Console y Network.
• Esperado: ningún subrecurso HTTP ni activo bloqueado.
• Fallo: aviso, fallo de autoactualización o función/diseño ausente.
• Acción: rastrea hasta plantilla, etiqueta, plugin o campo; corrige y repite.

Prueba 2: comparación fuente/CSP

• Objetivo: detectar infracciones exclusivas de usuarios o terceros.
• Método: compara rastreo y Content-Security-Policy-Report-Only por URL, plantilla, directiva y propietario.
• Esperado: ninguna infracción de producción sin explicar; ruido conocido excluido estrechamente.
• Fallo: infracción repetible ausente del rastreo o tercero sin propietario.
• Acción: reproduce el estado y corrige/elimina la integración.

Prueba 3: recurrencia tras publicar

• Objetivo: verificar que el CMS no genera nuevas referencias inseguras.
• Método: publica una prueba con el flujo normal y rastrea/renderiza.
• Esperado: marcado y recursos usan HTTPS válido.
• Fallo: la página nueva recrea una referencia HTTP ya limpiada.
• Acción: corrige valor, plantilla, plugin o transformación antes de publicar.

Recursos útiles

Mis ponencias

• Más vale prevenir que lamentar con HTTPS — SMX East 2016 (SlideShare): TLS, fallos HTTPS y problemas de migración que producen contenido mixto. (Mi comprensión; estadísticas de 2016).

Mis artículos relacionados

• Guía para principiantes de SEO técnico: dónde encajan HTTPS y contenido mixto.

Del sector

• What is mixed content? (web.dev / Google): definición y división activo/pasivo.
• Fixing mixed content (web.dev / Google): detección, URL, upgrade-insecure-requests e informes CSP.
• MDN: upgrade-insecure-requests: alcance y relación con HSTS.
• MDN: block-all-mixed-content: directiva obsoleta heredada.
• MDN: Mixed content: comportamiento bloqueable/actualizable.
• Habilitar HTTPS en tus servidores (web.dev / Google): URL relativas y configuración HTTPS.

Estadísticas citables

• El activo se bloquea por defecto. Google: “Most browsers already block this type of content by default to protect users.” (traducción) «La mayoría de los navegadores ya bloquean este tipo de contenido para proteger a los usuarios». Es una interrupción funcional. Fuente
• El activo es la amenaza mayor. “Active mixed content poses a greater threat than passive mixed content.” (traducción) «El contenido mixto activo supone una amenaza mayor que el pasivo». Fuente
• El pasivo ya no está permitido con seguridad. “Until recently, passive mixed content was loaded in all browsers … This is now beginning to change.” (traducción) «Hasta hace poco se cargaba en todos los navegadores… Esto empieza a cambiar». Fuente
• upgrade-insecure-requests no sustituye HSTS. MDN dice que “does not replace the Strict-Transport-Security (HSTS) header.” (traducción) «no sustituye la cabecera HSTS». Fuente
• Alrededor del 89 % de la web usa HTTPS (W3Techs, 2026; confirma la cifra actual). Por eso los subrecursos http:// restantes son un fallo común: la página es HTTPS, la carga quedó atrás. Contexto en el hub de HTTPS.

Ponte a prueba: contenido mixto

Cinco preguntas rápidas. Elige una respuesta y comprueba.

Registro de cambios