GEO: How to Get ChatGPT and Perplexity to Cite Your Site

People no longer type three words into Google and pick from ten blue links. They ask ChatGPT, Perplexity or Google’s AI Overview, get one synthesized answer and, if they’re lucky, two or three cited sources underneath. If your site isn’t among those sources, it doesn’t exist. It doesn’t matter that you rank third in the classic results: the model never shows them.

That’s the question that matters now. Not “how do I rank,” but how do I get a generative engine to cite me. Optimizing for that scenario is called GEO (generative engine optimization), and although it shares foundations with traditional SEO, the rules change enough that it deserves its own discipline. This article is what I apply, on this very portfolio and on client projects, to make the answer yes.

What GEO is and how it differs from classic SEO

Traditional SEO optimizes for a ranker: an algorithm sorts URLs and the user chooses. GEO optimizes for a reader-synthesizer: an LLM reads, understands, summarizes and decides whom to attribute what it says. Three practical consequences:

• The click is no longer the main goal. The goal is the citation: that your brand or your name appears in the answer and, if there’s a link, that it’s yours. A mention without a click already builds authority.
• The model doesn’t “see” your pretty CSS. It consumes plain text and structured data. Whatever it can’t cleanly extract and reword, it ignores.
• Trust becomes explicit. An LLM tends to cite sources it can verify: with an identifiable author, credentials, dates and checkable facts. That’s where E-E-A-T (experience, expertise, authoritativeness, trustworthiness) becomes an operational criterion, not a slogan.

GEO doesn’t replace SEO: it extends it. You still need to be crawlable, to load fast, and to ship semantic HTML, exactly the foundation I argue for in fast websites with Astro. On top of that foundation, GEO adds three layers: access for AI, machine-readable structure, and trust signals.

llms.txt: the file that tells AI what to read

Just as robots.txt guides search crawlers and sitemap.xml gives them the index, llms.txt is an emerging convention for guiding models: a Markdown file at the root of the domain (/llms.txt) that summarizes what your site is and where the good information lives, without forcing the model to guess between menus, banners and footers.

The idea is to offer a curated, plain-text version of what matters. A reasonable skeleton:

# Alberto Guinda — AI Engineer & Full-Stack Developer

> I take AI systems to production: computer vision (YOLOv8),
> LLM agents and digital twins (BIM + GIS) on critical infrastructure.

## Projects
- [RecruitSecure AI](/en/projects/cv-finder-ai): semantic candidate
  search, 100% on-device AI in the browser, GDPR by design.
- [DevFlow AI](/en/projects/devflow-ai): suite of 20 developer tools
  with an LLM provider chain and fallback.

## Contact
- Email and form at /en/#contact

Two honest caveats so I’m not selling smoke:

• Uneven adoption. A file existing doesn’t obligate anyone to read it. Support for llms.txt across providers is still partial, and it’s best treated as a low-cost, high-optionality bet, not a silver bullet.
• Zero marginal cost. On a statically generated site like this one (Astro at build time), publishing /llms.txt is just one more endpoint regenerated alongside the content. The risk of doing it is nil; the risk of skipping it is being left out if the convention catches on.

Meanwhile, what every crawler does read today is your HTML. And that’s where the real wins are.

Schema.org: speaking to AI in its own language

An LLM crawling your page appreciates being handed the facts already structured instead of having to infer them from the layout. JSON-LD with schema.org is exactly that: a block of machine-readable data that states, without ambiguity, who you are, what you offer and what backs you up. For a professional portfolio, three types do almost all the work.

Person + hasCredential: your verifiable identity

The Person type declares the entity behind the site, and the hasCredential property links formal credentials, a direct E-E-A-T asset. Instead of the model “guessing” that you hold a master’s degree, you state it in structure:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "Alberto Guinda Sevilla",
  "jobTitle": "AI Engineer & Full-Stack Developer",
  "knowsAbout": ["Computer Vision", "LLM Agents", "Digital Twin", "BIM/GIS"],
  "hasCredential": {
    "@type": "EducationalOccupationalCredential",
    "credentialCategory": "degree",
    "name": "Master's in AI Development"
  },
  "sameAs": [
    "https://github.com/albertoguinda",
    "https://www.linkedin.com/in/albertoguindasevilla/"
  ]
}
</script>

