Quitar contenido mixto en WordPress tras activar SSL

Qué es el contenido mixto y por qué aparece al activar SSL

Cuando activa SSL y su web pasa a cargarse por HTTPS, el navegador espera que todo lo que aparece en esa página también se entregue por HTTPS. Si parte de los recursos se siguen cargando por HTTP, el navegador detecta una mezcla de contenido seguro e inseguro. A esto se le llama contenido mixto o mixed content. El resultado típico es un candado con aviso, una advertencia de “no es seguro” o incluso recursos que se bloquean y dejan la web a medias, con estilos que no cargan, imágenes rotas o scripts que no funcionan.

El contenido mixto no suele ser un problema del certificado en sí, sino de URLs antiguas que se han quedado “pegadas” en algún sitio. Lo habitual es que WordPress lleve años funcionando con HTTP y, al migrar a HTTPS, sigan existiendo enlaces absolutos a recursos con http://. Esa ruta puede estar en el editor visual, en widgets, en un constructor tipo Elementor, en un ajuste de un plugin, en el tema, en una hoja de estilos, en un archivo JavaScript o dentro de la base de datos. También ocurre con recursos externos, por ejemplo si su web carga una fuente, un iframe, un script de analítica o un recurso de una CDN que solo está disponible por HTTP.

Hay dos tipos principales de contenido mixto. El pasivo suele ser imágenes o vídeo, y normalmente genera avisos pero puede seguir cargando. El activo incluye scripts, iframes, CSS y otros elementos que pueden permitir interferencias y por eso el navegador suele bloquearlos. En WordPress, los más molestos suelen ser los CSS y JS. Si fallan, se rompe el diseño o se desactivan funciones, por ejemplo el carrito de WooCommerce, un formulario o un menú desplegable.

La buena noticia es que suele resolverse con un proceso ordenado: detectar el recurso exacto, localizar de dónde sale y sustituir la URL por una segura. El error frecuente es aplicar múltiples “parches” sin saber el origen y terminar con bucles, redirecciones incorrectas o problemas de rendimiento.

Cómo saber si su WordPress tiene contenido mixto

El primer paso es confirmar qué recursos están entrando por HTTP. No conviene adivinar. Lo más fiable es usar las herramientas del navegador. En Chrome o Edge, abra su web, haga clic derecho y elija “Inspeccionar”. Después, vaya a la pestaña “Consola” y a “Red”. Si hay contenido mixto, verá avisos del tipo “Mixed Content” indicando la URL exacta que se intentó cargar por HTTP. Esa línea es oro, porque le dice qué archivo está causando el problema y en qué página ocurre.

Revise varias páginas, no solo la home. Es frecuente que el aviso aparezca solo en páginas de producto, en el checkout, en una landing antigua o en una plantilla concreta. Si su sitio es grande, el problema puede repetirse en cientos de entradas por un patrón común, como imágenes insertadas con URL absoluta. En ese caso, le interesa encontrar el origen y corregirlo de forma masiva, pero siempre con copia de seguridad previa.

Además de la consola, otra pista clara es el candado del navegador. Si aparece un icono de advertencia, haga clic y consulte el detalle. A veces muestra qué tipo de recurso se bloquea. Si su sitio usa un firewall o CDN, revise también la configuración de “modo flexible” o “full”. En algunos proveedores, un modo intermedio puede hacer que el navegador vea una mezcla de esquemas si su WordPress cree que está en HTTP mientras el proxy sirve HTTPS.

Un método adicional es mirar el código fuente de la página. Busque “http://” y verá si hay recursos estáticos insertados. Esto ayuda cuando el aviso no aparece como error, pero sí como degradación de seguridad. También es útil cuando el recurso mixto no se carga y por eso no queda rastro en “Red”. En WordPress, los casos típicos son: enlaces de imágenes en el contenido, URLs de fondo en CSS, scripts de terceros insertados en el header y llamadas desde plugins de optimización o analítica.

