Advertencia de contenido mixto después de activar HTTPS

Qué significa este error y cómo reconocerlo

• La dirección de la página usa HTTPS, pero las herramientas de desarrollo del navegador informan de contenido mixto.
• Un script, una hoja de estilos, una fuente, una imagen, un vídeo, una imagen de fondo o un frame incrustado no se carga o se comporta de forma diferente después de activar HTTPS.
• Los mensajes de la Consola identifican un recurso HTTP solicitado por una página HTTPS.
• La funcionalidad de la página está incompleta porque se bloquea contenido activo, como JavaScript o CSS.
• La advertencia solo aparece en determinadas páginas, plantillas o estados de usuario, lo que sugiere una referencia codificada directamente o generada condicionalmente.
• El certificado del sitio parece válido para la página principal aunque algunos recursos individuales todavía usen referencias inseguras.

Causas principales, ordenadas por probabilidad

1. Referencias HTTP codificadas directamente: El contenido de la página, las plantillas, los archivos del tema, los widgets o las hojas de estilos todavía apuntan a un recurso con una dirección http://.
2. Contenido almacenado antiguo: Las imágenes, inserciones, campos multimedia, scripts u otros valores de la base de datos conservaron referencias HTTP anteriores a la migración a HTTPS.
3. Salida de un tema o plugin: Un componente genera una URL insegura aunque la dirección principal del sitio esté configurada para HTTPS.
4. Recursos externos sin compatibilidad con HTTPS: Un script, una fuente, un frame, un archivo multimedia u otra dependencia de terceros puede no estar disponible de forma segura.
5. Archivos almacenados en caché o agrupados: Las cachés de página, los paquetes de recursos, los archivos minificados, las CDN o los proxies inversos pueden seguir sirviendo código con una referencia antigua.
6. Configuración de la aplicación o de los recursos desactualizada: La aplicación puede crear URLs absolutas a partir de una dirección base o una configuración de entorno antigua.

Una advertencia de contenido mixto no demuestra por sí sola que el certificado del sitio sea inválido. Un error de certificado afecta a la conexión segura con el sitio o el host del recurso; el contenido mixto afecta a los recursos inseguros solicitados dentro de una página que, por lo demás, es segura.

Cómo solucionarlo

1. Confirma que el problema es contenido mixto

Abre la página afectada en un navegador actualizado y abre sus herramientas de desarrollo. En la Consola, busca mensajes de contenido mixto. En el panel Network, inspecciona la solicitud identificada en la advertencia y anota su URL, tipo de recurso, estado y —cuando se muestre— el archivo o componente que la inició.

Si el navegador no puede establecer una conexión segura con el sitio principal y muestra una advertencia de certificado, trata ese problema por separado. No cambies la configuración del certificado para corregir una referencia de recurso insegura.

2. Identifica todas las referencias inseguras

Inspecciona la página renderizada y, cuando corresponda, su código fuente, hojas de estilos, scripts y archivos de recursos generados en busca de referencias HTTP. Revisa algo más que las imágenes visibles: JavaScript, CSS, fuentes, frames, contenido multimedia e imágenes de fondo CSS también pueden provocar advertencias o fallos de carga.

Prueba la página afectada en una ventana de navegación privada o después de borrar la caché relevante del navegador. Esto ayuda a distinguir una solicitud insegura actual de una respuesta antigua almacenada en caché, pero no sustituye la corrección de la referencia original.

3. Localiza el origen que genera la referencia

Usa el tipo de recurso y las páginas afectadas para acotar el origen de la URL:

• Un artículo o una página: inspecciona su contenido almacenado o su campo multimedia.
• Varias páginas que usan un mismo diseño: inspecciona la plantilla compartida, el tema, el widget o el componente reutilizable.
• Solo las páginas que usan una función: inspecciona el plugin, la integración, la inserción o el ajuste de configuración responsable.
• Una solicitud de un recurso combinado: inspecciona la hoja de estilos de origen, el script, el proceso de compilación, la caché o el proxy que produjo el paquete.
• Comportamiento diferente para visitantes con y sin sesión iniciada: compara el contenido y las capas de caché renderizados para cada estado.

4. Actualiza la referencia en su origen

Aplica la solución que corresponda al lugar donde se almacena la referencia:

• Cambia el contenido de la página o entrada para que use la versión HTTPS del recurso.
• Actualiza el ajuste del sitio, recurso multimedia, tema, plugin, inserción o integración que genera la URL.
• Corrige las referencias codificadas directamente en plantillas, hojas de estilos, scripts o archivos de configuración.
• Para un recurso del mismo sitio, usa una ruta relativa compatible cuando encaje con la aplicación y la estructura de despliegue.
• Para un recurso externo, confirma que su host admita HTTPS. Si no lo admite, sustituye la dependencia por una fuente segura o elimínala, especialmente si proporciona contenido activo.

5. Usa la sustitución masiva solo con medidas de seguridad

La sustitución masiva es adecuada cuando el mismo valor desactualizado está almacenado en muchos registros conocidos. Antes de modificar datos de producción, obtén autorización, crea una copia de seguridad restaurable, define el alcance exacto y prueba la operación en una copia de staging o en registros representativos cuando sea posible.

Ten en cuenta los datos serializados o estructurados y evita sustituir a ciegas todas las apariciones de una cadena de texto. Revisa los hosts externos, las redirecciones, las rutas de archivos, los valores de configuración y los registros cuyo texto http:// podría no ser una URL de página. Si no conoces la estructura de los datos, pide al responsable de la aplicación o a un desarrollador que realice el cambio.

6. Vacía el contenido generado y almacenado en caché

Después de corregir el origen, purga las cachés de la aplicación, la página, la CDN, el proxy inverso y el navegador que aún puedan contener código antiguo o paquetes de recursos antiguos. Regenera los recursos combinados o minificados si el sitio los utiliza. Realiza únicamente purgas de caché autorizadas para el entorno afectado, ya que pueden aumentar temporalmente el tráfico al origen o cambiar el comportamiento del sitio.

7. Verifica la reparación

Vuelve a cargar las páginas afectadas y comprueba de nuevo la Consola y el panel Network. Confirma que el recurso señalado anteriormente se solicita de forma segura, que los scripts y estilos funcionan y que no aparecen nuevas referencias inseguras.

Repite la comprobación en las plantillas relacionadas y en las vistas relevantes con y sin sesión iniciada. Si la advertencia vuelve a aparecer después de actualizar la caché, la plantilla, el plugin, la configuración o el recurso generado subyacente todavía necesita una corrección.

Prevención y cómo verificar la solución

• Añade imágenes, scripts, hojas de estilos, fuentes, inserciones y contenido multimedia mediante referencias compatibles con HTTPS.
• Mantén coherentes con HTTPS la dirección del sitio de la aplicación, la configuración de recursos, el tema, los plugins y las integraciones.
• Revisa las dependencias de terceros antes del despliegue y sustituye a los proveedores que no ofrezcan una entrega segura.
• Incluye comprobaciones de contenido mixto en las pruebas de staging y posteriores a la migración.
• Inspecciona las plantillas compartidas y los componentes reutilizables, no solo la página en la que se detectó inicialmente la advertencia.
• Mantén copias de seguridad probadas antes de realizar cambios masivos en el contenido y purga o regenera después las cachés y los paquetes de recursos afectados.
• Vuelve a comprobar las páginas con distintos estados de autenticación cuando rendericen recursos diferentes.

Preguntas frecuentes