Contenido mixto en WordPress: cómo recuperar el candado

En pocas palabras: El candado SSL falla en WordPress por contenido mixto: la página carga por HTTPS pero pide imágenes, scripts o estilos por HTTP. Se arregla poniendo https:// en los dos campos de Ajustes Generales (Dirección de WordPress y del sitio) y reemplazando las URLs http en la base de datos.

El contenido mixto en WordPress aparece cuando tu página carga por HTTPS pero pide imágenes, scripts o estilos por HTTP, y el navegador deja de mostrar el candado completo aunque el certificado SSL esté bien instalado. Se arregla pasando las URLs a https en Ajustes y en la base de datos.

Según MDN, el contenido mixto es el de una página cargada por una conexión segura (HTTPS) que incluye recursos pedidos por HTTP u otro protocolo inseguro. En WordPress lo causan URLs viejas guardadas en entradas, widgets, opciones del tema o archivos CSS. Es un problema del contenido del sitio, no del certificado, y lo detecta el navegador de cada visitante.

Si el certificado está instalado y el sitio igual dice «No seguro», todavía no le eches la culpa al hosting.

¿Cómo detectar qué recursos cargan por HTTP en mi sitio WordPress?

Abrí la página que muestra el aviso, apretá F12 y mirá la pestaña Consola (en Chrome, también la pestaña Issues). Cada recurso inseguro aparece con su URL completa, así que no hay nada que adivinar. Probá al menos la home, una entrada, una página y un producto si tenés WooCommerce, porque cada plantilla carga cosas distintas.

Los avisos tienen esta forma (rutas de ejemplo, el texto exacto varía según navegador y versión):

Mixed Content: The page at 'https://tudominio.com/' was loaded over HTTPS, but requested an insecure image 'http://tudominio.com/wp-content/uploads/logo.png'. This content should also be served over HTTPS.

Mixed Content: The page at 'https://tudominio.com/' was loaded over HTTPS, but requested an insecure script 'http://tudominio.com/wp-content/themes/mi-tema/js/slider.js'. This request has been blocked; the content must be served over HTTPS.

Ojo con la diferencia: la imagen es algo que el navegador todavía puede rescatar, el script ya lo bloqueó y por eso el slider ni arranca. Para no revisar página por página, tenés varias herramientas:

• Consola y pestaña Issues de Chrome. Según web.dev, Chrome registra mensajes detallados en Issues y lista cada recurso inseguro con su estado de restricción.
• HTTPSChecker. Es un crawler de escritorio que MDN cita para recorrer el sitio y encontrar links inseguros.
• mcdetect. Herramienta de línea de comandos, también citada por MDN, que revisa el sitio de forma recursiva.
• Mixed Content Checker y Why No Padlock. Son verificadores online; MDN nombra el primero. Sirven para un chequeo rápido de una URL.
• Simulación de WP-CLI. Un wp search-replace con --dry-run te informa cuántas ocurrencias hay por tabla sin modificar nada (lo uso como «contador» antes de decidir si vale la pena reemplazar).

MDN también recomienda bloquear todo el contenido mixto en tu navegador para probar el sitio (Safari ya lo hace por defecto).

¿Por qué el contenido mixto en WordPress rompe el candado si el SSL está instalado?

El certificado SSL solo cifra la conexión con tu servidor. El candado depende de que todo lo que arma la página (imágenes, CSS, JS, fuentes) también llegue por HTTPS; si un solo recurso va por HTTP, el navegador lo marca.

Ponele un caso hipotético: instalás Let’s Encrypt, activás la redirección a https, abrís la home y sale «No seguro». El certificado está perfecto. Lo que falla es el logo que subiste en 2019 y que quedó guardado como http://tudominio.com/... dentro de un widget. Cubrimos ese tema en detalle en recursos de la comunidad de WordPress.

El riesgo es concreto. Según web.dev, esas peticiones son vulnerables a ataques on-path: un atacante puede rastrear usuarios, reemplazar contenido y, si el recurso es activo (un script, por ejemplo), tomar control de toda la página. Los avisos del navegador suelen llegar tarde, porque la petición insegura ya salió.

Contenido mixto activo vs. pasivo: ¿cuál bloquea el navegador?

