Contenido mixto en WordPress. Cómo solucionarlo.
Tu web utiliza HTTPS, pero una imagen, un script o una fuente todavía se solicita por HTTP. Aprende a encontrar el recurso exacto, corregirlo sin romper WordPress ni Elementor y comprobar que el problema ha desaparecido.
no basta.
Page loaded over HTTPS
but requested:
http://ejemplo.com/app.js
↳ blocked by browser
¿Cómo solucionar el contenido mixto en WordPress?
Un error de contenido mixto (mixed content) aparece cuando una página servida por HTTPS intenta cargar un recurso mediante HTTP. Para corregirlo, identifica en la consola del navegador qué URL es insegura, comprueba que dispone de una versión HTTPS y sustituye su referencia en el origen: ajustes de WordPress, Elementor, base de datos, tema o plugin. Después, limpia las cachés y repite la prueba.
Si el problema apareció después de instalar un certificado SSL, cambiar de dominio o migrar el hosting, empieza por Ajustes → Generales y Elementor → Editor → Herramientas → Reemplazar URL. No hagas un reemplazo global de cualquier http:// sin limitarlo a un dominio verificado.
Antes de tocar la web: crea una copia verificable de archivos y base de datos, confirma que las URLs de destino funcionan por HTTPS y, si es una tienda o una web crítica, prueba primero en staging. HTTPS instalado no significa que todos los recursos se sirvan por HTTPS.
Qué es el contenido mixto y por qué rompe una web.
El navegador protege la página HTTPS impidiendo o transformando determinadas solicitudes HTTP. Las reglas varían según el recurso: por eso a veces «solo» falta una tipografía y otras veces deja de funcionar un formulario, una animación o el propio editor.
Imágenes y parte del contenido multimedia
Los navegadores actuales pueden actualizar automáticamente determinadas peticiones de imágenes, audio y vídeo de HTTP a HTTPS. Si el servidor no ofrece ese archivo por HTTPS, puede fallar. No todas las imágenes entran en esta categoría: srcset, picture o URLs con IP tienen reglas particulares.
JavaScript, CSS, fuentes e iframes
Los recursos que pueden afectar al comportamiento o presentación de la página, como scripts, hojas de estilo, fuentes web, iframes y peticiones fetch, normalmente se bloquean si se piden por HTTP desde un contexto seguro. El síntoma puede parecer un fallo del plugin, pero la causa es la URL.
Una petición bloqueada no se arregla vaciando la caché si la referencia HTTP original sigue existiendo.
Ejemplos reales de sintaxis que puede causar el error
| Recurso | Ejemplo dentro de una página HTTPS | Comportamiento habitual | Qué revisar |
|---|---|---|---|
| Imagen | <img src="http://.../foto.jpg"> | Puede actualizarse | Medios, contenido, fondos |
| Script JS | <script src="http://.../app.js"> | Bloqueado | Plugin, tema, GTM, widget |
| Hoja CSS | <link href="http://.../style.css"> | Bloqueada | Cabecera, CSS generado |
| Fuente web | url('http://.../font.woff2') | Bloqueada | Elementor, CSS @font-face |
| Iframe | <iframe src="http://..."> | Bloqueado | Embeds, editor, servicios externos |
| Imagen responsive | srcset="http://.../img.webp" | Puede bloquearse | srcset, picture, plugins de imagen |
Tabla orientativa basada en MDN. Una referencia HTTP dentro de un texto, enlace de navegación o comentario no implica necesariamente una solicitud de contenido mixto: importa cómo y desde dónde se solicita el recurso.
¿Es lo mismo que no tener SSL? No. Si el documento principal se carga mediante HTTP, el problema es que la página no usa HTTPS. Si el documento sí es HTTPS pero intenta pedir un recurso HTTP, hablamos de contenido mixto. Un certificado caducado, un error NET::ERR_CERT_... o un CORS error pueden producir síntomas parecidos, pero requieren un diagnóstico diferente.
Cómo detectar contenido mixto en menos pasos y con más precisión.
Lo más útil es saber qué archivo se ha pedido por HTTP y qué componente hizo esa solicitud. Para eso no necesitas instalar un comprobador SSL externo ni compartir accesos de WordPress.
Ejemplo visual de un error de consola
CAPTURA RECREADA · NO REALConsole | Default levels | Filter ⚠ Mixed Content: The page at 'https://ejemplo.com/' was loaded over HTTPS, but requested an insecure script 'http://ejemplo.com/wp-content/plugins/demo/app.js'. This request has been blocked; the content must be served over HTTPS. index:84
La interfaz y el texto exactos cambian según la versión del navegador. Aquí lo importante es el recurso HTTP y el archivo o línea que lo introduce.
Encuentra la URL insegura
En Chrome: abre la página, pulsa F12 (o Ctrl+Mayús+J), selecciona Console y recarga. Busca Mixed Content, blocked o automatically upgraded. También puedes usar Issues (Problemas) para ver los recursos afectados.
Encuentra quién solicita el recurso
En Network (Red), recarga con el registro abierto. Filtra por la URL o por el esquema http y revisa la columna Initiator. En Security, Chrome puede mostrar orígenes no seguros y enlazarte a sus solicitudes.
¿Dónde se suele esconder la URL HTTP en WordPress?
| Ubicación probable | Indicio en la consola o en Network | Primera acción segura |
|---|---|---|
| Biblioteca / entrada | /wp-content/uploads/2024/... | Comprobar media, contenido y URL histórica. |
| Elementor | /uploads/elementor/css/... o CSS personalizado | Reemplazar URL y limpiar archivos generados. |
| Plugin | /wp-content/plugins/nombre/... | Identificar plugin e inspeccionar su configuración. |
| Tema | /wp-content/themes/nombre/... | Revisar opciones del tema o código hijo. |
| Servicio externo | Dominio de analítica, widget, chat o CDN | Verificar HTTPS del proveedor; sustituir integración. |
| Proxy / Cloudflare | URLs HTTP reaparecen pese al cambio | Revisar URL base, detección HTTPS y caché de origen. |
Diagnóstico guiado y analizador local de URLs HTTP.
Selecciona tu síntoma o pega una parte del HTML, CSS o mensaje de consola. El analizador detecta posibles referencias HTTP y orienta el siguiente paso. No rastrea tu web, no comprueba certificados ni envía datos a ningún servidor. No pegues contraseñas, cookies ni información privada.
¿Qué está fallando?
La recomendación no modifica WordPress. Úsala para priorizar dónde investigar, no como diagnóstico definitivo.
Ruta inicial: medios y Elementor
Busca la imagen HTTP exacta en Console; comprueba HTTPS, revisa la URL guardada en Elementor y limpia los CSS generados.
Pega código o un aviso de consola
Procesamiento exclusivamente en el navegador. Límite de 80.000 caracteres; máximo 40 coincidencias visibles.
Sin análisis todavía
El detector busca cadenas que empiezan por http://. Después debes comprobar si son recursos realmente solicitados desde una página HTTPS.
Interpretación: una URL HTTP dentro de un enlace de navegación, un comentario, un log o una muestra de código no prueba por sí sola contenido mixto. El veredicto real lo da la solicitud de red y su contexto.
Cómo corregir el contenido mixto en WordPress paso a paso.
Este orden reduce cambios innecesarios: primero confirma HTTPS, después arregla la URL que genera el aviso y finalmente limpia archivos y cachés. El procedimiento cubre la mayoría de migraciones HTTP → HTTPS sin convertir cada error en un problema de servidor.
Crea una copia de seguridad y localiza el origen
Guarda base de datos y archivos, verifica que puedes restaurarlos y apunta tres datos: URL pública de la página, URL exacta del recurso HTTP y Initiator que aparece en Network. Si la web vende o recibe formularios, usa staging y revisa una ventana de mantenimiento.
No hagas búsqueda y reemplazo sobre toda la base de datos sin saber qué dominio hay que modificar: puedes estropear integraciones, enlaces externos o datos serializados.
Verifica certificado y direcciones de WordPress
Abre https://tudominio.com y comprueba que el certificado es válido para ese host. En WordPress → Ajustes → Generales, revisa Dirección de WordPress (URL) y Dirección del sitio (URL). En una instalación típica en la raíz, ambas usan el HTTPS correcto y su ruta correspondiente; si WordPress vive en una subcarpeta, pueden diferir legítimamente.
Si los campos están bloqueados, pueden venir de WP_HOME y WP_SITEURL en wp-config.php. Modifica estas constantes solo si controlas el servidor y tienes copia. Documentación oficial de ajustes ↗.
Corrige la URL HTTP que aparece en el recurso
Si pertenece a tu dominio, confirma que la misma ruta existe en HTTPS y cambia la referencia que la genera. Por ejemplo, una imagen insertada con http://tudominio.com/wp-content/uploads/foto.jpg debería apuntar a https://tudominio.com/wp-content/uploads/foto.jpg si esa URL segura responde correctamente.
Si la URL aparece en un bloque HTML, CSS personalizado, cabecera del tema o ajuste de un plugin, corrígela allí. Si es un recurso externo, no reemplaces a ciegas: prueba el endpoint HTTPS de ese proveedor y, si no existe, elimina o sustituye la integración.
Si usas Elementor, reemplaza URLs y limpia archivos generados
En las versiones documentadas de 2026, entra en Elementor → Editor → Herramientas → Reemplazar URL. Sustituye la dirección antigua http://tudominio.com por https://tudominio.com tras comprobar el destino. Después entra en General → Clear Files & Data / Borrar archivos y datos y guarda los cambios.
El nombre exacto del menú puede variar según la versión. Esta herramienta puede reparar referencias guardadas en diseños y archivos relacionados; Elementor recomienda también limpiar las cachés de WordPress, servidor y CDN. Guía oficial de Elementor, mayo de 2026 ↗.
Si quedan URLs en la base de datos, haz un reemplazo seguro
Para instalaciones con contenido antiguo, utiliza un procedimiento que respete los datos serializados. Una opción es Better Search Replace, con prueba previa (dry run) y solo las tablas necesarias. Si trabajas por SSH, WP-CLI permite simular el cambio antes de ejecutarlo.
Reemplaza el dominio antiguo concreto, no todos los enlaces que empiecen por HTTP. Evita ejecutar SQL REPLACE() indiscriminadamente sobre metadatos serializados: su longitud interna puede dejar de coincidir y romper contenido.
Limpia cachés, minificación y CDN en este orden
Después de guardar los cambios, limpia archivos de Elementor, caché del plugin de optimización, caché del hosting, caché de la CDN y, por último, vuelve a cargar el navegador sin caché. Si un plugin fusiona o minimiza CSS/JS, regenera también esos archivos.
La caché no corrige una URL de origen equivocada: solo evita que el navegador continúe mostrando una versión anterior una vez reparada.
Valida cada plantilla y la versión móvil
Reabre DevTools y comprueba home, entrada de blog, ficha de servicio, formulario, menú móvil y plantillas de Elementor. Revisa solicitudes que aparecen al hacer scroll, abrir un modal o enviar un formulario: algunos scripts se cargan más tarde.
Si el fallo persiste, usa Network → Initiator para encontrar la nueva referencia, o comprueba la capa de proxy/Cloudflare explicada más abajo. Una web sin errores en la portada puede seguir teniendo contenido mixto en páginas interiores.
Imágenes, fondos y fuentes de Elementor que no cargan en HTTPS.
Elementor guarda URLs tanto en contenido como en ajustes de estilo y archivos CSS generados. Por eso cambiar una entrada o instalar SSL no siempre basta: una referencia antigua puede sobrevivir en un widget o en /wp-content/uploads/elementor/css/.
Imagen rota tras migración
Revisa el widget, el archivo en Medios y su URL. Ejecuta Reemplazar URL en Elementor solo con origen y destino correctos. Después limpia CSS y cachés.
Fuente personalizada ausente
Inspecciona @font-face. Si la URL del WOFF2 usa HTTP, corrige la dirección base, reemplaza URL y regenera archivos. Si marca CORS, investiga también la política de origen.
Editor que no carga
Si el iframe de previsualización apunta a HTTP desde el panel HTTPS, verifica las dos direcciones de WordPress, proxy y redirecciones. No presupongas que el error procede de un plugin conflictivo.
Ruta actual de Elementor documentada en 2026
PROCEDIMIENTO DE REFERENCIAWordPress → Elementor → Editor → Herramientas
├─ Reemplazar URL
│ Antigua: http://tudominio.com
│ Nueva: https://tudominio.com
└─ General → Clear Files & Data / Borrar archivos y datos
Guardar cambios → Vaciar cachés → Volver a comprobarLas traducciones de la interfaz pueden cambiar. Fuentes: migración de Elementor y errores de fuentes.
¿Y si el problema sigue después de regenerar CSS?
Busca el dominio HTTP en widgets HTML, CSS personalizado, ajustes globales, plantillas de cabecera/pie, código personalizado de Elementor y plugins de terceros. Si la petición procede de un fichero generado de Elementor, identifica su fuente antes de editarlo: modificar el CSS generado a mano es temporal y se perderá al regenerarse.
Si el editor está bien pero el frontend no, revisa también minificación, carga diferida y caché. Si las fuentes se solicitan a otro subdominio, comprueba HTTPS y CORS por separado. Un mensaje de CORS no debe etiquetarse automáticamente como contenido mixto.
Base de datos, WP-CLI, Cloudflare y cabeceras de seguridad.
Cuando las referencias inseguras vuelven a aparecer después de arreglar Elementor, suele quedar una causa persistente: URL almacenada, código de tema/plugin o una infraestructura que informa mal del protocolo.
1. Búsqueda y reemplazo con WP-CLI: primero simulación
Con acceso SSH, WP-CLI admite --dry-run y maneja datos serializados. En este ejemplo el dominio y la ruta representan un sitio ficticio; sustitúyelos solo después de comprobar backups y alcance. La opción --skip-columns=guid evita reescribir el identificador histórico de los posts.
wp search-replace 'http://ejemplo.com' 'https://ejemplo.com' \ --all-tables-with-prefix --skip-columns=guid --dry-run
wp search-replace 'http://ejemplo.com' 'https://ejemplo.com' \ --all-tables-with-prefix --skip-columns=guid
En multisite el alcance y las tablas requieren una planificación específica. No uses el ejemplo literalmente en producción. Manual oficial de WP-CLI ↗ · Plugin Better Search Replace ↗.
2. Cloudflare, proxy inverso y bucles HTTPS
Cloudflare Flexible
En Flexible, Cloudflare cifra la conexión con el visitante pero habla por HTTP con el servidor de origen. Esto puede confundir a WordPress y provocar URLs HTTP o bucles si el origen fuerza HTTPS. No es equivalente a cifrado extremo a extremo.
Cloudflare Full (strict)
Si tu servidor ofrece un certificado de origen válido y compatible, Full (strict) cifra también el tramo Cloudflare → servidor y valida su certificado. Comprueba antes puertos, certificado y host: activarlo sin un origen preparado puede generar el error 526.
Si WordPress funciona detrás de un balanceador o proxy, comprueba que el servidor reconoce las peticiones HTTPS de forma fiable y que el proxy establece correctamente las cabeceras de protocolo. La documentación de WordPress menciona HTTP_X_FORWARDED_PROTO y is_ssl(), pero no debes fiarte de una cabecera enviada directamente por cualquier cliente: la configuración ha de estar bajo control del proxy de confianza. WordPress HTTPS detrás de proxy ↗.
3. ¿Sirve la cabecera CSP upgrade-insecure-requests?
La directiva Content-Security-Policy: upgrade-insecure-requests indica al navegador que trate determinadas URLs HTTP como HTTPS. Puede servir como medida complementaria durante una migración, pero no crea un endpoint seguro donde no existe: si el recurso no está disponible en HTTPS, fallará. Tampoco sustituye la limpieza de URLs ni la configuración de HTTPS y HSTS.
Content-Security-Policy: upgrade-insecure-requests
No confundas políticas: block-all-mixed-content se considera obsoleta en la documentación actual de MDN. Tampoco conviene aplicar redirecciones HTTP → HTTPS, HSTS, CSP y reglas del CDN indiscriminadamente sin comprobar su orden y compatibilidad: puedes provocar recursos rotos o un bucle de redirección. MDN: alcance de upgrade-insecure-requests ↗.
4. Lo que no debes hacer para «ocultar» el aviso
Desactivar la seguridad del navegador
No soluciona la web para tus visitantes y permite solicitudes que podrían ser manipuladas en tránsito.
Reemplazar todos los «http» sin filtro
Puedes afectar enlaces externos, integraciones, datos serializados o contenido que ni siquiera era un recurso.
Editar CSS generado a mano
Elementor puede sobrescribir esos archivos; corrige el widget, ajuste o registro que los está produciendo.
No todo lo que falla con HTTPS es contenido mixto.
Confundir estos mensajes lleva a instalar plugins SSL sin necesidad. Lee la causa en el panel de red antes de cambiar un ajuste.
Script HTTP bloqueado
Documento HTTPS que solicita http://.../app.js. Busca dónde se genera la URL insegura y cambia esa referencia.
Archivo no encontrado
La URL ya es HTTPS, pero el servidor devuelve 404. Comprueba ruta, archivo o reescritura; es un problema distinto.
Fuente o API entre orígenes
El archivo puede usar HTTPS y aun así fallar por permisos CORS. Comprueba las cabeceras y el origen solicitado.
Certificado inválido
El servidor no presenta un certificado fiable para ese dominio. Corrige SSL/TLS antes de investigar recursos.
Demasiadas redirecciones
HTTP y HTTPS se redirigen entre sí, a menudo por conflicto entre proxy, hosting, WordPress y CDN.
Recurso bloqueado por CSP
La política del sitio puede bloquear una solicitud incluso si usa HTTPS. Lee la directiva exacta de la consola.
Checklist final: una web sin HTTP en los recursos críticos.
Revisa las páginas y las acciones reales. Esta lista no guarda ni envía tu progreso; te sirve como control de entrega después de una migración o reparación.
¿El contenido mixto afecta al SEO?
Puede afectar a la experiencia, al renderizado y al funcionamiento de recursos necesarios para comprender o utilizar una página. Sin embargo, no existe una mejora de posiciones garantizada por eliminar el aviso. Es una corrección de calidad técnica y seguridad. Aprovecha la intervención para confirmar que tus URLs públicas, redirecciones y etiquetas canonical usan la versión HTTPS elegida.
En una migración completa, también verifica el sitemap, los enlaces internos y las propiedades de Search Console. Mantén separados los problemas de contenido mixto de los 404, las cadenas de redirección y la velocidad WordPress: están relacionados en una auditoría, pero tienen diagnósticos y soluciones diferentes.
Prueba de aceptación: abre una ventana privada y reproduce el flujo de una visita real —portada, navegación, entrada, formulario y versión móvil— con la consola abierta. Comprueba especialmente recursos que aparecen después de interactuar: menús, mapas, embeds, popups y herramientas de marketing.
Preguntas sobre el contenido mixto en WordPress.
Respuestas directas a errores frecuentes de HTTPS, Elementor, archivos, plugins y migraciones.
¿Qué significa «Mixed Content» en WordPress?
Que un documento servido por HTTPS ha intentado solicitar algún recurso por HTTP. Según el tipo de archivo, el navegador puede actualizar esa petición automáticamente o bloquearla. La consola y Network muestran qué recurso ha provocado la advertencia.
¿Cómo encuentro la imagen HTTP que causa el aviso?
Abre la página HTTPS, pulsa F12, ve a Console y recarga. Copia la URL indicada. Después revisa Network → Initiator y comprueba si la URL está guardada en Medios, el contenido, Elementor, CSS o algún plugin.
¿Por qué tengo SSL instalado y sigue apareciendo el error?
Porque el certificado protege las conexiones HTTPS, pero no reescribe necesariamente todas las referencias HTTP antiguas. Debes corregir el origen de esas URLs y comprobar la configuración del servidor, WordPress y caché.
¿El contenido mixto puede romper Elementor?
Sí. Puede afectar a imágenes, fondos, tipografías, estilos o al iframe de vista previa del editor. Elementor documenta reemplazar URLs, limpiar archivos generados y revisar el protocolo configurado en WordPress.
¿Dónde está «Reemplazar URL» de Elementor en 2026?
La ayuda oficial actual lo sitúa en Elementor → Editor → Herramientas → Reemplazar URL. En otras versiones puede aparecer bajo Elementor → Herramientas. Conviene comprobar la interfaz instalada y realizar una copia antes.
¿Es suficiente instalar un plugin SSL?
No necesariamente. Algunos plugins facilitan redirecciones o reescrituras temporales, pero la solución duradera es sustituir referencias incorrectas, regenerar archivos y arreglar las causas en tema, plugin o proxy. Evita depender solo de «ocultar» el aviso.
¿Es seguro hacer buscar y reemplazar en la base de datos?
Puede serlo con copia, dominio de origen exacto, dry run y una herramienta compatible con datos serializados, como WP-CLI o Better Search Replace. Un reemplazo SQL indiscriminado puede romper estructuras guardadas por WordPress y plugins.
¿Debo cambiar cualquier URL que empiece por http://?
No. Un enlace de navegación HTTP no es necesariamente una solicitud de contenido mixto; un dominio externo puede no admitir HTTPS, y pueden existir direcciones de prueba. Actúa sobre referencias identificadas y verifica cada destino.
¿Las imágenes HTTP siempre se bloquean?
No. Los navegadores modernos actualizan automáticamente algunas imágenes, vídeos y audios HTTP. Sin embargo, hay excepciones, como imágenes con srcset o hosts especificados mediante IP; además, si HTTPS no funciona, el recurso puede fallar.
¿Qué pasa con fuentes WOFF y Google Fonts?
Las fuentes solicitadas por HTTP desde un contexto HTTPS suelen bloquearse. Si la dirección ya es HTTPS y sigue fallando, comprueba CORS, ruta, permisos y archivos CSS generados. Son causas distintas.
¿Por qué sigue apareciendo un error después de vaciar la caché?
Porque una URL HTTP puede seguir guardada en un widget, tema, ajuste de plugin o base de datos, o el servidor seguir generándola por una mala detección de HTTPS. Network → Initiator ayuda a encontrar el origen real.
¿Cloudflare Flexible puede provocar problemas?
Sí. Flexible conecta con el origen por HTTP y puede causar conflictos con redirecciones HTTPS y la detección del protocolo en WordPress. Cloudflare recomienda Full o Full (strict) cuando el origen lo admite y está configurado correctamente.
¿Cambiar de HTTP a HTTPS perjudica al posicionamiento?
Una migración mal configurada puede causar problemas de rastreo, enlaces y redirecciones; por eso debes revisar URLs, canonicals y sitemaps. Corregir contenido mixto mejora la coherencia técnica, pero por sí solo no garantiza una posición concreta en Google.
¿El error Mixed Content y CORS son lo mismo?
No. Mixed Content se refiere a solicitar ciertos recursos HTTP desde HTTPS. CORS regula el acceso a recursos de otro origen mediante políticas del servidor. Una fuente puede fallar por uno, otro o ambos; lee el mensaje concreto.
¿Puedo comprobar URLs HTTP pegando código aquí?
Sí, con el analizador local de esta página. Sirve para destacar cadenas http:// presentes en un fragmento de HTML, CSS o consola, no para verificar en directo todos los archivos de una web. No comparte los datos con ningún servidor.
¿Cuándo debo pedir ayuda al hosting?
Cuando el certificado no es válido, HTTPS no funciona en el origen, hay bucles de redirección, problemas de proxy o permisos del servidor, o WordPress continúa generando HTTP a pesar de que la configuración de contenido es correcta.
Documentación técnica contrastada y enlaces de referencia.
Última comprobación editorial: 17 de octubre de 2026. El artículo prioriza documentación oficial de navegadores, WordPress, Elementor y Cloudflare. Las pantallas de consola incluidas son ilustraciones recreadas, no capturas obtenidas de una web real.
Enfoque editorial, alcance y límites
Esta guía se ha preparado para rogerllorens.com desde la perspectiva de diseño web WordPress, mantenimiento y SEO técnico. Distingue la solución de origen de las medidas temporales, separa errores de HTTPS de CORS o 404 y ofrece una herramienta para interpretar fragmentos pegados sin conexiones externas. Las rutas de menús y las políticas de navegador pueden evolucionar.
El analizador no accede a tu web, no instala certificados, no realiza peticiones remotas y no modifica contenido. Ante datos sensibles, migraciones multisitio o una infraestructura con proxy, valida el plan con quien administra el servidor.
