Tu cliente franquiciador lanza el subsite 247. WordPress crea wp_247_posts, wp_247_postmeta, wp_247_options — las mismas 12 tablas que creó para los subsites 1 al 246. Ahora tienes 2.964 tablas en una base de datos. Una actualización de plugin las toca todas. Una consulta en el sitio 118 compite con consultas en los sitios 12, 95 y 203. Tu dashboard de monitoreo muestra agotamiento del pool de conexiones a las 11:00 AM todos los martes. Esto no es arquitectura multi-sitio. Esto es una instalación de WordPress con copias numeradas del mismo esquema, y tiene siete consecuencias de escalado que se rompen en umbrales predecibles — la primera llega alrededor del sitio 40.

He migrado redes con 15, 40 e incluso 87 subsites fuera de WordPress Multisite. Cada vez, el cliente pensó que estaba obteniendo sitios independientes. Cada vez, descubrieron por las malas que no era así. Si estás ejecutando una franquicia, un negocio multi-ubicación o una red de departamentos universitarios en WordPress Multisite, este artículo te va a doler un poco. Pero es mejor saberlo ahora que después de que el subsite #47 derribe a los otros 46.

Tabla de Contenidos

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

Qué Hace Realmente WordPress Multisite Bajo el Capó

Veamos qué sucede cuando habilitas Multisite en WordPress. Añades 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 central para cada nuevo subsite.

Aquí está el aspecto de la base de datos después de solo 5 subsites:

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            (subsite 2)
wp_2_postmeta         (subsite 2)
wp_2_options          (subsite 2)
wp_3_posts            (subsite 3)
wp_3_postmeta         (subsite 3)
wp_3_options          (subsite 3)
...
wp_5_posts            (subsite 5)
wp_5_postmeta         (subsite 5)
wp_5_options          (subsite 5)

Cinco subsites y ya tienes ~55 tablas. ¿Cincuenta subsites? 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 pool de conexiones.

Cada tabla tiene sus propios índices. Cada consulta apunta a una tabla prefijada específica. El planificador de consultas tiene que lidiar con todo esto. Y cada una de esas tablas es accesible para cualquier proceso PHP ejecutándose en ese servidor, porque están todas en la misma base de datos con las mismas credenciales.

Esto no es arquitectura multi-sitio. Es una convención de nomenclatura haciéndose pasar por aislamiento.

Las 7 Consecuencias de la Arquitectura Falsa Multi-Sitio

1. Superficie de Vulnerabilidad Compartida

Cada subsite 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 subsites porque comparten la misma base de código.

Esto no es teórico. En febrero de 2025, 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) de 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, ese es un sitio comprometido. ¿En una red Multisite con 30 subsites? Esos son 30 sitios comprometidos. Mismo servidor. Misma base de datos. Mismo sistema de archivos. Un exploit, compromiso de red total.

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

2. Multiplicación de Conflicto de Plugins

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

En Multisite, un conflicto de plugin activado en la red rompe cada sitio simultáneamente. He visto una actualización de WooCommerce en una red Multisite derribar 23 páginas de ubicación de una vez porque un plugin de caché activado en la red no había sido 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 en la red. Tienen que esperar a que el Super Administrador lo arregle.

3. Degradación del Rendimiento

Cincuenta subsites compartiendo una instancia MySQL. Cada carga de página en el subsite #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 subsite #12 está ejecutando su propio conjunto de consultas contra wp_12_posts, wp_12_options y wp_12_postmeta. Y lo mismo hace cada otro subsite, todos golpeando la misma instancia MySQL.

El planificador de consultas de MySQL se confunde. El caché de tabla se llena. Cada tabla prefijada mantiene sus propios índices, pero el pool de buffer es compartido. El rendimiento se degrada no linealmente a medida que añades subsites. Pasar de 10 a 20 subsites no es el doble de carga — puede ser tres o cuatro veces la carga dependiendo de los patrones de tráfico, por causa de la contención de bloqueos y el thrashing del pool de buffer.