sameAs is key: it connects your identity on the site with your public profiles, which helps the model consolidate entities (understanding that the Alberto on the portfolio, on GitHub and on LinkedIn are the same person) and trust the attribution more. The certifications page of this portfolio exists in part to feed that chain of credentials.

FAQPage: answers ready to cite

FAQPage marks up question-answer pairs. It’s arguably the format a generative engine finds easiest to reuse, because it already comes in its natural unit: a question and its self-contained answer. If you write your FAQs as short, complete and verifiable answers, you’re serving the model the exact snippet it would want to cite.

The detail that makes the difference: consistency

Schema cannot contradict what the user sees. If the JSON-LD says one thing and the visible text says another, you not only lose the benefit: you risk a penalty for deceptive markup. The rule is simple: structured data describes the real content, it doesn’t dress it up.

Extractable content: writing so the machine understands

Here’s the part no tag fixes for you. A generative engine cites best the content it can extract as self-contained snippets. Patterns I apply when writing:

• Answer the question in the first sentence of the block. No three paragraphs of context before the fact. The model, and the hurried reader, want the answer up top, then the elaboration. It’s the inverted-pyramid principle carried into the AI era.
• Headings that are questions or clear statements. An H2 like “What is llms.txt?” or “Schema.org: speaking to AI in its own language” tells the model exactly what that section resolves. An H2 like “Reflections” says nothing.
• Concrete facts over adjectives. “100% on-device AI in the browser with Transformers.js” gets cited; “innovative and powerful solution” gets discarded. Verifiable facts are the fuel of trust.
• Snippets that survive copy-paste. Every important paragraph should make sense pulled out of context, because that’s exactly how an LLM is going to use it.

This connects with something I already argued about practical RAG in Spanish: a good retrieval system chunks the corpus into clean, self-contained fragments. When you write for GEO, you’re doing that work up front for the models that will crawl you. Your well-structured page is a pre-chunked corpus.

E-E-A-T: why AI trusts some sources and not others

An LLM, like a human editor, prefers to attribute to whoever seems to know what they’re talking about. The signals you can make explicit:

• Experience (the first E, the new one). Show that you’ve actually done what you describe. I don’t write about LLM fallback chains in the abstract: I built one in DevFlow AI and in this portfolio’s own AI terminal. “I did it” carries more weight than “this is how it’s done.”
• Expertise. Identified author, bio, credentials linked via hasCredential. Text signed by a verifiable entity is more citable than a wall of anonymous content.
• Authoritativeness. Inbound links, mentions, consolidated profiles with sameAs. Authority is built off your site as much as on it.
• Trustworthiness. Visible dates (pubDate), cited sources, HTTPS, and the honesty of saying “this isn’t settled yet,” as I just did with llms.txt. A text that acknowledges its limits is, paradoxically, more trustworthy.

The trap to avoid: E-E-A-T can’t be faked with tags. You can declare hasCredential in the schema, but if the content doesn’t demonstrate real expertise, the effect dilutes the moment the model cross-checks signals. Structure amplifies substance; it doesn’t replace it.

The GEO stack, at a glance

For a site that wants to be cited by generative engines in 2026, this is the order of priorities as I’d apply it, from highest to lowest return:

1. Semantic, fast HTML. Without a crawlable base, nothing else matters. Static Astro is an ideal starting point.
2. Schema.org JSON-LD: Person + hasCredential, FAQPage, and whatever types fit your content. Always consistent with what’s visible.
3. Extractable content: answer-first, question-headings, concrete facts, self-contained snippets.
4. Explicit E-E-A-T: authorship, linked credentials, sameAs, dates, honesty.
5. llms.txt: a cheap bet on the future, at no cost if you already build the site at build time.

What’s good about this order is that the first four points also improve your classic SEO. You’re not betting against Google to win on Perplexity: you’re building a base that serves both. The fifth is pure optionality.

Want AI to cite your site, not your competitor’s?

GEO is where SEO and AI engineering meet, and that’s exactly my ground: I understand how an LLM reads, retrieves and attributes, and I know how to translate that into schema.org, extractable content and site architecture. If you want a GEO audit of your site, or to build it from scratch so generative engines cite you, let’s talk.