¿Cómo solucionar el error 503 en PrestaShop durante el modo mantenimiento?

PrestaShop · Mantenimiento · Error 503 · Rendimiento web ⚙️

¿Cómo solucionar el error 503 en PrestaShop durante el modo mantenimiento?

Hay errores que llegan dando un portazo. El error 503 en PrestaShop, en cambio, suele aparecer con una cortesía casi teatral: “Service Unavailable”. Qué delicadeza. La tienda no está rota, dice el servidor; solo está “no disponible”. Como si un comercio bajara la persiana en plena avenida y dejara un cartel escrito con tinta invisible.

En PrestaShop, el modo mantenimiento utiliza normalmente una respuesta HTTP 503 para indicar que la tienda está temporalmente fuera de servicio. Y eso, bien usado, es correcto. Incluso saludable. El problema empieza cuando el mantenimiento termina, el café se enfría, el cliente llama, Googlebot pasa de visita y la tienda sigue respondiendo 503 como un mayordomo obstinado que no deja entrar a nadie.

Esta guía explica, con precisión práctica, cómo diagnosticar y resolver el error 503 durante el modo mantenimiento en PrestaShop, tanto desde el Back Office como desde la base de datos, los archivos del servidor, la caché, Cloudflare, Nginx, Apache y los logs. Porque entre una tienda cerrada por decisión propia y una tienda caída por accidente hay un abismo: el primero es control; el segundo, facturación evaporándose como rocío al sol. 🛒

Contenido rápido

Qué significa realmente el error 503 en PrestaShop
Cómo saber si el 503 viene del modo mantenimiento o del servidor
Solución rápida desde el Back Office
El problema de la IP permitida: el clásico invisible
Caché de PrestaShop, Smarty, navegador y CDN
Cómo desactivar el mantenimiento desde la base de datos
Cloudflare, proxies y balanceadores
Revisión de logs y modo depuración
Impacto SEO del error 503 y cómo evitar daños
Preguntas frecuentes

Qué significa realmente el error 503 en PrestaShop

El código HTTP 503 Service Unavailable significa que el servidor no puede atender la solicitud en ese momento. No es un 404, donde falta una página. No es un 500, donde algo se ha roto por dentro. Es más bien un “vuelva usted más tarde”, con ese aire burocrático que Internet heredó de las ventanillas antiguas.

En el contexto de PrestaShop en modo mantenimiento, el 503 puede ser una respuesta deliberada. Cuando desactivas temporalmente la tienda desde el panel de administración, PrestaShop muestra una página de mantenimiento a los visitantes no autorizados. Esto permite trabajar en actualizaciones, cambios de tema, módulos, migraciones o tareas de seguridad sin exponer una tienda a medio montar, como un escaparate con los maniquíes todavía sin cabeza.

La paradoja es interesante: un error que, en realidad, puede ser una buena práctica. La tienda está “cerrada” para protegerla. Oscuridad para preparar la luz. Silencio para que luego haya ventas. El contraste es casi elegante, hasta que deja de serlo.

Dato importante: en PrestaShop 1.7 y PrestaShop 8, el modo mantenimiento se gestiona normalmente desde Parámetros de la tienda > Configuración > Mantenimiento. En versiones antiguas como PrestaShop 1.6, la ruta puede aparecer como Preferencias > Mantenimiento.

Primero: identifica si es un 503 “normal” o un 503 de emergencia

Antes de tocar nada, conviene distinguir el origen. No todos los 503 son hijos del modo mantenimiento. Algunos vienen del servidor web, de PHP-FPM, de límites de recursos, de un proxy malhumorado o de un módulo que ha decidido convertir tu tienda en una novela de misterio.