Hice un benchmark de una red de 40 subsites una vez. El tiempo de consulta promedio en el subsite #1 era 45ms. Cuando probamos el subsite #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 subsite #23 de una red de 50 sitios a su propio WordPress independiente. Aquí está lo que necesitas hacer:

  1. Exportar todas las tablas con prefijo wp_23_
  2. Remapear cada tabla de prefijo wp_23_ a prefijo wp_
  3. Resealizar todos los datos de opciones y widgets (WordPress almacena PHP serializado en la base de datos, y las longitudes de cadena cambian cuando cambias prefijos)
  4. Remapear rutas de medios de /uploads/sites/23/ a /uploads/
  5. Búsqueda y reemplazo de todas las URLs internas
  6. Remapear capacidades de usuario de wp_23_capabilities a wp_capabilities en wp_usermeta
  7. Extraer usuarios de la tabla compartida wp_users (solo los que pertenecen al subsite #23)
  8. Recrear relaciones usuario-a-sitio

Un error en la serialización y obtienes datos corruptos. La configuración de widgets desaparece. Las opciones del personalizador de temas se rompen. Las estructuras de menú desaparecen. He hecho este proceso de extracción docenas de veces, y toma 4-8 horas por subsite incluso con herramientas como WP Migrate DB Pro. Multiplica eso por 50 subsites si estás decomisionando 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 Verdadero Aislamiento de Datos

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

Una vulnerabilidad de inyección SQL en el subsite #2 no solo expone wp_2_posts. El usuario de la base de datos conectándose a MySQL tiene acceso a cada tabla en la base de datos. Eso significa wp_posts (sitio principal), wp_3_posts (subsite 3), wp_users (todos los usuarios en todos los sitios) y cada otra tabla.

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 nomenclatura. Eso es todo.

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

6. Cuello de Botella de 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
  • Añadir nuevos sitios a la red
  • Gestionar configuración de red

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

Para una red de 3 sitios, esto está bien. ¿Para una franquicia de 50 ubicaciones donde cada gerente de ubicación quiere añadir su propio widget de reserva o plugin PDF de menú? Es un cuello de botella que cría resentimiento e IT en la sombra.

7. Mapeo de Dominio Frágil

¿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 de dropin sunrise.php integrado es notoriamente delicado.

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

Cuándo Funciona WordPress Multisite (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 gestionados por el mismo equipo
  • Sitios de departamentos universitarios donde el control centralizado es realmente deseado
  • Espejos dev/staging/production para el mismo proyecto
  • Redes de blogs donde el aislamiento de contenido no es crítico

Si tienes 5-8 sitios, un sysadmin 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 No Es Multi-Site: Arquitectura Que Escala a 500 Ubicaciones - arquitectura

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 Seguridad a Nivel de Fila (RLS) para 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 separadas fingiendo ser independientes, tienes un deployment 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 aplica. No la capa de aplicación. No una convención de nomenclatura. 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 Individual        │
│                                             │
│  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 DB         │
│  ⚠️  UN proceso PHP accede a TODAS tablas  │
│  ⚠️  CERO aislamiento a nivel de BD        │
└─────────────────────────────────────────────┘

Arquitectura de Next.js + Supabase:

┌─────────────────────────────────────────────┐
│      Base de Datos PostgreSQL Individual     │
│                                             │
│  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)       │
│                                             │
│  ✅  Políticas RLS aplican aislamiento      │
│  ✅  Usuario Denver NO PUEDE consultar     │
│      datos de Austin                        │
│  ✅  5 tablas en total, 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 aplica al nivel del motor de PostgreSQL — no es algo que la aplicación pueda eludir.

Factor WordPress Multisite Next.js + Supabase
Tablas a 500 ubicaciones ~5.500+ ~5-15
Aislamiento de datos Ninguno (solo convención de nomenclatura) RLS aplicado por base de datos
Superficie de vulnerabilidad Un exploit = todos sitios Aislamiento de auth por ubicación
Conflictos de plugin Corte de red N/A (sin arquitectura de plugin)
Añadir una ubicación Crear subsite + 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 compilación incremental
TTFB (promedio, sin cache) 800ms-2s+ 50-150ms (edge)
Alojamiento mensual (500 sitios) $200-800/mes (WP gestionado) $25-75/mes (Supabase + Vercel)
Recuperación de compromiso Remediación de red completa Rotar claves, redeploy

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

Aquí está cómo 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>
  );
}

