Un sitio web multiubicación para una franquicia necesita una infraestructura de WordPress compartida con páginas por ubicación creadas a partir de una plantilla reutilizable. La arquitectura adecuada –ya sea una estructura de subdirectorios en una única instalación de WordPress o una red Multisite– permite a la central mantener los estándares de marca y, al mismo tiempo, da a cada ubicación de la franquicia flexibilidad suficiente para posicionarse en la búsqueda local. Acertar con esta decisión desde el primer día ahorra meses de correcciones posteriores.
La mayoría de los sitios de franquicias no fallan por un mal diseño, sino por una decisión de arquitectura tomada demasiado pronto, sin entender sus implicaciones para el SEO y la operación. Esta guía explica qué decidir, en qué orden y por qué.
Puntos clave
- Las estructuras de URL con subdirectorios son la opción práctica por defecto para la mayoría de los sitios de franquicias: simplifican la analítica, el enlazado interno, la gobernanza del contenido y el rastreo bajo un solo dominio. Google afirma que puede posicionar igual subdominios y subdirectorios; la elección es sobre todo de arquitectura, no de posicionamiento.
- Una sola instalación de WordPress gestiona de forma eficiente la mayoría de las redes de franquicias. Multisite tiene sentido cuando las ubicaciones necesitan un aislamiento operativo real: administradores separados, permisos distintos o varias marcas de franquicia que comparten un motor de WordPress en lugar de mantener bases de código separadas.
- Las páginas de ubicación necesitan contenido realmente distinto, no solo nombres de ciudad intercambiados. En las implementaciones de IMADO, construimos cada página de ubicación con al menos cinco elementos específicos del lugar para que las páginas se diferencien de verdad entre sí.
- Los datos estructurados LocalBusiness dan a Google información explícita y legible por máquinas sobre cada ubicación física y pueden favorecer funciones de búsqueda local aptas. En los sitios de franquicias suelen estar implementados de forma insuficiente.
- Los requisitos de rendimiento de los sitios de franquicias crecen con el volumen de tráfico y la complejidad de las consultas, no con el número de ubicaciones. La CDN y la caché de objetos cobran importancia cuando hay páginas de ubicación con mucho tráfico, consultas geográficas costosas o integraciones dinámicas por ubicación, no simplemente por superar cierto número de páginas.
Estructura de URL para sitios de franquicias: ¿subdirectorio, subdominio o dominios separados?
Para la mayoría de los sitios de franquicias, los subdirectorios son la opción correcta. La estructura de rutas domain.com/locations/chicago/ mantiene todo el contenido bajo un mismo dominio, lo que simplifica el rastreo, el enlazado interno, la analítica y la gobernanza del contenido. La elección no tiene que ver principalmente con el posicionamiento: Google afirma que puede posicionar igual las estructuras de subdirectorios y de subdominios.
Los datos de casos prácticos se inclinan por los subdirectorios. Cuando IWantMyName pasó de un subdirectorio a subdominios, el tráfico orgánico cayó un 47 %, según un caso documentado por CognitiveSEO. Pink Cake Box hizo el camino inverso –de subdominios a subdirectorios– y ganó un 40 % de tráfico orgánico. Son datos útiles, aunque la propia Google indica que puede posicionar igual ambas estructuras. Decida en función de lo que resulte más sencillo de gestionar en el día a día.
Los subdominios tienen un caso de uso legítimo: franquicias cuyas ubicaciones funcionan como entidades jurídica o comercialmente distintas, cada una con su propio Perfil de Empresa en Google, servicios diferentes y contenido que se aleja mucho del de la central. Incluso entonces, una configuración de subdirectorios bien estructurada suele rendir mejor desde un punto de vista puramente SEO.
Los dominios separados por ubicación casi nunca compensan la carga operativa, salvo que usted gestione un verdadero portafolio de varias marcas y no una franquicia con una identidad de marca unificada.
| Factor | Subdirectorio | Subdominio | Dominio separado |
|---|---|---|---|
| Concentración del valor SEO | La mejor | Fragmentada | Totalmente fragmentada |
| Gobernanza desde la central | La más fácil | Moderada | La más compleja |
| Editores de contenido por ubicación | Posible (por roles) | Más fácil | Lo más fácil |
| Complejidad de configuración | Baja | Media | Alta |
| Recomendado para franquicias | Sí | Solo casos especiales | Solo portafolios multimarca |
WordPress Multisite o instalación única: ¿qué arquitectura encaja con su franquicia?
La arquitectura adecuada depende de los requisitos de aislamiento operativo, no del número de ubicaciones. Una red de 100 ubicaciones gestionada de forma centralizada puede funcionar bien en una sola instalación con un tipo de contenido personalizado Location (CPT). Ocho franquiciados que necesitan administradores propios, configuraciones de plugins independientes o una gestión de marca diferenciada sobre un motor compartido: ese es un caso para Multisite.
Multisite añade una carga operativa real. Cada plugin debe ser compatible con Multisite, y los cambios en toda la red requieren acceso de superadministrador. Las actualizaciones del tema se aplican a todos los subsitios a la vez, lo cual es muy potente cuando funciona y muy disruptivo cuando no. En una red en la que la central controla todo el contenido, esa carga no le aporta nada.
Para que el desarrollo con WordPress Multisite tenga sentido, debería cumplirse al menos una de estas condiciones: los franquiciados necesitan gestionar su propio contenido de forma independiente, cada ubicación necesita configuraciones de plugins distintas o su estructura jurídica exige separar los datos entre las entidades de cada ubicación. Multisite también encaja de forma natural con grupos franquiciadores que gestionan varias marcas distintas desde un mismo motor de WordPress: resulta bastante más económico que mantener una base de código separada para cada marca.
Como punto de partida aproximado, solemos evaluar Multisite a partir de unas 20 ubicaciones, pero esa cifra es secundaria frente a la cuestión operativa.
| Escenario | Arquitectura recomendada |
|---|---|
| Contenido gestionado de forma centralizada, cualquier número de ubicaciones | Instalación única + CPT Location |
| Editores por ubicación, configuraciones independientes | WordPress Multisite |
| Varias marcas de franquicia, motor de WordPress compartido | WordPress Multisite |
Lo que debe contener cada página de ubicación
En nuestras implementaciones para franquicias, construimos cada página de ubicación en torno a cinco elementos de contenido específicos del lugar. Las directrices de Google sobre páginas puerta advierten contra «muchas páginas similares, cada una ligeramente modificada para una ciudad distinta»: el objetivo son páginas realmente útiles para quien visita esa ubicación, no plantillas con el nombre de la ciudad cambiado.
Las cinco señales que hacen que una página de ubicación sea realmente distinta: un titular específico que haga referencia a la zona (no solo el nombre de la ciudad insertado), los datos NAP completos (nombre, dirección y teléfono), un mapa de Google insertado, una descripción única del servicio que mencione el contexto local –puntos de referencia cercanos, radio de servicio, referencias a clientes locales– y reseñas obtenidas específicamente del Perfil de Empresa en Google de esa ubicación.
Las pequeñas diferencias de formato, como «Suite» frente a «Ste.», rara vez importan: Google normaliza bien las direcciones. Céntrese en que la identidad real de la empresa sea exacta en su sitio web y en GBP: nombre de la empresa, dirección física, teléfono, URL del sitio web y horario. Es lo que Google utiliza para determinar la relevancia y construir la entidad local.
Insertar Google Maps sin perjudicar las Core Web Vitals requiere cargar el iframe de forma diferida. Cárguelo solo cuando el usuario se desplace hasta el mapa, no en la carga inicial de la página. Un sitio de franquicia con 30 páginas de ubicación que cargan cada una un mapa de Google completo nada más entrar suspenderá el LCP de forma sistemática.
Mostrar de forma dinámica reseñas específicas de cada ubicación requiere una conexión con la API de Google Business Profile o con un servicio de agregación de reseñas. Las reseñas que aparecen en cada página de ubicación deben corresponder a la ficha de GBP de esa ubicación concreta, no a un feed genérico de la central.
Gobernanza de marca: cómo controla la central la plantilla sin bloquear a los franquiciados
El modelo de gobernanza más limpio bloquea la cabecera, el pie de página, la tipografía y la paleta de colores globales en el tema de WordPress, y ofrece a los franquiciados una interfaz de edición basada en ACF con grupos de campos predefinidos. Los franquiciados editan el contenido, no la estructura. No tienen acceso a la biblioteca completa de bloques del editor Gutenberg ni pueden tocar el tema.
Es una decisión de ingeniería, no de normativa interna. La dispersión de la marca no se resuelve con un manual de estilo en PDF. Se resuelve construyendo un CMS en el que la opción equivocada no está disponible.
Los roles y capacidades de WordPress permiten un control muy preciso. Se puede configurar un rol de editor para franquiciados que solo acceda a tipos de contenido concretos (la página de su ubicación) y a grupos de campos ACF concretos, sin acceso a la personalización del tema, a los ajustes de plugins ni al contenido de otras ubicaciones. El filtro map_meta_cap de WordPress permite ampliar ese control hasta el nivel de detalle que necesite si los roles predeterminados no bastan.
La sincronización de los recursos de marca entre ubicaciones se gestiona en el tema. Los tokens de color, las definiciones tipográficas y los archivos del logotipo se encuentran en la configuración del tema, no en los ajustes de cada página de ubicación. Cuando la central actualiza el color principal de la marca, se actualiza en todas partes a la vez. Los franquiciados no tienen ningún campo para sobrescribirlo.
Cuando un franquiciado incumple las normas de marca –sube una foto que no encaja con la marca o sustituye un titular por un mensaje promocional que choca con la comunicación de la central–, lo importante es el proceso de recuperación. El sistema de revisiones de WordPress cubre el contenido de las entradas; para los campos ACF, ACF 6.8.1 introdujo un almacén de datos que integra los valores de los campos con las revisiones de WordPress, de modo que los editores pueden consultar y restaurar valores anteriores desde la pantalla nativa de Revisiones. Para un registro detallado de quién hizo qué, añada un plugin específico de registro de actividad. Identifique el incumplimiento, vuelva a la última versión aprobada y explique al franquiciado cuál debe ser el contenido correcto.
En los proyectos en los que la capa de diseño requiere plena atención junto con la arquitectura técnica, nuestro trabajo de diseño UI/UX para WordPress abarca tanto la definición del sistema de diseño como la implementación de Figma a WordPress para clientes franquiciadores.
Para los grupos franquiciadores que no quieren desarrollar esta infraestructura desde cero, IMADO Location Engine ofrece una arquitectura de WordPress lista para producción para sitios web multiubicación. Centraliza datos de cada ubicación, como horarios, precios, eventos, promociones e información de reservas, y da a cada establecimiento acceso controlado a su propio contenido. Las nuevas ubicaciones se lanzan a partir de un modelo probado con páginas locales, datos estructurados, navegación, permisos e integraciones ya integrados en la plataforma, lo que permite que una red crezca sin volver a desarrollar las mismas funciones para cada nuevo establecimiento.
Implementación del SEO local: schema, GBP y enlazado interno
Cada página de ubicación necesita un schema LocalBusiness con la dirección, el horario, el teléfono y las coordenadas geográficas correctos. Los datos estructurados LocalBusiness dan a Google información explícita y legible por máquinas sobre cada ubicación física y pueden favorecer funciones de búsqueda local aptas. En los sitios de franquicias suelen estar implementados de forma insuficiente.
El schema debe implementarse como JSON-LD, insertado en el <head> de cada página de ubicación. WordPress no añade el schema LocalBusiness por defecto: RankMath y Yoast SEO lo admiten a través de sus módulos de SEO local, o puede implementarlo con un plugin propio que lea los datos de los campos de la página de ubicación. El @type debe ser el subtipo más específico que corresponda: LocalBusiness, FoodEstablishment, AutoRepair, LegalService, etc. Los tipos más específicos mejoran el reconocimiento de la entidad.
Cada página de ubicación debe llevar una etiqueta canonical autorreferenciada que apunte a su propia URL, una práctica habitual para evitar problemas de contenido duplicado si la página llega a ser accesible por varias rutas. Por otro lado, en el Perfil de Empresa en Google de cada ubicación, configure el campo Sitio web con la URL de la página de ubicación correspondiente. Así es como Google asocia la ficha de GBP con su sitio web, no a través de la etiqueta canonical. La documentación de Google sobre datos estructurados de LocalBusiness detalla las propiedades obligatorias y recomendadas. Los factores de posicionamiento local documentados por Google siguen siendo la relevancia, la distancia y la prominencia: el schema LocalBusiness no es un impulso directo del posicionamiento, pero da a Google información estructurada y puede mejorar la aptitud para las funciones de búsqueda local.
El enlazado interno desde el dominio raíz hacia las páginas de ubicación transmite autoridad hacia abajo en la jerarquía. La página índice de ubicaciones (domain.com/locations/) debe enlazar con cada página de ubicación. Las páginas de categoría (domain.com/locations/new-york/) deben enlazar con subpáginas por ciudad si la red es lo bastante grande como para justificar esa profundidad. La navegación principal del dominio raíz debe incluir un enlace «Encontrar una ubicación» que apunte al índice de ubicaciones. Es algo básico, pero falta en una cantidad considerable de sitios de franquicias.
La canibalización de palabras clave entre páginas de ubicación es un riesgo real. Si en la página de Chicago apunta a «servicios de fontanería Chicago» y una entrada del blog apunta a la misma frase, compiten entre sí. La solución es repartir claramente: las páginas de ubicación se quedan con las palabras clave transaccionales locales y el contenido del blog apunta a palabras clave informativas. No escriba una entrada titulada «Los mejores servicios de fontanería en Chicago» si tiene una página de ubicación para Chicago.
Rendimiento a escala: CDN y caché para más de 50 páginas de ubicación
WordPress gestiona miles de entradas de ubicación sin problemas de rendimiento cuando las consultas están bien estructuradas e indexadas. El reto de rendimiento en los sitios de franquicias no es el número de ubicaciones, sino la complejidad de las consultas y el volumen de tráfico.
La caché en la CDN y una caché de objetos de WordPress (Redis o Memcached) cobran importancia cuando hay: mucho tráfico en páginas de ubicación concretas, consultas geográficas o por radio costosas en un buscador de ubicaciones, llamadas a API de terceros por ubicación (feeds de reseñas, inventario, disponibilidad) o contenido dinámico que varía según la ubicación del usuario. Un estudio de Google sobre la velocidad en móviles concluyó que el 53 % de los usuarios móviles abandona los sitios que tardan más de 3 segundos en cargar; las páginas de ubicación con mapas y widgets de reseñas sin optimizar suelen ser las más lentas de un sitio de franquicia. Añada estas capas de caché cuando la carga de trabajo lo justifique.
El almacenamiento en caché de página completa para las páginas de ubicación se complica con el contenido dinámico. Las páginas que muestran reseñas en tiempo real, el horario actual o el inventario en directo no pueden almacenarse por completo en caché en el edge sin quedar desactualizadas. El enfoque correcto es almacenar en la CDN la estructura estática de cada página de ubicación y cargar después el contenido dinámico (reseñas, horario) mediante JavaScript tras el renderizado inicial. Así el Largest Contentful Paint sigue siendo rápido y el contenido se mantiene actualizado donde importa.
Nuestro servicio de optimización de velocidad de WordPress se ocupa precisamente de esta capa: configuración de la CDN, caché de objetos con Redis, optimización de consultas para sitios de WordPress con muchas ubicaciones y medición de las Core Web Vitals por ubicación, no solo en la página de inicio.
Objetivos de Core Web Vitals para las páginas de ubicación: LCP inferior a 2,5 segundos, CLS inferior a 0,1 e INP inferior a 200 milisegundos. Los mapas insertados son la causa más habitual de problemas de LCP y CLS en las páginas de ubicación. Cárguelos de forma diferida. Sirva las fotos de cada ubicación en formato WebP con dimensiones explícitas para evitar desplazamientos del diseño.
Supervise el rendimiento por ubicación, no solo en la página de inicio. Una franquicia con 40 páginas de ubicación en la que tres de ellas no superan sistemáticamente las Core Web Vitals tiene un problema que no encontrará revisando la página de inicio. Utilice el informe de Core Web Vitals de Google Search Console filtrado por patrón de URL o programe ejecuciones periódicas de Lighthouse sobre una muestra de páginas de ubicación.
Seguimiento analítico por ubicación en GA4
Google Analytics 4 permite segmentar por ubicación mediante dimensiones personalizadas. La implementación consiste en etiquetar cada página de ubicación con un parámetro location_id en la configuración de GA4 y crear después informes de Exploraciones que desglosen el tráfico, la tasa de interacción y los eventos de conversión por ubicación.
Cree en GA4 una dimensión personalizada llamada location_id con el ámbito «evento». Envíe el parámetro mediante la configuración de gtag o mediante Google Tag Manager con una variable que lea el identificador de ubicación de la URL de la página o de un push al data layer. Una vez que la dimensión tenga datos, podrá segmentar cualquier informe estándar de GA4 por ubicación.
El seguimiento de objetivos por ubicación debe cubrir como mínimo: envíos de formularios (contacto o solicitudes de presupuesto), clics en el número de teléfono y clics en «Cómo llegar» en el mapa de Google insertado. Cada uno debe registrarse como evento de conversión en GA4, con la dimensión location_id asociada. Así la central ve con claridad qué ubicaciones convierten y cuáles necesitan atención.
En Search Console, configure una propiedad de GSC para el dominio raíz y use el filtro de páginas del informe de Rendimiento para segmentar por el patrón de URL de las ubicaciones (/locations/). No necesita propiedades de GSC separadas para cada ubicación salvo que use dominios separados. La propiedad del dominio raíz recogerá automáticamente los datos de todos los subdirectorios.
Preguntas frecuentes
¿Una franquicia debe usar WordPress Multisite o instalaciones separadas para cada ubicación?
La decisión depende de los requisitos de aislamiento operativo, no del número de ubicaciones. Una sola instalación sirve para la mayoría de las redes de franquicias, incluso las grandes. Multisite tiene sentido cuando las ubicaciones necesitan administradores propios, configuraciones de plugins independientes o cuando usted gestiona varias marcas de franquicia distintas desde un mismo motor de WordPress. Como punto de partida aproximado, solemos evaluar Multisite a partir de unas 20 ubicaciones, pero el número de ubicaciones por sí solo no debería determinar la decisión.
¿Cuál es la mejor estructura de URL para el sitio web de una franquicia?
Los subdirectorios son la recomendación por defecto para los sitios de franquicias. La estructura dominio.com/locations/nombre-ciudad/ concentra la autoridad del dominio bajo una sola raíz, es más fácil de gobernar para los equipos centrales y evita la fragmentación del valor SEO que provocan los subdominios.
¿Cómo mantienen los sitios de franquicias la coherencia de marca en todas las ubicaciones?
La coherencia de marca se impone desde el CMS, no con documentos de normas. Bloquee los elementos de diseño globales (cabecera, pie de página, fuentes, colores) en el tema de WordPress y dé a los franquiciados acceso solo a grupos de campos ACF predefinidos para el contenido de la página de su ubicación. Así, las ediciones que incumplen las normas no son simplemente desaconsejadas: no están disponibles.
¿Qué marcado schema debe usar el sitio de una franquicia para cada ubicación?
Use el schema LocalBusiness (o el subtipo más específico que corresponda) implementado como JSON-LD en el <head> de cada página de ubicación. Incluya la dirección, el teléfono, el horario, las coordenadas geográficas y la URL de la propia página de ubicación (por ejemplo, example.com/locations/chicago/). La propiedad url del schema LocalBusiness debe apuntar a la página web, no a la URL de Google Maps ni de la ficha de GBP.
¿Cómo se evita que las páginas de ubicación se consideren contenido duplicado?
Cada página de ubicación necesita al menos cinco señales de contenido únicas: un titular específico de la ubicación, una descripción de los servicios locales, los datos NAP, un mapa de Google insertado con esa dirección y reseñas de la ficha de GBP de esa ubicación. Las páginas pobres que solo cambian el nombre de la ciudad en una plantilla compartida se exponen a la penalización de Google por páginas puerta (doorway pages).
Resumen
El diseño web multiubicación para franquicias es, ante todo, una decisión de arquitectura, no de diseño. Defina primero la estructura de URL adecuada (subdirectorios), elija después entre instalación única y Multisite según el número de ubicaciones y quién controla el contenido, y construya luego páginas de ubicación realmente únicas en lugar de limitarse a sustituir el nombre de la ciudad. La gobernanza de marca, el SEO local y el rendimiento a escala se derivan de esas decisiones de base.
Los servicios de desarrollo WordPress de IMADO cubren todo este conjunto: definición de la arquitectura, configuración de Multisite, interfaces editoriales basadas en ACF, implementación del schema LocalBusiness, configuración de la CDN y seguimiento en GA4 por ubicación. Creamos plataformas de franquicias para redes de entre 5 y más de 100 ubicaciones.
Hable con nuestros ingenieros de WordPress para franquicias para definir el alcance de su proyecto.
