Durant anys s’ha acusat el SEO d’escriure per a robots.
La ironia és que ara els robots parlen amb nosaltres, llegeixen pàgines, consulten eines, combinen dades i poden executar accions. Ja no es limiten a ordenar enllaços. Comencen a fer de mediadors entre una persona i gairebé qualsevol capacitat digital.
Una persona pot dir:
Revisa els meus moviments de l’últim trimestre, detecta despeses anòmales i mostra’m en un gràfic què hauria de mirar primer.
L’agent no necessita únicament trobar una pàgina que expliqui què és un moviment bancari. Necessita descobrir quin sistema pot consultar, quins comptes està autoritzat a llegir, com ha de sol·licitar un període temporal, quina estructura retornarà cada transacció, quina moneda utilitza i quina part de la informació s’ha de convertir en una explicació, una taula o un gràfic.
Aquí apareix una nova frontera del SEO.
No perquè les pàgines hagin deixat d’importar. Al contrari: el contingut visible continua sent el lloc on una empresa explica què sap, què ofereix, quins límits té i per què mereix confiança. Però una explicació ja no és suficient quan l’usuari espera que l’agent faci alguna cosa.
La capacitat necessita dues representacions:
- Una representació visual i conversacional perquè una persona pugui comprendre-la, avaluar-la i controlar-la.
- Una representació estructurada, tipada i invocable perquè un agent pugui seleccionar-la i utilitzar-la de manera fiable.
La segona representació s’assembla al SEO de les dades portat fins a la seva conseqüència operativa: una API, una eina o un servidor MCP que no només descriu què existeix, sinó també què es pot fer.
La frase és deliberadament provocadora. Les dades estructurades no són una API i una API no és SEO. El salt conceptual és en un altre lloc: tots dos redueixen l’ambigüitat perquè un sistema automàtic pugui descobrir significat, triar una opció i actuar sense haver d’endevinar.
En resum
El SEO no ha mort amb els agents. S’ha dividit en dues capes complementàries.
La primera és el SEO que ja coneixem: contingut útil, text accessible, arquitectura clara, títols descriptius, enllaços, autoritat, dades estructurades i accés per a crawlers. La seva funció és ajudar a trobar i comprendre una font.
La segona és una capa emergent que proposo anomenar SEO operatiu: contractes d’eines, APIs, esquemes, permisos, resultats estructurats i errors accionables que permeten a un agent descobrir una capacitat, seleccionar-la, invocar-la i comprovar-ne el resultat.
Una pàgina respon:
Què és això, per a qui serveix i per què hi hauria de confiar?
Una eina respon:
Què puc fer, amb quins paràmetres, sota quins permisos i què retornaré?
I una interfície generada respon:
Com pot una persona comprendre, explorar, corregir o aprovar el que acaba de passar?
El futur no enfronta contingut, API i interfície. Els obliga a compartir la mateixa veritat.
El SEO sempre ha estat una interfície entre dues maneres de llegir
El SEO se sol reduir a rànquings, paraules clau o trànsit. Aquesta reducció n’amaga la funció més útil: traduir una pàgina perquè sigui comprensible al mateix temps per persones i sistemes automàtics.
Una persona interpreta jerarquia visual, to, exemples, reputació i context. Un crawler necessita enllaços accessibles, text disponible, HTML semàntic, títols descriptius, relacions entre URL i senyals que pugui processar de manera consistent.
Google defineix el SEO com el conjunt de pràctiques que ajuden els cercadors a descobrir i comprendre contingut. També insisteix que aquesta optimització aporta valor quan s’aplica a contingut creat principalment per a persones, no quan el contingut existeix per manipular el sistema.
Aquest equilibri és important perquè anticipa el problema actual.
Quan afegim dades estructurades a una pàgina, no creem una segona realitat secreta per al robot. Afegim pistes explícites sobre la realitat que la persona també pot veure. Google exigeix que el marcatge representi el contingut principal, sigui rellevant i no descrigui informació oculta o enganyosa.
La regla es pot generalitzar:
La representació per a màquines ha de ser una expressió més precisa de la mateixa capacitat que es promet a les persones.
A la web clàssica, aquesta representació ajuda a classificar i presentar informació. En un sistema agentiu, a més, es pot convertir en el contracte que habilita una acció.
El canvi no és que l’agent llegeixi la web: és que pot continuar després de llegir-la
Un cercador tradicional troba una pàgina i entrega el pas següent a la persona. La persona obre el resultat, interpreta la interfície i executa l’acció.
Un agent pot encadenar més parts del procés:
- Comprendre la intenció expressada en llenguatge natural.
- Cercar fonts o eines rellevants.
- Comparar informació i restriccions.
- Triar una capacitat.
- Preparar paràmetres.
- Sol·licitar autorització quan correspongui.
- Executar una consulta o acció.
- Transformar el resultat en una explicació o una interfície.
- Demanar confirmació abans d’un canvi sensible.
- Conservar evidència del que s’ha fet.
La visita a la pàgina deixa de ser sempre l’objectiu final. Pot convertir-se en una etapa de descobriment, confiança o documentació dins d’una tasca més gran.
Això no elimina la web. Canvia el destí d’una part del seu trànsit: de clics cap a pàgines a delegacions cap a capacitats.
La interfície deixa de ser únicament el lloc on executem la feina i passa a ser el lloc on definim, supervisem i verifiquem una delegació. El SEO viu una transformació paral·lela: deixa d’optimitzar només l’entrada a una pàgina i comença a participar en la llegibilitat d’allò que l’agent pot fer després.
El model de doble representació
Una capacitat digital madura necessitarà dues representacions coordinades.
1. Representació visual i conversacional
És la manera com una persona comprèn la capacitat i el seu resultat.
Pot adoptar moltes superfícies:
- Una pàgina editorial que explica un servei.
- Una conversa que resumeix una anàlisi.
- Una taula que conserva precisió.
- Un gràfic que revela una tendència.
- Un mapa que permet explorar relacions espacials.
- Un formulari per editar diverses opcions alhora.
- Un diff que mostra què ha canviat.
- Un panell d’aprovació que separa lectura d’escriptura.
Aquesta representació no és un embolcall decoratiu. Organitza el significat, redueix la càrrega cognitiva i permet verificar allò que l’agent interpreta o executa.
La conversa és excel·lent per expressar intenció, demanar una síntesi i afinar l’objectiu. És pitjor per comparar vint valors, detectar una anomalia entre centenars de files o revisar els detalls d’una acció irreversible. Per això la interfície agentiva no serà només veu o xat. Serà una combinació dinàmica de llenguatge, controls i visualitzacions.
2. Representació estructurada i invocable
És la manera com un agent descobreix i utilitza la capacitat sense dependre d’una interpretació visual fràgil.
Inclou, segons el sistema:
- Un nom estable i orientat a una acció.
- Una descripció que explica quan s’ha d’utilitzar.
- Un esquema d’entrada amb tipus, límits i valors permesos.
- Un esquema de sortida que conserva estructura i significat.
- Identificadors estables per continuar el flux.
- Autorització i abast d’accés.
- Declaració d’efectes sobre dades o sistemes externs.
- Errors accionables que permetin corregir paràmetres.
- Versionat, disponibilitat i límits operatius.
- Metadades per distingir lectura, escriptura i accions destructives.
OpenAI recomana tractar noms, descripcions i documentació de paràmetres com a product copy: són els textos que ajuden ChatGPT o Codex a decidir si una eina correspon a la intenció de l’usuari. MCP formalitza aquesta superfície mitjançant name, description, inputSchema, outputSchema i structuredContent.
Aquesta capa no intenta que l’agent “vegi millor” un botó. Intenta evitar que necessiti buscar el botó.
Dades estructurades no és el mateix que API
Convé aturar-se aquí perquè la metàfora pot induir a error.
Les dades estructurades d’una pàgina són principalment descriptives. Indiquen quin tipus d’entitat hi apareix, qui n’és l’autor, quan es va publicar, quines propietats conté o com es relaciona amb altres elements.
Una API o eina és operativa. Defineix una interacció possible amb un servei: què rep, què retorna, quins permisos verifica, quin estat pot canviar i quins errors pot produir.
| Capa | Pregunta principal | Resultat esperat |
|---|---|---|
| Contingut visible | Què significa i per què importa? | Comprensió humana, confiança i context. |
| Dades estructurades | Quina entitat o informació descriu aquesta pàgina? | Classificació i pistes explícites per a sistemes. |
| API o eina | Quina capacitat es pot executar i sota quin contracte? | Consulta o acció repetible. |
| Interfície de resultat | Com es comprèn, s’explora o s’aprova el resultat? | Evidència visual i control humà. |
Per això “la representació estructurada és el SEO de les dades convertit en API” funciona com a tesi editorial, no com a definició tècnica.
L’analogia correcta és aquesta:
El SEO redueix l’ambigüitat per descobrir i comprendre contingut. Un contracte d’eina redueix l’ambigüitat per seleccionar i invocar una capacitat.
El salt és de semàntica descriptiva a semàntica operacional.
De la paraula clau a la intenció executable
El SEO modern fa anys que s’allunya de la repetició literal de paraules clau. Una pàgina útil ha de resoldre una intenció, demostrar coneixement i oferir una resposta satisfactòria.
Les eines per a agents porten aquesta lògica a un nivell més estricte.
Una descripció com ara “Obté dades financeres” és massa àmplia. No explica:
- Si consulta saldos o moviments.
- Si treballa amb un compte o amb tots.
- Quin període accepta.
- Si retorna imports nets o bruts.
- Quines monedes pot combinar.
- Si les dades són en temps real.
- Si només llegeix o també modifica.
- En quins casos no s’ha d’utilitzar.
Una descripció orientada a la intenció s’assemblaria més a:
Utilitza aquesta eina quan l’usuari vulgui analitzar despeses ja registrades en un o diversos comptes autoritzats. No la utilitzis per iniciar transferències, modificar categories ni estimar moviments futurs.
L’equivalent tècnic pot incloure un contracte com aquest:
{
"name": "finance.get_spending_summary",
"description": "Analitza despeses registrades en comptes autoritzats dins d'un període. Només lectura; no inicia pagaments ni modifica transaccions.",
"inputSchema": {
"type": "object",
"properties": {
"account_ids": {
"type": "array",
"items": { "type": "string" }
},
"date_from": { "type": "string", "format": "date" },
"date_to": { "type": "string", "format": "date" },
"currency": { "type": "string" }
},
"required": ["account_ids", "date_from", "date_to"]
},
"outputSchema": {
"type": "object",
"properties": {
"totals_by_category": { "type": "array" },
"anomalies": { "type": "array" },
"source_period": { "type": "object" }
},
"required": ["totals_by_category", "anomalies", "source_period"]
}
}L’exemple no representa una API bancària real. Mostra el tipus de precisió semàntica que un agent necessita per no confondre anàlisi amb acció.
La descripció atrau la intenció correcta. L’esquema evita paràmetres improvisats. L’autorització delimita els comptes. La sortida estructurada permet continuar. La UI converteix el resultat en alguna cosa que una persona pot revisar.
El catàleg d’eines és una nova pàgina de resultats
Un agent connectat pot tenir desenes o centenars d’eines disponibles. Davant d’una petició, ha de decidir quina ha d’utilitzar, quines ha de descartar i si necessita combinar-ne diverses.
Aquest problema s’assembla a una cerca en miniatura.
OpenAI proposa avaluar metadades amb un conjunt de prompts directes, indirectes i negatius. Després recomana mesurar precisió i recall:
- Precisió: quan s’ha activat una eina, era realment la correcta?
- Recall: quan l’eina era necessària, l’agent l’ha trobada i utilitzada?
Aquestes mètriques pertanyen tant a la recuperació d’informació com al disseny de producte.
La comparació amb SEO ajuda a veure el paral·lelisme, sempre que no es confonguin les capes:
| SEO documental | Descobriment d’eines |
|---|---|
title i H1 descriuen la pàgina | name i title identifiquen l’acció |
| Meta description resumeix la rellevància | description explica quan cal invocar |
| Els encapçalaments desenvolupen el tema | Els paràmetres documenten abast i límits |
| Els enllaços interns connecten contingut | Les relacions i seqüències connecten eines |
| Schema.org aporta pistes explícites | JSON Schema defineix entrades i sortides |
| L’URL canònica estabilitza la referència | L’ID i la versió estabilitzen el contracte |
| Robots i sitemap controlen el descobriment | Registre, permisos i disponibilitat controlen l’exposició |
| Search Console revela rendiment | Evals i analítica revelen selecció i errors |
No estem davant de “SEO per enganyar el model”. Estem davant d’arquitectura de la informació perquè el model no hagi d’endevinar.
Descobrir, comprendre, invocar i verificar
El recorregut complet d’una capacitat agentiva es pot resumir en quatre verbs.
Descobrir
L’agent necessita localitzar una font o eina candidata.
A la web, això continua depenent del rastreig, la indexació, els enllaços, els sitemaps, el text accessible i els permisos del crawler. Google afirma que les pràctiques SEO existents continuen aplicant-se a AI Overviews i AI Mode, i que no cal cap fitxer especial ni un esquema exclusiu per aparèixer en aquestes experiències.
OpenAI distingeix OAI-SearchBot, utilitzat per mostrar llocs a les funcions de cerca de ChatGPT, de GPTBot, relacionat amb l’entrenament. Això confirma que l’accessibilitat per als sistemes de cerca continua sent una decisió tècnica concreta, no una abstracció.
Comprendre
Trobar una URL no és suficient. L’agent ha d’identificar què afirma la font, amb quina evidència, en quina data i sota quin context.
Aquí importen el contingut original, l’autoria, les definicions clares, les taules, la semàntica HTML, les dates, les referències i la coherència entre text visible i dades estructurades.
El contingut de qualitat no és un residu anterior a l’era agentiva. És la base amb què l’agent construeix una resposta, compara fonts o decideix si una capacitat és adequada.
Invocar
Quan existeix una acció repetible, l’agent necessita un contracte més estricte que una pàgina.
OpenAPI defineix una descripció estàndard perquè persones i sistemes puguin descobrir i comprendre capacitats HTTP. MCP exposa eines amb esquemes d’entrada i sortida. Els resultats estructurats permeten encadenar passos sense haver de tornar a extreure informació de prosa o píxels.
La invocació afegeix dimensions que el SEO clàssic no havia de resoldre directament:
- Identitat.
- Autorització.
- Abast.
- Efectes laterals.
- Idempotència.
- Límits d’ús.
- Errors i recuperació.
- Confirmació humana.
Verificar
L’agent pot haver cridat l’eina correcta i, tot i així, produir una conclusió equivocada.
Un JSON vàlid no garanteix que els seus valors siguin certs. OpenAI adverteix que Structured Outputs pot respectar un esquema i encara contenir errors dins dels valors. Un esquema assegura forma; l’evidència, la validació i la revisió sostenen el significat.
Per això l’última capa torna a ser humana: mostrar fonts, període, filtres, supòsits, anomalies, canvis i accions pendents d’aprovació.
Allò que els agents ens mostraran també és UX i també és SEO
L’agent no només necessita llegir millor. També necessita decidir com retornar allò que ha trobat.
Una resposta parlada pot ser suficient per dir:
Aquest mes has gastat un 18% més en programari que la mitjana dels últims sis mesos.
Però una persona pot necessitar comprovar:
- Quines subscripcions componen aquest augment.
- Quins mesos s’han comparat.
- Si l’import inclou impostos.
- Quin compte ha originat cada càrrec.
- Quines categories s’han inferit.
- Quins moviments han quedat sense classificar.
- Quina acció recomana el sistema i per què.
Aquí apareix la interfície generada o seleccionada per l’agent.
MCP Apps permet que les eines ofereixin gràfics, formularis i dashboards dins d’una conversa. OpenAI recomana afegir UI quan les persones necessiten inspeccionar, comparar, editar, confirmar o navegar informació estructurada. També proposa separar les eines que recuperen o processen dades de les que renderitzen la presentació final.
Aquesta separació és fonamental.
L’eina de dades hauria de retornar una representació precisa i reutilitzable. L’agent la pot analitzar, combinar o filtrar. Només després tria una vista adequada: gràfic, taula, mapa, formulari, diff o targeta de confirmació.
La UI deixa de ser necessàriament una pantalla fixa per on entra tothom. Es converteix en una vista contextual d’evidència, construïda per a la pregunta concreta.
El contingut, les dades i la interfície continuen relacionats:
- El contingut explica la capacitat abans d’utilitzar-la.
- L’esquema permet executar-la sense ambigüitat.
- Les dades estructurades conserven precisió durant el flux.
- La interfície permet comprendre i controlar el resultat.
- La conversa ho connecta tot amb la intenció original.
Un exemple: “revisa els meus comptes i mostra’m què necessito veure”
Imaginem que una persona pronuncia aquesta frase davant de l’ordinador.
Un sistema ben dissenyat no hauria de començar obrint pestanyes a l’atzar i llegint números de la pantalla com a única estratègia. Podria seguir un flux com aquest:
- Identificar que la petició és d’anàlisi, no de transferència.
- Mostrar quines fonts financeres estan connectades i demanar l’abast si n’hi ha diverses.
- Invocar una eina de només lectura per recuperar comptes autoritzats.
- Consultar moviments amb dates, monedes i identificadors estables.
- Normalitzar categories sense modificar el registre original.
- Calcular tendències i marcar anomalies amb criteris explícits.
- Conservar el període i les fonts dins del resultat estructurat.
- Triar una representació visual adequada.
- Resumir per veu les dues o tres conclusions principals.
- Permetre obrir cada categoria o moviment des del gràfic.
- Separar qualsevol acció posterior — per exemple, cancel·lar una subscripció — en una eina d’escriptura amb confirmació pròpia.
La persona rep una experiència simple: una conversa i un gràfic.
A sota hi ha una arquitectura complexa: eines enfocades, permisos, esquemes, fonts, càlculs, estats i traçabilitat.
El bon disseny no consisteix a ocultar completament aquesta complexitat. Consisteix a mostrar la part necessària en el moment adequat.
La mateixa font de veritat ha d’alimentar la pàgina, l’eina i la interfície
El risc més gran d’aquest model és crear tres versions incompatibles del negoci:
- La promesa comercial a la pàgina.
- El contracte tècnic a l’eina.
- El comportament real del sistema.
Proposo anomenar-ho triangle de paritat semàntica.
| Vèrtex | Què ha d’expressar | Error típic |
|---|---|---|
| Promesa visible | Què resol, per a qui, amb quins límits i evidència. | El màrqueting promet temps real, però les dades s’actualitzen una vegada al dia. |
| Contracte estructurat | Entrades, sortides, permisos, efectes, errors i abast. | La descripció diu “només lectura”, però l’endpoint pot modificar l’estat. |
| Comportament real | L’operació i el resultat que executa el sistema. | L’output omet moneda, zona horària o font i produeix una visualització enganyosa. |
La coherència no s’hauria de mantenir copiant text manualment entre CMS, documentació i codi. Sempre que sigui possible, convé derivar les representacions d’una font de veritat compartida:
- Catàleg canònic de capacitats.
- Tipus de dades versionats.
- IDs estables.
- Polítiques d’autorització centralitzades.
- Exemples d’ús verificables.
- Definicions de negoci compartides.
- Tests de contracte.
- Evals de selecció d’eines.
- Comprovacions de paritat entre contingut i comportament.
El SEO, el disseny i l’enginyeria deixen de ser fases separades. Participen en la mateixa arquitectura semàntica.
Què és el SEO operatiu
SEO operatiu no és un estàndard existent. És un marc per anomenar una responsabilitat que està apareixent.
El defineixo així:
El SEO operatiu és el disseny de contingut, metadades, esquemes i contractes perquè una capacitat digital pugui ser descoberta, compresa, seleccionada, invocada i verificada per agents sense perdre claredat, confiança ni control humà.
No substitueix el SEO tècnic ni editorial. Els amplia quan una pàgina representa una capacitat executable.
Una empresa no necessita convertir cada article en una eina. Una opinió, una investigació o una història poden continuar sent contingut. La capa operativa té sentit quan existeix un resultat repetible i autoritzable:
- Consultar disponibilitat.
- Calcular una tarifa.
- Recuperar una comanda.
- Analitzar moviments.
- Crear una reserva.
- Preparar un pressupost.
- Actualitzar un registre.
- Generar un informe.
- Obrir una incidència.
- Programar una reunió.
La pregunta pràctica és:
Després de comprendre aquesta pàgina, hi ha una capacitat concreta que l’usuari voldrà delegar?
Si la resposta és sí, probablement convé dissenyar-ne la representació invocable.
La matriu de maduresa: pàgina, contracte i acció
Podem classificar una capacitat segons les representacions disponibles.
| Representació humana | Contracte invocable | Estat de la capacitat |
|---|---|---|
| Sí | No | Comprensible, però la persona encara ha d’executar manualment. |
| No | Sí | Operable per integració, però opaca i difícil d’avaluar o governar. |
| No | No | Capacitat invisible o dependent de coneixement intern. |
| Sí | Sí | Capacitat delegable: es pot comprendre, invocar i verificar. |
L’última categoria no és automàticament bona. També necessita autorització, seguretat, observabilitat i recuperació. Un agent no hauria de poder actuar només perquè ha trobat un endpoint.
Tal com explico a Controlar agents IA com Codex en l’entorn de treball, les instruccions i anotacions no substitueixen els controls tècnics. Els permisos s’han d’aplicar al servidor, les accions sensibles s’han de separar i la persona ha de conservar la capacitat de revisió i revocació.
Com canvia la feina de SEO, UX/UI i desenvolupament
El SEO deixa d’acabar a la pàgina
El professional SEO continuarà treballant amb intenció, arquitectura, contingut, semàntica, indexació, enllaços, autoritat i mesurament.
Però, per a productes agentius, també haurà de col·laborar en:
- Taxonomies de capacitats.
- Noms i descripcions d’eines.
- Diferenciació entre operacions semblants.
- Exemples positius i negatius d’activació.
- Coherència entre promesa, esquema i resultat.
- Descobriment en catàlegs d’eines.
- Evals de precisió i recall.
- Versionat semàntic de capacitats.
És una evolució natural. Redactar una descripció d’eina no és tan diferent de redactar un títol i una meta description: totes dues condensen significat per ajudar un sistema a triar. La diferència és que una mala elecció d’eina pot modificar dades, enviar un missatge o gastar diners.
UX/UI dissenya l’evidència i el control
El dissenyador ja no treballa únicament en la interfície anterior a l’acció. També dissenya què passa després de delegar:
- Com s’expressa l’abast.
- Com es mostren les fonts.
- Com es comparen resultats.
- Quina visualització correspon a cada tipus de dada.
- Quan n’hi ha prou amb una resposta textual.
- Quan cal un formulari o dashboard.
- Com es presenta una confirmació.
- Com s’interromp o es reverteix una tasca.
- Com es distingeix una inferència d’una dada observada.
La interfície pot ser efímera i generada per a una petició específica, però els seus principis no es poden improvisar cada vegada.
El desenvolupament converteix funcions internes en contractes de producte
No convé exposar cada endpoint intern com una eina. OpenAI recomana començar per l’objectiu de l’usuari i agrupar operacions coherents, separant lectures d’escriptures i accions amb riscos diferents.
La feina inclou:
- Modelar inputs i outputs explícits.
- Retornar IDs estables.
- Evitar blocs de text quan el resultat necessita reutilització.
- Dissenyar errors que permetin corregir i reintentar.
- Aplicar autorització real.
- Declarar i provar efectes laterals.
- Mantenir compatibilitat i versionat.
- Separar processament de dades i renderització.
A Un LLM prediu tokens; un agent executa tasques, explico que el valor de l’agent no apareix només en el model, sinó en el sistema que l’envolta. El contracte d’eines és una d’aquestes capes decisives.
Com mesurar aquest nou SEO
El rànquing, per si sol, no descriu la visibilitat agentiva.
Convé mesurar tres nivells.
1. Descobriment documental
- Pàgines rastrejables i indexades.
- Cobertura del sitemap.
- Impressions i clics.
- Trànsit des de cercadors i assistents.
- Consultes en què apareix la font.
- Frescor i accessibilitat del contingut.
- Coherència del marcatge estructurat.
2. Selecció i invocació
- Precisió de selecció d’eina.
- Recall davant de prompts rellevants.
- Activacions falses en prompts negatius.
- Validesa dels arguments.
- Percentatge de crides reeixides.
- Reintents per errors d’esquema o de negoci.
- Temps fins a completar la tasca.
- Ús correcte de lectura enfront d’escriptura.
- Cost d’execució.
3. Comprensió i control humà
- Temps necessari per verificar el resultat.
- Capacitat de localitzar la font d’una dada.
- Errors de confirmació.
- Accions revertides.
- Correccions sol·licitades.
- Comprensió de límits i permisos.
- Satisfacció amb la representació visual.
- Incidents o accions no desitjades.
La unitat d’èxit deixa de ser només una visita. Pot ser una tasca completada de manera correcta, comprensible i reversible.
Què no convé fer
Crear contingut “per a agents” que no ajuda les persones
Google manté una posició clara: les pràctiques SEO serveixen quan s’apliquen a contingut útil i centrat en les persones. L’arribada dels agents no justifica produir pàgines buides, definicions repetides o text dissenyat únicament per aparèixer en una resposta generativa.
Tractar llms.txt com una solució màgica
Alguns llocs publiquen índexs llegibles per models i poden ser pràctics com a documentació. Però Google afirma que no cal crear nous fitxers “AI text” ni un marcatge especial per a les seves funcions d’IA. Un fitxer auxiliar no substitueix contingut accessible, enllaços, arquitectura, permisos de crawler ni una API ben dissenyada.
Copiar l’API interna sense pensar en l’objectiu
Una eina amb vint modes i paràmetres ambigus obliga el model a endevinar. Les capacitats s’han de dissenyar des del resultat que la persona espera, no des de la comoditat del backend existent.
Retornar només prosa quan la dada es reutilitzarà
Un paràgraf pot ser agradable de llegir, però perd IDs, tipus, unitats i relacions. La resposta estructurada hauria de conservar la precisió; la conversa la pot sintetitzar després.
Mostrar un gràfic sense exposar-ne la procedència
Una visualització convincent pot ocultar filtres, períodes o dades excloses. La UI ha de permetre rastrejar el resultat fins a les fonts i els supòsits.
Confiar en l’esquema com a garantia de veritat
L’esquema valida la forma, no necessàriament el significat. Cal validació de negoci, evidència, tests i revisió proporcional al risc.
Permetre que la descripció substitueixi l’autorització
Dir que una eina és de només lectura no la converteix tècnicament en només lectura. Les restriccions s’han d’imposar en permisos, endpoints i polítiques reals.
Una arquitectura pràctica per a capacitats llegibles per agents
Una organització pot començar amb set capes.
- Pàgina canònica: explica la capacitat, el públic, els límits, els exemples, les fonts i l’evidència.
- SEO tècnic: assegura text accessible, semàntica, enllaços, canonical, sitemap, rendiment i polítiques de crawling.
- Dades estructurades: descriuen entitats i contingut visible sense inventar una realitat paral·lela.
- Catàleg de capacitats: manté noms, descripcions, responsables, estat i versió.
- Contracte invocable: exposa eines o APIs amb esquemes, autorització, efectes i errors.
- Resultat estructurat: conserva IDs, unitats, fonts i camps reutilitzables.
- Renderització d’evidència: transforma el resultat en conversa, taula, gràfic, formulari o panell d’aprovació segons la tasca.
A aquestes capes cal afegir observabilitat, seguretat i governança. Cada crida hauria de poder respondre qui ha sol·licitat l’acció, quina eina s’ha utilitzat, amb quins arguments, quines dades ha retornat i quina part ha estat inferida pel model.
La web no desapareix: es converteix en documentació viva de capacitats
La predicció que els agents eliminaran els webs confon navegació amb significat.
Potser visitarem menys pàgines per executar tasques rutinàries. Però les organitzacions continuaran necessitant llocs canònics on explicar:
- Què ofereixen.
- Com funciona.
- Quines dades utilitzen.
- Quins límits apliquen.
- Quina evidència sustenta les seves afirmacions.
- Qui n’és responsable.
- Què canvia entre versions.
- Com es revoca l’accés.
- Què pot fer l’agent en nom de l’usuari.
La pàgina es torna encara més important com a font pública de veritat, fins i tot quan l’agent és qui la consulta primer.
La diferència és que el contingut ja no hauria de viure aïllat del producte. La definició visible, l’esquema i el comportament han d’evolucionar junts.
La conclusió incòmoda: el SEO s’acosta al disseny de producte
El SEO va néixer com una disciplina de descobriment. Amb els agents, una part d’aquest descobriment condueix directament a una acció.
Això obliga a ampliar la pregunta.
Ja no n’hi ha prou amb preguntar:
Pot un cercador trobar i comprendre aquesta pàgina?
També haurem de preguntar:
Pot un agent descobrir aquesta capacitat, distingir-la d’altres, invocar-la amb els paràmetres correctes i retornar un resultat que una persona pugui verificar?
Aquí el SEO toca arquitectura de la informació, disseny d’APIs, documentació, UX, seguretat i analítica de producte.
No perquè totes aquestes feines es converteixin en SEO, sinó perquè totes participen en la mateixa batalla: fer que una intenció humana arribi a la capacitat correcta amb la mínima ambigüitat possible.
La web per a persones i la interfície per a agents no són dos mons separats.
Una explica.
L’altra executa.
I totes dues han de dir la veritat.
Preguntes freqüents
- El SEO desapareixerà quan els agents responguin i actuïn per nosaltres?
- No. Els agents encara necessiten descobrir fonts, interpretar contingut, comprovar l'autoritat i recuperar informació fiable. A aquest SEO documental s'hi afegeix una nova capa operativa: descriure capacitats mitjançant eines, APIs i esquemes que es puguin seleccionar i invocar sense haver d'endevinar.
- Les dades estructurades d'una pàgina són el mateix que una API?
- No. Les dades estructurades descriuen el significat d'una pàgina o entitat. Una API o eina exposa una capacitat executable, amb entrades, sortides, autorització, errors i possibles efectes sobre l'estat. La relació entre totes dues és una analogia semàntica, no una equivalència tècnica.
- Què significa SEO operatiu per a agents?
- És un marc proposat en aquest article per dissenyar contingut, metadades i contractes d'eina de manera que una capacitat pugui ser descoberta, seleccionada, invocada i verificada per un agent, mantenint una representació clara i útil per a les persones.
- Una empresa necessita convertir tot el seu web en una API?
- No. El contingut editorial, institucional o explicatiu pot continuar sent únicament documental. Convé exposar una capa invocable quan existeix una capacitat repetible i autoritzable, com ara consultar disponibilitat, calcular una proposta, recuperar moviments, crear una reserva o actualitzar un registre.
- Les interfícies visuals continuen sent necessàries si l'agent pot parlar?
- Sí. La conversa serveix per expressar intenció i rebre una síntesi. Les interfícies visuals continuen sent superiors per comparar, explorar dades denses, editar opcions, revisar evidència, confirmar accions i conservar un registre persistent.
- Com es mesura la visibilitat d'una capacitat per als agents?
- A més de la indexació, les impressions i el trànsit, cal mesurar la selecció d'eines, la precisió i el recall d'activació, la validesa dels arguments, l'èxit de la tasca, els reintents, el temps de verificació humana, els errors de confirmació i la capacitat de recuperació.