I launched a new site, waited a few weeks for Search Console feedback, and was pleased to see my pages indexed on Google, complete with rich results. That first success came with a clear message: if I kept adding content the traditional way, I'd get bogged down repeating the same tasks—adding schema, writing TL;DR summaries, updating author details, and so on. And those optimisations had to work not just for SEO, but for AEO and GEO as well.

Off-the-shelf automation tools are great, but I wanted something that fit my setup and let me guide the process firsthand. So I turned every required step for a new page into a mix of templates, reusable components, and small bits of automation.

This post walks through the build. I'll cover the search signals that matter now—ranking, answering, and trust; explain how I wired them into each page, and show where the automation still needs work. If you're tired of copying the same optimisation snippets, or you need a future-proof workflow, take whatever ideas help. You'll see a few Google and schema-validator hiccups, some blunt lessons, and a plan for taking the system further.

The New Search Rulebook

Three Layers of Search Discovery - SEO | AEO | GEO

In a nutshell: SEO gets the page discovered, AEO pulls a clear answer into the result itself, and GEO convinces both users and large-language-model (LLM) assistants that the information is reliable. My templates wire all three signals into every page, so new content ships with discovery, answerability, and trust already baked in.

Why SEO Suddenly Feels More Dynamic

Search is no longer a single list of blue links. On some queries, Google pushes out an AI Overview, Perplexity crafts a paragraph with citations, and ChatGPT serves up code or buying advice inside the chat.

From my understanding of how these LLM-driven search experiences work, there are two broad types of search intent to prepare for:

  • Exploratory or "What / Why / How" searches. The user wants knowledge. LLMs summarise the web for them, quoting sources that expose clear entities, concise answers, and verifiable credentials.
  • Transactional or navigational searches. The user wants to buy, compare, or reach a specific brand. Classic ranking factors—speed, relevance, backlinks, structured offers—still rule, but generative snippets now tee up product specs, reviews, and pricing tables.

This dynamic setup means that a site can no longer just rely on getting the basics right once. Search behavior—and search formats—are evolving rapidly. That's why I wanted control over how the important elements (titles, schema, summaries, metadata) are included on every page. Not through another application, but through a setup I understand, can tweak, and can rewire quickly when needed. Moreover, the website is built on plain PHP, CSS, and JS, making the WordPress plugin environment inaccessible.

1. SEO — Get Found

This is where I start. Every page has PHP placeholders for <title>, meta description, H1/H2 structure, canonical tags, and any additional metadata I want to use. These variables are editable directly in the page code. So, instead of rewriting boilerplate SEO for every new page, I simply insert the relevant content where needed and reuse the structure.

If I want to, I can use a GenAI model to draft these pieces and then fine-tune them before updating the PHP file. It saves time, gives me full control, and keeps things consistent. For blog posts, there's also a built-in mechanism to show related articles—once I set the variable with a list of relevant slugs, the section renders automatically.

I currently manage sitemap updates and page publishing through Claude's code generation, which works smoothly with templated prompts. This process is evolving—moving from basic templates to partial and eventually complete automation. Many of these tasks will likely become fully automated in the coming months.

2. AEO — Give Answers That Can Be Quoted

AEO, or Answer Engine Optimisation, is about giving search engines or AI assistants the confidence to lift a sentence or structure from your page and use it directly in a response.

Each page on my site has a dedicated TL;DR section included via a PHP variable. It's a summary—usually around 50–60 words—that distills the page's core message or insight. I compose it myself or get a first draft from an LLM, tweak it as needed, and update the variable. It then appears at a fixed spot on the page, above the fold, and is easy to find.

The TL;DR section uses clear, consistent language that makes it easy for LLMs to detect and reference. Throughout the content, I also structure lists and explanations in a quote-friendly format, both visually and structurally. When I write additional Q&A on the page, the converter turns it into FAQ styled JSON-LD behind the scenes and pushes it to the live page on the fly. Other Schemas and Rich Snippets are automatically generated by a PHP framework while the page loads.

