RAG SEO: documentación recuperable para IA y búsqueda | Ighenatt

La mayoría de equipos prepara su documentación para dos lectores: personas y Googlebot. El tercer lector, el pipeline de recuperación que alimenta respuestas de IA, llega con otra costumbre: no lee una página de principio a fin. Trocea, embebe, busca por similitud, combina pasajes y, si el producto lo permite, devuelve fuentes.

Ahí empieza el RAG SEO. El paper original de Patrick Lewis y otros autores en NeurIPS 2020 definió Retrieval-Augmented Generation como una combinación de memoria paramétrica del modelo y memoria no paramétrica recuperada desde documentos. Las plataformas actuales han industrializado esa idea: OpenAI describe vector stores que chunkearán, embeberán e indexarán archivos; Google Cloud permite fundamentar Gemini con datos de sitios web o documentos mediante Vertex AI Search; y Gemini expone metadatos de grounding para vincular afirmaciones con fuentes.

La pregunta práctica no es “cómo hago que ChatGPT me cite”. Esa promesa sería falsa. La pregunta útil es más seca: ¿puede una máquina recuperar el fragmento correcto de mi documentación, entender de dónde viene y llevar al usuario a la URL canónica sin romper el contexto?

Qué cambia cuando tu documentación entra en un pipeline RAG

Un documento web tradicional se evalúa como página: title, contenido, enlaces, autoridad, renderizado, velocidad. Un pipeline RAG lo evalúa como colección de unidades recuperables. La página sigue importando, pero el pasaje gana protagonismo.

El flujo típico tiene cinco pasos. Primero, el sistema descubre URLs o archivos. Después extrae el texto útil, eliminando navegación y plantillas. Luego divide ese texto en chunks. Cada chunk se convierte en embedding y se guarda en un índice vectorial. Cuando llega una consulta, el sistema recupera los chunks más cercanos, los pasa al modelo y genera una respuesta con o sin citas, según la interfaz.

La documentación oficial de OpenAI lo resume desde el lado del producto: al añadir archivos a un vector store, el sistema los procesa, trocea, embebe e indexa para búsqueda semántica. Google Cloud usa otro vocabulario, pero la lógica es parecida: conectar Gemini con datos propios mediante Vertex AI Search para reducir alucinaciones y devolver grounding metadata. En ambos casos, el punto de fricción no es solo “tener contenido”; es tener contenido recuperable.

Considera esto: una guía de 4.000 palabras sobre facturación puede rankear bien y aun así fallar en RAG si cada sección empieza con “como vimos antes” o si las anclas cambian cada vez que el CMS reescribe el heading. El lector humano reconstruye el hilo. El chunk aislado no.

Checklist de preparación para recuperación

Una auditoría de RAG SEO empieza con una lista incómodamente concreta. Si una respuesta es “depende”, se documenta el criterio. Si una respuesta es “no lo sabemos”, se mide antes de cambiarlo.

Este checklist conecta con la lógica de contenido citable para AI Overviews, pero no es lo mismo. La citabilidad se centra en que una respuesta pueda extraer una afirmación. La recuperabilidad se centra en que un sistema pueda encontrar el pasaje correcto, conservar su procedencia y distinguirlo de versiones antiguas.

El punto contrarian: no todo debe convertirse en chunk. Tablas legales, condiciones comerciales y APIs deprecated necesitan más contexto, no menos. En esos casos conviene dividir por decisión de usuario, no por longitud automática.

Antes y después: convertir una guía opaca en documentación recuperable

Una estructura típica que falla se parece a esto:

# Guía de facturación

H2: Introducción
Texto general sobre el producto.

H2: Configuración
Explica cuentas, impuestos, recibos y permisos mezclados.

H2: Preguntas frecuentes
Respuestas cortas sin fuente ni enlaces a secciones.

El problema no es que sea ilegible. El problema es que ninguna sección responde una pregunta recuperable. “Configuración” puede contener cinco intenciones distintas. Un sistema que recupere ese chunk tendrá que adivinar si la consulta habla de IVA, permisos o descarga de recibos.

La versión recuperable separa unidades, anclas y criterios:

# Facturación en Ighenatt: recibos, impuestos y permisos