El navegador bloquea el contenido activo (scripts, hojas de estilo, iframes) y suele intentar subir a https el pasivo (imágenes, audio, video). La especificación actual de MDN reemplazó esos nombres por «actualizable» y «bloqueable», y la diferencia define si tu sitio solo muestra un aviso o directamente se rompe.

Categoría (según MDN)	Qué incluye	Qué hace el navegador
Actualizable (antes «pasivo»)	<img> con src, imágenes CSS como background-image, <audio> y <video> con src, <source>	Cambia la petición de http a https. Si el recurso no existe por https, no carga.
Bloqueable (incluye el antes «activo»)	<script>, <link> (hojas de estilo), <iframe>, fetch(), XMLHttpRequest, <object>, fuentes web, <img> con srcset o <picture>	Bloquea y avisa en la consola.
Excepción: host con IP	<img src="http://93.184.215.14/image.png">	Se bloquea en vez de actualizarse.

Dos cosas que saco de esa tabla y que MDN no te dice así de directo. Primera: WordPress agrega srcset a las imágenes del contenido, y según MDN esas URLs no se actualizan, se bloquean. Si tu sitio estuvo en http, el tema puede mostrar una imagen «bien» por el src y fallar en pantallas donde el navegador elige otra del srcset. Segunda: MDN lista background-image como actualizable, pero también menciona que los url() de CSS en general son bloqueables, o sea que no conviene apoyarse en la actualización automática.

Cuando se bloquea un script o un CSS, el síntoma es visual: menús que no abren, sliders congelados, el layout hecho una sopa. Cuando solo falla una imagen, el sitio «anda» pero el candado no vuelve.

Error: la Dirección de WordPress y la del sitio siguen en http

Si en Ajustes > Generales alguna de las dos URLs empieza con http://, WordPress va a generar en http los scripts, estilos y rutas de uploads de todo el sitio. Es la primera causa a descartar, porque esos valores se usan en todo el código de WordPress.

Síntomas

Los campos «Dirección de WordPress (URL)» y «Dirección del sitio (URL)» muestran http://. En la consola aparecen decenas de avisos que apuntan a /wp-content/themes/ y /wp-includes/, es decir, archivos del propio core y del tema.

Causa

La instalación original se hizo en http y nadie actualizó esas dos opciones al activar el certificado. La documentación oficial de migración aclara que ambos valores deben incluir https:// y no llevar barra al final.

Solución paso a paso

1. Hacé un backup completo (archivos y base de datos). Con WP-CLI: wp db export backup-antes-de-https.sql.
2. Entrá a Ajustes > Generales, cambiá ambos campos a https://tudominio.com (sin barra final) y guardá. WordPress te va a pedir que vuelvas a iniciar sesión.
3. Si no podés entrar al panel, definí los valores en wp-config.php, arriba de la línea «That’s all, stop editing!»:

define( 'WP_HOME', 'https://tudominio.com' );
define( 'WP_SITEURL', 'https://tudominio.com' );

Tomalo como parche: según la misma documentación, no es «necesariamente la mejor solución» porque deja los valores fijos y ya no los vas a poder editar desde el panel. Otra vía es wp option update home 'https://tudominio.com' y lo mismo con siteurl.

4. Para forzar login y administración por SSL, agregá en wp-config.php:

define( 'FORCE_SSL_ADMIN', true );

5. Si el sitio está detrás de un proxy inverso o balanceador que termina el SSL, WordPress puede creer que la petición es http y entrar en bucle. El patrón habitual, que figura en la documentación sobre HTTPS, es avisarle con el header del proxy:

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https' ) {
 $_SERVER['HTTPS'] = 'on';
}

Resultado esperado: los archivos del core y del tema ya se piden por https, y los avisos que quedan son de contenido guardado en la base.

Cómo prevenirlo

Poné https en las dos URLs el mismo día que activás el certificado, antes de cargar contenido. Y si usaste el truco de update_option en functions.php, sacalo cuando el sitio vuelva a andar, como pide la documentación. Te puede servir nuestra cobertura de crear una landing page en WordPress.

¿Cómo reemplazar http por https en la base de datos de WordPress?

Con WP-CLI, corriendo wp search-replace 'http://tudominio.com' 'https://tudominio.com' --skip-columns=guid, primero con --dry-run y después sin él. Así actualizás entradas, metadatos, widgets y opciones del tema sin romper los datos serializados ni tocar el GUID.

Síntomas