Señal	Probable origen	Qué revisar
Se muestra una página de mantenimiento con diseño de PrestaShop	Modo mantenimiento activo	Back Office, IP permitida, configuración `PS_SHOP_ENABLE`
Página genérica “503 Service Unavailable” sin diseño de la tienda	Servidor, hosting, Nginx, Apache, PHP-FPM o proxy	Logs del servidor, límites de recursos, estado de PHP
El Back Office funciona, pero el Front Office muestra 503	Mantenimiento activado o restricción de IP	Configuración de mantenimiento y caché
Ni Back Office ni Front Office cargan	Problema más profundo del servidor o error PHP	Logs, permisos, módulos, modo depuración
Solo tú ves el 503, otros no	Caché local, CDN, IP o sesión	Navegador, Cloudflare, caché de PrestaShop
Solo algunos países o redes ven el error	CDN, WAF, firewall o reglas por geolocalización	Cloudflare, firewall del hosting, reglas de seguridad

Un truco sencillo: abre la tienda desde una ventana privada, desde el móvil usando datos móviles y desde una herramienta externa como un comprobador HTTP. Si cada lugar cuenta una historia distinta, el culpable quizá no sea PrestaShop, sino una capa intermedia. Internet es así: una cebolla con demasiadas capas y alguna que otra lágrima. 🧅

Solución rápida desde el Back Office de PrestaShop

Si puedes entrar al panel de administración, empieza por lo obvio. Sí, lo obvio. Ese territorio humilde donde se resuelven más incidencias que en cualquier épica consola de comandos.

En PrestaShop 1.7 y PrestaShop 8

Accede al Back Office de tu tienda.
Ve a Parámetros de la tienda > Configuración.
Abre la pestaña Mantenimiento.
Comprueba el campo Activar tienda.
Si la tienda debe estar pública, selecciona Sí.
Guarda los cambios.
Limpia la caché desde Parámetros avanzados > Rendimiento > Vaciar caché.

En PrestaShop 1.6

Entra al panel de administración.
Dirígete a Preferencias > Mantenimiento.
Activa la tienda si quieres hacerla pública.
Guarda y limpia caché.

Consejo profesional: después de desactivar el modo mantenimiento, prueba la tienda como visitante anónimo, sin sesión de administrador. Muchas veces el administrador ve una realidad y el cliente otra; una pequeña comedia de espejos que cuesta ventas.

El campo de IP permitida: pequeño, discreto y capaz de arruinarte la tarde

PrestaShop permite mantener la tienda cerrada al público pero visible para ciertas direcciones IP. Es útil para desarrolladores, agencias y propietarios que quieren revisar cambios antes de abrir. El mecanismo es sencillo: si tu IP está en la lista autorizada, ves la tienda; si no, recibes la página de mantenimiento con código 503.

Hasta aquí, impecable. Pero las IPs cambian, las conexiones domésticas son dinámicas, el móvil usa otra red, la oficina sale por una VPN, Cloudflare se interpone y, de pronto, la lista de IPs permitidas parece escrita en una lengua muerta.

Qué hacer

Busca tu IP pública actual desde el mismo dispositivo con el que accedes a la tienda.
Entra al Back Office.
Ve a la sección de mantenimiento.
Usa el botón Añadir mi IP, si está disponible.
Guarda cambios.
Prueba el Front Office en una pestaña privada.

Si trabajas con varios dispositivos o redes, añade todas las IPs necesarias separadas según el formato que acepte tu versión de PrestaShop. En instalaciones modernas suele gestionarse como una lista de direcciones permitidas. Evita añadir rangos amplios si no son imprescindibles; abrir demasiado la puerta para arreglar una cerradura no es seguridad, es decoración.

Atención con IPv6: algunos proveedores entregan IPv6 además de IPv4. Puedes estar autorizando una dirección IPv4 mientras tu navegador llega mediante IPv6. El resultado: tú jurarías que todo está bien, y PrestaShop, con una frialdad de notario, te seguirá mostrando el 503.

Limpia la caché: PrestaShop recuerda más de lo que debería

La caché es una bendición cuando acelera la tienda y una pequeña maldición cuando conserva un error. Es como un camarero eficiente que sigue sirviendo el plato equivocado porque lo memorizó demasiado bien.

Si has desactivado el modo mantenimiento y el error 503 persiste, limpia las distintas capas de caché.

1. Caché desde el Back Office

