Com escriure contingut tècnic que serveixi per a Google, ChatGPT i lectors humans

Des que els models de llenguatge van començar a contestar preguntes tècniques directament, la pregunta òbvia per a qui manté un blog és: té sentit continuar escrivint? La resposta curta és sí, però no de la mateixa manera que abans. La resposta llarga és que el contingut tècnic ara té tres audiències simultànies: persones que llegeixen, Google que indexa i models d’IA que citen. I el més interessant és que les tres volen gairebé el mateix, encara que per raons diferents.

No vendré la idea que existeix una fórmula màgica per “optimitzar per a IA” com si fos una nova disciplina. El que explicaré és com estructurar contingut tècnic que sigui genuïnament útil, i per què resulta que funciona per a les tres audiències alhora.

GEO: què és i què no és

GEO (Generative Engine Optimization) és un terme que ha començat a circular com el “nou SEO”. La idea és que, de la mateixa manera que optimitzem contingut per a Google, hauríem d’optimitzar-lo per a ChatGPT, Perplexity, Gemini i altres models que responen preguntes citant fonts.

Hi ha quelcom de veritat en això. Els models de llenguatge sí que citen fonts quan generen respostes, i hi ha evidència que certs tipus de contingut es citen més que altres. Però hi ha molt de fum al voltant del terme.

El que GEO no és:

• No és una disciplina separada del SEO. Els mateixos principis de contingut de qualitat, estructura clara i experiència demostrable que funcionen per a Google funcionen per als models d’IA.
• No és ficar keywords per a IA. Els models no funcionen com el Google de 2010. No indexen per keywords; entenen semàntica.
• No és un truc tècnic. No existeix cap meta tag que faci que ChatGPT et citi més.
• No requereix eines noves. Si el teu contingut és bo per a persones i tècnicament correcte per a cercadors, ja està ben posicionat per a models d’IA.

El que GEO sí és (quan se’n parla amb serietat):

• Entendre que els models d’IA consumeixen contingut web com a font d’entrenament i com a referència en temps real (RAG, cerca web integrada).
• Estructurar el contingut perquè sigui fàcil d’extreure i citar: respostes clares, dades concretes, afirmacions verificables.
• Mantenir l’autoria i credibilitat, perquè els models tendeixen a preferir fonts amb senyals d’autoritat.

Si escrius contingut tècnic clar, ben estructurat, amb experiència real i dades verificables, ja estàs fent “GEO” sense necessitat de dir-ne així.

Estructura clara: la base que funciona per a tothom

L’estructura del contingut és probablement el factor que més impacta en les tres audiències simultàniament. Per a una persona, una estructura clara vol dir que pot trobar el que busca sense llegir-ho tot. Per a Google, vol dir que pot entendre la jerarquia del contingut. Per a un model d’IA, vol dir que pot extreure fragments rellevants per citar.

Headings com a esquelet informatiu

Els headings (H2, H3) no són decoració. Són l’esquelet semàntic de l’article. Un lector que escaneja hauria de poder llegir només els headings i entendre de què va l’article i què trobarà a cada secció.

Mal exemple:

## Introducció
## Desenvolupament
## Conclusió

Bon exemple:

## Quin problema resol FastAPI que Spring Boot no
## Quan el tipat de Python és suficient i quan no
## Comparativa de temps de deploy: Docker vs serverless

Els headings descriptius funcionen com a punts d’entrada. Google pot mostrar-los com a sitelinks als resultats de cerca. ChatGPT pot fer-los servir per navegar el contingut quan busca la resposta a una pregunta específica. Un lector pot fer scroll fins a la secció que li interessa.

Paràgrafs curts amb una idea cadascun

Els paràgrafs de text tècnic no haurien de superar les 4-5 línies. No és una regla estètica; és funcional. Un paràgraf curt amb una idea clara és més fàcil d’escanejar, d’indexar i d’extreure com a cita.

Quan un model d’IA necessita respondre “quan fer servir FastAPI en lloc de Spring Boot”, busca un fragment de text que contingui aquesta resposta de manera autònoma. Si la resposta està diluïda en un paràgraf de 15 línies barrejada amb altres idees, és menys probable que es citi correctament.

Resums i definicions explícites

Els blockquotes, les definicions al principi de seccions i les frases que sintetitzen una idea són extremadament útils per a les tres audiències.

Si estàs explicant un concepte, comença la secció amb una definició o síntesi clara abans de desenvolupar:

Pydantic és la llibreria de validació de dades de Python que FastAPI fa servir internament per serialitzar i deserialitzar request/response bodies amb tipat.

Aquesta frase pot ser citada tal qual per un model d’IA. Google pot fer-la servir com a featured snippet. Un lector la llegeix i sap si la secció li interessa o no.

Experiència real: per què E-E-A-T importa més que mai

