Quitar contenido mixto en WordPress tras activar SSL

El contenido mixto en WordPress aparece cuando tu web ya carga por HTTPS, pero todavía intenta servir algunos recursos por HTTP, como imágenes, hojas de estilo, scripts, fuentes o iframes. El resultado suele ser un candado roto, avisos del navegador o recursos bloqueados que pueden afectar al diseño y al funcionamiento.

En la mayoría de casos, se corrige localizando qué recursos HTTP siguen activos, actualizando URLs antiguas, revisando ajustes básicos de WordPress y limpiando todas las capas de caché. Aun así, no conviene aplicar cambios masivos sin copia de seguridad, porque el origen del problema puede estar en el theme, un plugin, una CDN, un constructor visual o incluso en la configuración del servidor o proxy.

Qué es el contenido mixto en WordPress y por qué aparece tras activar SSL

Cuando completas una migración a HTTPS WordPress o activas un certificado SSL, por ejemplo con Let’s Encrypt, WordPress puede funcionar en HTTPS pero conservar referencias antiguas en HTTP. Eso ocurre con frecuencia tras migraciones, cambios de dominio, restauraciones de copias o configuraciones mixtas entre WordPress, hosting, proxy y caché.

Las causas más habituales son imágenes insertadas con URL absoluta, CSS o JS cargados desde plugins, llamadas HTTP en el theme, fuentes externas sin HTTPS, contenido guardado dentro de builders y scripts de terceros no compatibles. El navegador detecta esas llamadas inseguras y puede bloquearlas total o parcialmente.

Cómo detectar qué recursos HTTP siguen cargando en tu web

Antes de tocar nada, identifica exactamente qué recurso está provocando el aviso. Lo más útil suele ser abrir la web en el navegador, revisar el candado y consultar la consola de desarrollo. Ahí normalmente se ve qué archivo, imagen, fuente, script o iframe intenta cargar por HTTP.

• Comprueba la página de inicio y también páginas internas, entradas y fichas si usas WooCommerce.
• Revisa la consola del navegador para ver los recursos bloqueados por el navegador.
• Anota si el problema viene de tu dominio, una CDN, una librería externa o un tercero.
• Valida si el aviso aparece solo para usuarios conectados o solo en algunas plantillas.

Este diagnóstico es importante porque no se resuelve igual una imagen antigua guardada en base de datos que un script hardcodeado en el tema o una fuente remota sin soporte HTTPS.

Solución rápida antes de tocar la base de datos o el tema

Empieza por lo básico y menos invasivo. En Ajustes > Generales, comprueba que la dirección de WordPress y la del sitio usan HTTPS. Si están mezcladas, WordPress puede seguir generando rutas antiguas.

Después, revisa si tu hosting, plugin de caché, proxy inverso o CDN están sirviendo versiones antiguas. Limpiar solo la caché de WordPress a veces no basta. Puede ser necesario purgar también caché del servidor, de Cloudflare si aplica, y del navegador.

En algunos entornos, también procede forzar HTTPS a nivel de servidor o configuración del sitio, pero no es una medida universal ni conviene aplicarla sin confirmar antes que el certificado, las redirecciones y los recursos externos están bien resueltos.

Buscar y reemplazar URLs HTTP en WordPress sin romper nada

Si el problema viene de URLs antiguas guardadas en contenido o ajustes, puede hacer falta un buscar y reemplazar. Hazlo solo con copia de seguridad previa y, si es posible, con una herramienta que respete datos serializados. Un reemplazo directo e indiscriminado en base de datos puede romper widgets, constructores o ajustes complejos.

Lo prudente suele ser sustituir la versión HTTP de tu propio dominio por la versión HTTPS, revisar el resultado y volver a validar la web. Si usas recursos externos, no conviene reemplazarlos a ciegas: antes hay que confirmar que el proveedor soporta HTTPS y que la URL correcta no ha cambiado.

Qué revisar en el theme, plugins, constructores visuales y código personalizado

Cuando el aviso persiste, revisa si hay HTTP en el theme, en snippets personalizados o en plugins. Es relativamente frecuente encontrar rutas fijas en archivos del tema, opciones del personalizador, widgets HTML, constructores visuales o campos personalizados.

• Imágenes añadidas manualmente con URL absoluta en contenido o bloques.
• CSS o JS cargados desde un plugin antiguo.
• Fuentes, iconos o librerías externas declaradas por HTTP.
• Embeds o iframes guardados dentro del builder.

Si desarrollas a medida, conviene revisar cómo se encolan scripts y estilos y evitar referencias hardcodeadas cuando WordPress puede generar la URL correcta de forma dinámica.

CDN, caché, fuentes, scripts externos e iframes: dónde suele esconderse el problema

Muchos casos de mixed content no están en WordPress como tal, sino en servicios externos. Una CDN con HTTPS mal configurada, una fuente remota servida por HTTP o un script de terceros antiguo pueden mantener el aviso aunque hayas corregido la base de datos.

También es habitual que la caché de WordPress o la optimización de archivos genere versiones antiguas de CSS y JS. Si usas minificación, combinación de archivos o reescritura de URLs, conviene desactivarlo temporalmente para aislar el origen.

Si necesitas una referencia oficial sobre navegación segura y contenido mixto, Mozilla mantiene documentación técnica verificable en MDN Web Docs.

Qué hacer si el contenido mixto sigue apareciendo después de los cambios

Si después de corregir URLs, limpiar cachés y revisar recursos externos el problema sigue apareciendo, toca validar la configuración completa: redirecciones, proxy, cabeceras, reglas del servidor y comportamiento del certificado. En algunos hostings, el sitio parece estar en HTTPS pero recibe variables inconsistentes cuando pasa por balanceador o CDN.

• Vuelve a revisar la consola tras cada cambio.
• Prueba en incógnito y desde otro dispositivo.
• Comprueba si el fallo solo afecta a ciertas URLs o plantillas.
• Desactiva temporalmente caché u optimización para confirmar el origen.

Los errores más frecuentes suelen ser dejar URLs absolutas en HTTP, olvidar cachés intermedias, cargar recursos externos inseguros o asumir que un plugin lo resolverá todo sin revisar el origen real. Como comprobación final, valida que el candado aparece en las páginas clave, que no hay recursos bloqueados y que imágenes, fuentes y scripts cargan por HTTPS. Si el aviso persiste, el siguiente paso razonable es una revisión técnica del entorno para localizar la referencia exacta sin poner en riesgo la web.