Cómo escribir contenido técnico que sirva para Google, ChatGPT y lectores humanos

Desde que los modelos de lenguaje empezaron a contestar preguntas técnicas directamente, la pregunta obvia para quien mantiene un blog es: tiene sentido seguir escribiendo? La respuesta corta es sí, pero no de la misma forma que antes. La respuesta larga es que el contenido técnico ahora tiene tres audiencias simultáneas: personas que leen, Google que indexa y modelos de IA que citan. Y lo interesante es que las tres quieren casi lo mismo, aunque por razones diferentes.

No voy a vender la idea de que existe una fórmula mágica para “optimizar para IA” como si fuera una nueva disciplina. Lo que voy a explicar es cómo estructurar contenido técnico que sea genuinamente útil, y por qué eso resulta que funciona para las tres audiencias a la vez.

GEO: qué es y qué no es

GEO (Generative Engine Optimization) es un término que ha empezado a circular como el “nuevo SEO”. La idea es que, de la misma forma que optimizamos contenido para Google, deberíamos optimizarlo para ChatGPT, Perplexity, Gemini y otros modelos que responden preguntas citando fuentes.

Hay algo de verdad en eso. Los modelos de lenguaje sí citan fuentes cuando generan respuestas, y hay evidencia de que ciertos tipos de contenido se citan más que otros. Pero hay mucho humo alrededor del término.

Lo que GEO no es:

• No es una disciplina separada del SEO. Los mismos principios de contenido de calidad, estructura clara y experiencia demostrable que funcionan para Google funcionan para los modelos de IA.
• No es meter keywords para IA. Los modelos no funcionan como el Google de 2010. No indexan por keywords; entienden semántica.
• No es un truco técnico. No existe una meta tag <meta name="ai-optimized"> que haga que ChatGPT te cite más.
• No requiere herramientas nuevas. Si tu contenido es bueno para personas y técnicamente correcto para buscadores, ya está bien posicionado para modelos de IA.

Lo que GEO sí es (cuando se habla con seriedad):

• Entender que los modelos de IA consumen contenido web como fuente de entrenamiento y como referencia en tiempo real (RAG, búsqueda web integrada).
• Estructurar el contenido para que sea fácil de extraer y citar: respuestas claras, datos concretos, afirmaciones verificables.
• Mantener la autoría y credibilidad, porque los modelos tienden a preferir fuentes con señales de autoridad.

Si escribes contenido técnico claro, bien estructurado, con experiencia real y datos verificables, ya estás haciendo “GEO” sin necesidad de llamarlo así.

Estructura clara: la base que funciona para todos

La estructura del contenido es probablemente el factor que más impacta en las tres audiencias simultáneamente. Para una persona, una estructura clara significa que puede encontrar lo que busca sin leer todo. Para Google, significa que puede entender la jerarquía del contenido. Para un modelo de IA, significa que puede extraer fragmentos relevantes para citar.

Headings como esqueleto informativo

Los headings (H2, H3) no son decoración. Son el esqueleto semántico del artículo. Un lector que escanea debería poder leer solo los headings y entender de qué va el artículo y qué va a encontrar en cada sección.

Mal ejemplo:

## Introducción
## Desarrollo
## Conclusión

Buen ejemplo:

## Qué problema resuelve FastAPI que Spring Boot no
## Cuándo el tipado de Python es suficiente y cuándo no
## Comparativa de tiempos de deploy: Docker vs serverless

Los headings descriptivos funcionan como puntos de entrada. Google puede mostrarlos como sitelinks en resultados de búsqueda. ChatGPT puede usarlos para navegar el contenido cuando busca la respuesta a una pregunta específica. Un lector puede hacer scroll hasta la sección que le interesa.

Párrafos cortos con una idea cada uno

Los párrafos de texto técnico no deberían superar las 4-5 líneas. No es una regla estética; es funcional. Un párrafo corto con una idea clara es más fácil de escanear, de indexar y de extraer como cita.

Cuando un modelo de IA necesita responder “cuándo usar FastAPI en vez de Spring Boot”, busca un fragmento de texto que contenga esa respuesta de forma autónoma. Si la respuesta está diluida en un párrafo de 15 líneas mezclada con otras ideas, es menos probable que se cite correctamente.

Resúmenes y definiciones explícitas

Los blockquotes, las definiciones al principio de secciones y las frases que sintetizan una idea son extremadamente útiles para las tres audiencias.

Si estás explicando un concepto, empieza la sección con una definición o síntesis clara antes de desarrollar:

Pydantic es la librería de validación de datos de Python que FastAPI usa internamente para serializar y deserializar request/response bodies con tipado.

Esa frase puede ser citada tal cual por un modelo de IA. Google puede usarla como featured snippet. Un lector la lee y sabe si la sección le interesa o no.

Experiencia real: por qué E-E-A-T importa más que nunca

