GEO y SEO técnico: por qué no es un reemplazo
El GEO (Generative Engine Optimization) no reemplaza al SEO técnico: le añade un objetivo. El SEO técnico busca que Google te indexe y te posicione; el GEO busca que ChatGPT, Perplexity o Gemini te citen en una respuesta generada. Ambos se apoyan en la misma fontanería: contenido accesible, estructurado, rápido y sin duplicar.
La diferencia está en las condiciones de acceso. Los crawlers de IA ejecutan poco o nada de JavaScript, tienen un presupuesto de rastreo limitado y rara vez vuelven a consultar un sitio inestable. Donde Googlebot sabe esperar al renderizado de una aplicación cliente, GPTBot descarga el HTML en bruto y se marcha con lo que ha encontrado. Un sitio perfectamente optimizado para Google puede ser, por tanto, totalmente invisible para los motores de respuesta, sin que salte ninguna alerta en Search Console.
Esta asimetría es una buena noticia para los equipos de SEO que ya existen. Las correcciones que desbloquean a los crawlers de IA son, casi siempre, correcciones que también mejoran la indexación en Google, la velocidad de rastreo y la calidad de las señales enviadas. No hay que elegir entre los dos canales, solo definir un orden de prioridad.
Este artículo detalla siete correcciones de doble efecto. Para cada una, el efecto medido en Google y el efecto medido en los LLM, con las comprobaciones concretas que hay que lanzar. Las conclusiones se apoyan en las auditorías que Mirok ha realizado en sitios SaaS B2B, cuyo resumen está disponible en lo que 500 auditorías de Mirok revelan sobre los sitios SaaS B2B.
Corrección 1: los datos estructurados, base común del GEO y el SEO
El marcado schema.org sigue siendo la palanca más rentable en ambos frentes, porque transforma una página en un conjunto de hechos legibles por una máquina. Organization, Article, FAQPage, Product, HowTo: cada tipo declara explícitamente qué contiene la página, quién la ha publicado y a qué responde.
En Google, el efecto es directo y medible: elegibilidad para los rich results, mejor comprensión de la entidad, alimentación del Knowledge Graph. Una página Article bien marcada con author, datePublished y publisher da a Google los elementos necesarios para vincular el contenido a una entidad identificable. En los LLM, el efecto es menos visible pero más determinante: el marcado aporta hechos atribuibles, extraídos sin ambigüedad, lo que reduce el riesgo de que el modelo reformule tu contenido sin citarte o, peor aún, de que alucine una información parecida.
Los errores frecuentes salen caros. Un marcado presente pero incoherente con el contenido visible (una fecha de publicación distinta, un autor que no aparece en ninguna parte de la página) envía una señal contradictoria. Un JSON-LD duplicado entre plantillas, heredado de un tema o de un plugin, genera varias declaraciones Organization en conflicto dentro del mismo sitio. La comprobación se resuelve en una sola pasada: validar cada tipo con el Rich Results Test y después comparar campo por campo con lo que ve el usuario. Para profundizar en la estructura de las páginas, consulta estructurar tus páginas para las citas de los LLM: 8 correcciones GEO.
Corrección 2: el renderizado en el servidor, condición de acceso de los crawlers de IA
La mayoría de los crawlers de IA no ejecutan JavaScript, o muy poco. No es una limitación temporal, es una decisión de arquitectura: ejecutar JS cuesta mucho cálculo y tiempo para un beneficio incierto. Googlebot, en cambio, renderiza las páginas desde hace años. Resultado: un contenido inyectado en el cliente, invisible en el HTML en bruto, sigue siendo invisible para ChatGPT, Perplexity y Gemini.
En Google, el renderizado en el servidor (SSR) o la generación estática mejoran la fiabilidad de la indexación y reducen el consumo de presupuesto de rastreo. Una página que no necesita renderizarse se indexa antes y con más frecuencia. En los LLM, es una condición de existencia: sin texto en la respuesta HTML, no hay nada que citar.
Las comprobaciones son sencillas y se hacen en cinco minutos. Recuperar la página con curl y leer el HTML en bruto: si el contenido principal no aparece ahí, el problema está confirmado. Comparar después con la versión renderizada en el navegador para medir la diferencia. Probar las páginas clave (home, páginas de producto, artículos del blog, páginas de precios) una por una, porque las plantillas no se comportan todas igual. Un sitio que muestra sus precios o sus funcionalidades solo mediante un componente de cliente pierde, para los motores de respuesta, lo esencial de su argumentario comercial.
Corrección 3: la velocidad y la estabilidad del servidor, del presupuesto de rastreo al presupuesto de contexto
Core Web Vitals y tiempo de respuesta del servidor pesan en los dos canales, por razones distintas. En Google, LCP, INP y CLS son señales de experiencia de usuario, y un tiempo de respuesta degradado reduce la frecuencia de rastreo: Google vuelve menos a menudo a un sitio lento. En los LLM, la lógica es aún más cruda: un sitio lento o inestable se reconsulta menos por parte de los agentes de respuesta, y un timeout hace fracasar directamente la recuperación de la página. El contenido no está mal posicionado, simplemente no se lee.
Las palancas son conocidas y no exigen una reestructuración. Caché de páginas y de consultas costosas, CDN para acercar el contenido a los crawlers, compresión Brotli o gzip, eliminación de redirecciones en cadena que multiplican los viajes de ida y vuelta. Cada redirección adicional es un coste de rastreo pagado para nada, y un riesgo extra de timeout en el lado del agente.
El método de medición consiste en seguir el TTFB en las páginas estratégicas, no solo en la home, y en vigilar los errores 5xx en los logs del servidor. Un pico de errores durante una ventana de rastreo se traduce en una pérdida de indexación silenciosa, a menudo atribuida por error a un problema de contenido.
Corrección 4: el enlazado interno, o cómo hacer que una página sea citable
El enlazado interno cumple dos funciones distintas según el canal. Para Google, distribuye el PageRank interno, controla la profundidad de clic y evita las páginas huérfanas. Para un LLM, señala que una página pertenece a un clúster temático coherente, lo que aumenta su probabilidad de ser elegida como fuente autorizada sobre un tema concreto. Un modelo que debe elegir entre dos páginas que tratan el mismo tema prioriza la que está conectada a un conjunto estructurado de contenidos relacionados.
El método se resume en tres reglas. Usar anclas descriptivas en lugar de «haz clic aquí» o «saber más», porque el ancla es una señal de tema para los dos canales. Crear enlaces contextuales desde las páginas fuertes del sitio hacia las páginas que quieres dar a conocer, colocando el enlace en el cuerpo del texto y no en un bloque al pie. Eliminar los enlaces rotos y los enlaces hacia redirecciones, que desperdician presupuesto de rastreo y enturbian la lectura del grafo.
Una auditoría de enlazado se hace cruzando un rastreo completo con los datos de Search Console. Las páginas con cero enlaces internos entrantes son prioritarias: existen, a veces están indexadas, pero no tienen ninguna posibilidad de ser seleccionadas como fuente. El informe semanal de seguimiento de competidores permite comparar la densidad de enlazado en los clústeres donde tus competidores son citados y tú no, como se explica en seguimiento de competidores en los LLM: el informe semanal en 5 minutos.
Corrección 5: sitemap y robots.txt, abrir la puerta a los crawlers de IA
Es la corrección que más se pasa por alto, porque no se ve en ningún dashboard. La cuestión no es técnica sino estratégica: qué user-agents de IA autorizar y para qué contenido. GPTBot (OpenAI), PerplexityBot, ClaudeBot (Anthropic) y Google-Extended (uso de contenido para el entrenamiento y los productos generativos de Google) se gestionan de forma independiente en el robots.txt. Bloquear por defecto, por herencia de un sitio antiguo o por reflejo de protección, deja el sitio fuera de las respuestas generativas sin que el equipo lo sepa.
En Google, la atención se centra en el sitemap: un archivo limpio, sin URL en 404 ni en redirección, con un lastmod fiable y no generado automáticamente en cada despliegue. Un lastmod que cambia todos los días sin modificaciones reales acaba siendo ignorado. Comprueba también que no haya un noindex accidental, a menudo dejado por un entorno de preproducción mal aislado.
En los LLM, la verificación se hace user-agent por user-agent. Probar el acceso de cada crawler a las páginas estratégicas, revisar las reglas heredadas (un Disallow: / olvidado en un archivo de staging, una regla copiada de un dominio antiguo) y documentar la decisión: autorizar para ganar visibilidad, bloquear para proteger contenido de pago. Ambas opciones son defendibles; la ausencia de decisión no lo es.
Corrección 6: canonical y duplicación, una sola verdad por contenido
La duplicación diluye los dos canales, por razones que se parecen. En Google, dispersa las señales entre varias URL, crea canibalización entre versiones y complica la consolidación de backlinks. En los LLM, produce un efecto más insidioso: un contenido presente en varias versiones genera citas contradictorias, o lleva al modelo a descartar la fuente por considerarla poco fiable al no saber cuál es la que manda.
Los casos clásicos están bien identificados. Parámetros de URL de tracking que crean variantes indexables, paginación mal declarada, versiones con www y sin www servidas ambas con un 200, contenido sindicado reutilizado sin un canonical que apunte al original, páginas de etiquetas y de archivos que duplican los extractos de los artículos. Cada uno de estos casos produce el mismo síntoma: varias URL para un solo contenido, y ninguna respuesta clara a la pregunta «qué página es la de referencia».
La corrección pasa por una regla simple: una intención, una URL, un canonical autorreferencial. Comprueba después que el canonical declarado corresponde de verdad a la URL servida, y no a una versión redirigida. Un canonical que apunta a un 301 es una señal perdida para Google y una ambigüedad más para los motores de respuesta.
Corrección 7: la accesibilidad técnica, la corrección que nadie mide
La accesibilidad técnica es la pariente pobre de las auditorías, aunque condiciona directamente la extractabilidad. Jerarquía de títulos limpia (un H1, H2 que estructuren de verdad el discurso), HTML semántico (article, section, nav, main en lugar de div apilados), textos alternativos descriptivos, contrastes suficientes, formularios con labels asociados: cada elemento hace que el contenido sea más legible por una máquina.
En Google, el efecto es doble: mejor comprensión estructural de la página y señales positivas de experiencia de usuario. En los LLM, el efecto es aún más directo. Un contenido organizado en títulos y listas se divide de forma natural en pasajes citables. Un modelo que debe extraer la respuesta a una pregunta concreta encuentra en una estructura clara el fragmento exacto que reutilizar, con su contexto. Un bloque de texto sin jerarquía obliga al modelo a adivinar las fronteras, y lo hace mal.
Esta corrección casi siempre la detecta una auditoría automatizada, y casi nunca se prioriza, porque no tiene un indicador de rendimiento asociado. Es precisamente lo que la convierte en una ventaja competitiva: los sitios que la abordan se diferencian en un criterio que sus competidores ignoran. Los formatos de contenido más citados por los LLM se apoyan en gran medida en esta estructura, como muestran las 500 auditorías sobre los formatos de contenido que los LLM citan de verdad.
Cómo priorizar estas 7 correcciones sin rehacer todo el sitio
El orden de ejecución sigue una lógica de acceso antes que una lógica de calidad. Primer bloque, lo que desbloquea: renderizado en el servidor, robots.txt, sitemap. Sin acceso, ninguna otra optimización produce un efecto medible, ni en Google ni en los motores de respuesta. Segundo bloque, lo que mejora la comprensión: datos estructurados, canonical. El contenido se vuelve legible y sin ambigüedades. Tercer bloque, lo que refuerza la citabilidad: enlazado interno, accesibilidad, velocidad. El sitio ya no se limita a ser leído, se vuelve seleccionable como fuente.
La medición debe hacerse en los dos canales en paralelo, con la misma muestra. Elegir de diez a veinte consultas testigo representativas de la intención de compra y seguir para cada una: posición e impresiones en Search Console, y presencia o ausencia de cita en ChatGPT, Perplexity y Gemini. Una corrección que mejora uno sin tocar el otro merece documentarse, porque suele ser señal de un problema adyacente.
Es exactamente el papel que juega Mirok dentro de una stack que ya existe: detectar las oportunidades en estos siete ejes, auditarlas, documentarlas y proponer una corrección sometida a validación humana antes de ejecutarse. Nada llega a producción sin aprobación, y cada acción es trazable. El protocolo se detalla en automatizar sin perder el control: el protocolo de validación humana, y la conexión con las herramientas que ya usas (Search Console, GA4, GitHub, CMS) lleva unos treinta minutos, como se explica en conectar tu stack de marketing a Mirok en 30 minutos.
FAQ
¿El GEO reemplaza al SEO técnico?
No. El GEO añade un objetivo, ser citado en una respuesta generada, pero se apoya en los mismos cimientos técnicos que el SEO: contenido accesible, estructurado, rápido y sin duplicar. Un sitio mal renderizado o mal marcado es invisible tanto para Google como para los motores de respuesta. Las dos disciplinas se refuerzan en lugar de oponerse.
¿Qué crawlers de IA conviene autorizar en el robots.txt?
Los principales a considerar son GPTBot (OpenAI), PerplexityBot, ClaudeBot (Anthropic) y Google-Extended. Un robots.txt que bloquea por defecto deja el sitio fuera de las respuestas generativas, a menudo sin que el equipo sea consciente de ello. La decisión depende de tu estrategia de contenido y de tu modelo de negocio: autorizar para ganar visibilidad, bloquear para proteger contenido de pago.
¿Los datos estructurados tienen efecto en las respuestas de ChatGPT o Perplexity?
Sí, de forma indirecta pero real. Facilitan la extracción de hechos atribuibles y reducen la ambigüedad sobre la entidad en cuestión. Un modelo que identifica con claridad el autor, la fecha y el tema de una página tiene más posibilidades de tomarla como fuente citada en lugar de parafrasear su contenido sin atribución.
¿Cómo saber si mi sitio es legible por los motores de respuesta de IA?
Compara el HTML en bruto que se sirve al crawler con la versión renderizada en el navegador: si el contenido principal no aparece en el HTML en bruto, es invisible para los crawlers de IA. Revisa después tu robots.txt user-agent por user-agent y prueba la recuperación de tus páginas clave sin ejecución de JavaScript. Estas tres comprobaciones bastan para establecer un diagnóstico básico.
¿Por qué corrección empezar cuando se tienen pocos recursos?
Empieza por lo que desbloquea el acceso: renderizado en el servidor, robots.txt y sitemap. Sin acceso, las demás optimizaciones no tienen ningún efecto medible, ni en Google ni en los motores de respuesta. Una vez confirmado el acceso, continúa con los datos estructurados y el canonical, que mejoran la comprensión del contenido en los dos canales.