Cómo configurar SSL y HTTPS en PrestaShop

Última actualización: junio de 2026.

Esta es la parte de una migración a SSL que suele pillar desprevenidos a los propietarios de tiendas PrestaShop: comprar el certificado es el 10% fácil. El certificado se instala en tu servidor en cuestión de minutos. El otro 90% —la parte que de verdad rompe tiendas— ocurre dentro de PrestaShop, donde SSL queda conectado con la base de datos, el reescritor de URL, el ámbito de las cookies y un interruptor escalonado de Activar SSL en todas las páginas que puede dejarte fuera de tu propio panel de administración si lo activas en el orden equivocado. Esta guía trata precisamente de ese 90%: configurar HTTPS correctamente en PrestaShop en concreto, con las rutas reales del panel de administración, las claves de configuración exactas y el procedimiento de recuperación cuando algo sale mal.

Si quieres una visión más amplia de cómo proteger una tienda —seguridad del panel de administración, reglas del servidor, parcheo virtual—, este es solo un punto dentro de una lista más larga; empieza por la lista de refuerzo de seguridad para PrestaShop. Este artículo se centra únicamente en SSL y HTTPS.

Por qué esto es innegociable para una tienda PrestaShop

Probablemente ya sabes que HTTPS cifra la conexión. Las razones por las que es obligatorio en una tienda, en términos empresariales claros, son estas:

• Los navegadores ahuyentan activamente a tus clientes si usas HTTP. Chrome y Firefox marcan las páginas HTTP sin cifrar como "No seguro" en la barra de direcciones, justo en las páginas donde un cliente está a punto de introducir el número de su tarjeta. Es un problema de conversión, no solo de seguridad.
• Las integraciones de pago lo exigen. Los webhooks y flujos de redirección de Stripe, PayPal, Mollie y Adyen presuponen puntos de conexión HTTPS. Un certificado configurado a medias es una de esas causas silenciosas por las que una llamada de retorno de pago falla sin dar señales claras.
• Es una señal de posicionamiento y la puerta de entrada a HTTP/2. Google considera HTTPS un factor de posicionamiento ligero desde 2014, y HTTP/2 —que realmente acelera la carga de páginas mediante multiplexación— solo está disponible sobre HTTPS. Así que el cambio que te hace más seguro también te hace más rápido.

La consecuencia práctica: hacerlo bien elimina una advertencia del navegador en tu proceso de compra, mantiene vivas las llamadas de retorno de pago y desbloquea una mejora de rendimiento gratuita. Hacerlo a medias —certificado presente, pero PrestaShop mal configurado— provoca avisos de contenido mixto y diseños rotos que dan peor impresión que el HTTP sin cifrar.

Qué certificado deberías comprar realmente (adelanto: probablemente ninguno)

Los certificados SSL se dividen en tres niveles de validación. El cifrado es idéntico en los tres; la diferencia de precio paga trámites de validación, no una seguridad más fuerte.

Un certificado DV gratuito de Let's Encrypt ofrece al navegador del cliente exactamente el mismo candado y el mismo cifrado que un certificado EV de 500 EUR. Salvo que seas una empresa B2B regulada cuyos compradores revisen específicamente los detalles del certificado, elige el DV gratuito e invierte ese dinero en tu tienda.

Paso 1: Instala el certificado en tu servidor

Esto ocurre en la capa de alojamiento, antes de que PrestaShop intervenga. Elige la ruta que corresponda a tu configuración.

• cPanel: abre SSL/TLS Status y haz clic en Run AutoSSL. Emite e instala certificados de Let's Encrypt para cada dominio y los renueva automáticamente en ciclos de 60 a 90 días.
• Plesk: Websites & Domains → SSL/TLS Certificates → Install en Let's Encrypt, y marca la renovación automática.
• VPS / dedicado (acceso root): instala Certbot. certbot --apache o certbot --nginx obtiene el certificado, edita tu vhost y deja configurado un cron/temporizador de renovación. Es la ruta más limpia si controlas la máquina.
• Cloudflare: el plan gratuito termina SSL en el borde de Cloudflare. Detalle crítico más abajo: configúralo como Full (Strict), nunca como Flexible.

