Es una de las consultas más frecuentes que recibe cualquier soporte de hosting. La persona contrató el plan, activó el certificado SSL, entró a su sitio con HTTPS y el navegador, en vez del candado, le muestra un triángulo de advertencia o directamente la leyenda "no seguro". La primera conclusión suele ser que el certificado está mal instalado. Casi nunca es eso. El problema se llama contenido mixto y no se arregla desde el certificado: se arregla desde adentro del sitio.
Qué es exactamente el contenido mixto
Cuando alguien visita tu página por HTTPS, el navegador descarga primero el HTML de forma cifrada. Perfecto hasta ahí. Pero ese HTML es solo el esqueleto: adentro hay referencias a decenas de otros archivos, imágenes, hojas de estilo, tipografías, scripts, videos incrustados.
Si alguna de esas referencias apunta a una dirección que empieza con http:// en lugar de https://, el navegador se encuentra con que le pidieron cargar un pedazo sin cifrar dentro de una página cifrada. Y ahí hace lo correcto: avisa. Porque una página es tan segura como su parte menos segura, y ese archivo sin cifrar podría ser modificado por alguien en el camino.
Los dos tipos, y por qué uno es mucho peor
Los navegadores distinguen entre contenido mixto pasivo y activo, y los tratan de forma muy distinta.
El pasivo son imágenes, videos y audio. Elementos que se muestran pero no pueden cambiar el comportamiento de la página. El navegador los carga igual, pero te saca el candado y muestra la advertencia. Es feo, daña la confianza, pero el sitio funciona.
El activo son scripts, hojas de estilo, iframes y peticiones al servidor. Elementos que sí pueden alterar la página entera. Acá el navegador ya no negocia: directamente los bloquea. Y ese es el momento en que el sitio se ve roto, sin estilos, o con funciones que dejaron de andar. Si tu web se descuadró justo después de pasar a HTTPS, esta es la causa el noventa por ciento de las veces.
Cómo encontrar qué recurso lo está causando
No hace falta adivinar. Abrí la página en el navegador, entrá a las herramientas de desarrollo con F12 y andá a la pestaña de consola. El navegador te lista uno por uno los recursos problemáticos con su dirección completa. Ahí vas a ver exactamente qué archivo está pidiendo por HTTP.
Si en la consola no ves nada, recargá con la caché desactivada, porque los avisos aparecen en el momento de la carga. Y revisá también las páginas internas, no solo la portada: es muy común que la portada esté limpia y el problema viva en una entrada vieja del blog con una imagen pegada desde otro sitio.
De dónde salen esas referencias
Imágenes subidas antes de instalar el SSL. La causa número uno. WordPress guarda la dirección completa de cada imagen en la base de datos. Si subiste cien fotos cuando el sitio andaba por HTTP, en la base hay cien direcciones que empiezan con http.
Enlaces escritos a mano en el contenido. Alguien pegó una imagen de otro sitio copiando la dirección tal cual, y esa dirección era HTTP.
Temas y plugins con direcciones fijas. Algunos cargan tipografías o librerías desde direcciones escritas a mano en su código.
Configuración del sitio. Si en los ajustes generales la dirección del sitio todavía figura con HTTP, todo lo que WordPress genere va a heredar ese prefijo.
Servicios externos que no soportan HTTPS. Cada vez más raro, pero pasa con widgets viejos, contadores de visitas antiguos o mapas de proveedores discontinuados.
La solución de raíz: reemplazar en la base de datos
El arreglo definitivo es cambiar todas las direcciones guardadas. En WordPress se hace con una herramienta de búsqueda y reemplazo en la base de datos, buscando http://tudominio.com y reemplazando por https://tudominio.com.
Dos advertencias importantes. Primera: hacé una copia de seguridad completa de la base antes de tocar nada. Un reemplazo mal hecho puede dejar el sitio inaccesible. Segunda: no uses una consulta SQL directa a mano, porque WordPress guarda mucha información en un formato donde el texto lleva anotada su propia longitud, y cambiar el texto sin corregir ese número rompe la configuración de los plugins. Usá una herramienta pensada para esto, que se encarga de recalcular esas longitudes.
Después del reemplazo, revisá también los ajustes generales para que la dirección del sitio y la dirección de WordPress figuren con HTTPS.
El parche rápido, y por qué solo es un parche
Existe una instrucción que le dice al navegador que actualice automáticamente cualquier pedido HTTP a HTTPS. Se agrega como una cabecera de seguridad y resuelve la advertencia al instante.
Es útil como medida de emergencia, sobre todo si tenés un sitio grande y necesitás que deje de verse roto hoy. Pero tiene dos problemas. Si el recurso original no existe en HTTPS, ahora directamente no carga. Y las direcciones sucias siguen en tu base de datos, esperando a causar problemas la próxima vez que migres o cambies de dominio. Usalo para ganar tiempo, no para cerrar el tema.
Que nadie llegue por HTTP en primer lugar
Una vez limpio el contenido, el último paso es asegurarte de que nadie navegue tu sitio sin cifrar. Eso se hace con una redirección permanente desde HTTP hacia HTTPS en la configuración del servidor. Con eso, cualquiera que escriba tu dominio sin el prefijo termina igual en la versión segura.
Un detalle que se pasa por alto: revisá que la redirección no genere un bucle. Si tu hosting ya fuerza HTTPS desde el panel y además lo agregás por tu cuenta, algunas configuraciones entran en un ciclo infinito y el sitio deja de cargar. Ante la duda, activalo en un solo lugar.
El orden correcto para no volver a pasar por esto
Si estás armando un sitio nuevo, el orden que te ahorra todo este trabajo es: activar el certificado primero, configurar la dirección del sitio con HTTPS desde el minuto cero, y recién después subir contenido. Los certificados gratuitos con renovación automática son estándar hace años y no hay ninguna razón para dejar esto para después.
Si tu plan de hosting incluye el certificado y se renueva solo, como pasa con BanaHosting, la parte del certificado deja de ser un tema y te podés concentrar en lo único que realmente da trabajo: que el contenido de tu sitio apunte a donde tiene que apuntar.