Ve a Parámetros avanzados > Rendimiento.
Haz clic en Vaciar caché.
Si usas CCC, combinación, minificación o caché de plantillas, prueba temporalmente a desactivarlas para diagnosticar.

2. Caché por archivos en PrestaShop 1.7 / 8

Si no puedes limpiar desde el panel, puedes hacerlo por FTP, SSH o administrador de archivos. En PrestaShop 1.7 y 8, revisa:

/var/cache/prod/
/var/cache/dev/

Borra el contenido de esas carpetas, no necesariamente la carpeta raíz si tu hosting tiene restricciones. PrestaShop regenerará la caché.

3. Caché en PrestaShop 1.6

En versiones antiguas, revisa:

/cache/smarty/cache/
/cache/smarty/compile/

Elimina el contenido interno, especialmente si has modificado plantillas de mantenimiento o configuración.

4. Caché del navegador

Prueba en ventana privada, cambia de navegador o fuerza recarga:

Windows / Linux: Ctrl + F5
Mac: Cmd + Shift + R

5. Caché de CDN o proxy

Si usas Cloudflare, LiteSpeed Cache, Varnish, un proxy inverso o una caché del hosting, limpia también esa capa. No basta con barrer la cocina si el humo está atrapado en el pasillo.

Cómo desactivar el modo mantenimiento desde la base de datos

A veces no puedes acceder al Back Office. Tal vez el módulo que tocaste explotó con discreción, tal vez PHP decidió no cooperar, tal vez alguien olvidó la URL del administrador —sucede más de lo que se admite en voz alta—. En ese caso, puedes revisar la configuración directamente desde la base de datos.

Antes de tocar la base de datos: haz una copia de seguridad. No una promesa mental de “luego la hago”. Una copia real. Descargarla puede parecer aburrido, pero restaurar una tienda rota sin backup es arqueología con los ojos vendados.

Tabla de configuración

PrestaShop guarda muchas preferencias en la tabla ps_configuration. El prefijo ps_ puede variar en tu instalación, por ejemplo abc_configuration o shop_configuration.

Busca estos valores:

PS_SHOP_ENABLE: indica si la tienda está activa.
PS_MAINTENANCE_IP: contiene las IPs autorizadas durante mantenimiento.

Consulta para comprobar el estado

SELECT name, value
FROM ps_configuration
WHERE name IN ('PS_SHOP_ENABLE', 'PS_MAINTENANCE_IP');

Desactivar mantenimiento y activar la tienda

UPDATE ps_configuration
SET value = '1'
WHERE name = 'PS_SHOP_ENABLE';

Después, limpia la caché de PrestaShop. Si estás en PrestaShop 1.7 o 8, puedes eliminar el contenido de:

/var/cache/prod/

Actualizar la IP permitida desde base de datos

Si prefieres mantener el modo mantenimiento activo pero permitir tu acceso:

UPDATE ps_configuration
SET value = '203.0.113.25'
WHERE name = 'PS_MAINTENANCE_IP';

Sustituye 203.0.113.25 por tu IP pública real. La dirección usada aquí es un ejemplo reservado para documentación.

Ojo con multitienda

En PrestaShop con multitienda, los valores pueden tener contexto por tienda o grupo de tiendas mediante campos como id_shop e id_shop_group. Si actualizas una fila global pero tu tienda está usando una configuración específica, el cambio puede no surtir efecto.

Comprueba si existen varias filas para el mismo nombre:

SELECT id_configuration, id_shop_group, id_shop, name, value
FROM ps_configuration
WHERE name = 'PS_SHOP_ENABLE';

Si hay registros por tienda, modifica el que corresponda. En multitienda, la precisión importa; es la diferencia entre apagar una lámpara y dejar a oscuras todo el edificio.

Cloudflare, proxies y balanceadores: cuando tu IP ya no es tu IP

Uno de los casos más frecuentes —y más traicioneros— ocurre cuando la tienda está detrás de Cloudflare, un proxy inverso, Varnish, un balanceador de carga o una capa de seguridad del hosting.