Hay una trampa de Cloudflare que conviene destacar porque afecta especialmente a las tiendas PrestaShop: en modo Flexible, el salto del visitante a Cloudflare va cifrado, pero el salto de Cloudflare a tu servidor va por HTTP sin cifrar. El candado parece correcto, pero PrestaShop ve una solicitud HTTP, y ese desajuste es la causa número uno del bucle de redirecciones que aparece en la sección de resolución de problemas. Usa Full (Strict), que exige un certificado en tu origen (aunque sea uno gratuito de Let's Encrypt) y cifra ambos saltos.

Paso 2: Activa SSL dentro de PrestaShop, en el orden correcto

Con el certificado activo en el servidor, todavía hay que decirle a PrestaShop que lo use. Este es el paso que deja a gente fuera del panel, así que hazlo con cuidado.

Ve a Parámetros de la tienda → General en el panel de administración (PrestaShop 1.7, 8 y 9.x). Hay dos interruptores, y el orden importa:

• Configura Activar SSL en Sí y guarda. Esto hace que PrestaShop sirva las páginas sensibles (inicio de sesión, proceso de compra, cuenta) mediante HTTPS, dejando el resto como está. Confirma que el panel de administración y un proceso de compra siguen cargando.
• Solo entonces configura Activar SSL en todas las páginas en Sí. Esto fuerza todas las URL de la tienda pública a HTTPS.

Por qué conviene hacerlo en dos pasos: si tu certificado o la configuración del proxy tiene un fallo sutil y activas ambos ajustes de una vez, PrestaShop puede empezar a redirigir el panel de administración a un punto HTTPS roto y perderás acceso a la pantalla que necesitas para deshacerlo. Activarlos uno por uno hace que el primer interruptor revele el problema mientras todavía puedes entrar al panel de administración.

Si aun así te has quedado fuera

Este es el movimiento de recuperación que merece la pena memorizar. Los dos interruptores corresponden a dos filas de ps_configuration: PS_SSL_ENABLED y PS_SSL_ENABLED_EVERYWHERE. Abre phpMyAdmin (o el cliente de base de datos que prefieras) y pon ambos en 0:

UPDATE ps_configuration SET value = 0 WHERE name IN ('PS_SSL_ENABLED', 'PS_SSL_ENABLED_EVERYWHERE');

(Sustituye ps_ por el prefijo real de tus tablas). Esto desactiva la aplicación forzosa de SSL, restaura el acceso al panel de administración y te permite corregir el problema real —normalmente el asunto de las cabeceras del proxy que se explica más abajo— antes de intentarlo de nuevo. Después, limpia la caché (elimina el contenido de var/cache/) para que el cambio tenga efecto.

Configura correctamente las URL de la tienda

Ve a Parámetros de la tienda → Tráfico & SEO → SEO & URL y usa el panel Establecer URL de la tienda al final de esa página (en multitienda, es la pantalla específica de URL de tiendas). Los campos Dominio de la tienda y Dominio SSL deben ser idénticos: nombres de host limpios, como yourstore.com, sin prefijo http:// ni https:// y sin barra final. PrestaShop añade el protocolo por sí mismo según los interruptores de SSL. Pegar una URL completa en estos campos es una causa clásica de direcciones duplicadas como https://https//yourstore.com.

Paso 3: Redirige todo el tráfico HTTP a HTTPS

Después de activar SSL dentro de PrestaShop, fuerza la redirección antes de que la aplicación haga ningún trabajo. Coloca la regla cerca del principio del .htaccess público, después de probarla en un entorno de pruebas.

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTPS} !=on
  RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

Activar SSL "en todas las páginas" hace que PrestaShop genere enlaces HTTPS, pero los marcadores antiguos, enlaces entrantes y direcciones escritas a mano seguirán llegando por HTTP. Una única dirección HTTPS canónica —forzada con una redirección 301— mantiene a los clientes en la versión cifrada y evita que los motores de búsqueda traten HTTP y HTTPS como sitios duplicados.

