WordPress Multisite No Es Multi-Site: Arquitectura Que Escala a 500 Ubicaciones

WordPress Multisite suena como si obtuvieras múltiples sitios. Lo que realmente obtienes es una instalación de WordPress que pretende ser múltiples sitios agregando un número delante de los nombres de las tablas de la base de datos. Tu sitio principal usa wp_posts. El subsitio 2 usa wp_2_posts. El subsitio 3 usa wp_3_posts. Eso no es arquitectura multi-sitio. Eso es una base de datos con copias numeradas de las mismas tablas. Y tiene consecuencias.

He migrado redes con 15, 40 y una vez 87 subsitios fuera de WordPress Multisite. Cada vez, el cliente pensaba que estaba obteniendo sitios independientes. Cada vez, descubrieron de la manera difícil que no lo eran. Si ejecutas una franquicia, un negocio de múltiples ubicaciones o una red de departamentos universitarios en WordPress Multisite, este artículo va a doler un poco. Pero es mejor saberlo ahora que después de que el subsitio #47 derrumbe a los otros 46.

Tabla de Contenidos

WordPress Multisite Is Not Multi-Site: Architecture That Scales to 500 Locations

Lo Que WordPress Multisite Realmente Hace Bajo el Capó

Veamos qué sucede cuando activas Multisite en WordPress. Agregas un par de líneas a wp-config.php:

define('WP_ALLOW_MULTISITE', true);
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', false);
define('DOMAIN_CURRENT_SITE', 'example.com');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);

WordPress luego crea algunas tablas a nivel de red (wp_blogs, wp_site, wp_sitemeta, wp_registration_log, wp_signups) y comienza a duplicar tu estructura de tabla principal para cada nuevo subsitio.

Así se ve la base de datos después de solo 5 subsitios:

wp_posts              (sitio principal)
wp_postmeta           (sitio principal)
wp_options            (sitio principal)
wp_users              (compartido - todos los sitios)
wp_usermeta           (compartido - todos los sitios)
wp_2_posts            (subsitio 2)
wp_2_postmeta         (subsitio 2)
wp_2_options          (subsitio 2)
wp_3_posts            (subsitio 3)
wp_3_postmeta         (subsitio 3)
wp_3_options          (subsitio 3)
...
wp_5_posts            (subsitio 5)
wp_5_postmeta         (subsitio 5)
wp_5_options          (subsitio 5)

Cinco subsitios y ya tienes aproximadamente 55 tablas. ¿Cincuenta subsitios? Estás mirando más de 500 tablas en una única base de datos MySQL. ¿Quinientas ubicaciones? Más de 5.000 tablas. En una base de datos. Compartiendo un grupo de conexión.

Cada tabla tiene sus propios índices. Cada consulta apunta a una tabla con prefijo específico. El planificador de consultas tiene que lidiar con todo esto. Y todas y cada una de esas tablas son accesibles para cualquier proceso PHP que se ejecute en ese servidor, porque están todas en la misma base de datos con las mismas credenciales.

Esto no es arquitectura multi-sitio. Esto es una convención de nombres disfrazada de aislamiento.

Las 7 Consecuencias de la Arquitectura de Multi-Sitio Falsa

1. Superficie de Vulnerabilidad Compartida

Cada subsitio en una red de WordPress Multisite ejecuta el mismo núcleo de WordPress, los mismos plugins y los mismos temas. Un exploit de plugin compromete todos los subsitios porque comparten la misma base de código.

Esto no es teórico. En febrero de 2026, WPVivid — un plugin de copia de seguridad con más de 900.000 instalaciones activas — tuvo una vulnerabilidad RCE (Ejecución Remota de Código) con severidad 9.8 divulgada. Severidad 9.8 de 10. Eso es territorio de "un atacante no autenticado puede ejecutar código arbitrario en tu servidor".

En un sitio de WordPress independiente, eso es un sitio comprometido. En una red Multisite con 30 subsitios? Eso es 30 sitios comprometidos. Mismo servidor. Misma base de datos. Mismo sistema de archivos. Un exploit, compromiso de toda la red.

No puedes instalar una versión diferente de un plugin en el subsitio #12 que en el subsitio #13. No puedes aislar los plugins de una ubicación de otra. Cada sitio obtiene la misma superficie de ataque.

2. Multiplicación de Conflictos de Plugin

