PrestaShop Multistore: gestionar varias tiendas desde un solo panel de administración
Revisado en junio de 2026, el modelo de grupo de tiendas / tienda / URL de tienda y la pantalla Parámetros avanzados → Multitienda se aplican a PrestaShop 1.7, 8 y 9.
PrestaShop Multistore es la función a la que recurren los comerciantes cuando una tienda se convierte en tres: una tienda online alemana, otra francesa, un canal mayorista. La promesa resulta atractiva, gestionarlas todas desde una sola administración, compartir un único catálogo de productos e iniciar sesión una sola vez. Y, en gran medida, cumple. Pero Multistore no es un selector multiidioma ni una forma de unir negocios sin relación entre sí. Es una pieza concreta de la arquitectura de PrestaShop, con su propio modelo de contexto, sus propias trampas y una decisión (qué compartes frente a qué separas) que tomas una vez y con la que convives durante años. Esta guía trata de esa arquitectura y del día a día de operarla: qué te ofrece realmente el back office, dónde puede complicarte la vida el contexto de tienda y cuándo Multistore es, directamente, la herramienta equivocada.
Qué es realmente Multistore a nivel estructural

Por debajo, PrestaShop Multistore se organiza en tres niveles anidados, y entenderlos marca la diferencia entre administrar con seguridad y causar daños accidentales entre tiendas:
- Grupos de tiendas (la tabla shop_group, id_shop_group). Un grupo es el límite de compartición. Clientes, pedidos, stock disponible y carritos pueden compartirse dentro de un grupo, pero nunca entre grupos. Si dos tiendas deben compartir el acceso de cliente, tienen que estar en el mismo grupo.
- Tiendas (la tabla shop, id_shop). La tienda online individual: su propio tema, su propia selección de catálogo, sus propios valores de configuración.
- URL de tienda (la tabla shop_url). A cada tienda se accede mediante una o varias combinaciones de dominio/URI física: myshop.de, myshop.fr o shop.example.com/de. Esto es lo que asigna una solicitud entrante a la tienda correcta.
El sistema completo se activa en Parámetros avanzados → Multitienda (en instalaciones antiguas de la 1.6 estaba en Preferencias → General → Activar multitienda). Una vez activado, casi todas las páginas del back office incorporan un selector de contexto de tienda en la parte superior izquierda, y ese selector es el control más importante de una instalación Multistore: determina si el cambio que estás a punto de guardar se aplica a Todas las tiendas, a un grupo de tiendas o a una tienda individual.
El modelo de compartido frente a sobrescrito
El modelo de compartición no es un mecanismo universal único: funciona de forma distinta para las entidades de catálogo y para la configuración, y esa diferencia importa. Para datos de catálogo como productos, categorías y transportistas, PrestaShop mantiene un registro base y añade una tabla de asociación por tienda, product_shop, category_shop, carrier_shop y similares, que permite a una tienda concreta sobrescribir campos específicos (en un producto, por ejemplo el precio, el estado activo, la redirección o incluso el nombre) mientras hereda el resto. Así que realmente gestionas un solo producto, pero su precio en la tienda francesa y su visibilidad en la tienda mayorista pueden ser distintos. En cambio, los ajustes no son filas asociadas: viven en la tabla configuration con alcance de tienda y grupo de tiendas, de modo que un valor puede escribirse globalmente, por grupo o por tienda. Esta sobrescritura por capas es la ventaja real de Multistore frente a ejecutar instalaciones separadas: editas una vez y diferencias de forma deliberada.
Cuándo Multistore es la herramienta adecuada
Tiendas por país en dominios diferentes
El encaje más limpio. myshop.de, myshop.fr y myshop.es como tres tiendas en un mismo grupo, compartiendo productos y clientes, cada una con su propio tema, moneda predeterminada, idioma predeterminado y reglas fiscales. El stock se comparte, así que no tienes que conciliar tres inventarios. Esto es Multistore funcionando exactamente como fue diseñado, pero conviene marcar el límite con claridad: Multistore gestiona las tiendas online, pero por sí solo no te da monedas correctamente localizadas, visualización con impuestos incluidos por país ni hreflang. Esos son trabajos aparte que tratamos en vender en Europa: idiomas, monedas e impuestos y etiquetas hreflang.
Marcas premium y económicas, un solo almacén
Los mismos productos físicos, dos tiendas online con nombres, temas y niveles de precio distintos, alimentadas desde un único stock compartido. La sobrescritura de precio por tienda y el nombre de producto por tienda convierten esto en unos pocos clics, no en un catálogo duplicado.
B2B y B2C en paralelo
Una tienda minorista que muestra precios con impuestos incluidos y una tienda mayorista que muestra precios netos, cantidades mínimas de pedido y pago por factura, ambas sobre la misma base de datos de productos. Los grupos de clientes más una segunda tienda en el mismo grupo te dan stock compartido con reglas comerciales completamente distintas.
Varias tiendas de nicho con solapamiento parcial de productos
Tiendas de jardín, cocina y baño que comparten una parte del catálogo pero tienen marcas diferenciadas. El solapamiento es lo que justifica Multistore; los productos compartidos amortizan el sistema cada vez que actualizas uno y el cambio se propaga.
Cuándo Multistore es la herramienta equivocada
Solo quieres más idiomas
Este es el error más habitual. PrestaShop es multilingüe dentro de una única tienda: todos los campos traducibles (nombre de producto, descripción, CMS, meta) se almacenan por idioma en tablas _lang, y los idiomas se añaden en Internacional → Localización → Idiomas. Si lo único que necesitas es contenido en inglés y francés con los mismos precios, Multistore añade gestión de contextos sin aportar nada. Hazlo de la forma estándar; consulta configuración de una tienda multiidioma.
Las tiendas no tienen relación real entre sí
Comida para mascotas y electrónica, sin productos compartidos, sin clientes compartidos, sin operaciones compartidas. En ese caso, Multistore te impone el coste de la complejidad sin ningún beneficio de compartición. Dos instalaciones separadas son más fáciles de entender, más fáciles de respaldar de forma independiente e imposibles de contaminar entre sí por una edición en el contexto equivocado. Multistore se justifica por el solapamiento; con solapamiento cero es pura sobrecarga.
Una sola persona, ya al límite
Cada edición en Multistore trae consigo la pregunta "¿en qué contexto estoy?". Un operador en solitario que olvide el selector una sola vez puede aplicar un precio o un estado desactivado a todas las tiendas. Si el equipo es pequeño y la disciplina todavía no está asentada, la carga cognitiva puede costar más que tener instalaciones separadas.
El contexto de tienda: donde Multistore de verdad puede fallar
El selector de contexto no es una comodidad: es un alcance activo que cambia lo que hace el botón de guardar:
[SCREENSHOT: desplegable del selector de contexto de tienda en la parte superior izquierda del back office abierto, mostrando "Todas las tiendas", un grupo de tiendas y tiendas individuales como alcance seleccionable]| Contexto | Qué hace al guardar | Cuándo usarlo |
|---|---|---|
| Todas las tiendas | Escribe el valor en todas las tiendas a la vez (y establece el registro compartido/predeterminado) | Un cambio verdaderamente global: una nueva regla fiscal para todas las tiendas, un ajuste que quieres en todas partes |
| Grupo de tiendas | Se aplica a todas las tiendas de ese grupo | Ajustes que deben coincidir dentro de un mismo grupo de mercado, pero no en otros |
| Tienda individual | Escribe una sobrescritura por tienda; las demás tiendas conservan su valor | El precio francés, el tema alemán, la página de inicio de una tienda |
En las páginas de producto, categoría y configuración, dentro del contexto de una sola tienda, verás una pequeña casilla junto a muchos campos: ese es el conmutador de sobrescritura. Márcala y el campo se separa del valor compartido solo para esta tienda. Déjala sin marcar y la tienda hereda el valor. La regla práctica que seguimos es esta: lee en voz alta el selector de contexto antes de hacer clic en Guardar. Editar en modo "Todas las tiendas" cuando pretendías tocar una sola tienda es el error más caro de Multistore, y no genera ningún aviso: simplemente hace en silencio exactamente lo que le has pedido, en todas partes.
Compartición de datos: la decisión que tomas una vez
Para cada tipo de dato eliges compartir o separar al crear la tienda, y cambiar de opinión después implica una migración. Los valores predeterminados razonables son estos:
- Productos, normalmente compartidos. Un catálogo, con sobrescrituras por tienda para precio, nombre y visibilidad. Esta es la principal ganancia de eficiencia.
- Clientes y carritos, compartidos dentro de un grupo cuando la misma persona debe iniciar sesión en todos tus mercados; separados (grupos distintos) para marcas realmente independientes donde una identidad común no tiene sentido.
- Pedidos, siempre conservan la tienda de origen (cada pedido lleva su id_shop). Si el grupo de tiendas está configurado para compartir pedidos, pueden ser visibles y compartirse dentro de ese grupo; de lo contrario, un pedido queda limitado a su propia tienda. En cualquier caso, puedes ver y procesar los pedidos de todas las tiendas desde una sola lista de Pedidos, que es la ventaja de la preparación de pedidos centralizada.
- Cantidades disponibles (stock). Pueden compartirse dentro de un grupo de tiendas cuando la opción "compartir cantidades disponibles" del grupo está activada, que es lo que permite los escenarios de un solo almacén; de lo contrario, el stock queda por tienda.
- Categorías y CMS. Pueden compartirse, pero a menudo conviene separarlos: un árbol de productos compartido, pero páginas legales localizadas y una página de inicio específica por país.
El problema de compatibilidad de los módulos
Este es el mayor riesgo práctico, y es real. Que un módulo sea compatible con Multistore no es automático: el desarrollador tiene que construirlo así. Un módulo que ignora Multistore hará lo siguiente:
- Ignorar el contexto de tienda y aplicar cada cambio a todas las tiendas, porque lee y escribe configuración con Configuration::get() / Configuration::updateValue() sin pasar el id de tienda ni respetar Shop::CONTEXT_SHOP.
- Guardar ajustes globalmente, de modo que no puedas dar valores distintos a dos tiendas: la segunda tienda sobrescribe la primera.
- Crear sus propias tablas de base de datos sin una columna id_shop, por lo que sus datos se comparten inevitablemente incluso cuando deberían ser por tienda.
- Funcionar bien en la tienda principal y romperse, o filtrar datos en silencio, en cualquier otro contexto de tienda.
Un módulo bien construido lee sus ajustes con el id de tienda (Configuration::get('MY_KEY', null, $id_shop_group, $id_shop) a través del contexto de tienda), añade id_shop a sus tablas y registra hooks por tienda. Antes de comprometerte con Multistore, audita todos los módulos de los que dependes. Revisa la documentación, pregunta directamente al desarrollador y, esto no es negociable, prueba en una instalación de preproducción con al menos dos tiendas antes de construir el entorno real. Descubrir que un módulo crítico no es compatible con Multistore después de haber montado tres tiendas en producción es una tarde francamente mala.
Precisamente por eso desarrollamos como lo hacemos. Nuestras suites de módulos están escritas para respetar el contexto de tienda desde la capa de datos, de modo que un ajuste que cambias en la tienda francesa se queda en la tienda francesa y las tablas de un módulo llevan su id_shop en lugar de mezclar datos entre todas las tiendas. Esa es la diferencia entre una instalación Multistore en la que puedes confiar y otra en la que cada guardado de configuración es una pequeña apuesta; relevante tanto si gestionas gestión SEO, facturación o contenido en la tienda en tus tiendas. Verifica siempre módulo por módulo, pero el sentido de comprar a un desarrollador que prueba en multitienda es no heredar el problema de compatibilidad anterior.
Monedas, banderas y detalles del escaparate por tienda
Multistore da a cada tienda su propia moneda predeterminada y su propio conjunto de idiomas activos, pero las piezas que ve el cliente, el selector de moneda, las banderas de idioma, la forma en que un visitante recurrente aterriza en la tienda correcta. Son trabajo del escaparate que se apoya sobre Multistore, no algo que Multistore resuelva internamente. Afinar esos pequeños detalles es lo que evita que un visitante internacional se marche; los tratamos en selector de moneda y banderas de idioma, y la mecánica completa de gestionar precios en varias monedas en la guía de configuración multimoneda.
Consejos prácticos de gestión
- Lee el selector de contexto antes de cada guardado. Es el hábito que evita el error más costoso de Multistore. Trata "Todas las tiendas" como un ajuste delicado.
- Nombra los recursos específicos de tienda por tienda. banner-myshop-de.jpg, no banner.jpg. Cuando subes logotipos e imágenes de tema por tienda, el nombre del archivo es tu único recordatorio de en qué tienda estás.
- Prueba en el contexto de cada tienda. Un ajuste de tema que se ve bien en la Tienda A puede romperse en la Tienda B con otro tema u otra configuración de módulo. Después de un cambio, revisa el front office real de cada tienda, no solo el principal.
- Haz una copia de seguridad antes de los cambios estructurales. Una edición en el contexto equivocado puede propagarse por todas las tiendas a la vez; un volcado reciente de la base de datos es tu botón de deshacer.
- Documenta el mapa de tiendas. Qué tiendas están en qué grupo, qué se comparte y qué se sobrescribe, qué módulos son específicos por tienda. Cuando algo falla o se incorpora alguien nuevo, este es el documento que salva el día.
- Vigila la asignación de shop_url. Los ajustes SSL, la marca de URL principal y la URI física/virtual por tienda son fáciles de configurar mal y pueden producir bucles de redirección o cargar la tienda equivocada. Revísalos en Parámetros avanzados → Multitienda → la URL de cada tienda.
Consideraciones de rendimiento
Cada consulta de Multistore lleva un filtro de tienda: PrestaShop hace joins con las tablas de asociación _shop y filtra por id_shop en la mayoría de lecturas de catálogo y configuración. Para dos o tres tiendas con catálogos normales, esta sobrecarga es insignificante. Para diez o más tiendas con catálogos grandes, se vuelve medible, y la solución es higiene ordinaria de base de datos: asegúrate de que existen índices en las columnas id_shop de las tablas de asociación pesadas, mantén controlados tus recuentos de categorías y productos, y apóyate en la caché de página completa para que el front office no vuelva a ejecutar consultas filtradas por tienda en cada visita. Mídelo en tu propia instalación: activa Multistore y observa los tiempos de consulta en el perfilador de depuración antes de asumir que hay un problema.
Preguntas frecuentes
¿Es Multistore la forma correcta de añadir más idiomas?
No; este es el error más habitual. PrestaShop es multilingüe dentro de una única tienda: cada campo traducible se almacena por idioma en tablas _lang, y los idiomas se añaden en Internacional → Localización → Idiomas. Si lo único que necesitas es el mismo catálogo con los mismos precios en inglés y francés, Multistore añade gestión de contextos sin aportar nada. Usa los campos multilingües integrados; consulta configuración de una tienda multiidioma. Recurre a Multistore solo cuando los mercados necesiten catálogos, estructuras de precios o marcas realmente diferentes.
¿Cuál es el error más caro en Multistore?
Guardar en el contexto "Todas las tiendas" cuando querías tocar una sola tienda. El selector de contexto (arriba a la izquierda) es un alcance activo: en modo "Todas las tiendas", un guardado escribe el valor en todas las tiendas a la vez, y no genera ningún error; hace en silencio exactamente lo que le dijiste, en todas partes. El hábito que lo evita es sencillo: lee en voz alta el selector de contexto antes de hacer clic en Guardar y trata "Todas las tiendas" como un ajuste delicado.
¿Pueden mis tiendas compartir clientes y stock?
Dentro de un grupo de tiendas, sí. Un grupo de tiendas es el límite de compartición: clientes, carritos y stock disponible pueden compartirse dentro de un grupo, pero nunca entre grupos. Así que, si dos tiendas deben compartir un acceso de cliente, tienen que estar en el mismo grupo, y el stock compartido (cuando la opción "compartir cantidades disponibles" del grupo está activada) es lo que permite los escenarios de un solo almacén. Los pedidos siempre conservan el id_shop de su tienda de origen, pero puedes procesar los pedidos de todas las tiendas desde una sola lista de Pedidos.
¿Cómo sé si un módulo es seguro para usarlo en varias tiendas?
Tienes que verificarlo: que sea compatible con Multistore no es automático, el desarrollador tiene que construirlo así. Un módulo que ignora el contexto de tienda aplicará cada cambio a todas las tiendas, guardará los ajustes globalmente para que dos tiendas no puedan diferir, o creará tablas sin una columna id_shop, de modo que sus datos se compartirán inevitablemente. Un módulo bien construido lee los ajustes con el id de tienda (Configuration::get('MY_KEY', null, $id_shop_group, $id_shop)), añade id_shop a sus tablas y registra hooks por tienda. Prueba cada dependencia en una instalación de preproducción con al menos dos tiendas antes de construir el entorno real. Nuestras suites de módulos están escritas para respetar el contexto de tienda desde la capa de datos, relevante tanto si gestionas gestión SEO, facturación o contenido en la tienda en tus tiendas.
¿Multistore gestiona por mí monedas, impuestos y hreflang por país?
No; Multistore gestiona las tiendas online. Cada tienda recibe su propia moneda predeterminada y su conjunto de idiomas activos, pero la visualización de moneda correctamente localizada, los precios con impuestos incluidos por país y hreflang entre dominios separados son trabajos aparte que se construyen encima. Consulta vender en Europa para moneda e impuestos, y etiquetas hreflang para la señalización SEO entre dominios que el núcleo no ensamblará entre tiendas.
Lecturas relacionadas
- Configuración de una tienda multiidioma, la herramienta adecuada cuando solo necesitas más idiomas, no más tiendas.
- Vender en Europa, la capa de moneda, impuestos y OSS que Multistore no resuelve por sí solo.
- Etiquetas hreflang. La reciprocidad entre dominios es el caso difícil cuando cada mercado tiene su propia tienda.
La conclusión
Multistore es la respuesta correcta cuando tus tiendas realmente se solapan: productos compartidos, clientes compartidos, stock compartido, y quieres variar deliberadamente el escaparate, los precios y la marca sobre ese núcleo común. Es la respuesta equivocada para "solo necesito más idiomas" (usa los campos multilingües integrados) y para negocios realmente separados (usa instalaciones separadas). Acierta desde el principio con la decisión de compartir frente a separar, respeta religiosamente el selector de contexto, verifica que tus módulos respetan el contexto de tienda antes de construir, y Multistore convierte la administración equivalente a tres instalaciones en una sola. La disciplina de configuración es el precio; la simplicidad operativa diaria es lo que compras.
Para una guía paso a paso sobre cómo crear tu primer grupo de tiendas y tu primera tienda, consulta nuestra guía de la base de conocimiento Cómo configurar PrestaShop Multistore.
Comentarios
Dejar un comentario
Comparte una pregunta, un detalle de instalación o una opinión que pueda ayudar a otro lector.