H2: Descargar una factura mensual {#descargar-factura-mensual}
Respuesta directa. Requisitos. Pasos. Enlace al panel.

H2: Cambiar datos fiscales antes de emitir factura {#cambiar-datos-fiscales}
Qué se puede cambiar. Qué no. Plazo. Fuente legal.

H2: Dar acceso de facturación a otro usuario {#permisos-facturacion}
Roles, permisos mínimos y registro de auditoría.

La diferencia parece editorial, pero es técnica. Cada H2 genera una frontera semántica. Cada ancla permite citar o enlazar el punto exacto. Cada bloque puede mapearse a una consulta concreta. Si más tarde publicas un llms.txt para SEO e IA, esa estructura también ayuda a decidir qué recursos merecen aparecer en el índice resumido del sitio.

Una regla práctica: escribe el primer párrafo después del H2 como si fuera el único texto que el modelo va a ver. Después amplía con matices, pasos, excepciones y fuentes. Es el mismo músculo que usamos en estrategia de citaciones y fuentes para LLMs, pero aplicado a documentación, no a artículos de opinión.

Chunks, anclas y URLs estables

Un buen chunk no es un párrafo bonito. Es una pieza de evidencia con dirección postal. Debe decir qué entidad describe, bajo qué condición aplica, cuándo fue actualizado y dónde vive la versión canónica.

Ejemplo débil:

También puedes cambiar estos datos desde el panel si todavía no se ha cerrado el periodo.

Ejemplo recuperable:

### Cambiar datos fiscales antes del cierre mensual {#cambiar-datos-fiscales}

Los datos fiscales de una cuenta pueden editarse desde el panel de facturación hasta las 23:59 del último día natural del mes. Después del cierre, la factura emitida no se modifica; el equipo debe crear una rectificación documentada. Última revisión: 2026-05-02.

La segunda versión contiene entidad (“datos fiscales”), lugar (“panel de facturación”), condición (“hasta las 23:59”), límite temporal y ancla. Si un sistema recupera solo ese bloque, no necesita el párrafo anterior.

Las anclas deben ser persistentes. No dependas únicamente de IDs autogenerados por el texto del heading, porque una corrección de estilo puede romper enlaces y referencias. Mejor define IDs semánticos y mantenlos cuando cambie el título visible. También conviene evitar URLs con parámetros de campaña, facetas, fechas innecesarias o slugs que caducan por año.

Para documentación larga, mantén un mapa de anclas:

canonical: https://ighenatt.es/docs/facturacion/
anchors:
  descargar-factura-mensual: "Descarga de facturas"
  cambiar-datos-fiscales: "Edicion de datos fiscales"
  permisos-facturacion: "Permisos de usuario"
lastReviewed: 2026-05-02
owner: "Equipo SEO tecnico"

Este mapa sirve para QA editorial y para detectar roturas tras migraciones. También conecta con el análisis de logs de bots IA: si OAI-SearchBot, GPTBot o Googlebot consumen siempre la página raíz pero nunca llegan a anclas o docs relacionados, quizá tu arquitectura de enlaces no está mostrando la documentación prioritaria.

Metadatos, Markdown alternativo y fuentes trazables

La documentación recuperable necesita dos capas de metadatos: visible y estructurada. La visible ayuda al lector y al editor. La estructurada ayuda a buscadores, parsers y sistemas de grounding.

En la capa visible, cada documento debería mostrar: propietario editorial, fecha de publicación, fecha de última revisión, alcance, versión del producto o API, y fuentes externas usadas. En la capa estructurada, usa schema.org cuando encaje: Article o TechArticle para documentación editorial, FAQPage para preguntas visibles, BreadcrumbList para jerarquía y Organization o Person para autoría. La guía de schema.org como puente entre SEO y GEO entra en la parte de marcado con más detalle.

El alternate en Markdown es útil cuando tu frontend añade mucho ruido. No hace magia. Un /docs/facturacion.md o un enlace rel="alternate" a text/markdown permite que un pipeline lea texto limpio, pero exige disciplina: mismo contenido, misma fecha, canonical hacia la página principal y una prueba automática que avise si HTML y Markdown divergen.

La trazabilidad de fuentes debe cumplir cinco criterios:

• Fuente primaria siempre que exista.
• URL HTTPS verificable y no un pantallazo suelto.
• Fecha de consulta o fecha de versión del documento citado.
• Frase exacta del dato que depende de esa fuente.
• Responsable editorial que decide cuándo retirar o actualizar el dato.

Google AI for Developers muestra por qué esto importa: el API de Gemini puede devolver groundingSupports y groundingChunks para vincular afirmaciones a fuentes. Google Cloud define GroundingChunk como evidencia que soporta una afirmación generada. Si tus fuentes están escondidas, duplicadas o sin fecha, haces más difícil esa conexión.

Frescura, versionado y documentos canónicos

La frescura no consiste en cambiar la fecha cada viernes. Esa práctica ensucia el rastro editorial y reduce confianza. La frescura útil responde tres preguntas: qué cambió, desde cuándo aplica y qué versión anterior queda reemplazada.

Reglas de versionado para documentación recuperable:

1. Mantén una URL canónica por tema estable. Si cambia el producto, actualiza la página; no publiques una variante nueva salvo que haya una ruptura real.
2. Usa datePublished y dateModified con criterio. La fecha modificada debe reflejar un cambio sustancial, no una corrección tipográfica.
3. Añade una nota de cambios cuando el documento impacte decisiones operativas.
4. Conserva anclas antiguas con redirección o alias cuando una sección se renombra.
5. Marca contenido deprecated con fecha, alternativa vigente y motivo.

Ejemplo:

> Actualizado el 2 de mayo de 2026: añadida regla de canonical para alternates Markdown y criterio de retirada de fuentes obsoletas.

Google Search Central recuerda que para aparecer como enlace de apoyo en AI Overviews o AI Mode la página debe estar indexada y ser apta para mostrarse con snippet; no hay requisitos técnicos especiales ni garantía de inclusión. Esa frase debería estar pegada en el tablero de cualquier proyecto de RAG SEO. Preparar documentos recuperables mejora la legibilidad de máquina. No compra visibilidad automática.

Medir recuperación sin prometer citas en ChatGPT

La medición empieza antes de mirar tráfico. Primero prueba si tu propia documentación se recupera bien. Crea 20 preguntas reales de soporte, producto o ventas. Para cada pregunta, registra qué URL y qué ancla deberían responderla. Luego usa tu buscador interno, un índice vectorial de prueba o una herramienta de QA con embeddings para comprobar si aparece el chunk correcto entre los tres primeros resultados.

Métricas útiles:

• Precisión top 3: porcentaje de preguntas donde el chunk correcto aparece entre los tres primeros resultados.
• Cobertura de anclas: porcentaje de H2 críticos con enlace estable y recuperable.
• Latencia editorial: días entre un cambio de producto y la actualización de la documentación.
• Tasa de fuentes verificables: afirmaciones con fuente completa frente a afirmaciones externas totales.
• Duplicidad canónica: número de documentos que compiten por responder la misma pregunta.

Después sí puedes observar señales externas: logs de bots, referencias desde productos de IA, menciones en AI Overviews y pruebas manuales en Gemini, Perplexity o ChatGPT Search. Pero con una advertencia: una no citación no demuestra que el documento esté mal, y una cita aislada no demuestra que la arquitectura esté bien.

En la práctica, RAG SEO se parece menos a escribir “para la IA” y más a ordenar una biblioteca técnica. Etiquetas claras. Estantes estables. Fichas de procedencia. Ediciones visibles. Quien venga a buscar, humano o máquina, encuentra el libro correcto y puede comprobar de dónde salió cada dato.

Preguntas frecuentes sobre RAG SEO

¿Hacer mi documentación recuperable garantiza que ChatGPT me cite?

No. La documentación recuperable mejora la probabilidad técnica de que un sistema encuentre, interprete y atribuya tus pasajes, pero no controla qué índice usa ChatGPT, qué consulta formula el usuario, qué fuentes competidoras existen ni qué política de citación aplica el producto en ese momento.

¿Qué longitud debe tener un chunk para RAG SEO?

Como regla editorial, cada chunk debería cubrir una idea completa en 150-350 palabras o en una tabla breve con contexto suficiente. La longitud exacta depende del sistema, pero la unidad debe conservar entidad, condición, fecha y enlace canónico sin depender del párrafo anterior.

¿Vale la pena publicar una versión Markdown de la documentación?

Sí, si se mantiene sincronizada con la página canónica. Un alternate Markdown reduce ruido de navegación, scripts y componentes visuales para pipelines de texto, pero no debe convertirse en una versión paralela con contenido diferente, fechas distintas o URLs no canónicas.

¿Qué metadatos importan más para documentación recuperable?

Los más importantes son URL canónica, título, descripción, idioma, fecha de publicación, fecha de actualización, autor o propietario, fuente primaria, licencia o condiciones de uso, anclas de sección y schema Article, TechArticle, FAQPage o BreadcrumbList cuando corresponda.

Empieza por tus 10 documentos que más tráfico orgánico o tickets de soporte generan. Añade anclas persistentes, revisa headings, separa chunks ambiguos y documenta fuentes. Es trabajo pequeño, pero cambia la textura de todo el sistema.