En un sitio de WordPress único, un conflicto de plugin rompe un sitio. Desactivas el plugin, diagnosticas, continúas. Molesto pero manejable.

En Multisite, un conflicto de plugin activado a nivel de red rompe todos los sitios simultáneamente. He visto una actualización de WooCommerce en una red Multisite derribar 23 páginas de ubicación a la vez porque un plugin de caché activado a nivel de red no se había actualizado para los nuevos hooks de WooCommerce. Veintitrés ubicaciones con páginas rotas. Una causa raíz, veintitrés gerentes de ubicación enojados llamando a la misma persona.

Y aquí está el truco — los administradores de sitios individuales generalmente no pueden desactivar plugins activados a nivel de red. Tienen que esperar a que el Super Admin lo solucione.

3. Degradación del Rendimiento

Cincuenta subsitios compartiendo una instancia MySQL. Cada carga de página en el subsitio #47 ejecuta consultas como:

SELECT * FROM wp_47_posts WHERE post_type = 'page' AND post_status = 'publish';
SELECT option_value FROM wp_47_options WHERE option_name = 'active_plugins';
SELECT * FROM wp_47_postmeta WHERE post_id IN (142, 143, 144, 145);

Mientras tanto, el subsitio #12 ejecuta su propio conjunto de consultas contra wp_12_posts, wp_12_options y wp_12_postmeta. Y también lo hace todos los demás subsitios, todos golpeando la misma instancia MySQL.

El planificador de consultas de MySQL se confunde. El caché de tabla se llena. Cada tabla con prefijo mantiene sus propios índices, pero el pool de búfer se comparte. El rendimiento se degrada de forma no lineal a medida que agregas subsitios. Ir de 10 a 20 subsitios no es el doble de carga — puede ser tres o cuatro veces la carga dependiendo de los patrones de tráfico, debido a la contención de bloqueos y el thrashing del pool de búfer.

Benchmarqueé una red de 40 subsitios una vez. El tiempo de consulta promedio en el subsitio #1 era de 45ms. Para cuando probamos el subsitio #38, el tiempo de consulta promedio había subido a 380ms. Misma estructura de consulta. Mismo volumen de datos por sitio. La base de datos simplemente estaba ahogándose en tablas.

4. La Migración Es una Pesadilla