Tú crees que PrestaShop ve tu IP. Pero PrestaShop puede estar viendo la IP del proxy. Es una escena casi filosófica: el visitante llega, pero lo que aparece en la puerta es su mensajero. Y la tienda, muy estricta, le niega el paso.

Síntomas típicos

Añades tu IP en mantenimiento, pero sigues viendo 503.
Al desactivar Cloudflare temporalmente, puedes entrar.
El error afecta de forma distinta según país, red o proveedor.
Los logs muestran IPs de Cloudflare o del proxy, no las IPs reales de visitantes.

Qué puedes hacer

Comprueba la IP que recibe el servidor revisando logs de Apache o Nginx.
Activa la restauración de IP real en tu servidor si usas Cloudflare. En Nginx suele hacerse con módulos y directivas de Real IP; en Apache puede requerir configuración equivalente.
No añadas rangos completos de Cloudflare como IPs permitidas salvo que entiendas el riesgo. Podrías permitir el acceso de más visitantes de los previstos.
Purge cache en Cloudflare tras cambiar el estado de mantenimiento.
Desactiva temporalmente la caché de página si está almacenando la respuesta 503.

Importante: Cloudflare no debería cachear respuestas 503 por defecto como una página normal en configuraciones estándar, pero reglas personalizadas de caché, “Cache Everything”, Workers, proxies del hosting o plugins externos pueden cambiar el comportamiento. La configuración real manda más que la teoría, como siempre.

Revisa reglas de .htaccess, Nginx y páginas de mantenimiento externas

No todo mantenimiento viene de PrestaShop. Algunos hostings, agencias o administradores implementan un modo mantenimiento a nivel servidor. Esto se hace con reglas en .htaccess, configuración de Nginx, paneles como cPanel/Plesk o plugins externos.

En Apache: archivo .htaccess

Revisa si existe alguna regla que fuerce una página de mantenimiento o devuelva 503:

RewriteCond %{REMOTE_ADDR} !^203\.0\.113\.25$
RewriteRule ^.*$ /maintenance.html [R=503,L]

También busca directivas como:

Redirect 503 /
ErrorDocument 503 /maintenance.html

Si encuentras reglas similares y ya no las necesitas, coméntalas o elimínalas con cuidado. Después reinicia cachés si aplica.

En Nginx

En Nginx puede haber bloques como:

if (-f $document_root/maintenance.flag) {
    return 503;
}

error_page 503 @maintenance;

O reglas basadas en un archivo bandera, por ejemplo maintenance.flag. Si ese archivo existe, Nginx devuelve 503 aunque PrestaShop esté perfectamente configurado. Un solo archivo vacío, diminuto como una semilla, puede cerrar una tienda entera.

Permisos de archivos y carpetas: el mantenimiento que se convierte en bloqueo

PrestaShop necesita escribir caché, compilar plantillas, generar archivos temporales y registrar logs. Si los permisos son incorrectos, puede mostrar errores, comportarse de forma extraña o quedarse atrapado en estados antiguos.

Revisa especialmente:

/var/cache/
/var/logs/
/img/
/modules/
/themes/
/app/config/ en ciertas versiones 1.7

Como orientación general, muchos entornos trabajan con permisos tipo 755 para carpetas y 644 para archivos, siempre con el propietario correcto del usuario web. Pero no existe una receta universal: depende de si el servidor usa Apache con PHP-FPM, suPHP, FastCGI, contenedores, paneles gestionados o despliegues más complejos.

No uses 777 como solución permanente. Es tentador, sí. También lo es dejar las llaves debajo del felpudo. Puede servir para una prueba controlada de diagnóstico, pero no para producción.

Comprueba módulos y temas que alteran la página de mantenimiento

Algunos módulos de PrestaShop modifican el comportamiento del Front Office, añaden páginas de “coming soon”, redirecciones, bloqueos por país, restricciones B2B, catálogos privados o protecciones de acceso. En teoría ayudan. En la práctica, a veces se pisan entre ellos como actores entrando por la misma puerta.

