GEO local en Madrid: cómo preparar tu empresa para ChatGPT y Google IA

Una empresa de Madrid puede aparecer en una respuesta de ChatGPT, Google AI o Bing Copilot sin que nadie haya escrito su nombre a mano. También puede no aparecer aunque tenga una web bonita y una ficha de Google activa. La diferencia rara vez está en una "técnica GEO" aislada: está en que el sistema pueda acceder a información clara, comprobar de qué empresa habla, encontrar una respuesta útil y relacionarla con una necesidad local concreta.

Esta página no intenta prometer que un asistente vaya a recomendarte. Ninguna agencia controla los índices, el modelo, la ubicación real de la persona que pregunta ni la selección final de enlaces. Su función es más concreta: explicar cómo preparar a una empresa que trabaja en Madrid para que sus datos, páginas, pruebas y recorridos de búsqueda sean más fáciles de descubrir, entender y citar.

Qué cubre esta guía y qué cubre la guía canónica de IA

En YAG separamos estas dos intenciones para no crear diez artículos que repitan lo mismo. La guía general de cómo aparecer en ChatGPT y Google AI Overviews explica los fundamentos comunes: acceso de robots, contenido fuente, entidades, datos estructurados, corroboración externa y medición.

Esta guía es la capa local. Sirve para una clínica, un despacho, una asesoría, una empresa de reformas, un ecommerce con recogida o cualquier pyme que quiera resolver preguntas como estas:

• "¿Qué empresas de este servicio hay cerca de mí en Madrid?"
• "¿Qué debería comprobar antes de contratar a un proveedor en Chamberí, Retiro o Arganzuela?"
• "¿Cuál es la diferencia entre dos opciones locales y qué señales de confianza tienen?"
• "¿Cómo puedo encontrar una empresa que haga esto en Madrid y entienda mi problema?"

La página general responde a la arquitectura de visibilidad en IA. Esta responde a la implementación local: qué datos deben ser consistentes, qué páginas deben existir, cómo evitar páginas de distrito copiadas y qué señales conviene medir. Las dos se enlazan porque complementan la decisión; no deben competir por la misma consulta genérica.

La condición de partida: ser elegible no equivale a ser recomendado

La documentación de Google es bastante clara: las prácticas de SEO habituales siguen siendo las relevantes para AI Overviews y AI Mode. Una página debe estar indexada y ser apta para mostrarse con un fragmento en Search; no existe un requisito técnico adicional que obligue a Google a incluirla. Google también indica que no hacen falta archivos de texto de IA ni marcado especial para estas funciones. Puedes comprobarlo en su documentación sobre funciones de IA y sitios web.

Para ChatGPT, OpenAI indica que un sitio público puede aparecer en la búsqueda y que, si se desea que el contenido pueda incluirse en resúmenes y fragmentos, no debe bloquearse OAI-SearchBot. Esa instrucción no convierte una página en una recomendación, pero bloquear el bot sí puede eliminar una vía de descubrimiento. La fuente de referencia es la FAQ para editores y desarrolladores de OpenAI.

En otras palabras: primero se habilita el acceso, luego se ofrece una fuente útil y por último se mide si los sistemas la usan. Saltarse el primer paso hace inútil el resto. Confundir el segundo con una garantía crea expectativas falsas.

Lo que una empresa sí puede controlar

Una empresa puede controlar que su página sea rastreable, que su teléfono y dirección estén bien escritos, que la ficha local esté actualizada, que sus servicios se expliquen sin ambigüedad, que sus casos tengan permiso y que sus artículos citen fuentes. También puede controlar si el formulario responde a la necesidad que atrajo a la persona.

No puede controlar que una IA mantenga la misma respuesta mañana, que una consulta dispare una respuesta generativa o que aparezca siempre el mismo conjunto de fuentes. Por eso el objetivo serio no es "salir primero en ChatGPT"; es elevar la calidad de las señales que permiten competir por una cita o una inclusión comercial cuando la pregunta y el sistema encajan.

