GEO vs SEO: what carries over and what does not

GEO and SEO share a technical foundation but optimise for different outcomes. SEO earns a position in a ranked list of ten links that a user chooses from; GEO earns a sentence inside a single synthesised answer where there is no list and often no click. Most of your crawlability and structure work carries over unchanged. What changes is what you do at the top of the stack.

What is the same?

More than the framing of "GEO vs SEO" suggests. Both disciplines need:

• A page that returns HTTP 200 over HTTPS with a sane content type.
• Content present in the server HTML.
• One <h1> and a heading hierarchy that descends one level at a time.
• A self-referencing canonical URL.
• An XML sitemap, declared in robots.txt.
• Structured data describing what the page is.
• Fast loading and a page that works on a phone.

If your SEO fundamentals are in order, you have already done a large share of the GEO work. The audit categories in Envoyix reflect this: crawlability and structure are largely shared ground, while authority and content are where the disciplines diverge.

Where do they diverge?

| Dimension | Classic SEO | GEO | | --- | --- | --- | | The prize | A position in a list of links | Being the cited source inside one answer | | JavaScript | Googlebot renders it before indexing | Most AI crawlers read raw HTML only | | Unit of competition | The page | The passage, chunked and embedded | | Query shape | Short keyword phrases | Full natural-language questions | | Ranking signals | Links, relevance, page experience | Extractability, specificity, attribution | | Duplicate handling | Canonical consolidates ranking | Canonical decides who gets named | | Success metric | Clicks and position | Citation frequency and share of voice | | Failure mode | Ranking on page three | Being absorbed without attribution |

JavaScript is the sharpest difference

Googlebot has rendered JavaScript for years, which let a generation of client-rendered applications rank acceptably. The retrieval bots behind answer engines largely do not render. This means a single architectural decision — client-side rendering versus server-side rendering — can leave a site visible in Google and simultaneously invisible in ChatGPT and Perplexity.

The fix is the ordinary one: server-render or statically generate the main content. Next.js, Nuxt, Astro, Remix and plain server-rendered templates all satisfy it.

Retrieval competes on passages, not pages

An answer engine splits your page into chunks, embeds each one, and retrieves the chunks nearest the user's question. This changes what "optimising a page" means in a concrete way:

• A 300-word paragraph covering four ideas produces one muddy embedding that matches nothing strongly. Two to four focused sentences produce a chunk that matches its question sharply.
• A heading reading "Renewals" carries almost no signal. "How do I renew a passport?" sits close to the user's actual question in vector space.
• A sentence starting "It costs £88" loses its meaning once extracted. "A standard adult passport renewal costs £88" survives.

Attribution replaces ranking as the scarce resource

In SEO, ten sources can appear on one result page. In an answer, typically three to five are cited, and often only one is named in the sentence that matters. The signals that decide which source gets named — a real author, a dateModified, a publisher, links to primary sources, a canonical URL — are therefore worth considerably more attention than they get in a typical SEO checklist.

What should I actually change?

If you have a healthy SEO baseline, the GEO-specific work is roughly this:

1. Audit robots.txt for the AI bots specifically. A User-agent: * group that was fine for Googlebot may be blocking OAI-SearchBot by accident. Name the retrieval bots in their own groups so a later wildcard change cannot catch them.
2. Verify raw-HTML rendering. curl your own page and read the output.
3. Rewrite openings to answer first. Delete the throat-clearing introduction. The first sentence should define the subject.
4. Rephrase headings as questions. Aim for roughly 40% of your <h2>/<h3> headings to be the questions readers ask. Forcing every heading into a question reads badly; ignoring the pattern entirely wastes the signal.
5. De-pronoun your key sentences. Search for sentences beginning "It", "This" or "They" and name the subject instead.
6. Add figures and cite them. Replace "significantly faster" with a number and a source.
7. Add an FAQ block with FAQPage JSON-LD. Question-and-answer pairs are the single most retrievable structure on the web, because each one is already a self-contained unit.
8. Publish llms.txt and, optionally, llms-full.txt.

How do I measure it?

There is no Search Console for answer engines yet, so measurement is more manual:

• Server logs. Confirm OAI-SearchBot, PerplexityBot, ClaudeBot and friends are actually fetching your pages. If they are not, nothing downstream matters.
• Citation tracking. Ask the engines the questions your pages target and record whether you are named. Do it on a fixed schedule so the results are comparable.
• Referral traffic. Assistant referrals show up in analytics from hosts such as chat.openai.com and perplexity.ai. The volume is usually small relative to search; the intent is usually high.

Where to go next

• What is GEO? for the conceptual grounding.
• How to structure content for AI citations for the page-level mechanics.
• Run an audit to see where a specific page stands.