Optimizing for SEO, AEO, GEO, and AI Search in 2026
I took one site from 14.5 MB to 1 MB and watched the agentic browsing score go from 67 to 100. Most of what AI search rewards is embarrassingly old-fashioned.
Originally published at agnelnieves.com.
My homepage weighed 14.5 megabytes and took 43 seconds to paint its largest element on a mid-range phone. I found this out the same week I sat down to make the site ready for AI search, which turned out to be a useful coincidence, because the single biggest thing you can do for AI visibility in 2026 is the same thing you could have done for Google in 2015: make the site fast, structured, and honest.
This is the audit I ran on my own site, with the numbers each fix bought. The full playbook with every command is on my site. What follows is the part that transfers to yours.
SEO, AEO, GEO: what the letters actually buy you
The acronyms read like three strategies. They are one strategy with three layers.
SEO is the base: indexable pages, clean metadata, fast loads, working links. AEO, answer engine optimization, is SEO plus structured answers: content organized so a model can quote a specific, correct chunk of it. GEO, generative engine optimization, is AEO plus machine-readable discovery for engines that are not Google: feeds, llms.txt, IndexNow, explicit crawler permissions.
You do not pick one. Each layer assumes the one below it. A site with perfect llms.txt files and a 14 MB homepage has built the roof before the foundation, which is exactly what I had done.
What Google says NOT to do
Google published actual guidance on AI search readiness, and the most useful part is the prohibition list. There is no special markup for AI Overviews or AI Mode. They use the same index as classic Search. Google explicitly advises against chunking your content into Q&A shards, rewriting prose to sound machine-friendly, piling on structured data beyond what earns a rich result, and chasing inauthentic backlinks.
Read that list again, because half the "AEO services" being sold right now are on it.
The scoreboard
One Lighthouse run on the mobile homepage, before and after.
| Metric | Before | After |
|---|---|---|
| Performance | 63 | 73 |
| Accessibility | 95 | 100 |
| Agentic browsing | 67 | 100 |
| Largest Contentful Paint | 43.2 s | 5.9 s |
| Speed Index | 6.2 s | 3.6 s |
| Total page weight | 14,561 KiB | 1,008 KiB |
A 93% weight cut and an 86% LCP improvement, and not one of the fixes was clever.
The fixes, in order of pain
Discoverability first. My Search Console verification record lived in the wrong DNS host, so Google could not verify the domain. One TXT record in the right place fixed it. Then I set up IndexNow with a tiny script and a GitHub Action that pings Bing only when blog content changes. Bing matters more than it used to: it feeds ChatGPT's web search, Copilot, and DuckDuckGo. IndexNow turns "indexed within days" into "indexed within hours."
Accessibility doubles as agent legibility. A components-level bug was rendering a fresh h1 for every project card, my canvas-dithered images were announcing empty alt text, and the logo link had no accessible name. That last one alone was worth 5 accessibility points and 33 agentic browsing points, because an agent walking the accessibility tree hit an unnamed link as the first interactive element on every page. One aria-label="Home" took both scores to 100. The accessibility tree is the interface agents actually read. Treat it like a public API.
Performance was two embarrassing assets. A 3.3 MB background music MP3 loaded eagerly on every route, for a feature most visitors never turn on. Lazy-instantiating the audio on first toggle removed it from the critical path, and re-encoding the file itself, mono, 64 kbps, cover art stripped, cut it to 1.1 MB. Then the photos: fourteen JPEGs at 500 KB to 1.1 MB each, displayed at 400 pixels wide. Re-encoded to AVIF at the display size they went from 10.5 MB to 113 KB. That is a 99% reduction with no visible difference. Another 28 thumbnails went from 1.16 MB to 91 KB the same way.
The stragglers: a modernized browserslist dropped 14 KB of polyfills nobody needed, the new LCP element got a priority hint, and a render-blocking Typekit stylesheet that served zero fonts got deleted. Every codebase has one of those.
What I deliberately did not do
No FAQPage or HowTo schema bolted onto pages that are not FAQs or how-tos. The five types I already ship, WebSite, Person, BlogPosting, BreadcrumbList, and CreativeWork, match the content; anything more is maintenance debt with no measured upside. No rewriting posts to sound machine-friendly: the blog reads like a human wrote it because a human does. And no third-party AEO submission services, which are the 2024 era equivalent of directory spam.
I also kept my llms.txt route while removing the inline copy from the page head, since Google confirmed it does not read the format and other engines only need the route. Promptway itself still ships the inline block for the engines that do read it. Reasonable sites can disagree here; the route is the part that matters. The content side of that stack is covered in the eight-layer guide.
The takeaway
There is no secret AI search lane. AI Overviews, AI Mode, ChatGPT browsing, Perplexity: they all reward the same boring fundamentals, just with less patience for bloat and broken semantics than human visitors have. If your site is fast, indexable, well structured, and useful, it is already AI search ready. Mine was not, and the gap was 13.5 megabytes of avoidable weight and one unlabeled link.
Run the audit on your own site before you buy anything. If the numbers come back like mine did, the fix list will write itself. And if you want the agent to run the whole thing for you, the audit my agency does over MCP shows what that looks like on the paid side.
Read next
Prompt Lab · 9 min read
The Constraint Goes First
Everyone writes prompts top-down: role, context, task, then a stack of rules at the end. That's the bug.