La trampa específica de PrestaShop: PrestaShop controla su .htaccess. En cuanto alguien hace clic en Generar archivo .htaccess dentro de Parámetros de la tienda → Tráfico & SEO → SEO & URL, todo el archivo se reescribe y desaparece cualquier regla de redirección añadida a mano. La propia redirección, y la forma segura de añadir reglas que sobrevivan a una regeneración, pertenecen a la configuración a nivel de archivo; lo explicamos en detalle en PrestaShop .htaccess: reglas de seguridad y rendimiento. Las opciones más limpias, que evitan por completo el problema de la regeneración:

• Cloudflare: activa Always Use HTTPS en SSL/TLS → Edge Certificates. La redirección ocurre en el borde antes de que la solicitud llegue siquiera a tu servidor: más rápido e inmune a la regeneración de .htaccess.
• Nginx: un bloque server en el puerto 80 que haga return 301 https://$host$request_uri;; una configuración que PrestaShop nunca toca.

Paso 4: Localiza el contenido mixto (la parte que rompe los diseños)

El contenido mixto es el problema al que de verdad dedicarás tiempo. Una página HTTPS que carga una imagen, un script o una hoja de estilos mediante http:// dispara advertencias del navegador, y los navegadores modernos bloquean directamente los scripts mixtos. Por eso una tienda puede aparecer completamente sin estilos o con el formulario de pago inutilizado justo después de la migración.

Para encontrarlo: abre la tienda en Chrome, pulsa F12 y revisa la pestaña Consola en busca de líneas como "Mixed Content: the page at https://… requested an insecure resource http://…". Cada una indica la URL problemática.

En PrestaShop, el contenido mixto se concentra en unos pocos lugares previsibles:

• http:// codificado directamente en la base de datos. Descripciones de productos, descripciones de categorías y páginas CMS donde alguien pegó una URL absoluta de imagen con http://. Es la fuente más común.
• Recursos de módulos. Módulos antiguos o mal escritos que registran CSS/JS con una URL explícita http:// en lugar de usar $this->context->link o helpers de PrestaShop conscientes del protocolo. Actualiza el módulo o notifícaselo a su desarrollador.
• Plantillas de correo electrónico. Imágenes referenciadas por HTTP en correos transaccionales, editadas en Diseño → Tema de correo electrónico.
• Archivos del tema. URL de background-image en CSS o fuentes codificadas como http:// en las hojas de estilo de un tema personalizado.
• Inserciones de terceros. Fuentes, analítica, vídeo o widgets sociales cargados por HTTP.

La búsqueda y sustitución en la base de datos

Para los casos que están en la base de datos, ejecuta actualizaciones específicas después de hacer una copia de seguridad. Los campos más importantes están en ps_product_lang (description, description_short), ps_category_lang (description) y ps_cms_lang (content):

UPDATE ps_product_lang SET description = REPLACE(description, 'http://yourstore.com', 'https://yourstore.com');

Repite por cada campo y tabla. La solución robusta a largo plazo es usar URL HTTPS o relativas al protocolo en el contenido a partir de ahora; la opción más limpia de todas es dejar de pegar URL absolutas con el dominio en las descripciones. Haz siempre una copia de seguridad de la base de datos antes de cualquier UPDATE masivo: no hay deshacer.

Paso 5: Reconfigura los servicios externos que aún creen que eres HTTP

Google trata http:// y https:// como propiedades separadas, así que una migración que se salta este paso te saca silenciosamente de tus propios informes. Revisa lo siguiente:

• Google Search Console: añade https://yourstore.com como nueva propiedad; no hereda el historial de la propiedad HTTP.
• Google Analytics / Merchant Center: actualiza la URL de la propiedad/sitio web a https://; una URL de fuente de datos HTTP obsoleta en Merchant Center puede provocar el rechazo de productos.
• Mapa del sitio: regenéralo para que todas las entradas sean HTTPS. Si usas un módulo de mapa del sitio, regenera desde el módulo en lugar de usar la herramienta del núcleo. Nuestro módulo de mapa del sitio de mypresta.rocks toma automáticamente el protocolo de tus ajustes de SSL, de modo que regenerar después de activar SSL emite URL HTTPS limpias sin edición manual: una cosa menos que recordar.
• Webhooks de pago: actualiza las URL de notificación en los paneles de tus proveedores —PayPal IPN, punto de conexión del webhook de Stripe, webhook de Mollie— a https://. Un webhook HTTP olvidado es un fallo silencioso en el estado de los pedidos.