Con la lista de URLs afectadas, ya puede decidir la estrategia: si son pocas, se corrige a mano. Si son muchas, se hace un reemplazo controlado o se ajustan opciones para que WordPress genere URLs relativas o seguras. Lo importante es empezar por la detección, porque el contenido mixto es un síntoma, no una causa única.

Solución rápida en WordPress y en el servidor sin romper nada

Antes de tocar base de datos o editar código, asegúrese de que WordPress “sabe” que su sitio está en HTTPS. Revise dos ajustes: la Dirección de WordPress (URL) y la Dirección del sitio (URL) en Ajustes, General. Ambas deberían empezar por https://. Si siguen en http://, WordPress seguirá generando enlaces inseguros en menús, assets y formularios, y los plugins heredarán esa configuración. Cambiarlo suele ser inmediato, pero hágalo con cuidado y con acceso al panel y al hosting, por si se queda fuera por un bucle de redirección.

Después, confirme que existe una redirección 301 desde HTTP a HTTPS en el servidor o en su proxy. Si la redirección no existe, los usuarios pueden entrar por HTTP y crear sesiones inconsistentes, sobre todo en WooCommerce. Si ya la tiene, verifique que no hay doble redirección, por ejemplo de www a no www y luego de HTTP a HTTPS en pasos separados. Lo ideal es una redirección única y estable.

Si usa un CDN o un proxy, revise el modo SSL. Un error clásico es que el CDN sirva HTTPS al usuario, pero se conecte al servidor por HTTP. En ese escenario, WordPress puede “creer” que está en HTTP, generando recursos inseguros. Normalmente se soluciona configurando el modo que cifra también hasta el servidor origen, y activando la cabecera correcta para que WordPress detecte HTTPS. Si no lo hace, verá contenido mixto persistente aunque todo parezca bien.

Otra acción rápida es limpiar cachés. Limpie la caché del plugin de caché, la caché del CDN si aplica, y la caché del navegador. Muchos avisos de contenido mixto son “fantasmas” de una versión anterior de CSS o JS minificado que contiene URLs en HTTP. Si no limpia, se quedará mirando un problema que ya arregló en origen.

Por último, evite instalar tres plugins “arregla SSL” a la vez. Algunos fuerzan reescrituras en runtime y ocultan el problema, pero no lo corrigen. Eso puede dificultar el diagnóstico y, en ocasiones, provocar conflictos con optimizadores o con el editor. Si necesita una solución rápida por urgencia, úsela como medida temporal, pero mantenga la intención de corregir la causa real, que suele estar en una URL fija o en un recurso externo.

Buscar y reemplazar URLs HTTP en base de datos, cuándo y cómo

Si el contenido mixto afecta a muchas páginas, lo más eficiente suele ser un reemplazo controlado en la base de datos. En WordPress, gran parte del contenido vive en tablas como posts, postmeta y options. Allí es donde se guardan enlaces a imágenes, shortcodes, bloques, ajustes de plugins y configuraciones del tema. Cuando una migración a HTTPS se hace tarde, es común que existan cientos o miles de apariciones de http:// en el contenido.

Ahora bien, este paso tiene una regla de oro: haga copia de seguridad completa antes de tocar nada. Si usa un plugin de reemplazo, elija uno que gestione serialización, porque WordPress guarda algunos valores serializados. Si hace un reemplazo bruto con SQL o con un editor que no entiende serialización, puede romper ajustes y dejar el sitio inestable. Por eso, la herramienta importa tanto como el proceso.

La forma más segura es ejecutar un “dry run” o prueba previa, si la herramienta lo permite. Primero identifique el dominio exacto. Por ejemplo, si antes era http://ejemplo.com, el reemplazo típico es hacia https://ejemplo.com. Si su sitio cambió además de dominio o de www, planifique ese cambio en una secuencia coherente. Evite mezclar varios reemplazos en un mismo paso si no tiene experiencia, porque luego será difícil aislar el origen de un error.

