Reece blog photo

    SEO, GEO and AEO: What Front End Developers Actually Control

    • Digital Marketing
    • Websites & Apps

    Three acronyms are doing the rounds at the moment. SEO you already know. AEO and GEO are the newer two, and nearly everything written about them is aimed at marketers.

    Very little of it says anything about the build. Which is a shame, because a fair chunk of SEO, GEO and AEO comes down to decisions made on the front end, long before anyone writes a word of copy.

    So here’s the dev’s view of it.

    What the three actually mean

    Quick definitions, then the interesting part.

    SEO: Search engine optimisation. Getting pages to rank in a list of links. The one everyone’s been doing for twenty years.

    AEO: Answer engine optimisation. Getting your content used as the answer rather than as a result. Featured snippets, voice assistants, People Also Ask.

    GEO: Generative engine optimisation. Getting cited inside an AI-generated answer, whether that’s Google’s AI Overviews, ChatGPT, Perplexity or Claude.

    The three overlap far more than the acronym count suggests. Google says its AI features are “rooted in our core Search ranking and quality systems”, so most of what already worked still works.

    The interesting part is where they come apart. And they come apart hardest on rendering.

    Woman working on a laptop at a desk with printed reports beside her

    Google renders your JavaScript. Most AI crawlers don’t.

    Google is comfortable with JavaScript. Their AI optimisation guide says Google “is able to process content within JavaScript as long as it isn’t blocked”. Gemini runs on the same infrastructure, so AI Overviews and AI Mode see client-side rendered content without much difficulty.

    The other crawlers are a different story.

    Vercel analysed crawler logs in December 2024 and found GPTBot and ClaudeBot fetch JavaScript files but never execute them. They pull the .js down, treat it as plain text, and move on. Anything rendered client-side simply isn’t there as far as they’re concerned.

    Glenn Gabe ran hands-on tests in August 2025 and landed in the same place. ChatGPT told him outright that it couldn’t read a page because the content relied on JavaScript rendering. Perplexity and Claude returned the URL with no visible content at all.

    Both of those are a while ago now and crawler behaviour does change, so neither is gospel. The pattern has held up across independent testing for a long time though.

    Why it catches people out

    A site can look perfectly healthy in Search Console, rank well, appear in AI Overviews, and still be close to a blank page in ChatGPT. Nothing in standard reporting flags it, because standard reporting is built around Google.

    The gap tends to open up in the things bolted on after the main build. Tabs that fetch their content on click. Product listings loaded by AJAX. Review widgets pulled in from a third party. FAQ answers injected from JSON.

    That last one is the most frustrating, because FAQ content is exactly the sort of thing that gets quoted back in AI answers.

    IT technician working at an open server rack in a data centre

    Server-side rendering quietly became the deciding factor

    For years the argument for server-side rendering was mostly about performance and a bit about Googlebot being fussy. Googlebot stopped being fussy a long time ago, which took some of the urgency out of it.

    A second audience has now arrived with none of Google’s patience. If the HTML that leaves your server doesn’t contain the content, a decent share of AI crawlers will never see it.

    On a well-built WordPress site this mostly takes care of itself, because the markup arrives complete. On heavier JavaScript builds it’s a genuine architectural decision, and it’s one the front end team makes rather than the marketing team.

    Page structure decides what can be quoted

    Retrieval systems don’t read a page top to bottom the way a person does. They break it into chunks and pull whichever chunk best matches the question being asked.

    Headings are what define those chunks. A page with a clear hierarchy gives a model obvious places to cut. A page that’s one long undifferentiated block gives it nothing to work with, so it either quotes something clumsy or skips the page entirely.

    Which means the heading structure everyone was already supposed to be using has picked up a second job. It’s no longer only about outlining the page for a reader. It decides which parts of your content are liftable at all.

    None of this is new advice. The cost of ignoring it went up.

    Structured data is doing less than people claim

    Plenty of people are currently selling schema as the route into AI answers. Google’s own position is considerably more boring:

    “Structured data isn’t required for generative AI search, and there’s no special schema.org markup you need to add.”

    It’s still worth having. It earns rich results, it makes content machine-readable, and it gives search engines an unambiguous read on what a page is.

    Two developers reviewing code together on a laptop screen

    The case for llms.txt

    llms.txt turned up this year as a way of pointing language models at the pages that actually matter. It’s a markdown file at the site root listing your key URLs and what each one covers, so anything reading it gets a clean summary rather than working through the whole site.

    We’ve been adding them. It takes about ten minutes, there’s nothing to maintain beyond a new line when a significant page goes live, and a handful of documentation platforms and AI tools already read the format. If wider adoption does arrive, the file is sitting there ready instead of becoming a retrofit job across every site you look after.

    Worth being straight about the current state of it though. Google have said their systems don’t use it, and their documentation notes you don’t need to create “new machine readable files, AI text files, markup, or Markdown to appear in Google Search”. So it isn’t something to promise rankings on. It’s groundwork for where this is heading rather than a lever that does anything today.

    Speed still feeds into all of it

    Nothing exotic here, and this is front end SEO as it’s always been. Page experience feeds into ranking, ranking feeds into what gets surfaced in AI features, so the same work still pays off.

    The metric that’s changed is Interaction to Next Paint, which replaced First Input Delay as a Core Web Vital. It measures how long a page takes to visually respond once someone interacts with it, and it’s the one a lot of otherwise fast sites struggle with. Plenty of sites scoring well on load time score badly here, which is usually the first surprise of any website audit.

    Yellow fibre optic cables connected to a server patch panel

    Where that leaves the build

    Most of this is technical SEO that’s been good practice for years. Server-rendered markup, a sensible heading hierarchy, clean structured data, pages that respond quickly. The work hasn’t changed much.

    What’s changed is the audience. A second set of crawlers is now reading your markup, they’re considerably less forgiving than Googlebot, and they arrived without most people noticing.

    Which makes it worth understanding where the build sits before spending money on content that a chunk of them can’t read. That’s usually where our SEO team starts.

    Reece blog photo