Paso 6: Verifica, no des nada por hecho

Ejecuta esta lista de comprobación antes de darlo por terminado:

• La página de inicio por HTTPS muestra un candado limpio, sin advertencias.
• Páginas de producto, categoría y CMS: consola libre de contenido mixto.
• Un proceso de compra de prueba completo finaliza por HTTPS, incluida la llamada de retorno de pago.
• Todas las páginas del panel de administración cargan por HTTPS.
• Al escribir http://yourstore.com, se redirige con 301 a https://.
• Un único host canónico: con www o sin www, pero no ambos resolviendo como válidos.
• Ejecuta la prueba gratuita de servidor de SSL Labs (ssllabs.com/ssltest); apunta a una A o A+.

Los tres fallos que explican la mayoría de tickets de "HTTPS ha roto mi tienda"

Bucle infinito de redirecciones

El clásico. Tu alojamiento o Cloudflare termina SSL aguas arriba y reenvía la solicitud a PrestaShop como HTTP sin cifrar. PrestaShop ve HTTP, redirige a HTTPS, el proxy se lo devuelve como HTTP, y así indefinidamente. La solución es hacer que PrestaShop confíe en la cabecera X-Forwarded-Proto del proxy para que reconozca que la solicitud original era HTTPS. En Cloudflare concretamente, cambiar de Flexible a Full (Strict) resuelve esto directamente. En otros proxies inversos puede que tengas que respetar la cabecera forwarded-proto a nivel de servidor web o de .htaccess.

La tienda carga sin estilos / el formulario de pago no funciona

Casi siempre es contenido mixto bloqueado: una hoja de estilos o un script que el navegador se negó a cargar por HTTP dentro de una página HTTPS. Vuelve al Paso 4: lee la consola, encuentra el recurso http:// y corrige su origen.

Las imágenes han desaparecido tras la migración

Imágenes de productos o CMS con URL http:// codificadas directamente, o una CDN de imágenes que no sirve HTTPS. La búsqueda y sustitución en la base de datos del Paso 4 resuelve lo primero; para lo segundo, confirma que tu CDN o alojamiento de imágenes soporta HTTPS.

Una nota para ir más allá

Cuando HTTPS esté limpio y verificado, el siguiente paso natural es HSTS (HTTP Strict Transport Security), que indica a los navegadores que rechacen por completo HTTP para tu dominio. Es potente y algo peligroso: un max-age demasiado largo en un sitio mal configurado puede hacer que el dominio quede inaccesible, así que conviene tratarlo junto con el resto del refuerzo de cabeceras de seguridad, no encajarlo aquí a la fuerza. Cubrimos HSTS, cabeceras de seguridad y las demás reglas a nivel de servidor en la guía de seguridad y rendimiento de .htaccess, y SSL forma parte del programa más amplio descrito en la lista completa de refuerzo. Si prefieres que primero te lo expliquemos todo sin jerga, la guía en lenguaje claro para proteger tu tienda es una entrada más suave.

SSL en PrestaShop no es difícil, pero no perdona errores de orden ni las particularidades de la plataforma: activa los interruptores uno a uno, conoce la recuperación mediante ps_configuration antes de necesitarla, espera que la base de datos esconda tus últimas URL http:// y verifica con la consola en lugar de fiarte de lo que ves. Hazlo así y la recompensa es inmediata: ningún "No seguro" en tu proceso de compra, llamadas de retorno de pago que se ejecutan y velocidad HTTP/2 gratis. Conviértelo en el proyecto de esta semana; es una de las tardes de mayor valor que puedes dedicar a la tienda.

Preguntas frecuentes

He activado SSL y ahora el panel de administración redirige sin parar: ¿cómo vuelvo a entrar?

