El contenido mixto aparece cuando una página cargada de forma segura utiliza recursos solicitados mediante una conexión insegura. El Comprobador de contenido mixto de Screpy encuentra referencias HTTP en el HTML de origen de una página HTTPS pública y muestra su categoría, dirección, primera línea y número de apariciones. Usa esos datos para localizar el contenido o la plantilla que necesitas corregir y preparar un reemplazo seguro.
El informe no ejecuta la página ni solicita los recursos enumerados. Identifica referencias del código que debes investigar, no lo que el navegador de un visitante cargó, actualizó a HTTPS o bloqueó realmente. Una comprobación satisfactoria tampoco certifica la seguridad de toda la web.
Comprueba la página HTTPS que contiene las referencias
Introduce la dirección pública completa de la página que quieres revisar. Para un artículo, envía su propia URL, como la dirección ilustrativa https://example.com/guides/setup/, en lugar de la portada o la imagen que sospechas que es insegura. Esta herramienta examina una página proporcionada; no descubre todas las páginas del dominio.
La entrada requiere HTTPS. Lee después la URL final porque las redirecciones pueden cambiar la página examinada. Si una dirección HTTPS termina en HTTP, el análisis de contenido mixto HTTPS no es aplicable. Eso no es un resultado sin problemas. Usa Redirect Checker para investigar un destino inesperado.
La página debe devolver HTML público y legible. Una pantalla de acceso puede contener referencias distintas de la página privada que protege. Una respuesta no disponible, un documento no admitido o una solicitud fallida dejan incompleta la comprobación; no demuestran que no existan referencias inseguras.
Interpreta recursos bloqueables, candidatos a actualización y formularios
Usa el filtro de categorías para centrar la tabla y revisa el elemento y el atributo junto a cada dirección. Las categorías describen cómo agrupa esta herramienta las referencias HTTP admitidas; no son resultados observados en el navegador.
| Categoría | Ejemplos en este informe | Qué investigar |
|---|---|---|
| Bloqueable, rojo | Scripts, hojas de estilo, marcos y candidatos srcset de imágenes adaptables |
Localiza el origen y confirma un reemplazo HTTPS adecuado. |
| Candidato a actualización, ámbar | Referencias admitidas de imágenes, audio y vídeo | Comprueba que el recurso previsto funcione realmente con HTTPS; una actualización automática no prueba su disponibilidad. |
| Destino de formulario inseguro, naranja | action de un formulario o formaction de un botón/input |
Confirma el destino seguro previsto antes de modificar el formulario. |
El comprobador también examina referencias admitidas de objetos, entradas de imagen, pósteres de vídeo y determinadas relaciones de enlace. Las URL de imágenes o medios cuyo servidor se identifica con una dirección IP se clasifican como bloqueables, en vez de candidatas a actualización.
La documentación actual sobre contenido mixto distingue solicitudes actualizables y bloqueables. El comportamiento real también depende de las reglas del navegador y las políticas de seguridad. Esta clasificación del código no evalúa todas las excepciones, incluidas direcciones locales potencialmente fiables. No interpretes cada fila roja como prueba de que un navegador concreto bloqueó la solicitud.
Los destinos de formularios son una categoría separada. La sección sobre envío de formularios de la especificación de contenido mixto trata los avisos del navegador por separado de las comprobaciones ordinarias de recursos. Screpy no envía esos formularios ni determina qué información recopilan. Revisa la finalidad del formulario real sin enviar datos sensibles de prueba a un destino sin verificar.
Localiza en el código los hallazgos agrupados
La tabla combina apariciones con el mismo elemento, atributo, clasificación y URL resuelta. Por eso una dirección idéntica en otro elemento o atributo puede ocupar otra fila. La línea mostrada es la primera aparición del grupo en el HTML recuperado, no necesariamente una línea de tu editor de plantillas.
Este fragmento ficticio contiene cuatro referencias HTTP:
<script src="http://static.example.com/site.js"></script>
<img src="http://static.example.com/logo.png" alt="Example homepage">
<img src="http://static.example.com/logo.png" alt="Example homepage">
<form action="http://example.com/contact/" method="post"></form>
| Grupo | Apariciones | Clasificación |
|---|---|---|
script[src] terminado en /site.js |
1 | Bloqueable |
img[src] terminado en /logo.png |
2 | Candidato a actualización |
form[action] terminado en /contact/ |
1 | Destino de formulario inseguro |
El resumen cuenta una referencia bloqueable, dos candidatas a actualización y una referencia de formulario: cuatro apariciones en tres filas. Eso no significa cuatro archivos únicos ni cuatro solicitudes de red confirmadas. El ejemplo ilustra la agrupación del informe; no es un análisis real ni un formulario de contacto completo y funcional.
Encuentra todas las apariciones de una referencia repetida en el contenido o componente compartido responsable. Corregir solo la primera línea mostrada puede dejar otra sin cambiar. Examina el código real alrededor de esa línea antes de decidir qué campo del CMS, ajuste del tema o plantilla lo genera.
Revisa la URL base antes de cambiar rutas relativas
La URL del recurso mostrada se resuelve respecto a la base efectiva del documento. Sin una base personalizada, las rutas relativas utilizan la URL final de la página. Un <base href> HTTP puede hacer que una referencia relativa se resuelva a HTTP aunque la página se haya recuperado por HTTPS.
Para una página ficticia en https://example.com/guides/setup/, considera este fragmento:
<head><base href="http://static.example.com/assets/"></head>
<body><img src="logo.png" alt="Example homepage"></body>
La imagen se resuelve a http://static.example.com/assets/logo.png, no a un archivo dentro del directorio de la página HTTPS. Una referencia relativa al protocolo, como //static.example.com/assets/logo.png, también utiliza el esquema de la base. Eliminar únicamente http: no establece, por tanto, un destino seguro.
La referencia del elemento base de HTML explica cómo la primera base aplicable controla las URL relativas. Examina juntos la base y la ubicación prevista del archivo. Cambiarla puede afectar a otros recursos, la navegación y los destinos de formularios; no elimines una base intencionada sin revisar esos efectos. Una dirección HTTPS explícita y funcional puede aclarar el reemplazo que buscas.
Sustituye la referencia insegura por un destino HTTPS funcional
Empieza donde se genera la referencia. Una URL antigua de imagen puede estar en un campo del artículo, un ajuste del logotipo o una plantilla compartida; un script incrustado puede proceder del código de una integración. Corrige ese origen, no un HTML generado que la siguiente publicación sobrescribirá. Evita reemplazar indiscriminadamente cadenas http:// sin relación por toda la web.
Comprueba el destino HTTPS propuesto antes de utilizarlo. Debe entregar la imagen, el script u otro recurso previsto, sin redirecciones inesperadas, pantallas de acceso ni contenido distinto. Este comprobador no ha realizado esa solicitud. Cambiar http://static.example.com/site.js a HTTPS puede fallar si el servidor no entrega el mismo archivo de forma segura.
Si una dependencia externa no tiene una versión segura adecuada, pide un reemplazo compatible o decide si debes retirar o sustituir la función. No coloques silenciosamente un archivo ajeno para eliminar el hallazgo. Para un formulario, verifica el destino receptor y el comportamiento previsto, no solo la escritura de la dirección.
Una Content Security Policy con upgrade-insecure-requests puede modificar las solicitudes del navegador mientras el código conserva referencias HTTP. Como explica la documentación de la directiva, un recurso HTTPS no disponible puede fallar sin recurrir a HTTP. Eso no demuestra que todos los recursos actualizados funcionen. Usa HTTP Headers Checker para inspeccionar por separado las cabeceras declaradas; no sustituyas una política existente a ciegas ni desactives protecciones del navegador para ocultar el problema.
Verifica el código publicado y las solicitudes del navegador
Conserva el informe original junto con el reemplazo previsto antes de hacer cambios. La descarga JSON mantiene los hallazgos y grupos retenidos; elegir una categoría cambia la tabla, no la descarga del informe completo. Esta herramienta no ofrece CSV ni reparación automática.
- Publica el contenido, ajuste o plantilla corregidos y comprueba de nuevo la misma página HTTPS cuando esté disponible la respuesta actualizada.
- Compara la URL, elemento, atributo y número de apariciones afectados. Un total menor puede ocultar otra referencia pendiente; revisa las filas, no solo el resumen.
- Abre la página en un navegador y revisa los avisos de la consola y las solicitudes de red. Prueba la imagen, el medio o la función correspondiente; el informe del código no ejecuta esas interacciones.
- Comprueba otras páginas que usen la misma plantilla modificada. Reparar la portada no demuestra que todos los productos o artículos estén corregidos.
La guía del panel de seguridad de Chrome explica cómo pasar de los orígenes no seguros a sus solicitudes de red. La evidencia del navegador puede revelar peticiones creadas por scripts o estilos que esta herramienta de código fuente no inspecciona. También puede mostrar una solicitud actualizada o bloqueada aunque el código original conserve HTTP.
Separa ambas observaciones: una referencia corregida en el código y una solicitud satisfactoria del navegador responden a preguntas distintas. Ninguna demuestra por sí sola que todo el contenido, todos los navegadores o toda la web sean seguros.
Entiende los hallazgos ausentes y la cobertura parcial
El comprobador acepta hasta 2 MiB de HTML y retiene hasta 1.000 referencias HTTP en 200 filas agrupadas. Si un límite impide conservar más evidencia, la cobertura pasa a ser parcial y el total completo es desconocido. El resumen describe entonces la parte retenida, no todas las referencias del documento. Si el código no puede recuperarse o supera el límite de HTML, la comprobación solicitada queda no disponible.
Sin hallazgos significa que no se encontraron referencias HTTP admitidas dentro del código examinado. No abarca solicitudes generadas mediante JavaScript, valores CSS url(), contenidos de hojas de estilo externas, documentos de marcos anidados ni todos los atributos posibles. Tampoco sigue redirecciones de recursos: leer un atributo HTTPS original no establece si después redirige a HTTP.
Los enlaces de navegación normales están excluidos, incluido un enlace ordinario a una página HTTP. Las descargas y la seguridad del destino necesitan otra revisión; no aparecer en esta tabla no los aprueba. Usa Internal Link Analyzer si tu pregunta trata sobre enlaces salientes en vez de recursos incrustados.
Para un informe parcial, conserva el alcance con la descarga JSON e investiga por separado las referencias restantes. Eliminar las filas mostradas no demuestra que las omitidas estén reparadas. Repite el análisis tras los cambios y guarda el informe anterior para distinguir una corrección confirmada de evidencia que nunca se comprobó.