Señales de localidad en LLM: geolocalización, contexto y citación

¿Cuántas veces has visto que ChatGPT o Perplexity responden a una búsqueda con intención local citando fuentes genéricas o de otro país? No es un error aleatorio. Es el resultado directo de cómo los LLM procesan —o no procesan— las señales de localidad. Si produces contenido a escala para marcas con presencia geográfica concreta, entender este mecanismo es operacionalmente crítico.

Qué entiende un LLM por «localidad»

Conviene aclarar esto desde el principio porque hay una confusión frecuente: un LLM no tiene acceso a tu IP, no consulta una base de datos de ubicaciones en tiempo real y no interpreta coordenadas GPS. Su noción de localidad es puramente textual y probabilística.

Cuando un modelo recibe una consulta como «mejores fontaneros en Sevilla», no ejecuta una búsqueda geolocalizada. Lo que hace es buscar, dentro de su corpus de entrenamiento o en los fragmentos recuperados vía RAG (Retrieval-Augmented Generation), contenido que asocie semánticamente «fontanero» con «Sevilla» de forma explícita. Si tu página habla de fontanería sin mencionar Sevilla en ningún lugar relevante, el modelo no infiere la relación.

La implicación directa es que la localidad tiene que estar escrita, no implícita. Un negocio cuya web solo menciona el nombre de la ciudad en el footer o en la dirección postal tiene una señal de localidad débil desde la perspectiva de un motor generativo.

La diferencia con el SEO tradicional

En SEO clásico, Google combina señales textuales con señales de entidad (Google Business Profile, NAP consistente, citas locales) y señales de comportamiento (clics desde una zona geográfica). Ese ecosistema de señales extratextuales no existe para un LLM de base.

Los motores generativos con capacidad de búsqueda en tiempo real —como Perplexity o el modo de búsqueda de ChatGPT— pueden recuperar páginas actuales, pero el criterio de selección sigue siendo semántico: el fragmento recuperado tiene que contener la señal de localidad de forma explícita para que el modelo lo considere relevante. Esto no está confirmado públicamente en detalle técnico por ninguna de las compañías, pero es inferencia razonada a partir del comportamiento observable de estos sistemas.

El papel del contexto de la conversación

Hay un matiz importante que afecta a los sistemas con memoria de sesión. Si el usuario ha mencionado su ciudad en un turno anterior de la conversación, el modelo puede usar ese dato como señal de localidad implícita para las consultas siguientes. Esto es relevante para el diseño de interfaces conversacionales, pero no para el contenido estático: tu artículo o ficha de negocio no controla el contexto de sesión del usuario.

Cómo el corpus de entrenamiento sesga la localidad

Antes de que entre en juego ninguna búsqueda en tiempo real, el LLM ya tiene una «opinión» sobre qué entidades locales existen y cuáles son relevantes. Esa opinión viene del corpus de entrenamiento, y ese corpus tiene un sesgo geográfico y lingüístico muy pronunciado.

El inglés, y especialmente el contenido anglosajón, está sobrerrepresentado en los modelos más extendidos. Para el español de España, la cobertura es razonable en contenido de alcance nacional, pero se deteriora significativamente en contenido hiperlocal: barrios, municipios pequeños, negocios de nicho en ciudades medianas. Si tu negocio opera en un mercado de ese tipo, la probabilidad de que el modelo lo haya «visto» durante el entrenamiento es baja.

Esto significa que la estrategia de citabilidad para motores generativos en contextos locales tiene que compensar ese déficit de cobertura. No puedes asumir que el modelo ya «sabe» que existes.

RAG y recuperación de fragmentos con intención local

Los motores generativos más avanzados —Perplexity, el modo de búsqueda de ChatGPT, Gemini con acceso a la web— usan RAG para complementar el conocimiento del modelo base con contenido recuperado en tiempo real. Este es el vector donde la optimización de contenido tiene más impacto directo.

En un pipeline RAG típico, el sistema convierte la consulta del usuario en un vector semántico, recupera los fragmentos más similares de un índice y los inyecta en el contexto del modelo antes de generar la respuesta. El fragmento que se recupera es, en la mayoría de los casos, un bloque de texto de entre 200 y 500 palabras, no la página completa.

Qué hace que un fragmento sea recuperable en búsquedas locales

