Modelado Correcto de Geografías Complejas en JSON‑LD para Knowledge Graph y AI Search

Elias Ramirez

El problema central es la ausencia de patrones canónicos oficiales para entidades multi-sede, áreas de servicio y negocios híbridos: Schema.org define las primitivas, pero no prescribe cómo combinarlas en grafos de conocimiento cohesionados. El resultado es que Google y los modelos de IA tienen que inferir relaciones entre entidades que deberían estar explícitamente conectadas.

Entidades como nodos, no como bloques aislados

El principio rector antes de cualquier patrón es construir un grafo de entidades con @id, no bloques JSON-LD independientes. Cada entidad (organización matriz, sede, área de servicio) recibe un identificador permanente con el que se referencia desde cualquier otro nodo del sitio. Esto garantiza que al añadir un GBP a la organización matriz, todas las páginas que referencian ese @id heredan la conexión automáticamente.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://tu-dominio.com/#organization",
  "name": "Nombre Corporativo",
  "sameAs": [
    "https://www.google.com/maps?cid=TU_CID_PERMANENTE",
    "https://www.linkedin.com/company/tu-empresa",
    "https://www.facebook.com/tu-empresa"
  ]
}

Para localizar el CID permanente (estable ante cambios de dirección o formato de URL), se extrae del código fuente de Maps buscando ludocid, o se usa el conversor de PlePer.com. 

Cadena Multi-Sede

¿Cómo conectar sedes con la organización matriz?

La sede matriz se modela como Organization (o el @type corporativo específico). Cada sucursal es una entidad LocalBusiness independiente con su propio @id y referencia a la matriz mediante parentOrganization. La matriz, a su vez, puede listar las sucursales con department o simplemente dejar que cada sede declare su branchOf. Cada sede tiene su propio bloque NAP (nombre, dirección, teléfono), coordenadas y enlace hasMap a su GBP individual.

// Sede individual — colocar en la página de esa ubicación
{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "@id": "https://tu-dominio.com/sede-madrid/#localbusiness",
  "name": "Empresa X — Madrid",
  "parentOrganization": {
    "@id": "https://tu-dominio.com/#organization"
  },
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Calle Gran Vía, 42",
    "addressLocality": "Madrid",
    "addressRegion": "Community of Madrid",
    "postalCode": "28013",
    "addressCountry": "ES"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 40.41999,
    "longitude": -3.70275
  },
  "hasMap": "https://www.google.com/maps?cid=CID_SEDE_MADRID",
  "sameAs": ["https://www.google.com/maps?cid=CID_SEDE_MADRID"],
  "telephone": "+34 91 000 0000",
  "openingHours": ["Mo-Fr 09:00-18:00"]
}

El error más común aquí es reutilizar el mismo sameAs de la GBP corporativa en todas las sedes: cada sede necesita su propio CID de GBP, de lo contrario Google mezcla reviews y horarios entre ubicaciones.

Servicio a Domicilio / Service Area Business

¿Cómo modelar áreas de servicio sin dirección pública?

Para negocios que operan en el domicilio del cliente (fontaneros, agencias, clínicas a domicilio), Schema.org ofrece dos propiedades complementarias:

  • areaServed: lista de ciudades, regiones o países donde se presta el servicio. Puede ser texto, City, State, o GeoShape.
  • serviceArea: acepta un objeto GeoShape con polygon o circle para delimitar el área con precisión geométrica.

El stack recomendado combina ambas, usando areaServed para la legibilidad semántica y GeoShape para la precisión geoespacial:

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "@id": "https://tu-dominio.com/#sab",
  "name": "Electricistas Madrid",
  "areaServed": [
    {"@type": "City", "name": "Madrid"},
    {"@type": "City", "name": "Alcalá de Henares"},
    {"@type": "AdministrativeArea", "name": "Comunidad de Madrid"}
  ],
  "serviceArea": {
    "@type": "GeoShape",
    "circle": "40.41650 -3.70379 50000"
  },
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "Madrid",
    "addressCountry": "ES"
  },
  "sameAs": ["https://www.google.com/maps?cid=CID_NEGOCIO"]
}

El círculo se expresa como "latitud longitud radio_en_metros". Para áreas irregulares (un polígono que excluye ciertos municipios), se usa "polygon": "lat1 lon1 lat2 lon2 ...". En Google Business Profile, esta configuración debe espejarse en Información > Área de cobertura con exactamente las mismas ciudades declaradas en areaServed.

Negocio Híbrido (Local + Online)

¿Cómo declarar presencia física y alcance nacional sin mezclar señales?

Un negocio con sede física pero clientes remotos (agencia de Madrid que trabaja con clientes en toda España) necesita separar la entidad física de la entidad de servicio online. La práctica más robusta es un grafo de dos nodos relacionados:

Nodo@typeFunciónPropiedades clave
Sede físicaLocalBusinessPresencia Maps, rich snippets localesaddress, geo, hasMap, sameAs → GBP
Alcance de serviciosOrganization o ProfessionalServiceAI Overviews nacionales, Knowledge GraphareaServed, serviceArea, knowsAbout