Paso 1: comprobar acceso real, no solo abrir la web en tu navegador

Una auditoría local empieza por validar que los robots llegan a las páginas que deberían servir de fuente. Que una URL cargue en tu móvil no prueba que Googlebot, Bingbot u OAI-SearchBot reciban el mismo HTML. Un CDN o un WAF puede responder con un challenge, una pantalla intermedia, un 403 o una página vacía para un bot aunque la experiencia humana sea normal.

La comprobación mínima debería incluir:

1. robots.txt público y coherente con la política de rastreo elegida.
2. Sitemap accesible, con las URLs canónicas que se quieren descubrir.
3. Una única URL canónica por página, sin noindex o nosnippet añadidos por error.
4. HTML principal con texto legible, no una interfaz que requiera varias interacciones para revelar el servicio.
5. Enlaces internos desde páginas ya indexables hacia los recursos que deben responder preguntas.
6. Pruebas contra el CDN y el WAF con agentes y rutas reales, especialmente tras cambios de seguridad.

Google recomienda permitir el rastreo tanto en robots.txt como en la infraestructura CDN, mantener el contenido importante en formato textual y facilitar su descubrimiento mediante enlaces internos. También recuerda que los datos estructurados deben coincidir con el texto visible. No es teoría: son los mínimos que permiten a un buscador entender una página antes de decidir si la muestra. La guía oficial de Google reúne esos puntos.

No hace falta activar GPTBot para permitir OAI-SearchBot. Son decisiones distintas. Si la empresa no quiere que su contenido se use para entrenamiento, debe revisar esa política de forma explícita y documentada; no conviene bloquear todos los agentes de OpenAI por defecto y perder también la posibilidad de aparecer en búsqueda.

Paso 2: hacer que la entidad local sea consistente

Una respuesta local necesita resolver cuatro preguntas simples: quién es la empresa, qué hace, dónde atiende y cómo puede comprobarse. Si cada fuente contesta algo distinto, una IA tiene más motivos para elegir otra opción menos ambigua.

Para una sede real en Madrid, la ficha de control debe incluir nombre comercial, razón social cuando corresponda, dirección o zona de servicio, teléfono, URL, horarios, categoría principal y descripción de servicios. La misma identidad debe aparecer de manera consistente en la web, perfiles sociales, directorios relevantes, facturas o páginas de contacto que la empresa controle.

La coherencia no significa repetir un bloque de palabras clave. Significa evitar contradicciones: una oficina que existe en la web pero no en los perfiles, un teléfono antiguo en Apple Maps, servicios que se anuncian en una landing y no aparecen en la página principal, o una ciudad declarada en JSON-LD que no se ve en ningún sitio. Para datos estructurados, Google recomienda describir el contenido de la propia página y no incluir información invisible solo porque sea cierta. Su documentación de structured data lo deja claro.

Google, Bing y Apple: tres activos, una sola identidad

Google Business Profile es el activo local de Google. Bing Places y Apple Business Connect cubren otros ecosistemas y permiten mantener datos de negocio actualizados para Bing, Copilot, Apple Maps, Siri y superficies relacionadas. No hay una base pública que permita afirmar que una ficha concreta garantiza una cita en un asistente, pero tener información local incompleta sí deja al negocio peor preparado para cualquier búsqueda de proximidad.

El orden práctico es sencillo:

• Actualiza primero Google Business Profile con categoría, horarios, servicios, fotos y datos verificables.
• Crea o revisa Bing Places for Business con la misma identidad.
• Completa Apple Business Connect para que Apple Maps no arrastre datos incorrectos o incompletos.
• Registra en una hoja de control quién revisó cada perfil, cuándo y qué fuente valida el dato.

Bing ya ofrece un informe de AI Performance en Bing Webmaster Tools que muestra actividad de citas por URL y consultas de grounding en experiencias compatibles. Es útil para descubrir qué páginas se usan, no para afirmar que una cita equivale a ranking, autoridad o venta.