Para que tu contenido sea recuperado en una consulta con intención local, ese fragmento de 200-500 palabras tiene que cumplir varias condiciones simultáneamente:

• Contener la entidad geográfica de forma explícita (ciudad, barrio, provincia) en el mismo bloque de texto, no solo en el título o en el footer.
• Asociar esa entidad geográfica con la categoría de servicio o producto de forma directa, no mediante inferencia.
• Tener suficiente densidad semántica alrededor del tema para que el vector del fragmento sea similar al vector de la consulta.
• Proceder de una fuente con autoridad suficiente para que el sistema la incluya en el índice de recuperación.

Un error frecuente es concentrar todas las señales de localidad en la página de inicio o en una única landing de «servicios en [ciudad]» y no distribuirlas en el contenido editorial. Desde la perspectiva de RAG, cada pieza de contenido es un fragmento potencialmente recuperable de forma independiente. Si el artículo de blog no menciona la ciudad, ese fragmento no compite en consultas locales aunque el dominio sí lo haga.

El problema de la ambigüedad geográfica

Algunos topónimos son ambiguos: Valencia puede ser la ciudad española o la región, pero también existe Valencia en Venezuela. Granada aparece en España y en Nicaragua. Un LLM resuelve esa ambigüedad por contexto, y si el contexto del fragmento no es suficientemente claro, puede resolver en la dirección equivocada.

La solución operacional es sencilla: añade contexto desambiguador explícito. «Valencia, España» o «Granada, Andalucía» en lugar de solo el topónimo. En contenido a escala, esto puede implementarse como una regla de estilo en el brief de contenido.

Geolocalización implícita: cómo el modelo infiere la ubicación del usuario

Hay una segunda dimensión del problema que afecta a cómo el motor generativo interpreta la consulta del usuario, no solo el contenido. Algunos sistemas intentan inferir la ubicación del usuario a partir de señales indirectas.

Las señales que un motor generativo puede usar para inferir la ubicación del usuario incluyen:

• El idioma y la variante dialectal de la consulta (español de España vs. español de México).
• Menciones explícitas de lugares en la consulta o en el historial de la sesión.
• Metadatos de la solicitud API que la aplicación cliente puede o no enviar (algunos sistemas pasan la región del usuario como parámetro).
• El perfil de la cuenta, si el usuario está autenticado y ha configurado su ubicación.

Lo que no ocurre en ningún LLM de uso general es una geolocalización por IP en tiempo real integrada en el razonamiento del modelo. Eso es inferencia razonada, no dato confirmado públicamente, pero es consistente con la arquitectura conocida de estos sistemas.

Citabilidad local: qué hace que un LLM te cite en respuestas con intención geográfica

La citabilidad —la probabilidad de que un motor generativo mencione o enlace tu contenido en una respuesta— tiene una dimensión local que merece tratarse por separado. No es suficiente con que tu contenido sea recuperable; tiene que ser lo suficientemente autoritativo como para que el modelo lo cite en lugar de parafrasear sin atribución.

Los factores que aumentan la citabilidad en respuestas locales son, en su mayoría, los mismos que en respuestas generales, pero con un matiz geográfico:

• Topical authority local: un dominio que trata de forma consistente temas relacionados con una geografía concreta tiene más probabilidades de ser recuperado en consultas de esa geografía. Esto es inferencia razonada basada en cómo funcionan los sistemas de ranking semántico.
• E-E-A-T con anclaje geográfico: las señales de experiencia y autoridad (E-E-A-T) son más creíbles cuando están ancladas a una ubicación. Un artículo firmado por un profesional con trayectoria verificable en una ciudad concreta tiene más peso que uno genérico.
• Consistencia de la entidad: si el nombre del negocio, la ciudad y la categoría aparecen de forma consistente en múltiples fuentes indexadas, el modelo tiene más confianza en la entidad y más probabilidades de citarla.
• Datos estructurados: el marcado Schema.org (LocalBusiness, Service, Event con ubicación) no es procesado directamente por el LLM, pero sí por los sistemas de indexación que alimentan el RAG. Es una señal indirecta pero relevante.

Dicho esto: ninguna compañía ha publicado los criterios exactos de selección de fuentes para sus motores generativos. Todo lo anterior es inferencia razonada a partir del comportamiento observable y de la arquitectura conocida de estos sistemas. Conviene tratarlo como hipótesis de trabajo, no como certeza.

