SEO local para empresas: estrategias WordPress multisite en 2026

Gestionar la visibilidad orgánica de un único establecimiento físico es una tarea relativamente sencilla. Pero cuando una empresa amplía su actividad a 50, 100 o 500 sucursales, oficinas o clínicas en España, aparece un reto serio de gobernanza técnica: mantener el control centralizado de la marca sin renunciar a la relevancia hiperlocal que exigen las búsquedas “cerca de mí”.

Muchas marcas con varias ubicaciones recurren a WordPress Multisite como infraestructura para unir la autoridad nacional del dominio con la especificidad de cada ubicación física. Esta guía describe la arquitectura y, en cada punto, lo que dice de verdad la documentación de Google y de WordPress, porque buena parte de lo que circula sobre SEO local a escala es folclore.

Conoce nuestros servicios avanzados de SEO y GEO pensados para arquitecturas empresariales multirregionales.

#1. Por qué usar WordPress Multisite para varias sucursales

Un enfoque equivocado frecuente entre las grandes redes es elegir uno de dos extremos problemáticos: intentar reunir todas las tiendas en una única página estática de listado, o crear decenas de instalaciones de WordPress completamente separadas. La primera opción no tiene profundidad suficiente para posicionar palabras clave geográficas concretas; la segunda convierte la seguridad y el mantenimiento en una pesadilla, con cientos de bases de datos y paneles aislados.

WordPress Multisite resuelve este dilema con una plataforma unificada que sostiene una red de subsitios a partir de una sola base de código:

• Gestión centralizada de temas y plugins: las actualizaciones de seguridad, los temas corporativos y las herramientas de analítica los instala una sola vez, a nivel de red, el Super administrador.
• Tablas de datos aisladas: cada subsitio tiene su propio conjunto de tablas (wp_X_posts, wp_X_options), de modo que la configuración y las publicaciones locales quedan estrictamente separadas.
• Jerarquía de permisos granular: los responsables locales reciben un acceso de edición restringido para actualizar horarios especiales o publicar avisos municipales, sin riesgo de romper la arquitectura del portal.

La documentación de WordPress sobre Multisite resume el modelo de datos en una frase: el contenido de cada sitio tiene “sus propias tablas en la base de datos, solo la tabla de usuarios se comparte entre las instancias” (traducción propia). La misma página recuerda que hace falta tener activas las reescrituras de URL para usar Multisite.

#2. Subdirectorios o subdominios para páginas locales

La estructura de direcciones define dónde vive cada sucursal y cuánto cuesta mantenerla. La tabla siguiente sigue la comparación publicada por Google en Gestionar sitios multirregionales y multilingües, aplicada a páginas de ciudades:

Google no atribuye a ninguno de estos modelos una ventaja de posicionamiento. Para una red de tiendas en un solo país, los subdirectorios suelen ganar por la operación: un certificado, un alojamiento, una configuración de caché. Los subdominios tienen sentido cuando hay razones técnicas para servir regiones desde servidores distintos.

En el lado de WordPress, la página Crear una red explica que la elección entre subdominios y subdirectorios se hace al instalar la red y que es posible reconfigurarla después hacia la otra opción, aunque el cambio da trabajo. La misma página aclara que el DNS comodín (wildcard) solo es necesario para sitios creados bajo demanda basados en dominio, aunque la pantalla de instalación sugiera lo contrario.

#3. Cómo añadir Schema LocalBusiness a cada sucursal

El marcado estructurado indica a los buscadores, de forma explícita, el nombre, la dirección y el horario de cada establecimiento. Según la documentación de datos estructurados LocalBusiness, quien busca negocios en la Búsqueda de Google o en Maps puede ver un panel de conocimiento con esos detalles.

Cada subsitio de la red Multisite debe generar de forma dinámica un marcado JSON-LD completo y específico. El ejemplo usa una marca ficticia:

<!-- Ejemplo de JSON-LD LocalBusiness generado para una sucursal (marca ficticia) -->
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Store",
  "name": "Marca Ejemplo Valencia",
  "url": "https://example.com/valencia/",
  "telephone": "+34 960 000 000",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Calle Ejemplo 100",
    "addressLocality": "Valencia",
    "postalCode": "46000",
    "addressCountry": "ES"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 39.46975,
    "longitude": -0.37739
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "09:00:00",
      "closes": "18:00:00"
    }
  ]
}
</script>

Las reglas de Google que sigue este ejemplo:

