RAG SEO: documentació recuperable per a IA i cerca | Ighenatt

La majoria d’equips prepara la seva documentació per a dos lectors: persones i Googlebot. El tercer lector, el pipeline de recuperació que alimenta respostes d’IA, arriba amb un altre costum: no llegeix una pàgina de dalt a baix. Trosseja, crea embeddings, cerca per similitud, combina passatges i, si el producte ho permet, retorna fonts.

Aquí comença el RAG SEO. El paper original de Patrick Lewis i altres autors a NeurIPS 2020 va definir Retrieval-Augmented Generation com una combinació de memòria paramètrica del model i memòria no paramètrica recuperada de documents. Les plataformes actuals han industrialitzat aquesta idea: OpenAI descriu vector stores que trossegen, embedeixen i indexen arxius; Google Cloud permet fonamentar Gemini amb dades de webs o documents mitjançant Vertex AI Search; i Gemini exposa metadades de grounding per vincular afirmacions amb fonts.

La pregunta pràctica no és “com faig que ChatGPT em citi”. Aquesta promesa seria falsa. La pregunta útil és més seca: pot una màquina recuperar el fragment correcte de la meva documentació, entendre d’on ve i portar l’usuari a la URL canònica sense trencar el context?

Què canvia quan la documentació entra en un pipeline RAG

Un document web tradicional s’avalua com a pàgina: title, contingut, enllaços, autoritat, renderitzat i velocitat. Un pipeline RAG l’avalua com una col·lecció d’unitats recuperables. La pàgina continua important, però el passatge guanya protagonisme.

El flux habitual té cinc passos. Primer, el sistema descobreix URLs o arxius. Després extreu el text útil, eliminant navegació i plantilles. Tot seguit divideix aquest text en chunks. Cada chunk es converteix en embedding i es guarda en un índex vectorial. Quan arriba una consulta, el sistema recupera els chunks més propers, els passa al model i genera una resposta amb cites o sense, segons la interfície.

La documentació d’OpenAI ho explica des del costat del producte: quan s’afegeixen arxius a un vector store, el sistema els processa, trosseja, embedeix i indexa per a cerca semàntica. Google Cloud usa un vocabulari diferent, però la lògica és semblant: connectar Gemini amb dades pròpies mitjançant Vertex AI Search per reduir al·lucinacions i retornar grounding metadata. En tots dos casos, la fricció no és només “tenir contingut”; és tenir contingut recuperable.

Considera això: una guia de 4.000 paraules sobre facturació pot rankejar bé i fallar en RAG si cada secció comença amb “com hem vist abans” o si els ancoratges canvien cada cop que el CMS reescriu el heading. El lector humà reconstrueix el fil. El chunk aïllat no.

Checklist de preparació per a recuperació

Una auditoria de RAG SEO comença amb una llista incòmodament concreta. Si una resposta és “depèn”, es documenta el criteri. Si una resposta és “no ho sabem”, es mesura abans de canviar-ho.

Aquest checklist connecta amb la lògica de contingut citable per a AI Overviews, però no és el mateix. La citabilitat se centra en si una resposta pot extreure una afirmació. La recuperabilitat se centra en si un sistema pot trobar el passatge correcte, conservar-ne la procedència i distingir-lo de versions antigues.

El punt contrarian: no tot s’ha de convertir en chunk. Taules legals, condicions comercials i APIs deprecated necessiten més context, no menys. En aquests casos convé dividir per decisió d’usuari, no per llargada automàtica.

Abans i després: convertir una guia opaca en documentació recuperable

Una estructura típica que falla s’assembla a això:

# Guia de facturació

H2: Introducció
Text general sobre el producte.

H2: Configuració
Explica comptes, impostos, rebuts i permisos barrejats.

H2: Preguntes freqüents
Respostes curtes sense font ni enllaços a seccions.

El problema no és que sigui il·legible. El problema és que cap secció respon una pregunta recuperable. “Configuració” pot contenir cinc intencions diferents. Un sistema que recuperi aquest chunk haurà d’endevinar si la consulta parla d’IVA, permisos o descàrrega de rebuts.

La versió recuperable separa unitats, ancoratges i criteris:

# Facturació a Ighenatt: rebuts, impostos i permisos

