SEO, AEO, and GEO: The Technical Foundations That Actually Matter
Discipline
What it optimizes for
What success can look like
Primary question
SEO — Search Engine Optimization
Visibility in search results and qualified visits to your site
A recipe, guide, or product page is crawled, indexed, ranked, and
clicked
Can the right person find this page in search?
AEO — Answer Engine Optimization
Clear, extractable answers to a specific question or task
Your content supplies a featured answer, spoken response, summary,
or direct solution
Can a system identify and deliver the best answer?
GEO — Generative Engine Optimization
Visibility, accurate representation, and citation in AI-generated
responses
Your expertise is retrieved, understood, cited, or used to shape a
synthesized answer
Can a generative system understand, trust, and use this source?
Search is no longer a single results page.
A person looking for dinner may type a few words into Google, ask a
long question in an AI assistant, use voice search while standing in the
kitchen, search inside a retailer’s app, or follow a recommendation
assembled from several sources. The interfaces are changing quickly. The
technical foundation beneath them is not changing nearly as much.
These are different discovery lenses, but they don't require three
separate content strategies. They depend on the same core conditions.
You need a system that must be able to access the page, understand what
it contains, connect it to related information, evaluate the source, and
find something worth returning.
For food creators, that doesn't mean producing three versions of
every recipe or stuff pages with every variation of a question. For
food-tech teams, it doesn't mean adding “AI optimization” as one more
disconnected workflow. It means fixing the shared infrastructure and
then formatting each page for its real intent.
SEO helps you get found. AEO helps you answer. GEO helps your work be
understood and trusted within a generated response. None of them can
compensate for content that is inaccessible, ambiguous, disconnected,
generic, or technically broken.
SEO,
AEO, and GEO overlap, but they are not interchangeable
SEO is the most established of the three disciplines. Its job is
broader than rankings. It includes making pages accessible to crawlers,
helping search engines interpret them, matching content to search
intent, earning authority, and creating a useful experience after
someone clicks.
AEO narrows the lens to questions and tasks. The goal is to make the
answer easy to locate and understand. For food content, the question may
be more explicit—“Can I freeze pesto?”—or embedded in a task—“What can I
substitute for pine nuts in pesto?” An answer-ready page doesn't bury
the response beneath six paragraphs of scene-setting. It gives a direct
answer, then supplies the conditions, exceptions, and evidence a reader
needs.
GEO focuses on generative systems that retrieve information from
multiple sources and synthesize a response. A generative answer may cite
your page, paraphrase it, combine it with other sources, or omit it
entirely. That makes GEO more difficult to measure than a conventional
ranking. The foundational GEO research defined visibility within
generative responses, but later research has reinforced an important
caution: no single rewrite reliably produces lasting visibility across
every engine, query, and run. For a practical look at how this applies to
recipe sites and food platforms, read Generative
Engine Optimization for Food Creators..
All three disciplines ask versions of the same questions:
Can the system reach and render the content?
Can it identify the main topic, entities, and relationships?
Does the page satisfy a recognizable intent?
Is the answer supported by useful detail or evidence?
Is the source connected to a credible body of work?
Can a person use the page successfully?
The shared technical
foundation
SEO, AEO, and GEO use different discovery lenses, but they depend on the same foundation.
1. Crawlability and
indexability come first
If a crawler can’t access a page, optimization farther down the stack
has nothing to work with.
Start with the basics. The page should return a successful status
code, load reliably, use a stable canonical URL, and remain free of
accidental noindex directives. Important pages should be reachable
through standard HTML links, not only through a site search, a filter,
or a JavaScript interaction a crawler may not execute as expected.
Maintain an XML sitemap that contains the canonical, indexable pages
you actually want discovered. A sitemap is a hint, not a guarantee, and
it doesn't replace internal linking. It helps a crawler locate and
revisit pages, especially on a large archive, but a URL with no
meaningful route from the rest of the site still looks isolated.
Review robots.txt, CDN rules, firewalls, and bot-management settings
together. A robots file may appear open while a security layer returns a
challenge or blocks the request. Search crawlers, AI search crawlers,
and model-training crawlers can also be different agents with different
purposes. For example, allowing a crawler used for search doesn't
necessarily mean granting permission for model training. Make the access
decision intentionally instead of using a blanket rule you do not
understand.
For Google’s AI features, the company’s current guidance is unusually
straightforward. A page must be indexed and eligible to appear in Search
with a snippet. There is no separate technical doorway for AI Overviews
or AI Mode. Get ordinary search hygiene right before buying an “AI
visibility” shortcut.
2.
Accessibility makes the page more legible to people and machines
Accessibility and machine readability are not identical, but they
often reward the same good construction.
Use one descriptive H1, followed by a logical heading hierarchy.
Write meaningful link text. Add accurate alternative text when an image
conveys information. Use real lists for ingredients and steps, real
buttons for actions, and real tables only when readers need to compare
values. Make sure essential content is available in the rendered page
and not trapped inside an image, video, or interaction with no text
equivalent.
For recipes, accessibility also means usable instructions. “Cook
until done” may be short, but it is not very useful. “Bake until the
center reaches 165°F and the juices run clear, about 22 to 25 minutes”
gives a cook—and a retrieval system—observable criteria.
Semantic HTML supplies landmarks and relationships that visual design
alone can’t. It helps a screen reader navigate the page and gives
automated systems a clearer representation of the content. A beautifully
designed page with an incoherent document structure still creates
friction.
The simplest test is to remove the styling in your mind. Can someone
still tell what the page is, where the answer begins, what belongs to
the recipe, and what action comes next?
3.
Structured data describes the content; it doesn't rescue it
Schema markup is a machine-readable description of information
already present on the page. It can identify a page as a recipe, connect
it to its author, describe ingredients and instructions, or clarify
relationships among a person, organization, article, video, and
breadcrumb trail.
For food publishers, Recipe schema remains foundational. At minimum,
make sure the structured data accurately reflects the visible recipe:
name, image, author, dates, description, ingredients, instructions,
yield, prep and cook times, and other applicable properties. Use
HowToStep and HowToSection when they truthfully represent the method.
Validate the markup, then inspect the live URL because a plugin can
generate valid code from incomplete or inconsistent inputs. For a deeper
explanation of what recipe markup communicates—and what it can't
fix—read Recipe
Schema: The Backbone of Discoverable Food Content.
Don't confuse validity with quality. A recipe card can pass a test
while the page contains vague steps, inconsistent units, an inaccurate
yield, or substitutions that are mentioned in prose but not connected to
the ingredient they replace. Schema makes the label readable; it doesn't
make the underlying information reliable.
The same principle applies to FAQ markup. Google restricted FAQ rich
results primarily to authoritative government and health sites in 2023.
For most creator and food-brand sites, FAQ schema should be treated as
deprecated as a Google visibility tactic, even though the FAQPage type
still exists in Schema.org.
That doesn't mean removing useful questions and answers. Keep the
visible content. Format it around real reader intent.
That short answer block is useful to a reader and easy for a system
to extract. Follow it with nuance when needed. Don't repeat ten lightly
reworded questions, add schema to content that is hidden, or use QAPage
markup on a page where the publisher supplies the only answer. Google
reserves QAPage guidance for pages centered on one question with
user-submitted answers.
4.
Internal linking turns an archive into information architecture
A collection of URLs is not yet a content system.
Internal links show how individual pages belong to a larger subject.
A basil pesto recipe can connect to a guide to storing fresh herbs, a
pine-nut substitution article, a recipe-schema explainer, and a tested
collection of no-cook sauces. Those relationships help readers continue
their task. They also help crawlers discover pages and understand which
resources are central.
This is where a hub-and-supporting-article model becomes more than an
editorial calendar. The hub explains the landscape. Supporting pages go
deeper on a distinct question. Each supporting page links back to the
hub, and the hub links out using descriptive anchor text rather than
“click here.” Related pages link to one another only when the
relationship is useful.
5. Authority
must be visible on and beyond the page
Authority is a pattern of evidence.
Show who created the content, why that person is qualified to address
the subject, when the page was published or meaningfully updated, and
how the information was produced. For a recipe, useful evidence might
include original testing notes, process photographs, specific failure
points, sensory cues, and the reason a substitution works. For a
food-tech explainer, it may include product documentation, named
sources, a methodology, direct experience with a platform, or clearly
labeled analysis.
Connect author bylines to substantial author pages. Keep organization
information consistent. Cite primary sources where they exist. Earn
relevant mentions and links by publishing work other people genuinely
need to reference. These practices help conventional search evaluation
and give generative systems more corroborating context.
They also protect against a common GEO mistake: polishing a paragraph
to sound authoritative without improving the evidence underneath it.
6.
Useful, non-commodity content gives the system a reason to choose
you
Technical readiness creates eligibility, not distinctiveness.
A commodity answer can be reproduced from hundreds of pages: the
number of teaspoons in a tablespoon, a generic definition of sautéing,
or an untested list of substitutions assembled from other lists. It may
still serve a reader, but it gives a search or generative system little
reason to select your version.
Non-commodity content contains something grounded in your work. It
may be an observation from testing 12 batches of biscuits in a humid
kitchen. It may explain why a recipe behaves differently with natural
and Dutch-process cocoa. It may reflect cultural knowledge, a regional
technique, customer-support data, or a content model built from
thousands of recipes.
But not every page needs a complicated original study. It means the
page should contribute more than a rearrangement of what is already
available.
For creators, what do you know because you cooked, tested,
photographed, taught, or served this food?
For food-tech teams, What do you know because you operate this
product, observe this behavior, maintain this dataset, or support this
workflow?
Then make that knowledge explicit. The most valuable detail is often
trapped in someone’s head, a photo caption, a support ticket, or a
separate spreadsheet. AI readiness begins by moving it into the source
content with enough structure and context to be understood.
From ontology
to knowledge graph to context graph
These terms are sometimes treated as interchangeable, but they
describe different layers.
An ontology defines what can exist. A knowledge graph represents what is known. A context graph preserves why it matters.
An ontology defines the concepts and allowed
relationships in a domain. In food content, it might define Recipe,
Ingredient, Technique, Cuisine, DietaryPattern, and Appliance, along
with relationships such as “uses ingredient,” “requires technique,” or
“suitable for diet.” It is the model of what can exist and how those
things can relate.
A knowledge graph is an implementation populated
with actual entities and relationships. “This pesto uses basil,” “basil
is an herb,” and “this recipe is authored by Sandie” are instances
within the model. In shorthand, the ontology provides the rules; the
knowledge graph represents the known what.
A context graph is an emerging, less standardized
idea that preserves the circumstances around information and decisions:
the why, for whom, under what conditions, based on
which evidence, and at what time. A recipe platform may know that a user
selected a dairy-free substitute. A context graph can help retain that
the substitution was chosen because of an allergy, for a specific recipe
version, after a particular test, and with an approved confidence
level.
Why does this matter for discovery? Because the same fact can produce
a bad answer when its context is missing. “Use coconut milk instead of
cream” is not universally helpful. The result depends on the dish,
flavor expectations, fat content, allergy requirements, and desired
texture.
Most creators don't need to build a graph database. They do need to
preserve relationships and reasons in their content model. Connect
substitutions to the ingredient and use case. Attach testing notes to
the correct recipe version. Distinguish verified facts from suggestions.
Record who approved a change and when. Information architecture
describes the landscape; structured relationships help systems move
through it; context helps them avoid flattening every answer into a
universal rule.
Intent-driven
formatting for food content
Formatting should follow the job the reader is trying to
complete.
Answer-ready does not mean writing for robots. It means making the answer easier for everyone to find.
A person searching “chicken safe temperature” needs a direct,
safety-conscious answer with an authoritative source. Someone asking
“why is my banana bread gummy?” needs diagnostic branches. A person
looking for “weeknight vegetarian meals for two” needs a curated set
with useful constraints. One template can't serve all three intents
equally well.
Use these patterns deliberately.
Definition intent: State the definition in one or
two sentences, then explain boundaries and examples.
Yes-or-no intent: Lead with yes, no, or “it
depends,” followed immediately by the controlling condition.
Substitution intent: Name the substitute, ratio,
suitable uses, and expected change in flavor or texture.
Troubleshooting intent: Organize by symptom, likely
cause, and corrective action.
Comparison intent: Use a real table with consistent
criteria.
Process intent: Use ordered, observable steps with
timing, temperature, and completion cues.
Recipe intent: Keep ingredients, quantities, yield,
timing, steps, and safety information structurally distinct.
Short answer blocks are not keyword-stuffing containers. Write the
question once in the language a reader would naturally use. Answer it
clearly. Then add the experience and context that make the answer
trustworthy.
What SEO, AEO, and
GEO look like in the code
The hybrid approach in this section was inspired by a talk from
content strategist Rahel Anne Bailie and her work at Content Seriously.
I have adapted the model here to show how the same food content can
support search visibility, direct answers, and generative discovery
without becoming three separate pieces of content.
Consider CaribbeanPot’s Green
Scotch Bonnet Pesto Shrimp recipe. The source information
remains the same in the following examples. What changes is the
discovery function being emphasized.
The source information stays the same. The discovery function being emphasized changes.
SEO example:
clarify the page and earn the click
The SEO layer gives crawlers and readers a consistent description of
the page. The title tag, meta description, canonical URL, H1, and
opening copy all reinforce the same subject and search intent.
<head>
<title>Green Scotch Bonnet Pesto Shrimp Recipe |
CaribbeanPot</title>
<meta name="description"
content="Make spicy Green Scotch Bonnet Pesto Shrimp with garlic,
lemon, parsley, and shell-on shrimp for extra flavor and a plump,
juicy texture.">
<link rel="canonical"
href="https://caribbeanpot.com/green-scotch-bonnet-pesto-shrimp/">
</head>
<main>
<article>
<h1>Green Scotch Bonnet Pesto Shrimp</h1>
<p>This Green Scotch Bonnet Pesto Shrimp pairs the natural
sweetness
of shell-on shrimp with spicy pesto, garlic, smoked paprika,
lemon,
and parsley.</p>
</article>
</main>
This markup helps a traditional search system understand what the
page is, which URL is authoritative, and how the result can be
presented. It doesn't replace useful recipe content; it accurately
labels that content.
AEO example: make
the answer easy to extract
The AEO layer organizes visible content around the questions a cook
is likely to ask. Each answer appears immediately after its question,
followed by only the context needed to act safely and confidently. This
works without FAQ schema.
<section aria-labelledby="shell-on-shrimp">
<h2 id="shell-on-shrimp">Why leave the shells on the
shrimp?</h2>
<p>Keeping the heads and shells on contributes flavor and helps
protect
the shrimp from overcooking, allowing them to remain plump and
juicy.</p>
</section>
<section aria-labelledby="cook-pesto-shrimp">
<h2 id="cook-pesto-shrimp">How do you cook Green Scotch Bonnet
Pesto Shrimp?</h2>
<ol>
<li>Cook the garlic in oil over low heat for about 25
seconds.</li>
<li>Add the shrimp and increase the heat to
medium-high.</li>
<li>After two minutes, stir in the pesto and cook for another
two minutes.</li>
<li>Turn off the heat and finish with parsley and lemon
juice.</li>
</ol>
</section>
<section aria-labelledby="ventilation">
<h2 id="ventilation">Do you need to ventilate the
kitchen?</h2>
<p>Yes. Scotch bonnet peppers can create strong fumes when the
pesto
reaches the heated oil. Open a window, use the exhaust fan, or cook
outside.</p>
</section>
The questions use ordinary language, the first sentence answers
directly, and the steps preserve sequence. That makes the passage useful
to readers, site search, voice interfaces, and systems assembling short
answers.
GEO example:
make provenance and context legible
There is no special “GEO tag” that guarantees inclusion in a
generated answer. The useful work is to expose authorship, dates, source
identity, claims, and relationships clearly enough to evaluate. Recipe
structured data can reinforce those signals.
<article>
<header>
<h1>Green Scotch Bonnet Pesto Shrimp</h1>
<p>By <span rel="author">Chris De La
Rosa</span>,
Caribbean culinary curator and cookbook author.</p>
<time datetime="2018-11-07">Published November 7,
2018</time>
</header>
<section aria-labelledby="recipe-context">
<h2 id="recipe-context">About this recipe</h2>
<p>Chris De La Rosa developed this dish as a
Caribbean-inspired
fusion recipe. It is not presented as a traditional Caribbean
recipe.</p>
</section>
<section aria-labelledby="technique-context">
<h2 id="technique-context">Why this method works</h2>
<p>The heads and shells contribute flavor and help protect the
shrimp
from overcooking. The pesto is added after approximately two
minutes,
followed by another two minutes of cooking.</p>
</section>
</article>
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Recipe",
"@id":
"https://caribbeanpot.com/green-scotch-bonnet-pesto-shrimp/#recipe",
"url":
"https://caribbeanpot.com/green-scotch-bonnet-pesto-shrimp/",
"name": "Green Scotch Bonnet Pesto Shrimp",
"datePublished": "2018-11-07",
"author": {"@type": "Person", "name": "Chris De La Rosa"},
"publisher": {"@type": "Organization", "name": "CaribbeanPot"},
"mainEntityOfPage": {
"@type": "WebPage",
"@id":
"https://caribbeanpot.com/green-scotch-bonnet-pesto-shrimp/"
}
}
</script>
The visible copy establishes the origin and limits of the claim. The
JSON-LD connects the recipe, author, publisher, and canonical page.
Neither guarantees citation, but together they reduce ambiguity and make
verification easier.
Hybrid
example: one page, three discovery functions
A production page should not publish three competing versions. It
should combine accurate search metadata, answer-ready sections, visible
provenance, complete recipe details, and matching structured data in one
coherent implementation.
<head>
<title>Green Scotch Bonnet Pesto Shrimp Recipe |
CaribbeanPot</title>
<meta name="description"
content="Make spicy Green Scotch Bonnet Pesto Shrimp with garlic,
lemon, parsley, and shell-on shrimp for extra flavor.">
<link rel="canonical"
href="https://caribbeanpot.com/green-scotch-bonnet-pesto-shrimp/">
</head>
<main>
<article>
<header>
<h1>Green Scotch Bonnet Pesto Shrimp</h1>
<p>By <span rel="author">Chris De La
Rosa</span></p>
<time datetime="2018-11-07">Published November 7,
2018</time>
<p>A Caribbean-inspired fusion of shell-on shrimp, spicy
pesto,
garlic, smoked paprika, lemon, and parsley.</p>
</header>
<section aria-labelledby="why-shells">
<h2 id="why-shells">Why leave the shells on the
shrimp?</h2>
<p>The heads and shells add flavor and help the shrimp stay
plump
and juicy during the short cooking time.</p>
</section>
<section aria-labelledby="method">
<h2 id="method">How to cook the shrimp</h2>
<ol>
<li>Cook the garlic in oil over low heat for about 25
seconds.</li>
<li>Add the shrimp and increase the heat to
medium-high.</li>
<li>After two minutes, add the pesto and cook for two more
minutes.</li>
<li>Remove from the heat; finish with parsley and lemon
juice.</li>
</ol>
</section>
<aside aria-labelledby="pepper-safety">
<h2 id="pepper-safety">Ventilate the kitchen</h2>
<p>Open a window, run the exhaust fan, or cook outside
because
heated Scotch bonnet pesto can create strong fumes.</p>
</aside>
</article>
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Recipe",
"@id":
"https://caribbeanpot.com/green-scotch-bonnet-pesto-shrimp/#recipe",
"url":
"https://caribbeanpot.com/green-scotch-bonnet-pesto-shrimp/",
"name": "Green Scotch Bonnet Pesto Shrimp",
"datePublished": "2018-11-07",
"author": {"@type": "Person", "name": "Chris De La Rosa"},
"publisher": {"@type": "Organization", "name": "CaribbeanPot"}
}
</script>
</main>
The hybrid version lets each layer do its job. SEO helps the page get
found. AEO makes a precise answer easier to identify and reuse. GEO
strengthens the context and provenance that support evaluation and
citation. The reader still receives one clear, useful recipe page.
One technical
checklist for SEO, AEO, and GEO
Use this as one shared review rather than three disconnected
optimization passes.
Access and indexation
☐ The canonical page returns 200 OK and uses HTTPS.
☐ The page is not accidentally blocked by robots.txt, noindex,
authentication, a WAF, or a bot challenge.
☐ Canonical tags point to the intended version, and redirects do not
create chains or loops.
☐ The page is included in a clean XML sitemap when appropriate.
☐ Important content is present in rendered HTML and works without
requiring an unsupported interaction.
Structure and accessibility
☐ The page has one descriptive H1 and a logical H2–H3 hierarchy.
☐ Headings describe the content that follows rather than functioning
as decoration.
☐ Links use descriptive anchor text and standard crawlable HTML.
☐ Images that convey meaning have accurate alt text; video and audio
have appropriate text alternatives.
☐ Ingredients, steps, comparisons, and navigation use the correct
semantic elements.
☐ The page is usable on mobile and the main content is easy to
distinguish from ads and interface elements.
Content and intent
☐ The primary reader intent is explicit.
☐ A direct answer appears near each genuine question, followed by
necessary nuance.
☐ Instructions include observable cues, not only vague actions.
☐ Claims, safety guidance, and statistics are accurate and supported
by primary sources where possible.
☐ The page adds first-hand testing, original analysis, cultural
context, operational insight, or another non-commodity contribution.
☐ The title and description represent the page honestly without
repeating awkward keyword variations.
Structured data and entities
☐ Structured data describes content that is visible on the page.
☐ Recipe markup includes accurate required and applicable recommended
properties.
☐ Author, organization, article, image, video, and breadcrumb markup
are consistent with the site’s real entities.
☐ The markup passes the appropriate validator, and the live URL is
inspected after deployment.
☐ FAQ schema is not being used as a shortcut to rich results; QAPage
is used only for a genuine question page with user-submitted
answers.
Connections and authority
☐ The page links to its hub or parent topic and to genuinely useful
supporting pages.
☐ No important page is orphaned.
☐ Author and organization pages make relevant expertise and ownership
clear.
☐ External citations point to reliable original sources.
☐ Dates, bylines, review information, and material updates are
visible and accurate.
☐ Similar pages have a distinct purpose or have been consolidated to
avoid duplication.
Measurement and maintenance
☐ Search Console and analytics are configured to monitor indexation,
queries, landing pages, referrals, and conversions.
☐ AI referrals are tracked where the platform supplies them, without
treating referral traffic as the only measure of influence.
☐ Priority questions are tested periodically across relevant engines
and phrasing variations.
☐ Citations and summaries are checked for accuracy, not merely
presence.
☐ Pages are updated when facts, products, safety guidance, links, or
reader needs change.
☐ Technical checks are repeated after plugin, theme, CMS, CDN, or
site-migration changes.
Build one
foundation, then prioritize by goal
The right balance among SEO, AEO, and GEO depends on what you are
trying to accomplish.
If the immediate goal is qualified traffic to a recipe archive,
indexation, internal linking, page experience, Recipe schema, and
differentiated recipe content may deserve the greatest weight. If the
goal is customer support, direct answers, troubleshooting structures,
and accurate product context may matter more. If the goal is to become a
trusted source in AI-generated explanations, invest in original
evidence, entity clarity, external authority, and content that remains
understandable when retrieved outside its original page.
The techniques should interact rather than compete. One well-built
page can rank in a conventional result, supply a concise answer, support
a generative response, and help an internal search tool retrieve the
right information. That is the advantage of a hybrid model: not triple
the optimization work, but one source designed to serve multiple
discovery experiences intentionally.
Before chasing a new acronym, inspect the source.
Can systems reach it? Can people use it? Is the information
structured? Are the relationships clear? Is the author credible? Does
the page contribute something worth finding?
If the answer to those questions is yes, you are not only preparing
content for the search interface of the moment. You are building content
that can work in more places, adapt to new discovery systems, and remain
useful as the interface changes again.
Better discovery starts with stronger source content.
SEO, AEO, and GEO may shape different discovery experiences, but they
depend on the same foundation. Blueberri helps food creators and food-tech
teams build content that is accessible, structured, connected, credible,
and easier for people and systems to understand.
Identify technical and structural gaps affecting discoverability
Make food content answer-ready without keyword stuffing
Strengthen structured data, internal linking, authority, and source content