While this approach is only partially automated, it's fully templated. This streamlines content creation while maintaining clarity.

3. GEO — Build Trust from the Start

If SEO gets the page seen and AEO gets the content surfaced, GEO—Generative Engine Optimisation—is what tells an assistant: this source is credible enough to reuse. That includes trust signals like who wrote it, what organisation is behind it, and whether there are any third-party endorsements or ratings.

Every page on my site references structured schema entities for myself (as the author) and my brand. These are linked consistently using the @id format across schema blocks—so whether it's a blog post or a service page, it's clear who created the content and how it's related to the rest of the site.

The author bio (with my name, role, and LinkedIn link) is pulled from a reusable PHP partial. I only have to update it once if I ever want to make changes across the site. In case of testimonials or feedback, I include Review schema where appropriate—again, set up as a template so I can plug in real quotes when available.

This structure means I don't need to add GEO signals from scratch on every page—they're already part of the template, just waiting to be filled in.

Why does this matter?

The search landscape is volatile and can change without warning. What works today might need revision next month as new schema properties emerge, AI citation patterns evolve, and rich-result layouts transform. By integrating these elements directly into my PHP templates and workflow, I avoid dependency on rigid plugins or platforms.

This flexibility allows for swift adjustments. When Google rolls out a new trust signal or AI Overviews adopt different methods for extracting author information, I can simply modify one template section, and all new pages automatically inherit the change.

While not fully automated, the system is fast, modular, and—most importantly—adaptable and automation-ready. That was the goal from day one.

Building Blocks for Discoverability

While exploring how AEO and GEO fit into the evolving search landscape, I made several key observations about creating content that's answerable, trustworthy, and well-structured for modern search. Rather than discovering a single comprehensive framework, I found recurring elements that proved consistently valuable. These components are worth templating for any content-rich site, whether you choose to automate them fully or simply make them easier to implement during content creation.

I gained these insights through extensive conversations with several AI assistants, including ChatGPT, Gemini, Claude, and Perplexity, along with lots of Google research.

1. Entity Schema (Start with the Who and What)

One of the clearest takeaways was the importance of entity-level clarity. That is: does a page identify what it's about, who it's by, and how it connects to other known things on the web?

This is where schema comes in. Whether it's a blog post, a service page, or a profile, the schema should declare things like:

  • @type: is this a Person, Organization, Article, FAQPage?
  • @id: a persistent identifier (usually a URL) that links to the "source of truth" for that entity
  • sameAs: links to external profiles (e.g., LinkedIn, YouTube) to help validate identity

What is clear is that entity clarity is foundational to both AEO and GEO. Without it, LLMs have a harder time linking your content to a credible source, even if the writing itself is good.

2. TL;DR or Summary (Lead with the Answer)

One of the more practical patterns that came up was the role of a TL;DR or just a short, direct answer block at the beginning of a page.

This isn't about clickbait intros or clever hooks. It's about surfacing the actual takeaway right away, in clear, unambiguous language. Think of it like this: if your page were going to be quoted in an AI Overview, this is the sentence you'd want quoted.

Here's what stood out from my digging:

  • Short summaries near the top increase the chances of your content being selected for featured snippets or AI-generated answers.
  • When consistently formatted, these summaries are easier for LLMs to extract and reuse.
  • AEO doesn't require you to use a specific tag, but structure and clarity matter.

3. FAQs (Still Relevant, Now Also Machine-Friendly)

FAQs have long been part of SEO playbooks. What I learned through these conversations is that they're just as useful, if not more so, in the age of answer engines.

But the framing shifts a bit.

Instead of cramming in keyword-rich filler questions, the focus is on:

  • Real user queries (things someone might ask)
  • Structured format (question + direct, standalone answer)
  • Schema support (FAQPage or even QAPage, depending on context)

Treat FAQs almost like an API for your page—each Q/A pair is a hook that lets a search engine or assistant understand a different entry point into the topic. It's not about volume, it's about coverage and clarity.

4. Author and Review Signals (Trust Layer)

