SEO, AEO and GEO for a Developer Portfolio: What Works

A developer portfolio has two readers now: a person who searches Google, and an assistant that reads the web on that person's behalf and writes a paragraph with a few links under it. This site is built for both. Below is what I actually changed, why, and where the evidence is thinner than the industry makes it sound.

#Three acronyms, one foundation

SEO ranks a page in a list. AEO tries to get one answer lifted out of the page. GEO tries to get the page cited inside text an AI assistant generates. The tactics overlap far more than the vocabulary suggests, and Google's own guidance on AI features is blunt about it: a page must be indexed and eligible to show with a snippet, there are no additional technical requirements, no special schema.org markup, and no need for new AI-specific files.

Read the 40% figure carefully. It comes from a research benchmark of generative engines, not from a measurement of your site, and it is a ceiling for the best method on that test. I use it as a reason to try the cheap changes, not as a forecast.

#Step 1: let the crawlers in

Nothing else matters if the fetch fails. Three separate things can block it: robots.txt, the CDN or firewall in front of the host, and rendering. On this site, Hostinger's CDN once answered GPTBot with a 429 even though robots.txt allowed it, which is why I check logs rather than trusting the file. The fix lives in the host settings, not in the code.

OpenAI documents three agents as independent settings, which means the policy can be granular.

This site's robots.txt names the AI user agents explicitly and allows all of them. That is a visibility decision for a personal brand, not advice for a publisher with paywalled work.

#Step 2: serve real HTML

Googlebot can render JavaScript, but it queues pages for rendering, and Google itself says server-side or pre-rendering is still a good idea because not all bots run JavaScript. Many AI fetchers read the raw response only. This site is a React 19 and Vite app, and the build renders every route to static HTML, so the first byte already contains the headline, the body, the FAQ and the JSON-LD. A related note covers how the prerender step works.

#Step 3: write answer-first

An assistant lifts passages, not pages. A passage works when it can stand alone: it names its subject, states the claim in the first sentence and carries its own number. Each post on this site opens with a lead that says what the post covers, uses question-shaped headings where the reader would have asked that question, and ends with an FAQ whose answers are complete without the surrounding article.

• Put the answer in the first sentence under a heading, then the evidence.
• Name the thing every time. "It" and "this approach" do not survive being copied out of context.
• Attach each number to a dated, linked source, so the claim is checkable.
• Keep one claim per sentence in the places you hope to be quoted.

#Step 4: structured data that matches the page

Google's guidance says structured data should match the visible text. Every block here is generated from the same data that renders the page, so it cannot drift: Person and WebSite on the home page, BlogPosting with citations on each post, FAQPage built from the visible FAQ, and BreadcrumbList. The person node lists the alternate name "D. Dinesh" because that is how the Springer chapter credits me, and that link between two names is the kind of entity fact a crawler cannot guess.

faq: [
  { q: "Should I block GPTBot in robots.txt?",
    a: "That depends on whether you object to training use..." }
]

#Step 5: the optional machine-readable files

The llms.txt proposal is a markdown file at /llms.txt with an H1 name, a blockquote summary, link lists and an optional section. This site generates it at build time from the same data as the pages, along with a full-text companion, a sitemap and an RSS feed. I want to be straightforward about the status: Google says it is not needed, and I am not aware of a published guarantee from any assistant vendor that it changes citations. It is cheap, it is generated, and it makes the site easy to summarize, so it stays. It is not where the effort goes.

#Step 6: keep it fresh and verify

Publishing cadence and honest modified dates are the last inputs. The sitemap here derives lastmod from real content changes, because stamping every URL with the build date teaches crawlers to ignore the field. After each deploy: fetch the page with a plain HTTP client and confirm the content is in the response, request indexing in Search Console, and read the server logs for the crawlers you care about.

#Related notes

• Prerender a React 19 and Vite Site for SEO, No Next.js