Paso 3: asignar una URL a cada pregunta local importante

La mayoría de webs locales fallan porque intentan que la home responda a todo. Una clínica con una única página de "servicios", una asesoría que no explica sus procesos o una empresa de reformas que solo tiene un portfolio visual deja preguntas críticas sin URL de referencia.

El primer mapa no necesita cien páginas. Necesita que cada intención comercial tenga una página principal y que los contenidos auxiliares amplíen una pregunta diferente. Para una empresa de Madrid, una arquitectura razonable puede verse así:

Una página debe declarar lo que puede demostrar. "Servicio SEO en Madrid" tiene que explicar qué analiza, qué trabajo incluye, qué depende del cliente y cómo se mide. "Abogado laboralista en Madrid" debe dejar que el despacho concreto explique sus especialidades reales, no usar una fórmula que se repite para todos los barrios.

En YAG trabajamos esta base en la guía de SEO local en Madrid y en la checklist operativa de SEO local. Antes de crear otra URL conviene comprobar si la pregunta ya tiene una respuesta útil; si no la tiene, se mejora esa página o se crea un recurso con función propia.

Paso 4: escribir cápsulas de respuesta que una persona quiera guardar

La extractabilidad no consiste en fragmentar el texto hasta que parezca un manual para robots. Consiste en no esconder la respuesta. Bajo un H2 o un H3 que formule una duda real, abre con una respuesta breve y concreta. Después añade el contexto: para quién vale, qué pruebas hacen falta, qué excepción existe y qué debe hacer la persona a continuación.

Por ejemplo, una empresa de reformas no necesita una frase genérica sobre "calidad y compromiso". Puede responder: "El presupuesto de una reforma integral depende de metros, distribución, licencias, instalaciones y acabados. Antes de comparar cifras, pide que cada partida indique materiales, mano de obra, plazo y qué imprevistos quedan fuera." Esa pieza es útil para un cliente, se puede contrastar y abre una conversación comercial honesta.

Para una empresa local, las preguntas más productivas suelen ser estas:

• Qué incluye exactamente el servicio.
• Qué información necesita el proveedor para presupuestar.
• Cuánto tiempo puede llevar y de qué depende.
• Qué errores comete un cliente al elegir una opción barata.
• Cuándo conviene una solución estándar, una integración o un desarrollo a medida.
• Qué prueba de experiencia puede revisar antes de contactar.

La respuesta corta no elimina la profundidad. Una buena guía combina una conclusión visible, criterios de decisión, ejemplos no inventados, fuentes primarias y un enlace a la acción o al recurso siguiente. Así puede servir a quien busca una definición, a quien compara proveedores y a un sistema que necesita entender el tema con precisión.

Paso 5: usar datos estructurados para describir, no para adornar

El JSON-LD ayuda a que buscadores y herramientas entiendan la relación entre una organización, una página, un servicio, un artículo, una persona y una dirección. Es especialmente útil cuando el sitio tiene varias líneas de negocio, autores, sedes reales o contenido técnico que necesita contexto.

Pero el marcado no sustituye al contenido visible ni arregla una propuesta comercial imprecisa. Una página sobre un servicio puede describir un Service; un artículo puede describirse como BlogPosting; una ruta local puede enlazar su WebPage con la organización y con la información que aparece de verdad en pantalla. Lo importante es mantener @id, URL, nombre, autor y datos del negocio de forma coherente, no añadir todos los tipos de Schema.org posibles.

Antes de publicar, revisa tres preguntas:

1. ¿Cada dato del JSON-LD se puede ver o verificar desde la página?
2. ¿La URL del servicio es exactamente la que declara el marcado?
3. ¿La organización, el teléfono, las sedes y las áreas de servicio cuentan la misma historia en todo el sitio?