Las URLs de Ajustes ya están en https, pero la consola sigue listando recursos como http://tudominio.com/wp-content/uploads/2021/05/banner.jpg dentro de entradas, páginas o widgets. Suele pasar en el contenido más viejo.

Causa

Cuando insertás una imagen o un link, WordPress guarda la URL absoluta tal como era en ese momento. Años después, esa URL con http sigue en post_content, en los metadatos, en las opciones de widgets y en los ajustes del tema. Cambiar las dos URLs de Ajustes no toca nada de eso.

Solución paso a paso

1. Backup de la base: wp db export backup-antes-del-reemplazo.sql. Guardalo fuera del servidor.
2. Simulá el reemplazo y mirá el informe por tabla:

wp search-replace 'http://tudominio.com' 'https://tudominio.com' --skip-columns=guid --dry-run

3. Si las cantidades tienen sentido, repetí el comando sin --dry-run. Si tu sitio responde también con www, corré una segunda pasada con http://www.tudominio.com.
4. Vaciá la caché de objetos con wp cache flush y recargá la página con F12 abierto.

Si no tenés acceso a WP-CLI, el plugin Better Search Replace hace lo mismo desde el panel y tiene opción de ejecución en simulación. Usala igual: el modo simulación existe justamente para que no descubras el problema en producción.

Una advertencia que ahorra disgustos: nunca hagas el reemplazo con un REPLACE() de SQL a ciegas, porque WordPress guarda muchos valores serializados (opciones de plugins, ajustes de widgets) con la longitud de cada string, y cambiar http por https agrega un carácter y los deja corruptos. La documentación del comando de WP-CLI está hecha para evitar eso, y además la columna GUID no se debe modificar (por eso el --skip-columns=guid).

Cómo prevenirlo

Antes de cualquier migración o cambio de protocolo, dejá el reemplazo con simulación como parte del checklist. Y si el sitio vive en un hosting WordPress como el de Donweb, revisá en el panel que el certificado esté emitido para el dominio con y sin www antes de empezar.

¿Sirve Really Simple SSL o hay que arreglarlo a mano?

Sirve para salir del paso, pero no corrige el origen del problema. Los plugins de este tipo redirigen a https y reescriben las URLs al vuelo cuando WordPress arma el HTML; las URLs viejas quedan en tu base de datos y en el código del tema. No lo verifiqué contra la última versión del plugin, así que revisá su documentación antes de instalarlo.

Mi postura: un plugin «mágico» de un clic está bien como cinta adhesiva mientras corregís la base. Como solución permanente, no. Cada capa de reescritura en tiempo real agrega trabajo a cada carga de página, y el día que lo desactivás reaparece todo lo que estaba escondido.

Si preferís la vía manual, hay dos refuerzos a nivel servidor. La redirección 301 en .htaccess (Apache):

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

Y la cabecera CSP upgrade-insecure-requests, que MDN describe como la que sube todas las peticiones a HTTPS, incluso el contenido bloqueable: En probar los cambios en un entorno staging profundizamos sobre esto.

Header always set Content-Security-Policy "upgrade-insecure-requests"

Eso sí: la cabecera es una red de seguridad, no una cura. Si el recurso externo no existe por https (un widget viejo de un tercero, por ejemplo), la petición va a fallar igual. Y la regla de .htaccess detrás de un proxy o CDN mal configurado es receta segura para un bucle de redirecciones, que es justo el próximo error.

Error: ERR_TOO_MANY_REDIRECTS con Cloudflare en modo Flexible o proxy inverso

Si apenas forzaste https el navegador muestra «Esta página te redirigió demasiadas veces», casi siempre el CDN o el proxy habla con tu servidor por HTTP, y WordPress responde redirigiendo a https una y otra vez. Se corrige poniendo el modo SSL del CDN en Full (o Full strict) con certificado válido en el origen.

Síntomas

ERR_TOO_MANY_REDIRECTS

Aparece después de activar la redirección a https (plugin, .htaccess o FORCE_SSL_ADMIN) en un sitio que pasa por Cloudflare u otro proxy. Puede afectar solo al wp-admin o a todo el sitio.

Causa

En el modo Flexible de Cloudflare, el visitante llega por https al CDN, pero el CDN le pide la página a tu servidor por http. Tu servidor ve una petición insegura, la redirige a https, el CDN vuelve a pedirla por http, y así hasta que el navegador se rinde. El mismo patrón pasa con cualquier proxy que termine el SSL y no avise.