Pasos recomendados

Desactiva temporalmente módulos relacionados con mantenimiento, seguridad, caché, redirecciones o SEO.
Prueba con el tema clásico si sospechas del tema actual.
Revisa si el archivo de plantilla de mantenimiento ha sido sobrescrito.
Consulta los logs tras cada cambio.

Si no puedes entrar al Back Office, una técnica de emergencia consiste en renombrar la carpeta del módulo sospechoso dentro de /modules/. Por ejemplo:

/modules/modulo_sospechoso/
a
/modules/modulo_sospechoso_disabled/

Hazlo solo si sabes qué módulo estás tocando y, preferiblemente, tras una copia de seguridad. No conviene convertir una avería en una colección.

Logs y modo depuración: escuchar lo que la tienda intenta decir

Los logs son poco glamorosos. No tienen interfaz bonita, no prometen milagros, no sonríen en capturas comerciales. Pero cuando una tienda PrestaShop falla, los logs son la linterna.

Logs de PrestaShop

En PrestaShop 1.7 y 8, revisa:

/var/logs/prod.log
/var/logs/dev.log

En PrestaShop 1.6, los errores pueden verse en el Back Office o en logs del servidor, según la configuración.

Logs del servidor

También consulta:

Log de errores de Apache.
Log de errores de Nginx.
Log de PHP-FPM.
Registros del panel de hosting.
Alertas de recursos: CPU, RAM, procesos, I/O o límites de entrada.

Activar modo debug en PrestaShop

Si sospechas de un error PHP oculto tras el 503, puedes activar el modo depuración. En PrestaShop 1.7 y 8 suele hacerse desde Parámetros avanzados > Rendimiento > Modo depuración, si el Back Office está disponible.

Si no puedes acceder, revisa el archivo:

/config/defines.inc.php

Busca la constante:

define('_PS_MODE_DEV_', false);

Y cámbiala temporalmente a:

define('_PS_MODE_DEV_', true);

Importante: no dejes el modo debug activo en producción. Puede mostrar rutas internas, errores, datos técnicos y detalles sensibles. Úsalo, diagnostica y vuelve a desactivarlo.

Cuando el 503 no es mantenimiento: límites del hosting y PHP-FPM

Si la página 503 no tiene aspecto de PrestaShop, o si el Back Office también cae, mira hacia el servidor. Un 503 puede aparecer cuando PHP-FPM no responde, el hosting limita procesos, se agota la memoria, hay demasiadas conexiones simultáneas o el servidor upstream está inaccesible.

Causas comunes a nivel servidor

PHP-FPM saturado: demasiados procesos ocupados.
Memoria insuficiente: módulos pesados, importaciones masivas, catálogos grandes.
Timeouts: operaciones lentas en base de datos o llamadas externas.
Límites del hosting compartido: CPU, Entry Processes, I/O.
Actualización incompleta: archivos mezclados de distintas versiones.
Extensiones PHP incompatibles o versión PHP no soportada por tu PrestaShop.

PrestaShop 8, por ejemplo, requiere versiones modernas de PHP dentro de un rango compatible. PrestaShop 1.7 tiene requisitos distintos según subversión. Instalar o actualizar sin comprobar compatibilidad es como echar aceite de oliva en un motor diésel: algo se mueve, sí, pero no como esperabas.

Qué revisar en el hosting

Versión de PHP compatible con tu versión exacta de PrestaShop.
Límite de memoria PHP, idealmente 256 MB o más para tiendas medianas; algunas instalaciones necesitan 512 MB o superior.
max_execution_time si realizas importaciones o actualizaciones.
Estado de PHP-FPM y reinicio del servicio si administras el servidor.
Uso de CPU, RAM, I/O y procesos concurrentes.
Errores recientes tras instalar un módulo o cambiar tema.

SEO: el 503 puede ser correcto, pero no eterno

Desde el punto de vista SEO, el código 503 durante mantenimiento tiene sentido. Indica a buscadores como Google que la indisponibilidad es temporal. Es mucho mejor que devolver un 200 con una página vacía o un 404 accidental. El 503 le dice al rastreador: “no borres nada, vuelve luego”.