• Obligatorios: solo name y address, con tantas propiedades de dirección como sea posible.
• Coordenadas: en geo, la latitud y la longitud deben tener “al menos 5 decimales” de precisión (traducción propia).
• Horario: opens y closes en formato hh:mm:ss; openingHoursSpecification acepta un objeto o una lista.
• Teléfono: el contacto principal para clientes, con prefijo del país y de la zona.
• URL: la dirección completa de la ubicación concreta, y tiene que ser un enlace que funcione. En una red Multisite es la página de la sucursal, no la página de inicio de la marca.
• Subtipo: Google pide el subtipo de LocalBusiness más específico posible (en el ejemplo, Store).
• Departamentos: una tienda con farmacia o taller puede describir cada sección con department.

Un punto que muchas guías pasan por alto: aggregateRating y review solo se recomiendan, en palabras de Google, para sitios que recopilan reseñas sobre otros negocios locales. Una cadena que marca las reseñas de sus propias tiendas no está en ese caso.

Con campos personalizados (por ejemplo, Advanced Custom Fields) o con la REST API, estos datos se rellenan en la base de datos de cada sucursal y se inyectan automáticamente en el HTML, sin que el equipo local tenga que programar nada.

#4. Sincronizar los datos NAP con Google Business Profile

Las discrepancias en los datos NAP (Name, Address, Phone) entre el sitio, los datos estructurados y Google Business Profile generan dudas sobre cuál es la información correcta. Si la dirección del sitio muestra un código postal distinto del registrado en el perfil, el usuario y el buscador reciben dos versiones de la misma tienda.

Para mantener la sincronía, WordPress actúa como repositorio maestro de datos:

1. Base de datos centralizada: la dirección, los horarios y los contactos de todas las tiendas se guardan en un formato canónico en WordPress.
2. Conectores de API: tareas programadas (WP-Cron o crontab en el servidor) envían los cambios a las APIs de Google Business Profile, para quien tiene acceso a ellas.
3. Propagación de excepciones: cuando un responsable cambia el horario de cierre por un festivo local, el cambio sale de un único sitio hacia la web, los datos estructurados y el perfil.

#5. Qué exigen las directrices de Google Business Profile a una red de tiendas

Las directrices para representar tu negocio en Google definen lo que debe contener cada registro en WordPress antes de enviarse al perfil:

• Un perfil por ubicación: Google pide no crear más de una página por ubicación, “en una sola cuenta o en varias cuentas” (traducción propia).
• Nombre: debe reflejar el nombre real del negocio, sin información innecesaria. En una cadena, “todas las ubicaciones deben tener el mismo nombre”, salvo cuando la representación real varía de una tienda a otra (traducción propia). Un campo nombre_publico por sucursal, con el nombre de la marca bloqueado a nivel de red, evita que un responsable añada palabras clave.
• Dirección: tiene que ser la ubicación física real; los apartados de correos y las oficinas virtuales no son válidos.
• Teléfono: bajo control directo de la empresa; Google prefiere un número local a una línea central de call center siempre que sea posible.
• Sitio web: debe representar la ubicación individual. En una red Multisite apunta de forma natural a la URL de la sucursal.
• Departamentos: los departamentos con atención al público que funcionan como entidades distintas pueden tener perfil propio, con un nombre diferente del negocio principal.
• Negocios de área de servicio: un perfil para la oficina central con el área de servicio definida y la dirección oculta a los clientes.

Para la verificación, la página de verificación en bloque se aplica a quien tiene “10 o más ubicaciones del mismo negocio” (traducción propia). La solicitud se hace con una hoja de cálculo de todos los perfiles gestionados, no está disponible para negocios de área de servicio y puede exigir verificación por vídeo con un representante autorizado en el local. Una exportación generada a partir de las tablas de la red Multisite es la forma más directa de producir esa hoja sin errores de copia.

#6. Cómo crear páginas locales sin contenido duplicado

Crear 100 páginas de ciudades cambiando solo el nombre de la localidad en un texto estático (“Los mejores servicios informáticos en Zaragoza”, “Los mejores servicios informáticos en Málaga”) produce páginas de poco valor.

Las políticas de spam de Google describen este patrón sin rodeos. Entre los ejemplos de abuso de doorways está “tener varios nombres de dominio o páginas dirigidas a regiones o ciudades concretas que llevan a los usuarios a una página” (traducción propia). La misma página define el abuso de contenido a escala como generar muchas páginas con el objetivo principal de manipular el posicionamiento y no de ayudar a los usuarios. Una red Multisite con 500 subsitios casi idénticos encaja en las dos definiciones.

Cada subsitio local debe enriquecerse con sustancia auténtica:

