How I Optimized This Site for Agent Engine Search Optimization

Updated Apr 27, 2026/12 min read

A practical tutorial on how I optimized daviddacruz.dev for AI search, answer engines, and agent-style crawlers: page roles, schema, internal links, llms.txt, support pages, and machine-readable context.

People keep inventing new labels for the same underlying shift.

Some call it answer engine optimization. Some call it agent engine optimization. Some call it agent engine search optimization. I still think agent search optimization is the cleanest label on the site, but the implementation work behind all of them is mostly the same.

The job is not to impress an acronym. The job is to make a site easier to:

  • understand
  • retrieve
  • compare
  • cite
  • route to the right next action

This post is the practical version of that work. Not theory. Not a trend summary. The exact changes I made on daviddacruz.dev to make the site stronger for AI search, answer engines, and agent-style crawlers.

What Agent Engine Search Optimization Actually Means

The simplest definition I can give is this:

agent engine search optimization is the work of making your important pages easier for machine-mediated search systems to interpret correctly and send users to confidently.

If you prefer the older label, you can read this as an answer engine optimization tutorial too. If you prefer the newer phrasing, it is also an agent engine optimization walkthrough. I am treating those phrases as close practical synonyms here because the implementation layer overlaps heavily.

That sounds abstract until you break it down.

In practice, it usually means:

  • one page should clearly own one main commercial intent
  • schema should describe the page type honestly
  • important pages should not be orphaned
  • support pages should answer the real comparison, cost, FAQ, and definition questions
  • the site should expose machine-readable context cleanly
  • the visitor landing from an AI answer should hit a page that can actually convert

That is the real shift.

It is not "write for robots." It is "stop making your site structurally ambiguous."

The Starting Point on This Site

daviddacruz.dev already had useful raw material:

  • a fast Nuxt stack
  • strong long-form content
  • public case studies
  • service pages
  • structured data already present on many templates

But that was not enough on its own.

The gap was not "no content." The gap was commercial search clarity.

The site needed stronger:

  • page-role separation
  • parent and child relationships
  • answer surfaces
  • machine-readable support assets
  • explicit internal-link paths between proof, offers, comparisons, and definitions

That is why I started building a more deliberate AI-search cluster instead of relying only on generic blog content.

The Exact Things I Implemented

Here is the short version of what changed.

1. I created parent pages instead of relying on scattered mentions

The most important shift was moving from "the site mentions this topic in several places" to "the site has an explicit parent page for this topic."

That is what pages like /solutions/agent-search-optimization are for.

A good parent page does three things:

  • defines the topic
  • narrows who it is for
  • routes the user to the right supporting or commercial child pages

Without that parent, the site often looks knowledgeable but fragmented.

2. I added supporting pages for distinct search intents

A lot of sites try to make one page do everything:

  • define the topic
  • sell the service
  • answer objections
  • explain cost
  • compare options
  • act as proof

That usually weakens the page.

So I split intent across dedicated supporting pages, including pages for:

  • preparation intent
  • audit intent
  • pricing intent
  • comparison intent
  • schema intent
  • content-heavy-site intent
  • SaaS-specific intent

The point is not volume. The point is cleaner page ownership.

3. I made the commercial path more explicit

It is not enough for AI systems to understand the site. The user still needs a strong next step.

So the cluster was connected back to:

This matters because AI-driven discovery often lands people mid-journey. If the page they land on is structurally clear but commercially weak, you still lose.

4. I strengthened the machine-readable assets

This site exposes support assets that make the public surface easier to interpret:

These do not replace normal SEO. They reinforce it.

5. I treated schema as a page-type system, not a checkbox

One of the most common mistakes in AI-search work is treating schema like decorative markup.

What actually matters is whether the schema:

  • matches the visible page honestly
  • scales by template
  • reinforces page meaning

On this site, the schema strategy is tied to actual page roles:

  • articles
  • case studies
  • service pages
  • FAQ surfaces
  • breadcrumbs
  • collection pages
  • speakable sections where useful

That is much more defensible than spraying generic markup everywhere.

The Page Types That Matter Most

If you want to copy this approach, do not start with random blog posts. Start with the page types that shape buyer understanding.

On a site like this, the most important page types are:

Parent solution pages

These define the main topic and route into the cluster.

Service pages

These are the commercial destination. They need strong CTAs, clear scope, and clean metadata.

Comparison pages

These capture decision-stage traffic and help AI systems understand tradeoffs.

Cost pages

These answer one of the highest-intent commercial questions a buyer can ask.

Case studies

These reinforce trust and give the commercial pages proof to link to.

Definition and checklist pages

These help the site capture earlier or lower-friction intent without forcing everything onto the service pages.

That is the pattern I would keep repeating.

The Machine-Readable Layer

This is the part people either overhype or ignore completely.

My take is simpler:

The machine-readable layer should make the site less ambiguous.

On this site, that includes:

llms.txt

The shorter reference file gives AI systems a compact, high-confidence summary of who I am, what the site offers, and where the main proof and services live.

llms-full.txt

The longer reference gives broader context and richer coverage of the site for systems that want more detail.