// Dos nodos en el mismo <script> o en scripts separados
[
  {
    "@context": "https://schema.org",
    "@type": "ProfessionalService",
    "@id": "https://tu-dominio.com/#service",
    "name": "Agencia SEO España",
    "areaServed": {"@type": "Country", "name": "Spain"},
    "parentOrganization": {"@id": "https://tu-dominio.com/#organization"}
  },
  {
    "@context": "https://schema.org",
    "@type": "LocalBusiness",
    "@id": "https://tu-dominio.com/#localbusiness",
    "name": "Agencia SEO — Oficina Madrid",
    "parentOrganization": {"@id": "https://tu-dominio.com/#organization"},
    "address": { "...": "dirección física Madrid" },
    "geo": { "@type": "GeoCoordinates", "latitude": 40.41, "longitude": -3.70 },
    "hasMap": "https://www.google.com/maps?cid=TU_CID"
  }
]

Franquicias Independientes con Marca Compartida

¿Cómo evitar que Google fusione entidades de franquiciados?

La clave es que cada franquiciado es una entidad jurídica distinta, por lo que debe tener su propio @id, su propio GBP, su propio dominio o subdirectorio, y su propio CID en sameAs. La relación con la marca se declara vía memberOf (si el franquiciado pertenece a la red) o branchOf (si es oficialmente una sucursal). La diferencia práctica:

  • branchOf: implica control operativo de la casa madre → Google puede consolidar entidades. Usar solo si la franquicia es de propiedad directa.
  • memberOf: implica afiliación a una red → preserva la independencia de cada entidad. Preferible para franquicias autónomas.
{
  "@type": "LocalBusiness",
  "@id": "https://franquiciado-barcelona.com/#localbusiness",
  "name": "Marca X — Barcelona (franquicia)",
  "memberOf": {
    "@type": "Organization",
    "@id": "https://marca-central.com/#organization",
    "name": "Marca X International"
  }
}

Consistencia NAP y Validación

La consistencia NAP (Name, Address, Phone) debe ser exacta al carácter entre el structured data del sitio y el GBP: «Calle Gran Vía 42» y «Gran Vía, 42» son cadenas distintas para un parser. Cuando hay discrepancia, la versión del GBP es la referencia autoritativa porque Google ya la ha verificado.

Herramientas de validación recomendadas:

  • Rich Results Test (search.google.com/test/rich-results): verifica elegibilidad para rich snippets y detecta errores de sintaxis.
  • Schema Markup Validator (validator.schema.org): valida conformidad con el vocabulario sin el filtro de Google.
  • Knowledge Graph Search API: comprueba si la entidad ya tiene un nodo en el KG (kgsearch.googleapis.com/v1/entities:search?query=...).
  • Google Search Console → Mejoras → Empresa local: monitoriza errores post-publicación y cobertura de rich results.

GeoShape vs. areaServed Textual

Hipótesis inicial: usar solo areaServed con strings de texto (ciudad, provincia) sería suficiente para que Google entienda el alcance geográfico.

Resultado observado: los paneles locales en queries como «electricista Comunidad de Madrid» aparecen con mayor consistencia cuando se combina areaServed con un GeoShape de tipo circle o polygon. Con solo texto, Google no puede determinar si un municipio limítrofe entra o no dentro del área.

Desviación: el GeoShape tipo polygon de alta complejidad (>50 vértices) puede ser ignorado por el parser y revertir a la interpretación textual de areaServed.

Conclusión técnica: usar GeoShape simple (círculo con radio) para la mayoría de SABs, reservar el polígono para áreas con fronteras administrativas muy irregulares, y siempre complementar con areaServed legible para el fallback semántico.

Casos de Fallo Documentados

  • Reutilizar el sameAs de la marca en todas las sedes: Google puede fusionar el Knowledge Panel de todas las ubicaciones en uno solo, mezclando reviews y horarios.
  • branchOf en franquicias independientes: si el franquiciado no tiene control operativo de la casa madre pero usa branchOf, Google puede atribuir los reviews negativos de una sede a toda la red.
  • NAP inconsistente entre GBP y schema: incluso una diferencia como «Av.» vs. «Avenida» reduce el score de confianza en el entity graph y puede impedir la aparición en AI Overviews locales.
  • areaServed en el nodo LocalBusiness con dirección física visible: mezclar señales de presencia física y cobertura de servicio en el mismo nodo puede confundir al algoritmo entre «está aquí» y «sirve allá».

Reproducibilidad

Para verificar que el @id de una entidad está siendo procesado correctamente por Google:

# Verificar entidad en Knowledge Graph API
curl "https://kgsearch.googleapis.com/v1/entities:search?\
query=NOMBRE_NEGOCIO&key=TU_API_KEY&limit=5&indent=True"

# Validar structured data con respuesta HTTP
curl -s "https://validator.schema.org/validate?url=https://tu-dominio.com" \
  -H "Accept: application/json"

# Comprobar extracción de rich results (headless)
ab -n 1 -H "Accept: application/json" \
  "https://search.google.com/test/rich-results?url=https://tu-dominio.com/sede-madrid/"

Para el estudio empírico, el dataset de referencia más usado para comparar rendimiento de Knowledge Panels locales es el Local Search Ranking Factors Survey de Whitespark (actualización 2026), que desglosa los factores de señal por tipo de negocio y modelo de servicio.