• Equipo sobre el terreno: presentación con foto, nombre y especialidad de los profesionales de la oficina.
• Proyectos y casos de la región: breves referencias a trabajos hechos para entidades y empresas locales, cuando existen y pueden publicarse.
• Accesos y transporte: información concreta sobre estaciones de metro, paradas de autobús o aparcamientos cercanos.
• Iniciativas municipales: participación en ferias locales, charlas o patrocinios deportivos en el municipio.

La prueba práctica: si la página de la sucursal desapareciera y el usuario no perdiera ninguna información que no esté ya en la página nacional, esa página no debería crearse.

#7. Crear nuevas sucursales con WP-CLI

Crear a mano cientos de delegaciones desde el panel consume cientos de horas y multiplica los errores de configuración. La administración central debe trabajar desde la terminal con WP-CLI.

#Activar Multisite en subdirectorios en wp-config.php

El primer paso es define( 'WP_ALLOW_MULTISITE', true );. Después de crear la red, la pantalla de instalación muestra las líneas finales, adaptadas a tu instalación; para una red en subdirectorios tienen este aspecto:

/* Configuración de red Multisite en subdirectorios */
define('WP_ALLOW_MULTISITE', true);
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', false);
define('DOMAIN_CURRENT_SITE', 'marca.es');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);

#Clonar nuevas sucursales con Bash y WP-CLI

El script parte de un sitio plantilla (ID 2, en marca.es/modelo/). Después de copiar las tablas de la plantilla, las opciones siteurl y home siguen apuntando a ella, así que el paso 3 las corrige con un search-replace limitado al nuevo sitio:

#!/usr/bin/env bash
# Script de aprovisionamiento automatizado de nuevas sucursales en WordPress

SLUG_CIUDAD="valencia"
NOMBRE_CIUDAD="Valencia"
EMAIL_RESPONSABLE="[email protected]"

# 1. Crear un nuevo subsitio en la red Multisite
NUEVO_BLOG_ID=$(wp site create --slug="$SLUG_CIUDAD" --title="Marca $NOMBRE_CIUDAD" --email="$EMAIL_RESPONSABLE" --porcelain)

# 2. Clonar ajustes y bloques desde la plantilla estándar (site_id 2)
wp db export /tmp/modelo.sql --tables=$(wp db tables "wp_2_*" --format=csv)
sed -i "s/wp_2_/wp_${NUEVO_BLOG_ID}_/g" /tmp/modelo.sql
wp db import /tmp/modelo.sql
rm /tmp/modelo.sql

# 3. Corregir las URL heredadas de la plantilla y los metadatos de la ubicación
wp search-replace "marca.es/modelo/" "marca.es/$SLUG_CIUDAD/" --url="marca.es/$SLUG_CIUDAD/"
wp option update blogname "Marca $NOMBRE_CIUDAD" --url="marca.es/$SLUG_CIUDAD/"
wp post update 1 --post_title="Delegación $NOMBRE_CIUDAD" --url="marca.es/$SLUG_CIUDAD/"

echo "Subsitio operativo en marca.es/$SLUG_CIUDAD/ con ID $NUEVO_BLOG_ID"

Prueba el script en un entorno de staging antes de usarlo en producción: la copia de tablas no pasa por los hooks de WordPress, y los plugins que guardan datos en tablas propias necesitan un tratamiento aparte.

#8. Quién controla qué en la administración de una red Multisite

El reparto de poderes descrito en la documentación de administración de red es lo que hace seguro el modelo para cientos de responsables locales:

• Super administrador: solo el Super administrador instala temas y plugins. En palabras de la documentación, “los administradores de sitio no pueden instalar nuevos temas ni plugins” (traducción propia).
• Plugins: el Super administrador puede activar un plugin en toda la red (Activar para la red), por ejemplo el plugin que genera el JSON-LD LocalBusiness, para que ninguna sucursal se quede sin él.
• Temas: un tema tiene que estar activado en la red o permitido en la pestaña Temas del sitio concreto. El tema corporativo queda disponible para todos; los temas alternativos no aparecen en las sucursales.
• Menú de plugins: el acceso de los administradores de sitio a la pantalla de plugins es una opción en Ajustes de la red. En una cadena de tiendas tiene sentido dejarla desactivada.
• Archivos: el primer sitio guarda las subidas en /wp-content/uploads/ y los siguientes en /wp-content/uploads/sites/, lo que permite hacer copias de seguridad y limpiezas por sucursal.

Como la tabla de usuarios es compartida, un director regional puede tener el rol de Editor en diez subsitios con una sola cuenta, y un responsable de tienda solo en el suyo.

