How to write technical content that works for Google, ChatGPT, and human readers

Since language models started answering technical questions directly, the obvious question for anyone maintaining a blog is: does it still make sense to keep writing? The short answer is yes, but not in the same way as before. The long answer is that technical content now has three simultaneous audiences: people who read, Google that indexes, and AI models that cite. And the interesting part is that all three want almost the same thing, though for different reasons.

I’m not going to sell the idea that there’s a magic formula for “optimizing for AI” as if it were a new discipline. What I’m going to explain is how to structure technical content that is genuinely useful, and why that turns out to work for all three audiences at once.

GEO: what it is and what it isn’t

GEO (Generative Engine Optimization) is a term that has started circulating as the “new SEO.” The idea is that, just as we optimize content for Google, we should optimize it for ChatGPT, Perplexity, Gemini, and other models that answer questions by citing sources.

There’s some truth to that. Language models do cite sources when generating answers, and there’s evidence that certain types of content get cited more than others. But there’s a lot of hype around the term.

What GEO is not:

• It’s not a discipline separate from SEO. The same principles of quality content, clear structure, and demonstrable experience that work for Google work for AI models.
• It’s not stuffing keywords for AI. Models don’t work like 2010 Google. They don’t index by keywords; they understand semantics.
• It’s not a technical trick. There’s no meta tag <meta name="ai-optimized"> that makes ChatGPT cite you more.
• It doesn’t require new tools. If your content is good for people and technically correct for search engines, it’s already well positioned for AI models.

What GEO actually is (when discussed seriously):

• Understanding that AI models consume web content as a training source and as real-time reference (RAG, integrated web search).
• Structuring content so it’s easy to extract and cite: clear answers, concrete data, verifiable claims.
• Maintaining authorship and credibility, because models tend to prefer sources with authority signals.

If you write clear, well-structured technical content with real experience and verifiable data, you’re already doing “GEO” without needing to call it that.

Clear structure: the foundation that works for everyone

Content structure is probably the factor that most impacts all three audiences simultaneously. For a person, clear structure means they can find what they’re looking for without reading everything. For Google, it means it can understand the content hierarchy. For an AI model, it means it can extract relevant fragments to cite.

Headings as an informational skeleton

Headings (H2, H3) aren’t decoration. They’re the semantic skeleton of the article. A reader who scans should be able to read just the headings and understand what the article is about and what they’ll find in each section.

Bad example:

## Introduction
## Development
## Conclusion

Good example:

## What problem FastAPI solves that Spring Boot doesn't
## When Python's typing is enough and when it isn't
## Deploy time comparison: Docker vs serverless

Descriptive headings work as entry points. Google can show them as sitelinks in search results. ChatGPT can use them to navigate the content when looking for the answer to a specific question. A reader can scroll to the section they care about.

Short paragraphs with one idea each

Technical text paragraphs shouldn’t exceed 4-5 lines. This isn’t an aesthetic rule; it’s functional. A short paragraph with one clear idea is easier to scan, to index, and to extract as a quote.

When an AI model needs to answer “when to use FastAPI instead of Spring Boot,” it looks for a text fragment that contains that answer in a self-contained way. If the answer is diluted across a 15-line paragraph mixed with other ideas, it’s less likely to be cited correctly.

Summaries and explicit definitions

Blockquotes, definitions at the beginning of sections, and sentences that synthesize an idea are extremely useful for all three audiences.

If you’re explaining a concept, start the section with a clear definition or synthesis before elaborating:

Pydantic is Python’s data validation library that FastAPI uses internally to serialize and deserialize request/response bodies with typing.

That sentence can be cited verbatim by an AI model. Google can use it as a featured snippet. A reader sees it and knows whether the section interests them or not.

Real experience: why E-E-A-T matters more than ever

E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness) is the framework Google uses to evaluate content credibility. The first “E” (Experience) was added relatively recently and is the most relevant for technical blogs.

The question Google tries to answer is: has the person writing this actually used what they’re explaining?

Content without experience:

“Spring Boot is a popular framework for developing Java applications. It offers many advantages like automatic configuration and a broad ecosystem.”

Content with experience:

“After migrating a service from Java to Kotlin with Spring Boot, the first problem I encountered was that JPA entities with data classes generated incorrect equals/hashCode. Hibernate needs mutable entities, and Kotlin pushes you toward immutability.”

The difference is obvious to a human reader. But it’s also obvious to Google (which evaluates experience signals in the text) and to AI models (which prefer citing specific content over generic content).

How to demonstrate experience in content

• Mention concrete decisions and their context. “We chose FastAPI because the team already had Python scripts we needed to expose as an API.”
• Include mistakes and lessons learned. “The first attempt with coroutines and @Transactional didn’t work because Spring transactions aren’t suspendable.”
• Show real code, not theoretical code. Snippets that could be in an actual project, with error handling, edge cases, and comments about why things were done that way.
• Give well-founded opinions. “MockK is better than Mockito for Kotlin, and I say that after using both for months. The main reason is native support for final classes.”

Concrete data and examples: what makes content citable

AI models cite content that contains specific data, verifiable comparisons, and direct answers to common questions. Vague or theoretical content rarely gets cited.