Intenta extraer el subsitio #23 de una red de 50 sitios en su propia instalación de WordPress independiente. Aquí está lo que necesitas hacer:

  1. Exporta todas las tablas con prefijo wp_23_
  2. Remapea cada tabla del prefijo wp_23_ al prefijo wp_
  3. Deserializa todas las opciones y datos de widget (WordPress almacena PHP serializado en la base de datos, y las longitudes de cadena cambian cuando cambias prefijos)
  4. Remapea rutas de medios de /uploads/sites/23/ a /uploads/
  5. Busca y reemplaza todas las URLs internas
  6. Remapea capacidades de usuario de wp_23_capabilities a wp_capabilities en wp_usermeta
  7. Extrae usuarios de la tabla compartida wp_users (solo los que pertenecen al subsitio #23)
  8. Recrea relaciones usuario-a-sitio

Un error en la serialización y obtienes datos dañados. Las configuraciones de widget desaparecen. Las opciones del personalizador de temas se rompen. Las estructuras de menú se desvanecen. He hecho este proceso de extracción docenas de veces, y toma 4-8 horas por subsitio incluso con herramientas como WP Migrate DB Pro. Multiplica eso por 50 subsitios si estás desmantelando una red.

El ecosistema de WordPress tiene herramientas para esto, seguro. Pero el hecho de que esas herramientas necesiten existir te dice algo sobre la arquitectura.

5. Sin Aislamiento de Datos Verdadero

Este es el que debería aterrarte si te importa la seguridad o el cumplimiento normativo.

Una vulnerabilidad de inyección SQL en el subsitio #2 no solo expone wp_2_posts. El usuario de base de datos que se conecta a MySQL tiene acceso a todas las tablas en la base de datos. Eso significa wp_posts (sitio principal), wp_3_posts (subsitio 3), wp_users (todos los usuarios en todos los sitios) y todas las demás tablas.

No hay aislamiento a nivel de base de datos. No hay seguridad a nivel de fila. No hay separación de esquema. WordPress Multisite es una base de datos, un conjunto de credenciales y una convención de nombres. Eso es todo.

Para empresas que manejan datos de clientes en múltiples ubicaciones — consultorios médicos, despachos de abogados, servicios financieros — esto es un problema de cumplimiento normativo. HIPAA, SOC 2 y PCI DSS tienen requisitos alrededor del aislamiento de datos. "Usamos diferentes prefijos de tabla" no va a satisfacer a un auditor.

6. Cuello de Botella del Super Admin

WordPress Multisite tiene un rol llamado Super Admin. Solo el Super Admin puede:

  • Instalar o eliminar plugins
  • Instalar o eliminar temas
  • Activar plugins a nivel de red
  • Agregar nuevos sitios a la red
  • Administrar configuración de red

Los administradores de sitios individuales tienen capacidades restringidas. No pueden instalar sus propios plugins. No pueden agregar sus propios temas. Todo cambio que toque la infraestructura compartida se encamina a través de una persona (o un pequeño equipo).

Para una red de 3 sitios, esto está bien. Para una franquicia de 50 ubicaciones donde cada gerente de ubicación quiere agregar su propio widget de reserva o plugin de PDF de menú? Es un cuello de botella que genera resentimiento e IT paralela.

7. Fragilidad del Mapeo de Dominio

¿Quieres que cada ubicación tenga su propio dominio? denver.yourbrand.com o yourbrand-denver.com? WordPress Multisite no maneja esto nativamente de manera confiable. Necesitas una solución de mapeo de dominio, y el enfoque dropin sunrise.php incorporado es notoriamente complicado.

Los certificados SSL para dominios mapeados agregan otra capa. La configuración de DNS agrega otra. Cada dominio mapeado es otro punto potencial de fallo que tu Super Admin tiene que administrar. Un cambio de DNS, un certificado expirado, una entrada de mapeo mal configurada, y el sitio de una ubicación se cae.

Cuándo WordPress Multisite Funciona (Honestamente)

No voy a pretender que es inútil. WordPress Multisite funciona bien en escenarios específicos:

  • Redes pequeñas (menos de 10 sitios) donde todos los sitios son administrados por el mismo equipo
  • Sitios de departamentos universitarios donde el control centralizado es realmente deseado
  • Espejos de desarrollo/staging/producción para el mismo proyecto
  • Redes de blogs donde el aislamiento de contenido no es crítico

Si tienes 5-8 sitios, un administrador de sistemas competente, y no necesitas aislamiento de datos entre sitios — Multisite está bien. Los problemas comienzan cuando intentas escalarlo a docenas o cientos de ubicaciones.

WordPress Multisite Is Not Multi-Site: Architecture That Scales to 500 Locations - architecture

La Arquitectura Que Realmente Escala a 500 Ubicaciones

Aquí está el enfoque alternativo que usamos en Social Animal para negocios multi-ubicación: una arquitectura headless con Next.js en el frontend y Supabase (PostgreSQL) en el backend, utilizando Row-Level Security (RLS) para un verdadero aislamiento de datos.

La idea central: en lugar de duplicar tablas para cada ubicación, tienes un conjunto de tablas con una columna location_id. Las políticas de seguridad a nivel de base de datos aseguran que las consultas solo devuelvan datos para la ubicación autorizada. Y en lugar de 500 instalaciones de WordPress independientes fingiendo ser independientes, tienes un despliegue de aplicación donde /locations/[slug] renderiza dinámicamente la página de cada ubicación desde una fila de base de datos.

Cómo Funciona Realmente la Seguridad a Nivel de Fila

-- Crear la tabla de ubicaciones
CREATE TABLE locations (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  slug TEXT UNIQUE NOT NULL,
  name TEXT NOT NULL,
  address TEXT,
  phone TEXT,
  hours JSONB,
  metadata JSONB,
  created_at TIMESTAMPTZ DEFAULT now()
);

-- Crear la tabla de páginas con aislamiento de ubicación
CREATE TABLE pages (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  location_id UUID REFERENCES locations(id),
  title TEXT NOT NULL,
  content JSONB,
  slug TEXT NOT NULL,
  published BOOLEAN DEFAULT false,
  created_at TIMESTAMPTZ DEFAULT now()
);

-- Habilitar RLS
ALTER TABLE pages ENABLE ROW LEVEL SECURITY;

-- Política: los gerentes de ubicación solo pueden ver las páginas de su propia ubicación
CREATE POLICY "location_isolation" ON pages
  FOR ALL
  USING (location_id = (SELECT location_id FROM user_locations WHERE user_id = auth.uid()));

-- Política: el público puede leer páginas publicadas para cualquier ubicación
CREATE POLICY "public_read" ON pages
  FOR SELECT
  USING (published = true);

Con esta configuración, un gerente de ubicación en Denver que de alguna manera elabora una consulta maliciosa físicamente no puede acceder a los datos de Austin. La base de datos lo asegura. No la capa de aplicación. No una convención de nombres. La base de datos misma.

Comparación de Arquitectura: Tablas con Prefijo vs Seguridad a Nivel de Fila

Aquí hay una representación visual de las dos arquitecturas:

Arquitectura de WordPress Multisite:

┌─────────────────────────────────────────────┐
│        Base de Datos MySQL Única             │
│                                             │
│  wp_posts          (sitio principal)        │
│  wp_options        (sitio principal)        │
│  wp_2_posts        (Denver)                 │
│  wp_2_options      (Denver)                 │
│  wp_3_posts        (Austin)                 │
│  wp_3_options      (Austin)                 │
│  wp_4_posts        (Seattle)                │
│  wp_4_options      (Seattle)                │
│  ... x 500 ubicaciones = 5.000+ tablas     │
│                                             │
│  ⚠️  UN conjunto de credenciales de BD      │
│  ⚠️  UN proceso PHP accede a TODAS las tablas
│  ⚠️  CERO aislamiento a nivel de base de datos
└─────────────────────────────────────────────┘

Arquitectura Next.js + Supabase:

┌─────────────────────────────────────────────┐
│      Base de Datos PostgreSQL Única         │
│                                             │
│  locations    (500 filas, una por ubicación)
│  pages        (contenido por ubicación)     │
│  media        (imágenes por ubicación)      │
│  staff        (equipo por ubicación)        │
│  reviews      (reseñas por ubicación)       │
│                                             │
│  ✅  Las políticas RLS aseguran aislamiento  │
│  ✅  El usuario de Denver NO PUEDE consultar datos de Austin
│  ✅  5 tablas totales, no 5.000             │
│  ✅  Índices estándar, planes de consulta óptimos
└─────────────────────────────────────────────┘

Una base de datos en ambos casos. Pero el modelo de aislamiento es fundamentalmente diferente. RLS se asegura en el nivel del motor PostgreSQL — no es algo que la aplicación pueda eludir.

Factor WordPress Multisite Next.js + Supabase
Tablas en 500 ubicaciones ~5.500+ ~5-15
Aislamiento de datos Ninguno (solo convención de nombres) RLS asegurado por base de datos
Superficie de vulnerabilidad Un exploit = todos los sitios Aislamiento de auth por ubicación
Conflictos de plugin Caída de toda la red N/A (sin arquitectura de plugin)
Agregar una ubicación Crear subsitio + configurar Insertar fila de base de datos
Eliminar una ubicación Proceso de extracción complejo Eliminar filas con CASCADE
Mapeo de dominio Plugin requerido, frágil Reescritura de middleware, nativa
Tiempo de build/deploy N/A (PHP en tiempo de ejecución) ~30s build incremental
TTFB (promedio, sin caché) 800ms-2s+ 50-150ms (edge)
Alojamiento mensual (500 sitios) $200-800/mes (WordPress administrado) $25-75/mes (Supabase + Vercel)
Recuperación de compromiso Remediación de toda la red Rotar claves, redeploy

Implementación: Next.js + Supabase para Sitios Multi-Ubicación

Así es como funciona el enrutamiento en la práctica con Next.js:

// app/locations/[slug]/page.tsx
import { createClient } from '@/lib/supabase/server';
import { notFound } from 'next/navigation';

export async function generateStaticParams() {
  const supabase = createClient();
  const { data: locations } = await supabase
    .from('locations')
    .select('slug');
  
  return locations?.map(({ slug }) => ({ slug })) ?? [];
}

export default async function LocationPage({ 
  params 
}: { 
  params: { slug: string } 
}) {
  const supabase = createClient();
  
  const { data: location } = await supabase
    .from('locations')
    .select(`
      *,
      pages(*),
      staff(*),
      reviews(*, rating)
    `)
    .eq('slug', params.slug)
    .single();
  
  if (!location) notFound();
  
  return (
    <div>
      <h1>{location.name}</h1>
      <LocationHero location={location} />
      <LocationServices pages={location.pages} />
      <LocationTeam staff={location.staff} />
      <LocationReviews reviews={location.reviews} />
    </div>
  );
}

¿Agregar una nueva ubicación? Insertar una fila:

INSERT INTO locations (slug, name, address, phone, hours)
VALUES (
  'portland-or',
  'Portland, OR',
  '123 Burnside St, Portland, OR 97209',
  '(503) 555-0142',
  '{"mon": "9-5", "tue": "9-5", "wed": "9-5"}'
);

Eso es todo. El próximo build lo recoge. O si estás usando ISR (Regeneración Estática Incremental), aparece dentro de tu ventana de revalidación sin una compilación completa.

¿Eliminar una ubicación? DELETE FROM locations WHERE slug = 'portland-or'; Las eliminaciones en cascada manejan el resto. Sin proceso de extracción de 4-8 horas.

Para dominios personalizados por ubicación, Next.js middleware lo maneja limpiamente:

// middleware.ts
import { NextResponse } from 'next/server';

const DOMAIN_MAP: Record<string, string> = {
  'yourbrand-denver.com': '/locations/denver-co',
  'yourbrand-austin.com': '/locations/austin-tx',
  // ... cargado desde config de edge en producción
};

export function middleware(request: Request) {
  const hostname = new URL(request.url).hostname;
  const rewritePath = DOMAIN_MAP[hostname];
  
  if (rewritePath) {
    return NextResponse.rewrite(new URL(rewritePath, request.url));
  }
  
  return NextResponse.next();
}

Sin plugins. Sin dropin sunrise.php. Sin reglas de mapeo frágiles. Solo una reescritura en el edge.

Ruta de Migración: Saliendo de WordPress Multisite

Si actualmente estás en WordPress Multisite con 20+ ubicaciones, aquí está la ruta de migración realista:

Fase 1: Exportación de Datos (1-2 semanas)

Extrae contenido de cada subsitio usando la API REST de WordPress o WP-CLI. No intentes reasignar manualmente tablas con prefijo. Usa la API — abstrae la pesadilla del prefijo.

# Exportar todos los posts del subsitio 23
wp post list --url=example.com/location-23 --format=json > location-23-posts.json

# Exportar todos los medios
wp media list --url=example.com/location-23 --format=json > location-23-media.json

Fase 2: Diseño de Esquema (1 semana)

Diseña tu esquema de Supabase alrededor de tu modelo de contenido real, no del modelo post/postmeta de WordPress. Este es el momento para corregir años de deuda de modelo de datos acumulada.

Fase 3: Migración de Contenido (1-2 semanas)

Escribe scripts de migración que transformen contenido de WordPress en tu nuevo esquema. Maneja datos serializados, shortcodes y bloques de Gutenberg.

Fase 4: Construcción del Frontend (3-4 semanas)

Construye el frontend de Next.js. Aquí es donde ves las ganancias reales de rendimiento. Las páginas que tomaban 1.5 segundos en WordPress ahora se cargan en menos de 200ms.

Fase 5: Cutover de DNS (1 día)

Apunta tus dominios a la nueva infraestructura. Mantén la red antigua corriendo como copia de seguridad de solo lectura durante 30 días.

Para empresas que necesitan ayuda con este proceso de migración, hemos documentado nuestro enfoque en nuestra página de desarrollo de CMS headless. Hemos hecho suficientes de estas migraciones para saber dónde están los cuerpos enterrados.

Números Reales: Comparación de Rendimiento y Costo

Aquí hay datos de una migración real que completamos en Q1 2025 — una red de consultorios dentales con 34 ubicaciones:

Métrica WordPress Multisite (Antes) Next.js + Supabase (Después)
TTFB promedio 1.240ms 89ms
Largest Contentful Paint 3.8s 1.1s
Costo de alojamiento mensual $347/mes (WP Engine) $45/mes (Vercel Pro + Supabase Pro)
Tiempo para agregar nueva ubicación 2-3 horas (configuración manual) 15 minutos (insertar fila + contenido)
Tiempo para actualizar todas las ubicaciones Actualización de plugin + oración git push
Tasa de aprobación de Core Web Vitals 12 de 34 ubicaciones 34 de 34 ubicaciones
Incidentes de seguridad (12 meses) 3 0

La reducción de costo de alojamiento por sí sola pagó la migración dentro de 8 meses. Las mejoras de rendimiento impulsaron aumentos medibles en los rankings locales de búsqueda para 28 de las 34 ubicaciones dentro de 90 días.

Si estás evaluando costos para tu propia red, nuestra página de precios tiene desgloses transparentes para proyectos multi-ubicación.

Preguntas Frecuentes

¿Es WordPress Multisite bueno para administrar múltiples ubicaciones? Para un pequeño número de ubicaciones (menos de 10) con administración centralizada, WordPress Multisite puede funcionar. Pero no fue diseñado para negocios multi-ubicación que necesitan operación independiente, aislamiento de datos o alto rendimiento en escala. La arquitectura de base de datos compartida crea problemas de seguridad, rendimiento y operativos que se agravan con cada ubicación que agregas.

¿Cuáles son los problemas más grandes con WordPress Multisite? Los siete problemas principales son: superficie de vulnerabilidad compartida (un exploit afecta todos los sitios), multiplicación de conflictos de plugin (un conflicto derriba todos los sitios), degradación de rendimiento no lineal, procesos de migración/extracción pesadilla, cero aislamiento de datos a nivel de base de datos, cuello de botella de Super Admin para todos los cambios administrativos, y mapeo de dominio frágil. Estos problemas son arquitectónicos — no pueden ser corregidos con plugins o mejor alojamiento.

¿Puede WordPress Multisite manejar 100+ sitios? Técnicamente, sí. Prácticamente, se vuelve muy doloroso después de 30-50 sitios. Con 100 sitios estás tratando con 1.100+ tablas de base de datos en una única instancia MySQL, degradación severa del planificador de consultas, y complejidad operativa que requiere personal de DevOps dedicado. Con 500 sitios, no es viable para la mayoría de los entornos de alojamiento.

¿Cuál es la mejor alternativa a WordPress Multisite para múltiples ubicaciones? Una arquitectura headless usando Next.js o Astro para el frontend con una base de datos PostgreSQL (como Supabase) usando Row-Level Security proporciona verdadero aislamiento de datos, rendimiento dramáticamente mejor, costos de alojamiento más bajos, y administración trivial de ubicaciones. Cada ubicación es una fila de base de datos, no una instalación de WordPress completa.

¿Cómo se migra de WordPress Multisite a una arquitectura headless? El enfoque más seguro es extraer contenido vía la API REST de WordPress o WP-CLI en lugar de intentar reasignar manualmente tablas de base de datos con prefijo. Exporta contenido por subsitio, diseña un esquema limpio en tu base de datos objetivo, escribe scripts de transformación, construye el nuevo frontend, y cambia DNS. Planifica para 6-10 semanas totales para una red con 20+ sitios.

¿WordPress Multisite afecta el SEO? Indirectamente, sí. La degradación de rendimiento de WordPress Multisite lleva a cargas de página más lentas, lo que afecta las puntuaciones de Core Web Vitals. Google ha confirmado que las señales de experiencia de página influyen en los rankings. En nuestros datos de migración, el 82% de ubicaciones vieron mejores rankings de búsqueda locales dentro de 90 días de trasladarse a una arquitectura headless con TTFB sub-200ms.

¿Es WordPress Multisite seguro para datos empresariales? No, si defines seguridad como aislamiento de datos entre ubicaciones. WordPress Multisite usa una base de datos con un conjunto de credenciales. Una inyección SQL en cualquier subsitio puede acceder a los datos de todos los demás subsitios. Para empresas sujetas a HIPAA, SOC 2, PCI DSS o requisitos de cumplimiento similar, la falta de aislamiento a nivel de base de datos es una responsabilidad significativa.

¿Cuánto cuesta ejecutar WordPress Multisite vs una alternativa headless? El alojamiento de WordPress administrado para Multisite generalmente corre $200-800/mes dependiendo de la cantidad de sitios y niveles de tráfico (los planes Multisite de WP Engine comienzan en $240/mes para su tier Growth en 2025). Una configuración headless comparable en Vercel Pro ($20/mes) más Supabase Pro ($25/mes) maneja el mismo tráfico por una fracción del costo. La inversión inicial de construcción es mayor para el enfoque headless, pero los costos operativos mensuales son significativamente más bajos. Siéntete libre de contactarnos si quieres una comparación de costos específica para tu tamaño de red.