Solución paso a paso

1. Instalá un certificado válido en tu servidor de origen (Let’s Encrypt alcanza). En el hosting WordPress de Donweb o en cualquier otro proveedor, el alta se hace desde el panel de hosting.
2. En el CDN, cambiá el modo SSL de Flexible a Full o Full (strict). Strict exige que el certificado de origen sea válido, y es lo recomendable.
3. Si por alguna razón no podés cambiar el modo, agregá el snippet de HTTP_X_FORWARDED_PROTO de la sección anterior en wp-config.php.
4. Purgá la caché del CDN y probá en una ventana de incógnito.

Cómo prevenirlo

Definí el modo SSL del CDN antes de activar cualquier redirección en WordPress, no después. Más sobre esto en opciones de autenticación en dos pasos.

¿Por qué sigue apareciendo el aviso de contenido mixto después de corregirlo?

Casi siempre es una caché que sigue sirviendo el HTML viejo (plugin de caché, servidor, CDN o navegador), o un recurso hardcodeado fuera de la base de datos: el CSS del tema, un constructor de páginas, un iframe o un script embebido. Primero vaciá las cachés; si el aviso persiste, buscá la URL en los archivos. Lo complementamos en comparativa entre Sucuri y Cloudflare.

Síntomas

Ya cambiaste Ajustes, ya hiciste el reemplazo en la base, y sin embargo en tu navegador el candado sigue roto, o se ve bien en tu compu y mal en la de un cliente. Subís la consola y aparece la misma URL http.

Causa