Pero aquí aparece la antítesis incómoda: el 503 es prudente por unas horas y peligroso durante días. Medicina en dosis pequeñas, veneno si se olvida en la mesa.

Buenas prácticas SEO durante mantenimiento

Usa el modo mantenimiento solo el tiempo necesario.
Evita dejar la tienda en 503 durante varios días salvo causa justificada.
Si puedes, añade cabecera Retry-After para indicar cuándo volver a intentar.
No bloquees el rastreo con robots.txt durante una caída temporal; podrías complicar la recuperación.
Verifica en Google Search Console si aparecen errores de disponibilidad.
Comprueba URLs importantes: home, categorías, productos, carrito y sitemap.

Ejemplo de cabecera Retry-After

La cabecera Retry-After puede indicar a los bots cuándo deberían volver. No siempre es gestionada directamente desde PrestaShop sin personalización, pero puede añadirse a nivel servidor si sabes lo que haces.

Retry-After: 3600

Ese valor indica 3600 segundos, es decir, una hora. También puede usarse una fecha HTTP válida. En cualquier caso, conviene aplicarla con criterio y retirarla cuando la tienda vuelva a estar activa.

Resumen SEO: un 503 breve durante mantenimiento es correcto. Un 503 persistente puede reducir rastreo, afectar indexación temporalmente y erosionar confianza. Google suele entender interrupciones cortas; lo que no entiende bien es una tienda que promete volver “en breve” durante una semana entera. Y los clientes, menos.

Checklist profesional para resolver el error 503 en PrestaShop

Si necesitas actuar rápido, sigue este orden. No es heroico, pero funciona; y en mantenimiento web, la épica está sobrevalorada.

Confirma el tipo de 503: ¿página de mantenimiento PrestaShop o error genérico del servidor?
Prueba desde otra red: móvil con datos, ventana privada, navegador distinto.
Accede al Back Office: revisa si la tienda está activada.
Comprueba IP permitida: añade tu IP actual y considera IPv6, VPN o proxy.
Limpia cachés: PrestaShop, navegador, CDN, hosting, Varnish o LiteSpeed.
Revisa base de datos: valida PS_SHOP_ENABLE y PS_MAINTENANCE_IP.
Comprueba multitienda: asegúrate de editar el contexto correcto.
Inspecciona .htaccess o Nginx: busca reglas externas de mantenimiento.
Desactiva módulos sospechosos: especialmente caché, seguridad, redirecciones y coming soon.
Consulta logs: PrestaShop, PHP, Apache, Nginx, hosting.
Verifica recursos del servidor: CPU, RAM, procesos, PHP-FPM, límites del plan.
Revisa SEO: estado HTTP, Search Console, sitemap y URLs clave.

Errores habituales que alargan el problema

Hay fallos técnicos. Y luego están esas pequeñas decisiones humanas que los alimentan, como migas para palomas.

Error habitual	Por qué ocurre	Cómo evitarlo
No probar como usuario anónimo	El administrador puede ver la tienda por sesión o IP	Usa incógnito y conexión externa
Olvidar Cloudflare o CDN	La respuesta 503 puede estar cacheada o alterada	Limpia caché y revisa reglas
Editar la fila equivocada en multitienda	Configuración por tienda o grupo	Consulta `id_shop` e `id_shop_group`
No hacer backup antes de tocar base de datos	Prisa, confianza excesiva, viernes por la tarde	Copia antes de modificar
Dejar debug activo	Se resuelve el error y se olvida el ajuste	Desactívalo tras diagnosticar
Confundir 503 de servidor con mantenimiento	Ambos usan el mismo código HTTP	Revisa diseño de página, headers y logs

Plan preventivo: cómo usar el modo mantenimiento sin sobresaltos

El mejor error 503 es el que dura exactamente lo previsto. Para eso conviene preparar el mantenimiento como se prepara una intervención quirúrgica menor: lista, horario, responsables, respaldo y salida de emergencia.