Tenga en cuenta que no todo debe convertirse a HTTPS. Si hay recursos externos que solo funcionan en HTTP, convertirlos a HTTPS los romperá. Lo ideal es revisar la lista de URLs mixtas detectadas por la consola. Si son mayoritariamente internas, el reemplazo masivo encaja. Si son externas, conviene una corrección selectiva.

Tras el reemplazo, vuelva a guardar enlaces permanentes desde Ajustes, Enlaces permanentes (sin necesidad de cambiar nada, solo guardar) para regenerar reglas. Luego, regenere cachés y verifique varias páginas. Si el problema persiste, probablemente la URL está en un archivo del tema o en un script, no en la base de datos. Esa distinción le ahorra horas.

Recursos pegados en el tema, maquetadores y código personalizado

Cuando el contenido mixto no se resuelve con ajustes ni con reemplazos, suele estar en el tema o en código personalizado. Esto incluye archivos header, footer, functions, plantillas, hojas de estilos, scripts y widgets personalizados. Un ejemplo frecuente es un script insertado manualmente para analítica, chat, mapas o un píxel publicitario con una URL en HTTP. Otro caso típico son imágenes de fondo en CSS, definidas como background-image con una ruta absoluta http://.

Si utiliza un maquetador, puede haber dos niveles: el contenido visible que está en la base de datos, y el contenido que el maquetador inyecta desde plantillas globales o ajustes. Elementor, por ejemplo, guarda parte en postmeta y parte en plantillas. Otros constructores guardan en tablas propias. Por eso, si el reemplazo masivo no lo detectó, hay que buscar dentro de la configuración del constructor.

Otro punto delicado es cuando el tema usa funciones que construyen URLs de manera incorrecta. Por ejemplo, si en lugar de usar funciones de WordPress para obtener la URL del sitio, está concatenando cadenas y asumiendo http://. Esto ocurre en temas antiguos o muy personalizados. En ese caso, la solución no es solo reemplazar la URL, sino corregir la forma de generar enlaces para que respeten el esquema actual.

Si su sitio tiene código en un plugin propio o en snippets, revise inserciones en el head. Muchos administradores han pegado scripts hace años. Hoy, esos scripts deben apuntar a HTTPS. Si el proveedor del script ofrece una URL “protocol relative” o un enlace que ya es HTTPS, úselo. Si el proveedor no soporta HTTPS, plantéese sustituir ese servicio, porque mantenerlo en HTTP compromete el nivel de seguridad del sitio y genera avisos persistentes.

Por último, tenga cuidado con soluciones que reescriben contenido en cada carga. Pueden esconder el síntoma, pero aumentan carga y complican el mantenimiento. En un WordPress con tráfico, conviene que el contenido esté correcto en origen, no en un parche que corre en cada solicitud.

Plugins y recursos de terceros, CDN, fuentes, tracking y iframes

Una parte importante del contenido mixto no viene de su dominio, sino de terceros. Es habitual que un plugin inserte un script externo, una librería, una fuente, un iframe o un recurso de marketing. Si ese recurso se carga por HTTP, el navegador lo marcará como mixto aunque su WordPress esté perfecto. Por eso, cuando vea la URL en la consola, fíjese en el dominio. Si no es el suyo, el foco cambia.

Con CDNs sucede algo particular. Puede que usted esté sirviendo imágenes desde una CDN con HTTP configurado, o que un plugin de optimización esté reescribiendo rutas hacia un dominio CDN antiguo. La solución suele pasar por revisar el plugin de CDN, el “pull zone” o la configuración de “rewrite” para que apunte a HTTPS. En algunos casos, la CDN soporta HTTPS pero requiere activar el certificado o usar un subdominio específico. Si el recurso no existe por HTTPS, no hay forma limpia de evitar el aviso salvo dejar de usar ese recurso.