clean crawl resources

Sitemap, robots, feed, and related crawl surfaces need to reflect the actual public structure cleanly.

schema by template

This is still the most important machine-readable meaning layer on the site.

predictable page naming and URL structure

If the site architecture is unstable or vague, no extra file will rescue it.

That is why I think the right mental model is:

machine-readable assets support the structure; they do not compensate for bad structure.

That is also the part many answer engine optimization articles skip. They jump straight to "be more quotable" without cleaning up the structural layer that makes quotability believable in the first place.

The Internal Linking Layer

Internal links are where a lot of this work becomes real.

A site can have excellent pages in isolation and still underperform because the relationships between them are weak.

On this site, the cluster is designed so that:

  • parent pages link to the right child pages
  • child pages link back to the parent
  • service pages are connected to proof
  • support pages connect to commercial pages
  • cost and comparison pages sit inside the same cluster, not outside it

That helps both users and machines answer a simple question:

which page is supposed to lead here?

If that answer is fuzzy, retrieval and conversion both get worse.

The Support Content Layer

This is where a lot of "AI search optimization" discussions stay too shallow.

The strongest sites do not just have a homepage and a service page. They have support surfaces around the real questions buyers ask.

On this site, that meant building or strengthening pages around:

  • how to prepare a website for AI search
  • why AI Overviews do not mention your site
  • schema strategy for AI search
  • pricing pages for AI search
  • comparison pages for AI search
  • SaaS-specific search-readiness angles

This matters because AI systems often respond better to explicit question-answering surfaces than to vague general pages.

It also matters because users arriving from AI search are often partly pre-qualified already. They want a page that resolves the next question fast.

A Practical Checklist You Can Copy

If I were doing this again on a fresh site, this is the order I would follow.

Phase 1: clarify page roles

  • pick the main parent page for the topic
  • decide which child pages support it
  • decide which page is the true commercial destination
  • remove or merge pages that overlap too much

Phase 2: fix technical clarity

  • check canonicals
  • check sitemap coverage
  • check robots behavior
  • check status codes
  • check metadata consistency
  • validate schema by page type

Phase 3: add support surfaces

  • FAQ page or section
  • comparison pages
  • cost page
  • proof pages
  • definition or checklist pages where useful

Phase 4: strengthen internal linking

  • link parent to child
  • link child to parent
  • link support to service
  • link proof to commercial pages
  • link commercial pages back to proof and support

Phase 5: expose machine-readable context

  • add llms.txt
  • maintain llms-full.txt if useful
  • keep sitemap and related resources clean
  • make sure the public identity and offer are explicit

Phase 6: measure what matters

  • are the right pages indexed?
  • are the right pages being surfaced for the target topic?
  • are support pages routing traffic toward the commercial pages?
  • do visitors landing from search have a clear next step?

That is a much better process than trying to optimize "AI visibility" with no structural model.

If you are searching for a simpler phrase, this checklist is effectively the agent engine optimization checklist I would follow on a service site, SaaS site, or content-heavy site today.

What I Would Fix Next

The site is stronger than it was, but it is not finished.

The next improvements I would prioritize are:

  • tighter first-party proof around this exact topic
  • more direct public evidence on outcomes over time
  • stronger cross-linking from older relevant articles into the newer AEO cluster
  • a few more pages that capture exact-match wording variants without bloating the cluster

That is the normal state of a good site. Clearer than before, but still improving.

Final Thought

If you strip away the acronym churn, the work is not mysterious.

This site became more optimized for agent engine search optimization by becoming:

  • clearer
  • more structured
  • more explicit
  • more internally connected
  • more machine-readable

That is the real pattern.

If you want the proof-first version of this same work, read the companion case study:

daviddacruz.dev AI search optimization case study →

FAQ

Common questions.

What is agent engine search optimization?

The phrase is still unsettled, but in practice it overlaps heavily with answer engine optimization, AI search optimization, and agent search optimization. It means making a site easier for search engines, AI answer systems, and agent-style crawlers to interpret, retrieve, compare, and route to the right page.

What are the most important things to optimize first?

Start with page roles, schema, internal links, canonical and sitemap hygiene, answerable support pages, and machine-readable context like llms.txt. Those make the strongest pages easier to understand before you publish more content.

Does llms.txt replace normal SEO?

No. llms.txt is a support layer, not a replacement. The foundation is still crawlability, page clarity, structured data, internal linking, and useful pages with clear intent.

Can a small site do this without a big content team?

Yes. A smaller site can often move faster because the structure is easier to fix. One strong parent page, a few strong support pages, clear schema, and good internal links usually beat a much larger but messier site.

Is this tutorial about daviddacruz.dev specifically?

Yes. It explains the exact structural changes made on daviddacruz.dev, but the checklist is generic enough to reuse on other service, SaaS, and content-heavy websites.

References

Authority sources.

Written by

David Dacruz

Digital architect in Ericeira, Portugal. 42 alumni. I write about building at the intersection of AI, web3, and what actually ships.

Work with me Subscribe More about me

← Previous

AI Agents and the Marketing Opportunity of the Decade