E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness) es el framework que Google usa para evaluar la credibilidad del contenido. La primera “E” (Experience) se añadió hace relativamente poco y es la más relevante para blogs técnicos.

La pregunta que Google intenta responder es: la persona que escribe esto, ha usado de verdad lo que está explicando?

Contenido sin experiencia:

“Spring Boot es un framework popular para desarrollar aplicaciones Java. Ofrece muchas ventajas como la configuración automática y el ecosistema amplio.”

Contenido con experiencia:

“Después de migrar un servicio de Java a Kotlin con Spring Boot, el primer problema que encontré fue que las entidades JPA con data classes generaban equals/hashCode incorrectos. Hibernate necesita entidades mutables, y Kotlin te empuja hacia la inmutabilidad.”

La diferencia es evidente para un lector humano. Pero también lo es para Google (que evalúa señales de experiencia en el texto) y para los modelos de IA (que prefieren citar contenido específico sobre contenido genérico).

Cómo demostrar experiencia en el contenido

• Mencionar decisiones concretas y su contexto. “Elegimos FastAPI porque el equipo ya tenía scripts Python que necesitábamos exponer como API.”
• Incluir errores y aprendizajes. “El primer intento con coroutines y @Transactional no funcionó porque las transacciones de Spring no son suspendables.”
• Mostrar código real, no teórico. Snippets que podrían estar en un proyecto de verdad, con manejo de errores, edge cases y comentarios sobre por qué se hizo así.
• Dar opiniones fundamentadas. “MockK es mejor que Mockito para Kotlin, y lo digo después de usar ambos durante meses. La razón principal es el soporte nativo de clases final.”

Datos y ejemplos concretos: lo que permite ser citado

Los modelos de IA citan contenido que contiene datos específicos, comparativas verificables y respuestas directas a preguntas comunes. El contenido vago o teórico rara vez se cita.

Ejemplo de contenido vago:

“FastAPI es más rápido que Spring Boot en muchos escenarios.”

Ejemplo de contenido citable:

“Un servicio FastAPI con uvicorn arranca en 1-2 segundos, consume ~50MB de memoria en reposo y la imagen Docker pesa ~150MB. El equivalente en Spring Boot arranca en 5-15 segundos, consume ~200MB y la imagen pesa ~250MB.”

El segundo ejemplo contiene datos concretos que un modelo de IA puede extraer y presentar como respuesta factual. Google puede usarlo para un featured snippet. Un lector lo lee y obtiene información útil directamente.

Las tablas comparativas son especialmente efectivas:

Una tabla bien construida es uno de los formatos más citados por modelos de IA y más usados por Google para rich snippets. Pero la tabla tiene que contener datos reales, no relleno.

Schema y structured data: la capa técnica

Los datos estructurados (Schema.org) no hacen que tu contenido sea mejor, pero ayudan a Google a entenderlo y presentarlo correctamente. Para modelos de IA que usan búsqueda web (como Perplexity o ChatGPT con browsing), la claridad semántica del contenido también puede influir en qué se cita.

Article / TechArticle

El schema básico para un blog técnico. Incluye autor, fechas, descripción y tema:

{
  "@context": "https://schema.org",
  "@type": "TechArticle",
  "headline": "FastAPI para automatizaciones internas",
  "author": {
    "@type": "Person",
    "name": "Roger Bosch",
    "url": "https://oshy.tech/about"
  },
  "datePublished": "2026-05-18",
  "dateModified": "2026-05-18",
  "description": "Cuándo tiene sentido usar FastAPI para herramientas internas...",
  "inLanguage": "es"
}

FAQ

Si tu artículo responde preguntas concretas, el schema FAQ puede generar resultados enriquecidos en Google y facilitar que los modelos de IA extraigan respuestas:

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Cuándo usar FastAPI en vez de Spring Boot?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "FastAPI es mejor opción cuando necesitas integrar con scripts Python existentes, el proyecto es una herramienta interna con ciclo de vida corto, o necesitas un prototipo rápido."
      }
    }
  ]
}

HowTo

Para artículos que explican procedimientos paso a paso (configuración, deployment, debugging), el schema HowTo es relevante:

{
  "@context": "https://schema.org",
  "@type": "HowTo",
  "name": "Cómo configurar Spring Boot con Kotlin",
  "step": [
    {
      "@type": "HowToStep",
      "name": "Configurar plugins de Gradle",
      "text": "Añade kotlin-spring, kotlin-jpa y kotlin-allopen al build.gradle.kts..."
    }
  ]
}

No hace falta poner todos los schemas en todos los artículos. Usa TechArticle siempre, FAQ cuando hay preguntas y respuestas claras, y HowTo cuando el artículo es un procedimiento.

FAQs: preguntas que la gente realmente busca