¿Añadir 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 siguiente build la recoge. O si estás usando ISR (Regeneración Estática Incremental), aparece dentro de tu ventana de revalidación sin un build en absoluto.

¿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, el middleware de Next.js lo maneja de manera limpia:

// 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 de configuración 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 regla de 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 subsite usando la API REST de WordPress o WP-CLI. No intentes remapear manualmente tablas con prefijo. Usa la API — abstrae la pesadilla del prefijo.

# Exportar todos los posts del subsite 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 el modelo de post/postmeta de WordPress. Este es el momento para arreglar años de deuda acumulada del modelo de datos.

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

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

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

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

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

Punta tus dominios a la nueva infraestructura. Mantén la red antigua ejecutándose como copia de seguridad de solo lectura durante 30 días.

Para negocios 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 Costos

Aquí hay datos de una migración real que completamos en Q1 2025 — una red de práctica dental 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 añadir nueva ubicación 2-3 horas (configuración manual) 15 minutos (insertar fila + contenido)
Tiempo para actualizar todas las ubicaciones Actualizar plugin + rezos 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 solo pagó la migración en 8 meses. Las mejoras de rendimiento impulsaron aumentos medibles en clasificaciones de búsqueda local 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.

FAQ

¿Es WordPress Multisite bueno para gestionar múltiples ubicaciones?

Para un pequeño número de ubicaciones (menos de 10) con gestió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 a escala. La arquitectura de base de datos compartida crea problemas de seguridad, rendimiento y operativos que se componen con cada ubicación que añades.

¿Cuáles son los problemas más grandes con WordPress Multisite?

Los siete problemas principales son: superficie de vulnerabilidad compartida (un exploit golpea todos los sitios), multiplicación de conflicto de plugin (un conflicto derriba cada sitio), degradación de rendimiento no lineal, procesos de migración/extracción de 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 arreglados 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 instancia MySQL individual, degradación severa del planificador de consultas, y complejidad operativa que requiere personal de DevOps dedicado. Con 500 sitios, es un no-iniciador para la mayoría de ambientes 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) utilizando Seguridad a Nivel de Fila proporciona verdadero aislamiento de datos, rendimiento dramáticamente mejor, costos de alojamiento más bajos, y gestión de ubicación trivial. Cada ubicación es una fila de base de datos, no una instalación de WordPress completa.

¿Cómo se migra desde WordPress Multisite a una arquitectura headless?

El enfoque más seguro es extraer contenido a través de la API REST de WordPress o WP-CLI en lugar de intentar remapear manualmente tablas de base de datos con prefijo. Exporta contenido por subsite, diseña un esquema limpio en tu base de datos objetivo, escribe scripts de transformación, construye el nuevo frontend, y corta DNS. Planifica 6-10 semanas totales para una red con 20+ sitios.

¿Afecta WordPress Multisite al SEO?

Indirectamente, sí. La degradación de rendimiento de WordPress Multisite conduce a cargas de página más lentas, que lastiman las puntuaciones de Core Web Vitals. Google ha confirmado que las señales de experiencia de página influyen en las clasificaciones. En nuestros datos de migración, el 82% de ubicaciones vieron mejoras en clasificaciones de búsqueda local dentro de 90 días de mudarse a una arquitectura headless con TTFB sub-200ms.

¿Es WordPress Multisite seguro para datos empresariales?

No, si defines seguridad como que incluye aislamiento de datos entre ubicaciones. WordPress Multisite usa una base de datos con un conjunto de credenciales. Una inyección SQL en cualquier subsite puede acceder a los datos de cada otro subsite. Para negocios sujetos a HIPAA, SOC 2, PCI DSS o requisitos de cumplimiento similares, 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 gestionado para Multisite típicamente corre $200-800/mes dependiendo del número de sitios y niveles de tráfico (los planes de Multisite de WP Engine comienzan en $240/mes para su nivel Growth en 2026). 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 en la construcción es más alta para el enfoque headless, pero los costos operativos mensuales son significativamente más bajos.