H2: Descarregar una factura mensual {#descarregar-factura-mensual}
Resposta directa. Requisits. Passos. Enllaç al panell.

H2: Canviar dades fiscals abans d'emetre factura {#canviar-dades-fiscals}
Què es pot canviar. Què no. Termini. Font legal.

H2: Donar accés de facturació a un altre usuari {#permisos-facturacio}
Rols, permisos mínims i registre d'auditoria.

La diferència sembla editorial, però és tècnica. Cada H2 genera una frontera semàntica. Cada ancoratge permet citar o enllaçar el punt exacte. Cada bloc pot mapar-se a una consulta concreta. Si més tard publiques un llms.txt per a SEO i IA, aquesta estructura també ajuda a decidir quins recursos mereixen aparèixer a l’índex resumit del lloc.

Una regla pràctica: escriu el primer paràgraf després de l’H2 com si fos l’únic text que el model veurà. Després amplia amb matisos, passos, excepcions i fonts. És el mateix múscul que fem servir en estratègia de citacions i fonts per a LLMs, però aplicat a documentació, no a articles d’opinió.

Chunks, ancoratges i URLs estables

Un bon chunk no és un paràgraf bonic. És una peça d’evidència amb adreça postal. Ha de dir quina entitat descriu, sota quina condició aplica, quan va ser actualitzat i on viu la versió canònica.

Exemple feble:

També pots canviar aquestes dades des del panell si encara no s'ha tancat el període.

Exemple recuperable:

### Canviar dades fiscals abans del tancament mensual {#canviar-dades-fiscals}

Les dades fiscals d'un compte es poden editar des del panell de facturació fins a les 23:59 de l'últim dia natural del mes. Després del tancament, la factura emesa no es modifica; l'equip ha de crear una rectificació documentada. Última revisió: 2026-05-02.

La segona versió conté entitat (“dades fiscals”), lloc (“panell de facturació”), condició (“fins a les 23:59”), límit temporal i ancoratge. Si un sistema recupera només aquest bloc, no necessita el paràgraf anterior.

Els ancoratges han de ser persistents. No depenguis només d’IDs autogenerats pel text del heading, perquè una correcció d’estil pot trencar enllaços i referències. Defineix IDs semàntics i mantén-los quan canviï el títol visible. També convé evitar URLs amb paràmetres de campanya, facetes, dates innecessàries o slugs que caduquen per any.

Per a documentació llarga, mantén un mapa d’ancoratges:

canonical: https://ighenatt.es/docs/facturacio/
anchors:
  descarregar-factura-mensual: "Descàrrega de factures"
  canviar-dades-fiscals: "Edició de dades fiscals"
  permisos-facturacio: "Permisos d'usuari"
lastReviewed: 2026-05-02
owner: "Equip SEO tècnic"

Aquest mapa serveix per a QA editorial i per detectar trencaments després de migracions. També connecta amb l’anàlisi de logs de bots IA: si OAI-SearchBot, GPTBot o Googlebot consumeixen sempre la pàgina arrel però mai arriben a ancoratges o docs relacionats, potser la teva arquitectura d’enllaços no mostra la documentació prioritària.

Metadades, Markdown alternatiu i fonts traçables

La documentació recuperable necessita dues capes de metadades: visible i estructurada. La visible ajuda el lector i l’editor. L’estructurada ajuda cercadors, parsers i sistemes de grounding.

A la capa visible, cada document hauria de mostrar: propietari editorial, data de publicació, data de darrera revisió, abast, versió del producte o API, i fonts externes usades. A la capa estructurada, usa schema.org quan encaixi: Article o TechArticle per a documentació editorial, FAQPage per a preguntes visibles, BreadcrumbList per a jerarquia i Organization o Person per a autoria. La guia de schema.org com a pont entre SEO i GEO entra en la part de marcatge amb més detall.

L’alternate en Markdown és útil quan el teu frontend afegeix molt soroll. No fa màgia. Un /docs/facturacio.md o un enllaç rel="alternate" a text/markdown permet que un pipeline llegeixi text net, però exigeix disciplina: mateix contingut, mateixa data, canonical cap a la pàgina principal i una prova automàtica que avisi si HTML i Markdown divergeixen.

La traçabilitat de fonts ha de complir cinc criteris:

• Font primària sempre que existeixi.
• URL HTTPS verificable i no una captura solta.
• Data de consulta o data de versió del document citat.
• Frase exacta de la dada que depèn d’aquesta font.
• Responsable editorial que decideix quan retirar o actualitzar la dada.

Google AI for Developers mostra per què això importa: l’API de Gemini pot retornar groundingSupports i groundingChunks per vincular afirmacions a fonts. Google Cloud defineix GroundingChunk com evidència que suporta una afirmació generada. Si les teves fonts estan amagades, duplicades o sense data, fas més difícil aquesta connexió.

Frescor, versionat i documents canònics

La frescor no consisteix a canviar la data cada divendres. Aquesta pràctica embruta el rastre editorial i redueix confiança. La frescor útil respon tres preguntes: què ha canviat, des de quan aplica i quina versió anterior queda reemplaçada.

Regles de versionat per a documentació recuperable:

1. Mantén una URL canònica estable per tema. Si canvia el producte, actualitza la pàgina; no publiquis una variant nova tret que hi hagi una ruptura real.
2. Usa datePublished i dateModified amb criteri. La data modificada ha de reflectir un canvi substancial, no una correcció tipogràfica.
3. Afegeix una nota de canvis quan el document impacti decisions operatives.
4. Conserva ancoratges antics amb redirecció o àlies quan una secció es reanomena.
5. Marca contingut deprecated amb data, alternativa vigent i motiu.

Exemple:

> Actualitzat el 2 de maig de 2026: afegida regla de canonical per a alternates Markdown i criteri de retirada de fonts obsoletes.

Google Search Central recorda que per aparèixer com a enllaç de suport a AI Overviews o AI Mode la pàgina ha d’estar indexada i ser apta per mostrar-se amb snippet; no hi ha requisits tècnics addicionals ni garantia d’inclusió. Aquesta frase hauria d’estar enganxada al tauler de qualsevol projecte de RAG SEO. Preparar documents recuperables millora la llegibilitat de màquina. No compra visibilitat automàtica.

Mesurar recuperació sense prometre cites a ChatGPT

La mesura comença abans de mirar trànsit. Primer prova si la teva pròpia documentació es recupera bé. Crea 20 preguntes reals de suport, producte o vendes. Per a cada pregunta, registra quina URL i quin ancoratge l’haurien de respondre. Després usa el teu cercador intern, un índex vectorial de prova o una eina de QA amb embeddings per comprovar si apareix el chunk correcte entre els tres primers resultats.

Mètriques útils:

• Precisió top 3: percentatge de preguntes on el chunk correcte apareix entre els tres primers resultats.
• Cobertura d’ancoratges: percentatge d’H2 crítics amb enllaç estable i recuperable.
• Latència editorial: dies entre un canvi de producte i l’actualització de la documentació.
• Taxa de fonts verificables: afirmacions amb font completa davant afirmacions externes totals.
• Duplicitat canònica: nombre de documents que competeixen per respondre la mateixa pregunta.

Després sí que pots observar senyals externes: logs de bots, referències des de productes d’IA, mencions a AI Overviews i proves manuals a Gemini, Perplexity o ChatGPT Search. Però amb una advertència: una no citació no demostra que el document estigui malament, i una cita aïllada no demostra que l’arquitectura estigui bé.

En la pràctica, el RAG SEO s’assembla menys a escriure “per a la IA” i més a ordenar una biblioteca tècnica. Etiquetes clares. Prestatges estables. Fitxes de procedència. Edicions visibles. Qui vingui a buscar, humà o màquina, troba el llibre correcte i pot comprovar d’on ha sortit cada dada.

Preguntes freqüents sobre RAG SEO

Fer la meva documentació recuperable garanteix que ChatGPT em citi?

No. La documentació recuperable millora la probabilitat tècnica que un sistema trobi, interpreti i atribueixi els teus passatges, però no controla quin índex usa ChatGPT, com formula la consulta l’usuari, quines fonts competidores existeixen ni quina política de citació aplica el producte en aquell moment.

Quina llargada ha de tenir un chunk per a RAG SEO?

Com a regla editorial, cada chunk hauria de cobrir una idea completa en 150-350 paraules o en una taula breu amb context suficient. La llargada exacta depèn del sistema, però la unitat ha de conservar entitat, condició, data i enllaç canònic sense dependre del paràgraf anterior.

Val la pena publicar una versió Markdown de la documentació?

Sí, si es manté sincronitzada amb la pàgina canònica. Un alternate Markdown redueix soroll de navegació, scripts i components visuals per a pipelines de text, però no ha de convertir-se en una versió paral·lela amb contingut diferent, dates diferents o URLs no canòniques.

Quines metadades importen més per a documentació recuperable?

Les més importants són URL canònica, títol, descripció, idioma, data de publicació, data d’actualització, autor o propietari, font primària, llicència o condicions d’ús, ancoratges de secció i schema Article, TechArticle, FAQPage o BreadcrumbList quan correspongui.

Comença pels 10 documents que més trànsit orgànic o tiquets de suport generen. Afegeix ancoratges persistents, revisa headings, separa chunks ambigus i documenta fonts. És feina petita, però canvia la textura de tot el sistema.