Las fuentes son una fuente clásica de incidencias. Si carga Google Fonts o una fuente propia desde un servidor externo, asegúrese de que todas las URLs de CSS y archivos woff2 se sirven por HTTPS. Lo mismo aplica a iconos, librerías JavaScript y assets de frameworks. Los avisos de “blocked mixed content” en CSS suelen romper el diseño de manera evidente, con tipografía por defecto y saltos de layout.

En tracking y marketing, revise scripts de analítica, píxeles y etiquetas. Algunos se insertan desde el plugin del proveedor. Otros se pegan en un campo de “Header scripts”. Asegúrese de que el script sea HTTPS y, si el proveedor ofrece un código actualizado, use el oficial. Mantener scripts viejos es una fuente recurrente de problemas.

En iframes, por ejemplo mapas, calendarios o reproductores, el atributo src debe ser HTTPS. Si el iframe apunta a HTTP, el navegador puede bloquearlo y su página se quedará con un hueco vacío. Si el proveedor no ofrece iframe seguro, conviene migrar a otro servicio, porque la alternativa es degradar la seguridad del sitio de forma permanente.

Casos frecuentes: WooCommerce, Elementor y contenidos antiguos

En WooCommerce, el contenido mixto no solo es un aviso visual. Puede afectar a la confianza del usuario y, en algunos casos, a la funcionalidad. Si el checkout carga scripts por HTTP, el navegador puede bloquearlos y fallar validaciones, métodos de pago o el proceso de finalizar compra. Además, si hay cookies de sesión y redirecciones inconsistentes entre HTTP y HTTPS, verá carritos que se vacían, usuarios que se desloguean o pagos que se quedan en bucle.

Revise que las páginas clave de WooCommerce estén forzadas a HTTPS y que el sitio no permita servir checkout por HTTP. También compruebe integraciones de pasarela, porque algunas insertan scripts externos. Si el aviso de contenido mixto aparece solo en el checkout, es una señal clara de que la pasarela, un script antifraude o un plugin de marketing es el origen.

Con Elementor y otros constructores, el problema típico es que el constructor guarda enlaces absolutos en widgets, botones, fondos y galerías. Una migración a HTTPS puede dejar esos enlaces antiguos. Aquí suele ayudar una combinación: reemplazo controlado en base de datos y, después, regenerar CSS de Elementor y limpiar cachés. Si no regenera, Elementor puede seguir sirviendo un CSS cacheado que contiene URLs antiguas en HTTP.

Los contenidos antiguos son el tercer gran caso. Entradas de hace años con imágenes insertadas por URL completa, o copias de contenido pegado desde otro editor. Esto produce apariciones dispersas de http:// en páginas concretas. En esos casos, un reemplazo masivo funciona, pero también puede dejar restos si el contenido está embebido en shortcodes o en campos personalizados. Si el problema está en una sola landing, quizá es más rápido editar esa página y sustituir manualmente el recurso.

Finalmente, revise la biblioteca de medios. En teoría, WordPress debería servir los adjuntos con la URL actual del sitio, pero si los insertó manualmente o si hubo migraciones intermedias, puede haber rutas absolutas antiguas guardadas en el contenido. Una señal típica es que, al ver el HTML del post, las imágenes tienen src con http://. Cambiar la URL del sitio y limpiar cachés no lo arregla, porque ese src está en el contenido. Es ahí donde un reemplazo controlado suele ser la solución definitiva.

Caché, minificación y optimizadores: cuando el problema no es real

Los plugins de caché y optimización son una causa habitual de confusión. Puede que usted ya haya corregido una URL en el contenido, pero el navegador siga mostrando contenido mixto porque está viendo un CSS o JS minificado antiguo que aún referencia HTTP. También ocurre cuando el plugin combina archivos y genera un archivo cacheado con rutas absolutas. Si ese archivo no se regenera, el aviso persistirá.