Es el bucle de redirecciones, y casi siempre se debe a un proxy que entrega a PrestaShop una solicitud HTTP sin cifrar mientras el salto del navegador al borde es HTTPS. La recuperación rápida consiste en desactivar la imposición en la base de datos: UPDATE ps_configuration SET value = 0 WHERE name IN ('PS_SSL_ENABLED', 'PS_SSL_ENABLED_EVERYWHERE'); (sustituye el prefijo de tus tablas) y después limpiar la caché vaciando var/cache/. Eso restaura el acceso al panel de administración. Antes de volver a activarlo, corrige la causa real: en Cloudflare cambia de Flexible a Full (Strict); en otro proxy inverso, haz que PrestaShop respete la cabecera X-Forwarded-Proto para que reconozca que la solicitud original era HTTPS.

¿Un certificado gratuito de Let's Encrypt es realmente tan seguro como uno de pago?

Para el cifrado, sí: idéntico. Un certificado DV de Let's Encrypt ofrece al navegador del visitante el mismo candado y el mismo cifrado TLS que un certificado EV de 500 EUR. El precio de OV y EV paga trámites de validación (se comprueba la identidad legal de tu empresa), no una criptografía más fuerte, y los navegadores eliminaron la barra verde con el nombre de la empresa, que era la única ventaja visible de EV. Salvo que seas una empresa B2B regulada cuyos compradores revisen específicamente los detalles del certificado, elige el DV gratuito.

Mi tienda carga sin estilos o el formulario de pago no funciona tras pasar a HTTPS: ¿por qué?

Casi siempre por contenido mixto bloqueado: una página HTTPS está cargando una hoja de estilos o un script mediante http://, y los navegadores modernos se niegan a cargar scripts inseguros en una página segura. Abre la tienda en Chrome, pulsa F12 y revisa la pestaña Consola: cada línea de "Mixed Content" indica la URL http:// problemática. Los culpables habituales son enlaces absolutos http:// pegados en contenido de productos o CMS (corrígelo con una búsqueda y sustitución en la base de datos después de hacer copia de seguridad), módulos antiguos que registran recursos con un protocolo codificado directamente y hojas de estilo de temas personalizados. Corrige el origen, no el síntoma.

¿Por qué debo activar los dos interruptores de SSL uno por uno?

Porque el orden es tu red de seguridad. Activar SSL (PS_SSL_ENABLED) solo fuerza HTTPS en páginas sensibles —inicio de sesión, proceso de compra, cuenta—, de modo que si tu certificado o proxy tiene un fallo sutil, el problema aparece mientras todavía puedes acceder al panel de administración. Solo cuando hayas confirmado que el panel de administración y un proceso de compra siguen cargando debes activar Activar SSL en todas las páginas (PS_SSL_ENABLED_EVERYWHERE). Activa ambos a la vez con una configuración rota y PrestaShop puede empezar a redirigir el panel de administración a un punto HTTPS muerto, dejándote fuera justo de la pantalla que necesitas para deshacerlo.

¿Tengo que hacer algo en Google Search Console después de cambiar a HTTPS?

Sí. Google trata http:// y https:// como propiedades separadas, así que añade https://yourstore.com como nueva propiedad: no hereda el historial de la versión HTTP. Actualiza también tus URL de Analytics y Merchant Center a HTTPS (una URL de fuente de datos HTTP obsoleta en Merchant Center puede provocar el rechazo de productos), regenera el mapa del sitio para que todas las entradas sean HTTPS y vuelve a apuntar los webhooks de pago (PayPal IPN, Stripe, Mollie) al punto de conexión HTTPS. Un webhook HTTP olvidado es un fallo silencioso en el estado de los pedidos.

¿Debo activar HSTS de inmediato?

No como primer movimiento. HSTS indica a los navegadores que rechacen por completo HTTP para tu dominio, lo cual es bueno, pero un max-age demasiado largo en un sitio que no está totalmente limpio puede hacer que el dominio quede inaccesible, y la directiva es difícil de revertir porque los navegadores la cachean. Primero verifica HTTPS de extremo a extremo (consola limpia, proceso de compra funcionando, 301 desde HTTP, una A/A+ en la prueba de SSL Labs) y después añade HSTS junto con el resto del refuerzo de cabeceras de seguridad, no durante la migración en sí.