E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness) és el framework que Google fa servir per avaluar la credibilitat del contingut. La primera “E” (Experience) es va afegir fa relativament poc i és la més rellevant per a blogs tècnics.

La pregunta que Google intenta respondre és: la persona que escriu això, ha fet servir de veritat el que està explicant?

Contingut sense experiència:

“Spring Boot és un framework popular per desenvolupar aplicacions Java. Ofereix molts avantatges com la configuració automàtica i l’ecosistema ampli.”

Contingut amb experiència:

“Després de migrar un servei de Java a Kotlin amb Spring Boot, el primer problema que vaig trobar va ser que les entitats JPA amb data classes generaven equals/hashCode incorrectes. Hibernate necessita entitats mutables, i Kotlin t’empeny cap a la immutabilitat.”

La diferència és evident per a un lector humà. Però també ho és per a Google (que avalua senyals d’experiència al text) i per als models d’IA (que prefereixen citar contingut específic sobre contingut genèric).

Com demostrar experiència al contingut

• Esmentar decisions concretes i el seu context. “Vam triar FastAPI perquè l’equip ja tenia scripts Python que necessitàvem exposar com a API.”
• Incloure errors i aprenentatges. “El primer intent amb coroutines i @Transactional no va funcionar perquè les transaccions de Spring no són suspendables.”
• Mostrar codi real, no teòric. Snippets que podrien estar en un projecte de veritat, amb gestió d’errors, edge cases i comentaris sobre per què es va fer així.
• Donar opinions fonamentades. “MockK és millor que Mockito per a Kotlin, i ho dic després de fer servir tots dos durant mesos. La raó principal és el suport natiu de classes final.”

Dades i exemples concrets: el que permet ser citat

Els models d’IA citen contingut que conté dades específiques, comparatives verificables i respostes directes a preguntes comunes. El contingut vague o teòric rarament es cita.

Exemple de contingut vague:

“FastAPI és més ràpid que Spring Boot en molts escenaris.”

Exemple de contingut citable:

“Un servei FastAPI amb uvicorn arrenca en 1-2 segons, consumeix ~50MB de memòria en repòs i la imatge Docker pesa ~150MB. L’equivalent en Spring Boot arrenca en 5-15 segons, consumeix ~200MB i la imatge pesa ~250MB.”

El segon exemple conté dades concretes que un model d’IA pot extreure i presentar com a resposta factual. Google pot fer-lo servir per a un featured snippet. Un lector el llegeix i obté informació útil directament.

Les taules comparatives són especialment efectives:

Una taula ben construïda és un dels formats més citats per models d’IA i més usats per Google per a rich snippets. Però la taula ha de contenir dades reals, no farciment.

Schema i structured data: la capa tècnica

Les dades estructurades (Schema.org) no fan que el teu contingut sigui millor, però ajuden Google a entendre’l i presentar-lo correctament. Per a models d’IA que fan servir cerca web (com Perplexity o ChatGPT amb browsing), la claredat semàntica del contingut també pot influir en què es cita.

Article / TechArticle

L’schema bàsic per a un blog tècnic. Inclou autor, dates, descripció i tema:

{
  "@context": "https://schema.org",
  "@type": "TechArticle",
  "headline": "FastAPI per a automatitzacions internes",
  "author": {
    "@type": "Person",
    "name": "Roger Bosch",
    "url": "https://oshy.tech/about"
  },
  "datePublished": "2026-05-18",
  "dateModified": "2026-05-18",
  "description": "Quan té sentit fer servir FastAPI per a eines internes...",
  "inLanguage": "ca"
}

FAQ

Si el teu article respon preguntes concretes, l’schema FAQ pot generar resultats enriquits a Google i facilitar que els models d’IA extreguin respostes:

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Quan fer servir FastAPI en lloc de Spring Boot?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "FastAPI és millor opció quan necessites integrar amb scripts Python existents, el projecte és una eina interna amb cicle de vida curt, o necessites un prototip ràpid."
      }
    }
  ]
}

HowTo

Per a articles que expliquen procediments pas a pas (configuració, deployment, debugging), l’schema HowTo és rellevant:

{
  "@context": "https://schema.org",
  "@type": "HowTo",
  "name": "Com configurar Spring Boot amb Kotlin",
  "step": [
    {
      "@type": "HowToStep",
      "name": "Configurar plugins de Gradle",
      "text": "Afegeix kotlin-spring, kotlin-jpa i kotlin-allopen al build.gradle.kts..."
    }
  ]
}

No cal posar tots els schemas a tots els articles. Fes servir TechArticle sempre, FAQ quan hi ha preguntes i respostes clares, i HowTo quan l’article és un procediment.

FAQs: preguntes que la gent realment busca