Subís la corrección, la probás en tu navegador, ves que la consola sigue marcando lo mismo, vaciás una caché pero no las otras, el CDN conserva la copia con http, el CSS generado por el constructor tiene rutas absolutas viejas y el tema hijo trae un url(http://...) en la hoja de estilos de hace años. Esa es la lista de sospechosos reales, en orden de probabilidad: Más contexto en corregir los enlaces rotos de tu sitio.

• Caché del plugin de caché. Guarda páginas HTML ya armadas, con las URLs viejas adentro.
• Caché del servidor y del CDN. Tienen su propia copia, independiente del plugin.
• CSS generado por constructores. Elementor y similares guardan archivos CSS con rutas absolutas.
• Tema hijo y hojas de estilo. Cualquier url(http://...) o <script src="http://..."> escrito a mano.
• Iframes y scripts de terceros. Un mapa, un video o un chat pegado hace años con http://.

Solución paso a paso

1. Vaciá la caché del plugin de caché desde su panel y, si tenés caché de objetos, corré wp cache flush.
2. Purgá la caché del servidor (desde el panel de tu hosting) y la del CDN.
3. Abrí el sitio en una ventana de incógnito y recargá con Ctrl+F5, con la consola abierta.
4. Buscá URLs hardcodeadas en el tema desde SSH (o con el buscador de tu editor):

grep -rn "http://" wp-content/themes/tu-tema-hijo

5. Si usás Elementor, regenerá el CSS (Elementor > Herramientas, opción de regenerar CSS y datos) y revisá su herramienta de reemplazo de URLs.
6. Para los iframes y scripts externos, cambiá http:// por https:// y probá que el recurso cargue. MDN lo recomienda: usar la versión https de los recursos de terceros siempre que exista. Si el tercero no tiene https, tenés que reemplazarlo o sacarlo.

Cómo prevenirlo

Dejá escrito en tu checklist de publicación el orden: reemplazar, vaciar todas las cachés, probar en incógnito. Y evitá pegar snippets de terceros sin revisar el protocolo.

Tabla de diagnóstico rápido

Si ya sabés qué te pasa, buscá tu caso acá. Ninguna de estas causas depende de una versión puntual de WordPress; son problemas de configuración y de contenido guardado.

Síntoma	Causa probable	Solución rápida	Versiones afectadas
Archivos del tema y del core cargan por http	Las URLs de Ajustes > Generales están en http	Cambiar ambas a https, sin barra final	Cualquier versión
Imágenes de entradas viejas por http	URLs absolutas guardadas en la base	wp search-replace con --skip-columns=guid y --dry-run	Cualquier versión
Imágenes fallan solo en ciertas pantallas	srcset con URLs http (se bloquean, no se actualizan)	Reemplazo en la base de datos	Cualquier versión con imágenes responsivas
Script o CSS bloqueado, diseño roto	Recurso activo cargado por http	Corregir la URL en tema, plugin o builder	Cualquier versión
ERR_TOO_MANY_REDIRECTS	CDN en Flexible o proxy sin header de protocolo	Modo Full/Full (strict) o snippet de HTTP_X_FORWARDED_PROTO	No depende de WordPress
El aviso persiste tras corregir	Caché de plugin, servidor, CDN o navegador	Vaciar todo y probar en incógnito	No depende de WordPress

Cuándo contactar soporte

Pedí ayuda si el aviso ya no es de contenido mixto sino del certificado, si el problema desaparece al desactivar un plugin que no controlás, o si la consola no muestra ninguna URL http pero el candado sigue roto. Un error como NET::ERR_CERT_COMMON_NAME_INVALID o un certificado vencido es de tu proveedor de hosting, no de WordPress.

Antes de abrir el ticket, juntá esto:

• URL exacta de la página afectada y una captura de la consola con los avisos.
• Valores de siteurl y home (wp option get siteurl y wp option get home).
• Versión de WordPress y PHP, tema activo y lista de plugins.
• Capas de caché y CDN que usás, con el modo SSL configurado.
• Qué cambiaste y cuándo, incluidos los comandos de reemplazo que corriste.

Para temas de WordPress en general, el foro oficial de soporte sirve; para algo de un plugin, su propio foro; para certificados y configuración del servidor, el soporte de tu hosting.

Preguntas Frecuentes

¿Por qué mi WordPress no muestra el candado si ya instalé el certificado SSL?

Porque la página carga algún recurso (imagen, script, hoja de estilo) por HTTP, y el navegador lo trata como contenido mixto. El certificado cifra la conexión con el servidor, pero el candado depende de que todo lo que forma la página también sea seguro.

¿Cómo encuentro qué imagen o script está cargando por HTTP en WordPress?

Abrí la consola del navegador con F12 y buscá los avisos «Mixed Content»: cada uno incluye la URL http exacta. También podés usar herramientas como HTTPSChecker o mcdetect, que MDN menciona, para recorrer el sitio completo.

¿Cómo cambio todas las URLs de http a https en WordPress sin romper el sitio?

Hacé un backup, corregí las dos URLs en Ajustes > Generales y usá wp search-replace con --skip-columns=guid, primero en --dry-run. Ese comando maneja los datos serializados, algo que un reemplazo SQL manual no hace.

¿Es necesario un plugin como Really Simple SSL para arreglar el contenido mixto?

No es necesario, pero puede servir como parche rápido. Lo definitivo es corregir las URLs en la base de datos y en el código del tema; un plugin que reescribe al vuelo tapa el síntoma sin limpiar el origen.

¿Por qué sigue apareciendo el aviso de contenido mixto después de arreglarlo?

Lo más probable es una caché (del plugin, del servidor, del CDN o del navegador) que sigue sirviendo la versión vieja. Vaciá todas, probá en incógnito y, si persiste, buscá URLs http hardcodeadas en el CSS del tema, en el constructor de páginas o en iframes de terceros.

Conclusión

La causa más frecuente del candado roto con un SSL bien instalado es el contenido mixto en WordPress: URLs con http guardadas en la base de datos o en el tema. Lo que resuelve la mayoría de los casos es la secuencia de siempre: backup, URLs de Ajustes en https, wp search-replace con simulación previa y limpieza de todas las cachés.

Si después de eso la consola sigue marcando algo, buscá el recurso en el CSS del tema, el constructor o los embebidos de terceros. Y si el problema es un bucle de redirecciones o el certificado mismo, el siguiente paso es revisar el modo SSL del CDN o hablar con el soporte de tu hosting con los datos de la sección anterior. Por mi parte, ahorrate el plugin si podés: arreglar la base no te deja deuda.

Fuentes

• Migrating WordPress, Advanced Administration Handbook – documentación oficial sobre cambio de URL del sitio y wp-config.php
• HTTPS en WordPress, Advanced Administration Handbook – documentación oficial sobre SSL y proxies
• wp search-replace, WP-CLI – referencia del comando de reemplazo en la base de datos
• Mixed content, MDN – tipos de contenido mixto, comportamiento del navegador y herramientas
• What is mixed content?, web.dev – contenido activo y pasivo, y riesgos asociados