Google advierte que es mejor aportar pocas propiedades completas y precisas que muchas propiedades incompletas o incorrectas. El Rich Results Test sirve para validar errores de sintaxis, pero no evalúa si una empresa merece ser recomendada ni sustituye la revisión editorial.

Paso 6: trabajar Madrid sin convertir los distritos en contenido basura

Madrid tiene barrios y distritos con búsquedas reales, pero eso no convierte cada combinación de servicio + barrio en una página necesaria. Cambiar "Chamberí" por "Salamanca" en una plantilla no aporta experiencia, puede confundir la arquitectura y deja una huella de contenido escalado sin valor.

Una página territorial tiene sentido cuando puede aportar algo que la página de ciudad no ofrece: una sede, un equipo que atiende allí, un caso autorizado, un tipo de cliente predominante, limitaciones logísticas, fotos propias, una ruta de servicio verificable o preguntas que cambian de verdad por zona. Si la información no cambia, la URL de Madrid y una sección de cobertura bien escrita son mejores que veinte páginas repetidas.

El criterio no es "podemos posicionar por distrito". El criterio es "podemos responder mejor la intención de una persona que está en ese distrito". La arquitectura de SEO local por distritos explica cómo tomar esa decisión antes de publicar más URLs.

Paso 7: conseguir corroboración fuera de tu propio dominio

Una empresa no gana confianza porque se autodenomine experta en todas sus páginas. Las menciones externas ayudan cuando aportan contexto independiente: una ficha verificada, un proyecto que el cliente explica, una asociación sectorial, un medio local relevante, una conferencia, un directorio específico o una documentación técnica que demuestre una integración.

No hace falta perseguir cientos de listados sin audiencia. Conviene priorizar fuentes que una persona también consideraría razonables al elegir proveedor. Para una pyme de Madrid, eso puede incluir asociaciones de su sector, medios de distrito si hay una noticia real, colaboraciones con clientes, proveedores que describen un proyecto o directorios profesionales que revisan los datos.

La mejor unidad de prueba suele ser un caso claro: problema inicial, alcance, trabajo realizado, fecha o periodo, URL del proyecto cuando es pública y límites de lo que se puede afirmar. Si no hay permiso para publicar ese detalle, se describe el proceso sin atribuir resultados al cliente. Inventar porcentajes, posiciones o reseñas hace más daño que no tener caso.

Paso 8: medir con una muestra estable y decisiones pequeñas

Buscar tu marca una vez en una conversación privada no es medición GEO. Los modelos cambian, las respuestas se personalizan, la ubicación influye y la misma pregunta puede activar fuentes distintas. Para convertirlo en un sistema útil hace falta una batería fija de preguntas y un registro de lo que ocurrió.

Para una empresa de Madrid, empieza con diez o quince preguntas repartidas entre servicio, problema, comparación y decisión. Mantén idioma, mercado y fecha. En cada prueba anota:

• Pregunta exacta y tipo de intención.
• Asistente, modelo visible y contexto de ubicación si se muestra.
• Si aparece la marca, una URL concreta o ninguna de las dos.
• Texto o argumento con el que se presenta la empresa.
• Otras fuentes y competidores citados.
• Error factual, omisión relevante o contexto que conviene corregir en la propia web.

Search Console agrupa las apariciones de las funciones de IA de Google en el tipo de búsqueda Web; no interpreta automáticamente una variación como ganancia o pérdida de visibilidad generativa. OpenAI indica que el tráfico de referencia de ChatGPT puede seguirse en analítica cuando llega con utm_source=chatgpt.com. Bing AI Performance añade una señal de citas por URL cuando la propiedad tiene acceso al informe. Ninguna de esas métricas aislada demuestra una venta, pero juntas permiten priorizar una URL concreta antes de reescribir toda la web.

Un plan realista de 30 días para una empresa de Madrid

Días 1 a 7: inventario y acceso