This is where GEO starts to differ from traditional SEO. In SEO, it was enough to show expertise. In GEO, you have to prove it—and not just to users, but to algorithms that make trust-based decisions.

Based on the back-and-forth I had:

  • Pages should identify the author, with a name, role, and link to a verifiable profile (like LinkedIn).
  • If there are testimonials or reviews, marking them up properly with Review or Rating schema adds an extra layer of credibility.
  • Consistency across pages matters—reuse the same identifiers (@id, sameAs) so search engines know it's the same person or org behind the content.

This isn't just a best practice anymore. It's becoming a requirement for inclusion in AI-generated responses.

5. Structured Media (Because AI Looks at More Than Text)

A key theme emerged across different discussions: don't treat your media as invisible. Modern AI systems and search engines analyze everything from image metadata to video objects, file names, and their contextual structure.

Here are the essential takeaways:

  • Use the ImageObject schema for visuals, particularly when they contain important information.
  • Write meaningful alt text that describes the image—avoid generic labels like "image" or "banner."
  • When including video content, implement VideoObject schema and consider providing a transcript.

Think of media not as mere decoration but as another layer of structured information. This is particularly valuable for AEO, where visual elements can enhance summaries and answer cards.

Claude, ChatGPT, Gemini & Perplexity: Same Goal, Different Roads

When I peppered four major language models with the same SEO-for-AI questions, their advice converged on the usual suspects—structured schema, a punchy TL;DR, solid E-E-A-T. Yet the way each model found information, ranked pages, and decided what to quote could not have been more different. Understanding those quirks may help us to fine-tune where to spend energy.

Four search lenses, four processes

Claude's playbook starts with web_search, powered by Brave's index. It submits a focused keyword query and receives up to 10 results (including titles, URLs, and snippets), reading only the text that Brave provides. If a snippet seems insufficient, or if given a specific URL, it switches to web_fetch to retrieve the page's raw HTML directly. The system strips away all scripts and styles, processing only plain text. Claude reportedly reads the entire page before creating his answers. After retrieving content, it performs a rigorous schema validation—any pages with missing @id links or disorganized nesting are immediately disqualified from consideration.

ChatGPT follows a streamlined path: a web tool call followed by quick analysis.

First, the tool sends your query to an OpenAI service, which connects to partner search APIs—currently Bing. It receives a collection of links, headlines, and plain-text snippets, with Bing's ranking signals already weighing authority and freshness. For promising snippets, it makes an open call to fetch the raw HTML, seeing only what a logged-out browser would see, without JavaScript or paywalled content. Pages that load their main content through AJAX appear empty to the system.

ChatGPT then examines multiple sources, not just the top result, comparing them for consistency before crafting a summary in its voice. While Bing's rankings shape the initial selection, ChatGPT's processing determines the final output: it filters out thin content, and even lower-ranked pages can earn citations if they offer the most precise explanation.

Gemini doesn't wander far for information—it piggybacks on the same real-time Google index that feeds AI Overviews. When you ask a question, it first classifies your intent: exploratory queries (using "how," "why," or "what") lead it toward sources from Google's Overviews and knowledge panels, while commercial queries (containing "buy," "hire," or "best near me") direct it to Shopping units, local packs, and review-rich listings. This intent classification influences how Gemini re-ranks results beyond Google's default order.

The model relies heavily on Google's snippets, avoiding deep fetches when possible. It examines the first visible text block—title tag, meta description, and opening paragraph—to make a quick assessment: does the page offer a concise answer and display credible signals like author name, date, and recognizable domain? If so, Gemini cites the URL directly; if not, it moves on without a second look. Pages that prominently display E-E-A-T signals—named authors with credentials, recent update dates, and clear organization schema—receive a subtle advantage, while lengthy articles that bury their main points tend to get overlooked.

The upshot is that Gemini favors pages that answer questions quickly and already hold strong positions in Google's live index.