Antes del mantenimiento

Haz copia de seguridad de archivos y base de datos.
Anota la versión exacta de PrestaShop, PHP, tema y módulos críticos.
Define ventana horaria de baja actividad.
Añade IPs autorizadas de desarrolladores y responsables.
Comprueba acceso al hosting, FTP/SSH, base de datos y Back Office.
Prepara un plan de reversión.

Durante el mantenimiento

Activa modo mantenimiento.
Evita instalar varios módulos o cambios grandes a la vez.
Prueba compra, carrito, login, búsqueda y checkout.
Documenta cada cambio. Aunque sea en una nota fea. Sirve.
Vigila logs en tiempo real si estás tocando componentes críticos.

Después del mantenimiento

Desactiva mantenimiento.
Limpia todas las cachés.
Comprueba códigos HTTP con herramientas externas.
Realiza una compra de prueba si es posible.
Revisa Google Search Console al día siguiente.
Confirma que no quedan reglas temporales en servidor o CDN.

Preguntas frecuentes sobre el error 503 en PrestaShop

¿El error 503 en PrestaShop siempre significa que la tienda está caída?

No. Si el modo mantenimiento está activo, PrestaShop puede devolver 503 de forma intencionada. Es una señal temporal. Sin embargo, si aparece sin haber activado mantenimiento o afecta también al Back Office, puede indicar problemas de servidor, PHP, caché, módulos o configuración.

¿Por qué yo veo la tienda y mis clientes ven 503?

Probablemente tu IP está permitida o tienes una sesión administrativa activa. Prueba desde una ventana privada y otra red. También puede haber caché diferente por usuario, país o CDN.

¿Por qué añadí mi IP y sigo viendo mantenimiento?

Puede que tu IP haya cambiado, estés usando IPv6, una VPN, Cloudflare o un proxy. También puede ser caché del navegador, del hosting o de CDN. Revisa qué IP llega realmente al servidor mediante logs.

¿Puedo desactivar el modo mantenimiento desde phpMyAdmin?

Sí. En la tabla de configuración, normalmente ps_configuration, puedes establecer PS_SHOP_ENABLE en 1. Recuerda que el prefijo de tabla puede variar y que en multitienda debes revisar el contexto correcto.

¿El 503 afecta al SEO?

Un 503 breve y controlado suele ser correcto para SEO porque indica indisponibilidad temporal. El riesgo aparece si se mantiene durante demasiado tiempo, si se cachea accidentalmente o si afecta a páginas importantes durante días.

¿Qué hago si el Back Office también muestra 503?

Revisa logs del servidor, PHP-FPM, límites de recursos del hosting, errores PHP y reglas externas de mantenimiento. También puedes activar debug temporalmente desde config/defines.inc.php, siempre desactivándolo después.

Cierre: que el mantenimiento no se convierta en una persiana oxidada

El error 503 en PrestaShop durante el modo mantenimiento no es, por sí mismo, una catástrofe. Es una herramienta. Una pausa. Un cartel de “estamos trabajando”. Pero toda herramienta mal guardada termina en el suelo, y toda pausa demasiado larga empieza a parecer abandono.

La solución casi siempre está en una cadena de comprobaciones sensatas: estado de la tienda, IP autorizada, caché, base de datos, CDN, reglas del servidor, permisos, módulos y logs. Lo técnico y lo humano caminan juntos aquí: la máquina devuelve un código, pero la causa suele esconderse en una decisión anterior, en una prisa, en una regla temporal que nadie quitó.

PrestaShop puede ser robusto, flexible y generoso con quien lo entiende. Pero también es literal como una cerradura: si le dices que cierre, cierra. Si le das una IP equivocada, no improvisa. Si una caché conserva el 503, lo servirá con disciplina militar. Por eso el mantenimiento web exige método, paciencia y cierta desconfianza elegante.

Al final, una tienda online saludable no es la que nunca se detiene, sino la que sabe detenerse sin perder el camino de vuelta. 🔧🚀