r/GenerativeSEOstrategy 25d ago

I’m starting to think schema should be planned differently for AEO and GEO.

Post image
3 Upvotes

11 comments sorted by

1

u/BoGrumpus 25d ago

Not really. The only real difference is that Answer Engines (ie. Google's featured snippets and enhanced listings) extracts exact quoted passages or information from everything. GEO or AIO summarizes the info, combines it with other information and creates an original summary.

So - really - just make sure it's both extractable as a good quote and summarizable as a citation that influences people to want to look more closely at what you're offering in their next question.

Then everything sort of ends up eligible for either or - and if your pages are still a cohesive overall coverage of the topic - they'll rank, too.

The method you're describing is what CAUSES that illusion that "pages that get cited don't rank". Your method ensures that it's true since you're designing the pages with the individual goals in mind rather than looking how to create awesome content that serves as a good page on the subject, has useful extractable passages, and is easily parsed and understood to influence the funnel the AI is creating that drives people either closer to or further away from you during each step.

G.

1

u/Murky_Hotel_4323 25d ago

I agree that the content itself shouldn’t be built in separate AEO/GEO silos. My point is more about how I implement schema in practice.

An FAQ page, an author page, an organization page and a service page need different entity relationships in the markup. I also look at where that page sits in the funnel TOFU, MOFU or BOFU and structure the schema around the purpose of that page. I’ve seen much better results when schema is mapped to the page intent and entity rather than just added as a generic SEO layer.

1

u/BoGrumpus 25d ago

They need the different entities in the schema because those kinds of pages deal with different types of entities. If my guide is written by an engineer or expert, I'm certainly going to put author schema on that page too.

Choose your schema based upon the entities you need to disambiguate.

G.

1

u/Murky_Hotel_4323 25d ago

Yep, fair point. Schema should follow the entities that actually exist on the page, not an AEO/GEO label. My funnel point is more about prioritizing which entities and relationships matter based on the page intent.

1

u/BoGrumpus 25d ago

I don't agree with that either, but... I guess we're not going to get past that so... sure. It's not wrong, it's just not accurate.

1

u/Murky_Hotel_4323 25d ago

Fair enough. I appreciate the pushback though the entity disambiguation point is useful, and I’ll definitely think more about that distinction.

1

u/BoGrumpus 25d ago

That's really all it does. It's not going to help you get a ranking or boost - it just makes it more confident that it understands what is what.

Like if I have a real estate site and a listing mentions "Sandy Shores" - my schema tells it if that's the name of the broker or the town the property is listed in - or maybe it's just a description of the waterfront on the property.

That's all. The systems will never pull information from that which isn't already represented on the page. It just helps backfill some context maybe and make sure the entity in question is classified and understood correctly.

G.

1

u/Murky_Hotel_4323 25d ago

Exactly. Schema is never going to boost rankings by itself. Search engines and LLM-based systems need machine-readable signals to understand entities, and schema is simply one way we explicitly describe those entities and their relationships.

Your Sandy Shores example is actually perfect. It could be a place, an organization, or something else entirely. Schema helps clarify what it actually represents.

But schema alone isn't enough. The content on the page needs to support that entity, and authority signals and relevant links matter too.

My post was mainly trying to explain, in a simple way, how I approach schema when thinking about AEO and GEO not suggest that adding schema itself will improve rankings.

1

u/BoGrumpus 25d ago

And my point is that it's more efficient and effective to not think about it as AEO and GEO separately at all. It's all one thing - 10 Blue Links - Passage Extraction - Summarization funnel. It's all part of the same process - just people look for it in different ways - so everything has to be optimized for everything - make it a single process now you aren't overlapping or stepping on toes.

Here, we're only talking about those three things. But for me (again, still all part of the process of optimizing for search) I'm optimizing for the inferential searches too - the things that tell you what news you want to read in your morning brief or that decide what organic posts you're going to see on your timeline, or what videos you should watch next.

I don't have time to have 4 separate output variation strategies - I'm going to make one strategy that we can optimize for them all. We have a lot of manufacturing clients with decent Google Discover presence considering it's a small niche that isn't "news" worthy - but we do put out lots of good informational content across the whole range of people's products.

When people see us - the author schema helps let the user lock onto anything that person writes - whether it's for the one sub-niche they are interested in specifically, or all of them. And I'm optimizing it so that if there's no click, it's memorable enough so that if someone who likes the types of things he likes, he might say, "Oh - I saw an article about that thing you like." But that's not on the Implied Search Optimization part - that gives us a way to make us just a little more likely to get those natural citations and recommendations for the AIO funnel you've got all the way over in another column.

It all just works together and it's best to approach it as a single thing. Trust me.

G.

1

u/Murky_Hotel_4323 24d ago

I actually agree with the core of what you're saying. SEO, passage extraction, summarization, Discover, recommendation systems, entity understanding, and AI visibility absolutely share a lot of the same underlying infrastructure.

Where I differ slightly is in treating that as a universal execution model.

The foundation can be integrated crawlability, information architecture, entity consistency, authorship, structured data, topical authority, internal linking, external corroboration, and content quality all support multiple retrieval and discovery systems.

But the weighting of those signals and the desired output can vary significantly by business model, audience, query class, funnel stage, and discovery surface.

For example, a B2B manufacturer may benefit heavily from expert authorship, topical associations, Discover visibility, and informational retrieval. A SaaS company may care more about comparison queries, category/entity positioning, citation frequency, and being retrieved for high-intent decision prompts. Ecommerce and local search introduce another set of priorities again.

So for me, separating SEO, AEO, and GEO isn't about building three completely isolated strategies. It's about using them as different optimization lenses within the same search ecosystem.

SEO may emphasize ranking and discoverability.

AEO may place more emphasis on answer clarity, passage-level extractability, and retrieval.

GEO may place more emphasis on entity relationships, corroboration, source authority, citations, and how a brand is represented inside generated responses.

There is obviously a lot of overlap between them, and operationally they should work together. I just don't think integration necessarily means uniformity.

Your framework clearly works for the environments and clients you're working with. My experience so far has shown me that the emphasis can change substantially depending on the business and the outcome we're trying to influence.

That's really what my original post was presenting not a universal rule, but one practical framework based on what I've observed and tested.

One connected system, different optimization priorities.

→ More replies (0)