#9. Dominios propios para franquiciados con mapeo de dominios

No todas las ubicaciones viven bajo el dominio principal. Un franquiciado con marca propia puede exigir su dominio. Según la página de mapeo de dominios, desde WordPress 4.5 esta función es nativa de Multisite: en el panel de la red, en Sitios, se edita el subsitio y se escribe la URL completa en el campo Dirección del sitio (URL).

Los requisitos prácticos, todos de la misma página:

• DNS: los dominios adicionales deben apuntar al dominio principal de la red antes del mapeo.
• SSL: certificado en el dominio principal y SNI para los demás; cada dominio debe tener SSL para que el acceso al panel vaya cifrado.
• Cookies: si el acceso falla en un subsitio mapeado, la documentación indica añadir define( 'COOKIE_DOMAIN', $_SERVER['HTTP_HOST'] ); a wp-config.php, después del código de la red.

El compromiso es el de la tabla de la sección 2: cada dominio independiente tiene que construir su presencia desde cero, así que el mapeo sirve para casos de identidad de marca, no de SEO.

#10. Hreflang cuando la red cubre varios países

Una red con sucursales en España, México y Argentina suele tener la misma página de servicio en español de España, de México y de Argentina. Aquí entra el hreflang, descrito por Google en Versiones localizadas de tu página:

• Tres métodos: etiquetas link en el HTML, cabeceras HTTP o el sitemap XML. En una red Multisite, el sitemap que genera cada subsitio es el método más fácil de mantener.
• Reciprocidad: “cada versión lingüística debe incluirse a sí misma y a todas las demás versiones” (traducción propia). Si el subsitio mexicano apunta al español y el español no apunta de vuelta, la anotación falla.
• x-default: el valor reservado que se usa cuando ningún idioma o región coincide con la configuración del navegador, por ejemplo una página de selección de país.
• Códigos: solo se aceptan códigos de idioma ISO 639-1 y de región ISO 3166-1 Alpha 2, como es-ES, es-MX o es-AR. Google es explícita: no se puede indicar solo el código del país.
• Detección de idioma: Google no usa el hreflang ni el atributo lang del HTML para detectar el idioma de una página; el texto visible tiene que estar de verdad en ese idioma.

Las páginas de ciudades dentro del mismo país y del mismo idioma no llevan hreflang entre sí: Madrid y Sevilla no son versiones lingüísticas una de otra.

#11. Por qué no adaptar el contenido por IP o por idioma del navegador

Una tentación habitual en redes grandes es redirigir automáticamente al visitante a la sucursal más cercana. La misma página de Google sobre sitios multirregionales desaconseja este enfoque por dos razones:

• El rastreador envía peticiones HTTP sin la cabecera Accept-Language, así que el contenido que cambia según el idioma del navegador puede no encontrarse nunca.
• “No uses el análisis de IP para adaptar tu contenido” (traducción propia), porque la localización por IP es difícil y, en general, poco fiable.

Google recomienda URL distintas para cada versión e ignora las metaetiquetas de ubicación como geo.position. En la práctica: un selector de tienda visible, con enlaces rastreables a cada subsitio, en lugar de una redirección silenciosa. Entre las señales que usa Google para entender el público de un sitio están las direcciones y teléfonos locales en la página, otro motivo para mostrar los datos NAP en el HTML de cada sucursal.

#12. Acelerar Multisite con caché en el edge y Redis

Una instalación de WordPress con cientos de subsitios en producción exige cuidados especiales de arquitectura:

• Caché en el edge con CDN: distribuye la caché estática de páginas por los puntos de presencia (PoP) de una CDN como Cloudflare o Fastly, más cerca de los usuarios de cada región.
• Caché de objetos con Redis: instala Redis Object Cache para guardar en memoria RAM los resultados de opciones y metadatos de los cientos de tablas de la red.
• Indexación de la base de datos: mantén optimizadas las tablas wp_blogs y wp_site para que el enrutamiento de peticiones en el servidor web funcione sin fricción.

La ubicación del servidor también es una de las señales de público que enumera Google, pero la propia Google dice que no es una señal definitiva. La CDN aporta velocidad; la segmentación geográfica sale de los datos de la página y del hreflang.

#13. Modelo de madurez de SEO local para empresas

Si estructuras la red de tu empresa sobre WordPress Multisite, tu marca combina la gobernanza de un portal corporativo con páginas locales que responden a quien busca cada tienda, siempre que cada una tenga contenido propio y datos alineados con el perfil de Google.