Perplexity's pipeline is noticeably more aggressive than the others. It starts by breaking down your question into several narrower sub-queries, often sending them simultaneously to a mix of partner search APIs and its lightweight crawler. That crawler retrieves the complete HTML (excluding scripts) for each promising URL and conducts a readability analysis, allowing the model to access the entire article, not just a snippet. Once half a dozen pages are gathered, Perplexity's LLM cross-checks dates, figures, and claims, flags any discrepancies, and retains the version that seems most consistent across sources. The answer it provides is compiled from those reconciled facts, with every sentence footnoted to the exact paragraph it originated from. Since this process emphasizes unique data points and side-by-side comparisons, pages that contain original research, statistics, or explicit "X vs Y" breakdowns tend to appear more frequently than generic overviews.

What does that mean for a site like mine?

  1. Index coverage is step one. A page absent from Brave won't exist for Claude; if it's missing from Bing, then ChatGPT never sees it. If it's missing from Google Search, Gemini won't see it. Same content, four visibility outcomes.
  2. The snippet matters. Brave strips pages to text, Bing lifts just the target paragraph, Google skims the opening lines, and Perplexity ingests nearly everything. If the first 150 words don't include a clear entity, answer, or credential cue, one or more assistants will pass you over.
  3. Schema/FAQs/TL;DR remains the universal handshake. Once any of them fetch a page, consistent @type, @id, and author data greatly increase the likelihood that they will cite or summarize your content. TL;DR makes it easy for all of them. FAQs assist in answering user questions. Claude views schema as a gate pass; Gemini considers it a trust badge; Perplexity and ChatGPT use it as a tie-breaker when sources appear equal.
  4. Bias is inherited. None of these models overrides their search partner's ranking logic. They amplify it. High-authority domains climb higher; thin or new sites fight uphill.

How I'm using these insights

The traditional SEO best practices still matter. I adhere to several of these, plus new ones that may improve my chances of getting cited:

  • Entity schema, TL;DR, and author bio live in every template—easy to tweak if a search partner changes its taste.
  • Performance and crawl basics stay on a manual checklist until I'm confident all indexes pick up changes reliably.
  • FAQs have moved to the front row. Because large-language-model chats revolve around question-and-answer exchanges, pages that serve information in the same format are far more likely to surface. Make them a first-order element, not an afterthought.

That way, if Brave tightens its snippet requirements or Google rolls out yet another AI card, I fix a template once and ship—no plugin scramble, no mass rewrite.

The upshot? All four models care about the same fundamentals, but they arrive at them by four very different routes. My job is to make sure whichever road they take, they can't miss the signposts.

Automating and Templatizing the Steps

My "Schema Factory" in plain English

Think of my site as a magazine where every article ends with the same "About the author" box. I do something similar for search engines, but instead of a box, it's a block of hidden code called schema. The schema is what tells Google (and every AI assistant that relies on Google, Bing, or Brave) who wrote the page, what it's about, when it was published, whether it contains reviews, and so on.

Rather than re-writing that block by hand each time, I use a two-piece kit that lives in an /includes folder:

  1. schema-functions.php — the recipe book

    Inside are ready-made recipes for the common page types on my site. There's one for an everyday web page, one for a blog post, one for pages that hold testimonials, and so forth. Each recipe knows which ingredients it needs—title, date, TL;DR, FAQs, author name—and how to turn them into "search-engine speak" (JSON-LD).

  2. footer.php — the waiter

    This file is tacked onto the bottom of every page. When a visitor (or Googlebot) reaches the footer, the waiter looks at the kind of page it's serving.

    If the URL sits in /blogs/…, it hands the page's details to the blog recipe. For everything else, it calls a general web-page recipe. If I've added a list of customer quotes or FAQs higher up the page, the waiter slips those to the matching recipe, too.

The result: each finished page quietly leaves the kitchen carrying a perfectly filled schema card that may contain any or all of these elements, depending on what I provided:

  • Website & Web Page – the basic "who and where."
  • Author – pulls my bio once and re-uses it everywhere.
  • Blog Posting – adds headline, publish date, and reading time.
  • FAQPage – only appears if I drop in Q&A pairs.
  • Review / Testimonial – shows up when I paste real client praise.