En estos casos, el síntoma es que usted busca en el contenido y no encuentra el HTTP, pero la consola sigue mostrándolo. La solución suele ser limpiar todas las capas de caché: plugin, servidor, CDN y navegador. A veces incluso hay caché en el proveedor de hosting. Si usa un sistema de optimización con minificación, pruebe temporalmente a desactivar la minificación y comprobar si el contenido mixto desaparece. Si desaparece, ya sabe que el origen es el archivo generado, no el contenido original.

Los optimizadores de imágenes también pueden intervenir. Si reescriben URLs hacia un dominio distinto para servir WebP, asegúrese de que ese dominio tiene HTTPS y de que el plugin lo usa. Si no, terminará con imágenes que se cargan por HTTP. En ocasiones, el dominio de imágenes se gestiona desde un ajuste de “CDN” dentro del plugin. Revise ese campo con calma.

Otro punto es el lazy load. Algunos sistemas inyectan data-src con HTTP mientras el src es HTTPS, o al revés. El navegador puede seguir marcándolo como mixto según cómo se ejecute el script. Esto se detecta mirando el HTML final renderizado, no solo el código fuente. Si el HTML renderizado contiene HTTP, debe corregir la configuración del plugin de lazy load o del optimizador.

Por último, si usa un sistema de caché por página a nivel de servidor, tenga presente que puede estar sirviendo versiones antiguas a visitantes no logueados. Usted, como administrador, puede ver una versión distinta y pensar que está arreglado. Por eso, verifique siempre en una ventana de incógnito después de limpiar cachés. Así evita falsas conclusiones.

HSTS, redirecciones 301 y SEO después de pasar a HTTPS

Una vez corregido el contenido mixto, toca consolidar el cambio a HTTPS. Aquí entran redirecciones 301, canonicals, sitemaps y, en ciertos casos, HSTS. El objetivo es que buscadores y usuarios solo conozcan una versión: la HTTPS. Si conviven ambas, pueden aparecer duplicados, problemas de indexación y señales divididas, además de reaparición de recursos mixtos por entradas antiguas.

A nivel SEO, lo más importante es que cada URL HTTP redirija a su equivalente HTTPS con 301. Además, su web debe emitir canonicals en HTTPS, y el sitemap debería listar solo HTTPS. Si usa plugins SEO, normalmente esto se ajusta al cambiar la URL del sitio, pero conviene revisar. En proyectos con muchas URLs, estos detalles marcan la diferencia en estabilidad.

HSTS es una política que indica al navegador que, durante un tiempo, debe usar HTTPS siempre para ese dominio. Es útil para seguridad, pero exige estar seguro de que todo funciona bien en HTTPS. Si activa HSTS cuando aún hay subdominios sin certificado o recursos internos que se sirven por HTTP, puede provocar errores difíciles de depurar. Por eso, HSTS es el paso final, no el inicial.

Revise también enlaces internos y recursos internos. Aunque las redirecciones 301 lleven de HTTP a HTTPS, tener enlaces internos en HTTP es una mala práctica. Añade redirecciones innecesarias, ralentiza y mantiene la puerta abierta a incidencias. Lo ideal es que todo apunte directamente a HTTPS.

Finalmente, monitorice durante unos días. El contenido mixto puede reaparecer cuando se activa un plugin nuevo, se cambia un widget o se pega un script en una campaña. Tener un procedimiento de revisión, al menos en páginas clave, le ahorrará sorpresas. En sitios de captación o ecommerce, una pequeña advertencia de seguridad puede impactar en la conversión más de lo que parece.

Preguntas frecuentes

Si su objetivo es quitar contenido mixto en WordPress tras activar SSL de manera estable, piense en ello como una limpieza: detectar, corregir origen, limpiar cachés y consolidar HTTPS con redirecciones correctas. Con ese enfoque, el aviso del navegador deja de ser un misterio y se convierte en un checklist controlable.