Si tu web abre con HTTPS pero pierde una fuente, una imagen o una función, conviene comprobar si existe contenido mixto en WordPress. Esta guía propone un diagnóstico por recurso para corregir la causa y dejar una prueba repetible.
Qué significa contenido mixto
Según MDN, aparece cuando una página cargada de forma segura solicita recursos mediante HTTP. El navegador puede actualizar determinadas solicitudes a HTTPS o bloquearlas, según su tipo. Un certificado válido para la página no corrige las direcciones de todos sus recursos.
No todo fallo visual tiene esta causa. Si la consola muestra un error de certificado, de permisos o un archivo inexistente, registra ese mensaje y sigue su diagnóstico específico.
1. Reproduce el problema y guarda la evidencia
- Abre la URL afectada en una ventana privada.
- Abre las herramientas de desarrollo y entra en Consola.
- Recarga la página y busca avisos que mencionen contenido mixto o Mixed Content.
- Anota la URL solicitada, el tipo de recurso y la página donde ocurre.
- En Red, revisa la solicitud y su iniciador para localizar qué elemento la genera.
Mi recomendación es comenzar por una página y un recurso. Evita cambiar ajustes generales hasta poder explicar qué solicitud falla y de dónde sale.
2. Localiza dónde se guarda la dirección antigua
Como lista de revisión, comprueba el bloque de imagen, los fondos del maquetador, el CSS personalizado, los widgets y la configuración del plugin implicado. También conviene revisar el HTML público: una corrección guardada en el editor puede no coincidir todavía con la versión servida.
Ejemplo hipotético: una cabecera solicita una fuente desde una dirección HTTP escrita en una regla CSS. Cambiar la dirección de una imagen del artículo no resolvería esa solicitud. La corrección debe llegar al lugar que produce la URL de la fuente.
3. Corrige el origen con una copia disponible
Antes de cambiar datos, prepara una copia recuperable. Para una referencia aislada, recomiendo editar el elemento responsable y comprobar que la dirección HTTPS del archivo funciona.
Si hay muchas referencias antiguas, prepara primero un inventario y prueba en staging. WP-CLI dispone de search-replace, que trata datos serializados y permite simular el cambio con --dry-run. El alcance de tablas y columnas debe decidirse para la instalación concreta; no copies un reemplazo masivo sin revisar su informe.
Para un recurso externo sin una versión HTTPS funcional, plantea sustituirlo o retirarlo según su función y sus condiciones de uso. No pidas a los visitantes que reduzcan las protecciones del navegador.
4. Revisa las capas de caché
Tras guardar, propongo limpiar únicamente las capas afectadas y volver a comprobar la respuesta pública. Anota si intervienen el maquetador, la caché de página o una CDN. La guía de niveles de caché en WordPress ayuda a organizar esta comprobación.
No daría el incidente por cerrado solo porque desaparezca el aviso en tu sesión. Repite la visita sin iniciar sesión y comprueba que las funciones antes afectadas siguen operativas.
Checklist para cerrar la incidencia
- La URL problemática ya se genera correctamente en el HTML o CSS correspondiente.
- El recurso carga por HTTPS sin errores en la prueba.
- La consola no reproduce el aviso original.
- Se han revisado otras páginas que comparten ese elemento.
- Las imágenes, fuentes y funciones afectadas se han comprobado también en móvil.
- Queda registrado el cambio y cómo revertirlo.
Una captura del antes y después, junto con la URL del recurso, sirve como evidencia de esta corrección. No equivale a una auditoría completa de seguridad.
¿Tu web presenta fallos después de un cambio?
El mantenimiento WordPress puede abordar el diagnóstico y la validación de estas incidencias.
Fuentes oficiales
Documentación consultada el 2 de noviembre de 2026. El procedimiento y el checklist son recomendaciones de trabajo que deben adaptarse a cada instalación.