If Google changes a field tomorrow, I will edit the recipe book once, and the whole site will update. If I launch a new "Case Study" section, I just write a new recipe, tell the waiter when to serve it, and the rest of my workflow stays the same. No copy-and-paste, no forgotten fields—just fill in the blanks and publish.

The schema-functions.php "recipe book" wasn't written from scratch by me alone. I prototyped it in a long back-and-forth with Claude:

  • We started with a plain JSON-LD draft; Claude flagged why Google's validator showed only three entities and walked me through untangling circular @id references and newline issues.
  • Next, it suggested turning hard-coded text (like the page TL;DR) into PHP variables to match the rest of my site architecture.
  • When the first version still spewed 30 warnings on Review markup, I shared the error log; Claude rebuilt the Review and AggregateRating blocks and added a clean-text helper to strip rogue line breaks.
  • Iteration by iteration, that dialogue produced the modular class system you see in the live file today.

The result is solid enough to ship, but far from "done." I want to keep a list of future tweaks, higher automation level, and more autonomous content detection for schema-building intelligence. The factory works now because Claude helped me debug and construct every detail; the next round of improvements will probably start the same way, with prompts, code improvements, human debugging, and best practices.

Auto-Writing the TL;DR

A concise summary is important for skimmers and for AI systems that quote the first clear answer they find. To make sure every page ships with one—and to avoid the "rewrite-trim-rewrite" treadmill—I built a tiny routine around a single variable, $tldr_text.

  1. Prompt, then polish

    After finishing the main copy, I hand Claude or ChatGPT the headline and three bullet highlights and ask:

    "Return a one-sentence TL;DR, active voice, no more than 60 words."

    The model's draft is usually 90% there; I tighten phrasing or tone in a few keystrokes.

  2. Drop it into $tldr_text

    Each template starts with an empty $tldr_text line. The moment I paste the summary there and hit save, two things happen automatically:

    The TL;DR appears in a styled box just below the H1. Spacing, font size, and mobile visibility are all handled by the shared CSS—no extra markup on my part.
  3. Built-in enforcement

    Every content template on the site expects that the $tldr_text field is filled—a gentle shove that forces whoever is publishing to write a one-sentence takeaway. After that single line is entered, the framework does the rest: the summary is dropped into its styled box under the headline, inherits the right font and spacing on every screen size, and requires no further code or markup from the author.

The result: one prompt, one copy-paste, and every page delivers an upfront answer that humans can scan and AI tools can quote, without bolting on extra widgets or remembering another checklist step.

Foundational SEO: Meta Tags on Autopilot

Before any schema or TL;DR appears, every page starts by loading includes/header.php.

This single file takes care of the unglamorous—but essential—SEO plumbing:

  • Title & meta description – pulled from $page_title and $meta_description. If you forget to set them, sensible defaults kick in.
  • Keywords – optional, yet templated the same way ($meta_keywords).
  • Open-Graph and Twitter tags – $og_title, $og_description, $og_image, $og_url, $og_type all share the same fallback logic.
  • Canonical URL – printed automatically, so duplicate-content headaches stay away.

All a writer has to do is define those variables at the top of the page file, exactly the way the homepage and the GA4-vs-UA blog post do:

// index.php
$page_title       = 'Funnelysis | SaaS Marketing and Google Analytics Services';
$meta_description = 'Funnelysis helps SaaS startups enhance…';
$og_image         = 'images/logo_funnelysis_white_dark.webp';
include 'includes/header.php';

// ga4-vs-ua.php
$page_title       = $blog_title . ' | Funnelysis';
$meta_keywords    = 'GA4, Google Analytics, SaaS Marketing…';
$meta_description = 'Explore Funnelysis\'s knowledge hub…';
include './includes/header.php';

Once header.php runs, the page leaves the server already armed with:

  • a correct <title> tag,
  • descriptive meta tags,
  • Complete social-share previews
  • and a canonical link pointing to itself.