Implicaciones prácticas para la producción de contenido a escala

Si gestionas producción de contenido para clientes con presencia local —agencias, franquicias, negocios con múltiples sedes— las señales de localidad LLM tienen que entrar en el brief de contenido como requisito explícito, no como algo que «ya se entiende».

Lo que puedes implementar ahora mismo

Estas son las acciones con mayor impacto operacional, ordenadas de menor a mayor fricción de implementación:

1. Añade la entidad geográfica en los primeros 100 palabras de cada pieza, no solo en el título o en la meta description. El fragmento recuperado por RAG suele empezar cerca del inicio del contenido.
2. Desambigua los topónimos cuando haya riesgo de confusión: «Málaga, España» en lugar de solo «Málaga».
3. Distribuye las señales de localidad en el contenido editorial, no solo en páginas de aterrizaje. Cada artículo de blog es un fragmento recuperable independiente.
4. Incluye referencias a entidades locales verificables: nombres de barrios, referencias a instituciones locales conocidas, eventos o características geográficas reconocibles. Esto aumenta la densidad semántica local del fragmento.
5. Mantén consistencia de la entidad entre la web, el perfil de Google Business, directorios sectoriales y cualquier fuente que pueda ser indexada. La consistencia reduce la incertidumbre del modelo sobre quién eres y dónde estás.

Lo que no puedes controlar (y conviene asumir)

No puedes controlar si el sistema generativo que usa tu cliente final tiene acceso a búsqueda en tiempo real o trabaja solo con el corpus de entrenamiento. No puedes controlar el contexto de sesión del usuario ni los metadatos que la aplicación cliente envía al modelo. Y no puedes controlar los criterios de selección de fuentes de cada plataforma, porque no son públicos.

Lo que sí puedes controlar es la calidad y la densidad de las señales de localidad en el contenido que produces. Ese es el único vector de optimización que está en tu mano. El resto es ruido sobre el que no tiene sentido gastar recursos.

La conclusión operacional es directa: trata cada bloque de contenido como si tuviera que ser entendible de forma aislada, sin contexto de dominio ni de navegación. Si ese fragmento de 300 palabras no deja claro quién eres, qué ofreces y dónde lo ofreces, no está optimizado para motores generativos con intención local. Esa es la regla de producción más simple y más ignorada en este momento.

Preguntas frecuentes

¿Los LLM usan la IP del usuario para determinar su ubicación?

No directamente. Los LLM de uso general no tienen acceso a la IP del usuario en el proceso de generación. Algunos sistemas pueden recibir metadatos de región desde la aplicación cliente, pero eso depende de cómo esté implementada la integración, no del modelo en sí. La inferencia de ubicación se basa principalmente en señales textuales de la consulta y del historial de sesión.

¿Sirve de algo el marcado Schema.org LocalBusiness para los motores generativos?

De forma indirecta, sí. El LLM no procesa el JSON-LD directamente, pero los sistemas de indexación que alimentan el RAG sí pueden interpretarlo. Además, Schema.org mejora la coherencia de la entidad en los resultados de búsqueda tradicionales, lo que a su vez aumenta la probabilidad de que esas páginas sean indexadas y recuperadas. No es una señal primaria, pero tampoco es irrelevante.

¿Cómo afecta esto a negocios con varias sedes en distintas ciudades?

Cada sede necesita señales de localidad propias en el contenido que la representa. Una página genérica de «nuestras sedes» con una lista de ciudades tiene una señal de localidad débil para cada una de ellas. Lo más efectivo es crear contenido específico por sede donde la entidad geográfica, la categoría de servicio y los detalles de la ubicación aparezcan de forma explícita y consistente en el mismo fragmento.

¿Hay diferencia entre cómo trata la localidad Perplexity versus ChatGPT?

Las arquitecturas de recuperación difieren, pero el principio subyacente es el mismo: ambos sistemas dependen de que el contenido recuperado contenga señales de localidad explícitas para considerarlo relevante en consultas geográficas. Perplexity publica más detalles sobre sus fuentes, lo que permite observar qué tipo de contenido recupera. ChatGPT con búsqueda es más opaco. En la práctica, optimizar el contenido para que las señales de localidad sean explícitas y densas funciona en ambos sistemas.