Les FAQs dins d’un article tècnic no són un truc SEO. Són una manera de respondre directament les preguntes que algú podria fer a Google o a ChatGPT. La clau és que les preguntes siguin reals, no inventades.

Com trobar preguntes reals:

• Google Autocomplete. Escriu el tema a Google i mira quines suggerències apareixen.
• People Also Ask. Les preguntes relacionades que Google mostra als resultats.
• Search Console. Les queries reals que porten tràfic al teu lloc.
• Stack Overflow. Les preguntes freqüents sobre el tema.
• La pròpia experiència. Què em va preguntar el meu equip quan ho vam implementar? Què vaig buscar jo quan estava aprenent?

Una FAQ útil en un article sobre Spring Boot amb Kotlin podria ser:

Es poden fer servir data classes com a entitats JPA?

Tècnicament sí, però no és recomanable. Les data classes generen equals() i hashCode() que inclouen tots els camps, cosa que causa problemes amb lazy loading i amb el cicle de vida de persistència d’Hibernate. És millor fer servir classes normals per a entitats JPA i reservar les data classes per a DTOs.

Aquesta resposta és directa, tècnica, basada en experiència i citable. Un model d’IA pot extreure-la i presentar-la com a resposta. Google pot mostrar-la com a featured snippet. Un lector que tenia aquest dubte el resol immediatament.

Evitar contingut generat sense criteri

Cal abordar l’elefant a l’habitació. Amb eines d’IA generativa, és possible produir articles tècnics a un ritme molt superior que abans. Però el volum sense criteri és exactament el que el Helpful Content System de Google està dissenyat per penalitzar.

El problema no és fer servir IA com a eina. Jo faig servir IA per revisar esborranys, generar esquelets de codi i buscar informació. El problema és publicar contingut generat per IA sense que passi pel filtre de l’experiència real.

Un article generat per IA sobre “Spring Boot amb Kotlin” cobrirà els mateixos punts que altres 500 articles: configuració, avantatges, exemple bàsic. El que no tindrà és l’experiència d’haver-se barallat amb JPA i data classes durant setmanes, o d’haver decidit deixar les entitats a Java i migrar només els serveis. Això és el que diferencia contingut útil de contingut de farciment.

Les senyals que delaten contingut sense criteri:

• Explicacions genèriques que no diuen res que no sigui a la documentació oficial
• Absència d’opinió o decisió justificada
• Codi d’exemple que és el mateix que apareix al “getting started” del framework
• Estructura predictible: introducció, llista d’avantatges, llista d’inconvenients, conclusió
• Falta d’errors o problemes reals (ningú no aprèn alguna cosa sense trobar problemes)

El test que faig servir: si esborres el nom de l’autor i el del lloc, es podria identificar qui ho va escriure pel contingut? Si no, probablement no té prou veu pròpia.

Què funciona a la pràctica

Després d’analitzar quins articles d’oshy.tech han funcionat millor (en tràfic orgànic, en temps de lectura i en cites per models d’IA), els patrons són consistents:

1. Articles que resolen un problema concret posicionen millor que articles que expliquen un concepte genèric. “Com recuperar la contrasenya de n8n” funciona millor que “Què és n8n”.

2. Articles amb codi real i errors documentats tenen més engagement que articles teòrics. La gent busca solucions a problemes que estan tenint ara mateix.

3. Articles amb estructura escanejable (headings descriptius, paràgrafs curts, taules comparatives) retenen millor el lector que blocs llargs de text.

4. Articles que prenen una posició (“MockK és millor que Mockito per a Kotlin”) generen més interacció que articles neutrals que presenten opcions sense opinar.

5. Articles amb dades concretes (temps, mides, mètriques) es citen més que articles amb afirmacions vagues.

Res d’això és sorprenent. És sentit comú aplicat a l’escriptura tècnica. Però és fàcil oblidar-ho quan estàs pensant en keywords i en optimització.

La convergència real

El més interessant de tot això és que les tres audiències (persones, Google, models d’IA) convergeixen en el mateix. Totes volen contingut que sigui:

• Clar i ben estructurat
• Basat en experiència real
• Amb dades concretes i verificables
• Amb autoria identificable
• Que resolgui problemes reals

No hi ha cap truc per “optimitzar per a ChatGPT” que sigui diferent d’escriure bon contingut tècnic. No hi ha cap meta tag secreta perquè Perplexity et citi. La millor estratègia de GEO és la mateixa que la millor estratègia de SEO, que és la mateixa que la millor estratègia perquè persones reals llegeixin i comparteixin el teu contingut: escriure coses útils, amb criteri, des de l’experiència.

La tecnologia que consumeix el teu contingut canvia. Els algorismes de ranking evolucionen. Els models d’IA milloren. Però la base no canvia: contingut clar, honest i basat en experiència real sempre troba la seva audiència. La resta és optimització marginal.