No extra HTML, no manual copy-paste—set the variables, include the header, and the groundwork for classic SEO is done. That frees me to focus on richer layers like TL;DR blocks and JSON-LD without worrying if I forgot a basic tag somewhere.

Roadblocks I Hit and the Straightforward Fixes

1. Circular @id links

My first schema had the blog post pointing to the author, and the author pointing back to the same post. Google's Rich-Results test flagged an endless loop. The fix: give every entity a fixed URL fragment (/#rudranil, /#org) and let child items point only to those anchors—never back down the chain.

2. Too many separate <script> blocks

Early versions printed a new JSON-LD tag for every entity: author, org, article, FAQ, review. Claude advised merging them into one "@graph": [ … ] array. Now, a single block covers everything, making the page smaller and easier to check.

3. Review-markup avalanche

When I copied testimonials into a case-study page, the validator lit up with warnings: missing itemReviewed, stray aggregateRating, empty ratingValue. Claude rewrote the helper so a testimonial inherits the page's @id for itemReviewed, adds rating keys only when values exist, and skips aggregate data unless I explicitly pass it. Thirty warnings fell to zero.

4. Newline chaos in FAQ answers

Long answers occasionally carried hidden line breaks that broke JSON. A two-line sanitizer

str_replace(["\r", "\n"], ' ', $text);

Now scrubs every string before it's encoded. No validator complaints since.

Validations

  • JSON sanity check: before any change goes live, an automated script tries to read the generated schema as JSON. If the file won't load cleanly, I stop the deployment and fix the issue.
  • Rich-Results and Schema Check: I run these checks on https://search.google.com/test/rich-results and https://validator.schema.org/ to validate that the generated schema is in line with the standard template.

Next-Level Automation on My Roadmap

Templatizing saves clicks, but the long-term goal is hands-off automation—a system that can set up a page's SEO layer with almost no human input. Here's how I see that maturing:

1. A simple "SEO control panel"

What it is – A small web form (or VS-Code sidebar) where an editor enters only the core facts: page title, primary keyword, publish date, and any unique data points like price or testimonial quotes.

What it does – Pushes those inputs into the existing PHP variables, then triggers the next steps automatically.

2. Auto-detect and fill from the page itself

LLM assist – As soon as the draft HTML exists, an agent reads the headings, intro, image alt tags, and table captions. It then:

  • Suggests a 60-word TL;DR and auto-fills the $tldr_text slot.
  • Spots FAQ-style headings ("Why…", "How…") and turns them into schema-ready Q & A pairs.
  • Identifies entities (people, products, places) and proposes the right schema types to include.

3. Website-agnostic code

The templates now running on Funnelysis work, but they're tied to my codebase. The next step is to lift the whole routine—schema, TL;DR, meta tags—out of the site and turn it into a plug-and-play tool anyone can drop onto their domain.

4. Self-testing before publication

Validation loop

  1. The agent generates the JSON-LD.
  2. It calls Google's Rich-Results or Schema.org validator API (or scrapes the CLI output).
  3. If errors appear, it fixes obvious ones (empty fields, bad types) or flags a clear TODO.
  4. Only then does it embed the final block and mark the page "ready."

5. Meta and social tags on autopilot

An LLM prompt—"Create an 80-character title and 140-character description from this draft"—feeds the <title> and <meta description> tags. A second prompt drafts the OG text and alt-text for the share image. The agent drops them into the head of the page, saving me yet another checklist step.

6. Packaging it all as an "SEO agent"

Bundle:

  • the control-panel UI,
  • the detection-and-drafting LLM calls,
  • The validator loop,
  • and a CLI that plugs into GitHub Actions.

Result: commit a markdown file → agent adds schema, TL;DR, FAQs, meta, OG → runs tests → opens a pull request with everything filled. I review, merge, and publish, with no manual markup at all.

This approach offers a clear path from my current templated system to full automation, while maintaining control and quality at each step. The foundation is already working—it's just a matter of building the right tools on top of it.