Haz un inventario de páginas comerciales, fichas locales, autores, casos, reseñas, directorios y consultas que ya traen impresiones. Verifica robots, sitemap, canonicals, HTML, CDN y WAF. El resultado debe ser una lista corta de bloqueos comprobables, no un PDF con cien recomendaciones genéricas.

Días 8 a 20: una página principal y dos recursos de decisión

Elige la página que debe responder la consulta comercial más valiosa. Añade respuesta directa, alcance, proceso, prueba visible, preguntas frecuentes y enlaces hacia las guías que resuelven objeciones. Después publica o actualiza dos recursos que tengan una función distinta: por ejemplo, una guía para decidir proveedor y un tutorial para resolver una tarea local. No cambies title, H1, FAQ, enlaces y schema de diez URLs el mismo día si luego quieres saber qué funcionó.

Días 21 a 30: corroboración y segundo corte

Revisa que los perfiles de Google, Bing y Apple compartan los datos correctos. Corrige menciones antiguas relevantes, prepara un caso publicable si existe autorización y repite la misma muestra de preguntas. El objetivo no es declarar victoria en treinta días; es llegar al siguiente ciclo con una línea base, una URL reforzada y una hipótesis medible.

Errores que frenan la visibilidad local en IA

Tratar llms.txt como una garantía. Puede mantenerse como ayuda experimental, pero no sustituye el rastreo, el HTML, la indexación, las fuentes ni el contenido. Google dice que no necesita archivos especiales de IA para sus experiencias generativas.

Publicar páginas de barrio sin operación diferenciada. Una lista interminable de ciudades o distritos puede empeorar la lectura y no responde mejor a nadie. Prioriza zonas con prueba, demanda e información propia.

Añadir datos estructurados que el usuario no puede comprobar. Las reseñas, ofertas, direcciones, precios y resultados deben ser reales y visibles. El schema describe la página, no permite inventar autoridad.

Cambiar todo a la vez. Si se cambian textos, metadatos, enlaces, plantillas y CDN en una semana, después no existe una forma honesta de atribuir el resultado. Mantén un registro por URL e hipótesis.

Confundir una cita con una venta. Una guía puede ser una fuente estupenda para una pregunta informativa y no generar ninguna solicitud. La URL de destino, el mensaje y la siguiente acción también forman parte de la estrategia.

Checklist de preparación GEO local

• La web permite el rastreo que la empresa ha decidido permitir y no bloquea por error a los bots relevantes.
• Sitemap, robots, canonicals y contenido principal se pueden recuperar sin una interacción compleja.
• Cada servicio comercial tiene una URL propia con alcance, proceso, límites y siguiente paso.
• Nombre, teléfono, dirección o área de servicio y URL son consistentes en la web y perfiles locales.
• Google Business Profile, Bing Places y Apple Business Connect se revisan como activos distintos.
• Las páginas locales solo existen cuando aportan información real y diferenciada.
• El JSON-LD coincide con el texto visible y enlaza entidades coherentes.
• Los artículos responden preguntas concretas con fuentes y límites, no con promesas abstractas.
• Los casos, testimonios y resultados publicados se pueden sostener con permiso y evidencia.
• La batería de preguntas de IA mantiene fecha, mercado, idioma y criterios de comparación.

El siguiente paso correcto

La mejor estrategia GEO local no empieza añadiendo otro plugin ni llenando el blog de definiciones. Empieza eligiendo una pregunta que un cliente real formularía, asignándole una URL que pueda responderla con claridad y comprobando si buscadores y asistentes pueden llegar a esa fuente.

Si quieres revisar esa base para una empresa de Madrid, el posicionamiento GEO y AIO combina auditoría de acceso, entidades, contenido, fuentes y medición. Cuando el problema principal es captar demanda orgánica local, el servicio de SEO en Madrid conecta ese trabajo con arquitectura, contenido y seguimiento. La decisión útil no es contratar una etiqueta nueva; es identificar qué señal falta hoy y corregirla con evidencia.