Eoin
McGee

Most operators treat GEO and AEO as interchangeable. They are not. Understanding the distinction is the difference between being cited by AI and being invisible to it.

GEO — Generative Engine Optimisation is about entity authority. When a user prompts ChatGPT, Perplexity, or Claude with a question, these systems synthesise answers from sources they deem authoritative. GEO is the practice of becoming one of those sources — structuring your content, schema, and entity signals so that generative engines cite you in their outputs.

AEO — Answer Engine Optimisation is about structured answer capture. AEO targets featured snippets, People Also Ask boxes, voice search responses, and knowledge panels in traditional search engines. It's about formatting your content so that the answer layer of search — not just the blue links — surfaces your information directly.

Why conflating them fails you: GEO requires deep entity provenance — JSON-LD schema, consistent brand signals, citation across trusted sources. AEO requires concise, question-formatted content with clear headers and structured data. Optimising only for one leaves you exposed in the other layer.

The DR approach: Build entity authority first (JSON-LD Person/Organisation/WebSite graph, consistent NAP signals, sameAs cross-linking). Then layer AEO-formatted content — short declarative answers, FAQ schema, H2s that mirror search intent. Both layers compound. Neither works alone.

If you're not doing both, you're not visible in the AI search layer. That layer is where buying decisions increasingly begin.

Meta tags are a whisper. JSON-LD is a declaration. If you want generative engines to know who you are, what you do, and why you should be cited — you need to inscribe it in machine-readable structured data, not hope it gets inferred from page copy.

What JSON-LD actually does: It embeds a structured graph of entities — Person, Organisation, WebSite, Product, Article — directly into your HTML in a format designed for machines. Search engines and AI crawlers parse this graph to build their internal model of who you are, what you offer, and how you relate to other entities on the web.

The @graph pattern: The most powerful implementation is a connected @graph — multiple entity types linked via @id references. A Person entity linked to an Organisation entity linked to a WebSite entity creates a coherent provenance signal. Each link reinforces the others.

What most operators get wrong: They either skip JSON-LD entirely, implement it incorrectly (missing @id interlinking, wrong @type, no sameAs cross-references), or treat it as a one-time checkbox rather than a living architecture that grows with their content.

The minimum viable schema stack: Person (@id, name, jobTitle, knowsAbout, sameAs) + Organisation (@id, name, founder, sameAs) + WebSite (@id, potentialAction SearchAction). That's the foundation. Add Article schema to every content piece. Add Product schema to every offer.

This site has the full @graph implemented. It's not an accident — it's the provenance architecture that tells every generative engine exactly who built this, what they specialise in, and why they should be cited.

Most passive income frameworks fail at the same point: they're built on a single tactic with no system behind it. A Pinterest pin, a Gumroad product, an email list — none of these work in isolation. The architecture is what makes them compound.

The DR passive income stack has four layers:

1. Traffic (Pinterest): 24 custom pins across 4 visual styles, scheduled daily. Each pin links to a Carrd landing page — not directly to the product. The landing page pre-sells and captures email before the Gumroad click.

2. Landing (Carrd): A single-purpose page with one CTA. No navigation. No distractions. The only action is to click through to the product or enter an email. Split-tested headline variants run continuously.

3. Product (Gumroad + Etsy simultaneously): Gumroad captures returning brand audience. Etsy captures cold search traffic. The same product listed on both platforms doubles exposure with zero additional work. Three pricing tiers — Starter Pack, Creator Kit, Empire Kit — give every buyer an entry point.

4. Email (Brevo): Every lead captured goes into a 5-email nurture sequence. Email 1: deliver the lead magnet. Email 3: introduce the Starter Pack. Email 5: present the Creator Kit. No hard sell. Just progressive value delivery.

The system runs without daily input once the pins are scheduled and the sequences are live. That's the definition of leverage.

A dental clinic, aesthetic practice, or medical centre has one consistent problem: the phone doesn't get answered at 11pm, but patients are searching at 11pm. An AI agent solves this without hiring a receptionist.

What the agent does: Answers service questions. Qualifies leads based on procedure interest and location. Books consultations directly into the calendar. Follows up with unbooked leads automatically. Handles objections using your clinic's actual language and pricing.

The build stack: Claude API (or GPT-4) as the reasoning layer. Trained on a custom knowledge base of your services, FAQs, pricing, and patient journey. Integrated with Calendly or Google Calendar for booking. Deployed via website chat widget (Tidio or custom) and optionally WhatsApp Business API.

The acquisition math: A clinic seeing 200 website visitors per month with a 2% booking rate gets 4 consultations. The same clinic with an AI agent converting at 8–12% gets 16–24 consultations. Same traffic. Quadrupled output. The agent pays for itself in the first booked procedure.

What the DR ebook covers: The full build — from knowledge base construction to system prompt architecture to widget deployment. Not a tool manual. A build guide for clinic owners who want to do it themselves or hand it to their team.

This is the highest-leverage AI implementation available to service businesses right now. Most clinics don't know it exists.

The average independent operator is running 12–16 tools. Most of them do the same thing with different branding. The result is tool debt — monthly subscriptions, context switching, and maintenance overhead that eats the time you were trying to save.

The three-layer model: Every independent operation needs exactly three layers: Income, Traffic, and Conversion. Each layer needs one primary tool. Not three. One.

Income layer: Gumroad (digital products) or Stripe (services/SaaS). One checkout system. Everything flows through it. No split between PayPal, Wise, and three other processors.

Traffic layer: One platform you own the output on. Pinterest for visual/evergreen content. Reddit for community and authority. LinkedIn for B2B. Pick one. Master it. Add the second only when the first is systemised.

Conversion layer: One landing page tool (Carrd or Netlify), one email system (Brevo — free to 300/day), one form handler (Formspree). That's it. The DR operation runs on exactly this stack.

What to cut immediately: Any tool that duplicates a function you already have covered. Any subscription you haven't logged into in 30 days. Any platform that requires daily manual input with no automation path.

Simplicity isn't a constraint. It's the system. The operators who scale fastest are almost always running fewer tools, not more.