Las FAQs dentro de un artículo técnico no son un truco SEO. Son una forma de responder directamente las preguntas que alguien podría hacer en Google o en ChatGPT. La clave es que las preguntas sean reales, no inventadas.

Cómo encontrar preguntas reales:

• Google Autocomplete. Escribe el tema en Google y mira qué sugerencias aparecen.
• People Also Ask. Las preguntas relacionadas que Google muestra en los resultados.
• Search Console. Las queries reales que llevan tráfico a tu sitio.
• Stack Overflow. Las preguntas frecuentes sobre el tema.
• La propia experiencia. Qué me preguntó mi equipo cuando implementamos esto? Qué busqué yo cuando estaba aprendiendo?

Una FAQ útil en un artículo sobre Spring Boot con Kotlin podría ser:

Se pueden usar data classes como entidades JPA?

Técnicamente sí, pero no es recomendable. Las data classes generan equals() y hashCode() que incluyen todos los campos, lo cual causa problemas con lazy loading y con el ciclo de vida de persistencia de Hibernate. Es mejor usar clases normales para entidades JPA y reservar las data classes para DTOs.

Esa respuesta es directa, técnica, basada en experiencia y citable. Un modelo de IA puede extraerla y presentarla como respuesta. Google puede mostrarla como featured snippet. Un lector que tenía esa duda la resuelve inmediatamente.

Evitar contenido generado sin criterio

Hay que abordar el elefante en la habitación. Con herramientas de IA generativa, es posible producir artículos técnicos a un ritmo mucho mayor que antes. Pero el volumen sin criterio es exactamente lo que el Helpful Content System de Google está diseñado para penalizar.

El problema no es usar IA como herramienta. Yo uso IA para revisar borradores, generar esqueletos de código y buscar información. El problema es publicar contenido generado por IA sin que pase por el filtro de la experiencia real.

Un artículo generado por IA sobre “Spring Boot con Kotlin” va a cubrir los mismos puntos que otros 500 artículos: configuración, ventajas, ejemplo básico. Lo que no va a tener es la experiencia de haber peleado con JPA y data classes durante semanas, o de haber decidido dejar las entidades en Java y migrar solo los servicios. Eso es lo que diferencia contenido útil de contenido de relleno.

Las señales que delatan contenido sin criterio:

• Explicaciones genéricas que no dicen nada que no esté en la documentación oficial
• Ausencia de opinión o decisión justificada
• Código de ejemplo que es el mismo que aparece en el “getting started” del framework
• Estructura predecible: introducción, lista de ventajas, lista de desventajas, conclusión
• Falta de errores o problemas reales (nadie aprende algo sin encontrar problemas)

El test que uso: si borras el nombre del autor y el del sitio, se podría identificar quién lo escribió por el contenido? Si no, probablemente no tiene suficiente voz propia.

Qué funciona en la práctica

Después de analizar qué artículos de oshy.tech han funcionado mejor (en tráfico orgánico, en tiempo de lectura y en citas por modelos de IA), los patrones son consistentes:

1. Artículos que resuelven un problema concreto posicionan mejor que artículos que explican un concepto genérico. “Cómo recuperar la contraseña de n8n” funciona mejor que “Qué es n8n”.

2. Artículos con código real y errores documentados tienen más engagement que artículos teóricos. La gente busca soluciones a problemas que están teniendo ahora mismo.

3. Artículos con estructura escaneable (headings descriptivos, párrafos cortos, tablas comparativas) retienen mejor al lector que bloques largos de texto.

4. Artículos que toman una posición (“MockK es mejor que Mockito para Kotlin”) generan más interacción que artículos neutrales que presentan opciones sin opinar.

5. Artículos con datos concretos (tiempos, tamaños, métricas) se citan más que artículos con afirmaciones vagas.

Nada de esto es sorprendente. Es sentido común aplicado a la escritura técnica. Pero es fácil olvidarlo cuando estás pensando en keywords y en optimización.

La convergencia real

Lo más interesante de todo esto es que las tres audiencias (personas, Google, modelos de IA) convergen en lo mismo. Todas quieren contenido que sea:

• Claro y bien estructurado
• Basado en experiencia real
• Con datos concretos y verificables
• Con autoría identificable
• Que resuelva problemas reales

No hay un truco para “optimizar para ChatGPT” que sea diferente de escribir buen contenido técnico. No hay una meta tag secreta para que Perplexity te cite. La mejor estrategia de GEO es la misma que la mejor estrategia de SEO, que es la misma que la mejor estrategia para que personas reales lean y compartan tu contenido: escribir cosas útiles, con criterio, desde la experiencia.

La tecnología que consume tu contenido cambia. Los algoritmos de ranking evolucionan. Los modelos de IA mejoran. Pero la base no cambia: contenido claro, honesto y basado en experiencia real siempre encuentra su audiencia. Lo demás es optimización marginal.