Example of vague content:

“FastAPI is faster than Spring Boot in many scenarios.”

Example of citable content:

“A FastAPI service with uvicorn starts in 1-2 seconds, uses ~50MB of memory at idle, and the Docker image weighs ~150MB. The Spring Boot equivalent starts in 5-15 seconds, uses ~200MB, and the image weighs ~250MB.”

The second example contains concrete data that an AI model can extract and present as a factual answer. Google can use it for a featured snippet. A reader gets useful information directly.

Comparison tables are especially effective:

A well-constructed table is one of the formats most cited by AI models and most used by Google for rich snippets. But the table has to contain real data, not filler.

Schema and structured data: the technical layer

Structured data (Schema.org) doesn’t make your content better, but it helps Google understand it and present it correctly. For AI models that use web search (like Perplexity or ChatGPT with browsing), the semantic clarity of the content can also influence what gets cited.

Article / TechArticle

The basic schema for a technical blog. Includes author, dates, description, and topic:

{
  "@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

If your article answers concrete questions, the FAQ schema can generate rich results in Google and make it easier for AI models to extract answers:

{
  "@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

For articles that explain step-by-step procedures (configuration, deployment, debugging), the HowTo schema is relevant:

{
  "@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..."
    }
  ]
}

You don’t need to put every schema on every article. Use TechArticle always, FAQ when there are clear questions and answers, and HowTo when the article is a procedure.

FAQs: questions people actually search for

FAQs within a technical article aren’t an SEO trick. They’re a way to directly answer questions someone might ask on Google or ChatGPT. The key is that the questions should be real, not made up.

How to find real questions:

• Google Autocomplete. Type the topic in Google and see what suggestions appear.
• People Also Ask. The related questions Google shows in search results.
• Search Console. The actual queries driving traffic to your site.
• Stack Overflow. The frequently asked questions about the topic.
• Your own experience. What did my team ask when we implemented this? What did I search for when I was learning?

A useful FAQ in an article about Spring Boot with Kotlin might be:

Can you use data classes as JPA entities?

Technically yes, but it’s not recommended. Data classes generate equals() and hashCode() that include all fields, which causes problems with lazy loading and with Hibernate’s persistence lifecycle. It’s better to use regular classes for JPA entities and reserve data classes for DTOs.

That answer is direct, technical, experience-based, and citable. An AI model can extract it and present it as an answer. Google can show it as a featured snippet. A reader who had that question gets it resolved immediately.

Avoiding content generated without judgment

We need to address the elephant in the room. With generative AI tools, it’s possible to produce technical articles at a much higher rate than before. But volume without judgment is exactly what Google’s Helpful Content System is designed to penalize.

The problem isn’t using AI as a tool. I use AI to review drafts, generate code skeletons, and search for information. The problem is publishing AI-generated content without it passing through the filter of real experience.

An AI-generated article about “Spring Boot with Kotlin” will cover the same points as 500 other articles: setup, advantages, basic example. What it won’t have is the experience of fighting with JPA and data classes for weeks, or of deciding to leave entities in Java and only migrate the services. That’s what differentiates useful content from filler.

The signals that give away content without judgment:

• Generic explanations that say nothing beyond what’s in the official documentation
• Absence of opinion or justified decisions
• Example code that’s the same as what appears in the framework’s “getting started”
• Predictable structure: introduction, list of advantages, list of disadvantages, conclusion
• Lack of real errors or problems (nobody learns something without encountering problems)

The test I use: if you remove the author’s name and the site name, could you identify who wrote it from the content? If not, it probably doesn’t have enough of its own voice.

What works in practice

After analyzing which oshy.tech articles have performed best (in organic traffic, reading time, and AI model citations), the patterns are consistent:

1. Articles that solve a concrete problem rank better than articles that explain a generic concept. “How to recover the n8n password” performs better than “What is n8n.”

2. Articles with real code and documented errors get more engagement than theoretical articles. People search for solutions to problems they’re having right now.

3. Articles with scannable structure (descriptive headings, short paragraphs, comparison tables) retain readers better than long blocks of text.

4. Articles that take a position (“MockK is better than Mockito for Kotlin”) generate more interaction than neutral articles that present options without giving an opinion.

5. Articles with concrete data (times, sizes, metrics) get cited more than articles with vague claims.

None of this is surprising. It’s common sense applied to technical writing. But it’s easy to forget when you’re thinking about keywords and optimization.

The real convergence

The most interesting thing about all of this is that the three audiences (people, Google, AI models) converge on the same thing. They all want content that is:

• Clear and well structured
• Based on real experience
• With concrete and verifiable data
• With identifiable authorship
• That solves real problems

There’s no trick to “optimize for ChatGPT” that’s different from writing good technical content. There’s no secret meta tag to make Perplexity cite you. The best GEO strategy is the same as the best SEO strategy, which is the same as the best strategy for getting real people to read and share your content: write useful things, with judgment, from experience.

The technology that consumes your content changes. Ranking algorithms evolve. AI models improve. But the foundation doesn’t change: clear, honest content based on real experience always finds its audience. Everything else is marginal optimization.