What is Answer Engine Optimisation (AEO)?

Answer Engine Optimisation (AEO) is the practice of making your website legible to AI systems — chatbots, AI overviews and agents — so that they can understand what you offer and recommend or act on it. Where SEO tries to rank a page in a list of blue links, AEO tries to get your business quoted inside the answer itself. In practice it means writing clear, machine-readable descriptions of your product, your pages, and your inventory, and publishing them where crawlers can find them.

That is the definition I would give anyone asking. Old discovery was about ranking. New discovery is about being legible.

How do I get my site indexed by Google?

The foundation still has to be laid the old way, so start there. I made sure my pages actually get indexed by Google by submitting the site through Google's tools, including submitting a sitemap so the crawler can find every page easily.

One clarification here that will save you wandering around lost, because Google has confusingly named tools. The place you go to submit your site and your sitemap for indexing is Google Search Console. That is a different tool from the Google Cloud console where you set up your OAuth and your sign-in branding back in Section One. Same company, similar-sounding names, two completely separate dashboards for two completely separate jobs. Indexing lives in Search Console. Just know that going in, so you do not burn an afternoon in the wrong place.

This is the least glamorous part of SEO for startups in Nigeria or anywhere else, and it is also the part people skip. Do not skip it. A beautiful platform that Google has never crawled is a beautiful platform nobody will ever see.

llms.txt explained: speaking directly to the machines

Now the part that actually prepares you for the age of answers.

The single most important thing to have for AEO is a plain markdown file whose entire job is to explain your platform to AI crawlers, in clear language, with directions. The emerging convention for this is a file often called llms.txt, sitting at the root of your site. Think of it as a welcome note written specifically for an AI, telling it what you are, what you offer, and where to look. You are no longer hoping the machine guesses correctly from messy HTML. You are handing it a clean briefing.

It is worth being honest that this is an emerging convention, not a settled standard. Some crawlers will read it, some will ignore it. That is exactly why you keep the traditional work — robots.txt, your sitemap, your meta tags — running alongside it rather than instead of it.

Speaking of which: alongside llms.txt, two more things. A sitemap, as I mentioned, so everything is easy to reach. And proper meta tags on your pages, giving each one extra context about what it actually is.

Why structured data matters when the agent is the buyer

I will add one thing that earns its place precisely because of that agentic future I described. Structured data, sometimes called schema markup, is a standardised way of labelling your information so a machine knows that this is an event, with this date, this venue, and this ticket price.

When the agent comes to book on a user's behalf, structured data is the difference between it understanding your event instantly and skipping you for a competitor it could actually read. You are setting the table for the machine that is coming to buy.

Write for the crawler as deliberately as you write for the human, because soon the crawler is the one holding the wallet.

One more clean-up before the lights

With all of these changes made, you do not just ship. You go back and repeat the testing and optimisation passes for security and performance one more time. New changes always introduce new mess. In particular, you are hunting for ghost code — the dead, orphaned bits left over from earlier iterations that are quietly causing inefficiency while doing nothing useful.

And here is a prompting trick I lean on for exactly this kind of serious pass, and I want you to steal it:

Have Claude assume the role of the project's head engineer, the one who has to personally sign off before this goes to live production.

That single instruction changes the entire quality of the review you get back. You are no longer asking a helpful assistant to glance at things. You are asking the person whose name is on the line before launch. The standard rises to meet the role.

Give the machine a map, not a maze

Now my favourite practical pro-tip of this part. As your codebase grows, the AI starts spending real effort, and real money in tokens, just re-reading your whole project every session to remember how it all fits together. That orientation cost compounds quietly until it is a serious drain.

The fix I use is a tool called Graphify (one letter at a time: G-r-a-p-h-i-f-y, because it is worth finding correctly). You install it onto your Claude, and it builds a map of your project — a structural graph of how everything connects — so that Claude can read the map instead of walking every single street of your codebase from scratch. It navigates with far better context, and it saved me a meaningful amount of tokens, because the model was no longer stressed into rereading the entire codebase just to orient itself.

A few honest notes so you use it well:

• The payoff is largest on bigger projects with lots of files. On a tiny codebase it barely matters, so do not bother early.
• When you install it, the best practice is to have Claude clone the repository and then install from that clone, so you are in control of what enters your project and you are not risking Claude pulling in something that could ruin it.
• Remember to reset the map in the terminal after you make big changes, otherwise it is navigating with an out-of-date picture.

This whole space of tooling moves quickly, so check the current setup when you get there, but the principle is permanent: never make the machine re-read what it could have pre-computed.

The final frontier: the terminal

I have saved the best for last. That black screen you have dreaded since the very first day of this journey. The terminal. The command line. The place that, more than anything else, says to a non-coder you do not belong here.

So let me make you a promise. When you have come this far — all the way from "code is just another novel" to a live, optimised, monetised, discoverable platform — that black screen loses its power over you. You will open it, type the exact command Claude handed you, press enter, and watch it behave.

That is the whole secret the screen was hiding. It was never a test of whether you are a real engineer. It is just another place where you articulate an instruction clearly and a patient machine carries it out. The same thing you have been doing since page one.

Hands-on lab

The chapter above is the why. These guides are the how. The one rule never changes: if a step stumps you, screenshot it and paste it to your AI with "assume I have no technical experience; tell me exactly what to click next." Nothing here cannot be undone.

G9.1 · Submit your site to Google Search Console and add a sitemap [Core]

What you'll have: Google can find and index your pages.

Before you start: Beginner · ~30 min · free · you'll need a live domain

1. Go to Google Search Console (search.google.com/search-console). This is different from the OAuth Cloud Console in G3.1.
2. Add your domain as a property and verify ownership (a DNS record or a file).
3. Ask Claude to generate a sitemap.xml, then submit its URL in Search Console.

Check you did it right: Search Console shows your property verified and your sitemap submitted.

If something looks off: Verification failing → match the method (DNS versus file) exactly.

G9.2 · Add an llms.txt file for AI crawlers [Core for AEO]

What you'll have: A plain-language brief that tells AI answer engines what you are.

Before you start: Beginner · ~30 min · free · you'll need a live site

1. Ask Claude to write an llms.txt (markdown) describing your platform, what you offer, and key pages.
2. Place it at your site root (yourdomain.com/llms.txt).

Check you did it right: The file loads at your root URL.

If something looks off: Crawlers ignore it → it is an emerging convention; keep traditional SEO (G9.1 / G9.3) too.

G9.3 · Add page meta tags and structured data (schema) [Core for AEO]

What you'll have: Machines understand each page, which matters as AI agents start booking.

Before you start: Beginner–Intermediate · 1–2 hrs · free · you'll need your site

1. Ask Claude to add proper meta tags (title, description) per page.
2. Add structured data (schema.org) labelling events, venues, dates, and prices.
3. Validate it with a structured-data testing tool.

Check you did it right: Tools read your events and prices as structured data.

If something looks off: Invalid schema → fix it per the validator.

G9.4 · Run a final security and performance pass [Core]

What you'll have: A senior-level review before you scale.

Before you start: Intermediate · 1–2 hrs · free · you'll need the full app

1. Prompt: "Assume the role of this project's head engineer signing off for live production. Review security and performance."
2. Ask it to find and remove ghost or dead code and inefficiencies.
3. Re-test after the changes.

Check you did it right: Claude signs off, no obvious holes remain, and dead code is gone.

If something looks off: Big changes introduce bugs → re-run the test pass.

G9.5 · Install and use Graphify to save tokens [Advanced]

What you'll have: A project map so Claude navigates without re-reading everything.

Before you start: Intermediate · ~1 hr · free (open source) · you'll need a larger codebase

1. Have Claude clone your repo, then install Graphify from that clone, so you control what enters the project.
2. Generate the project map.
3. Reset the map in the terminal after big changes.
4. It pays off on larger codebases (hundreds of files); skip it on tiny ones, and check the current setup since tooling moves fast.

Check you did it right: Claude references the map and sessions use fewer tokens.

If something looks off: Out-of-date map → reset it.

G9.6 · Your first terminal commands, without fear [Core]

What you'll have: Comfort with the command line, the black screen.

Before you start: Beginner · ~30 min · free · you'll need a project

1. Open the terminal (Claude or Claude Code tells you which and where).
2. When Claude gives you a command, copy it exactly, paste it, and press enter.
3. Read what it prints back, and paste anything confusing to Claude.
4. Remember it is just a place to give clear instructions, the same skill as everything else.

Check you did it right: You ran a command and watched it work.

If something looks off: "command not found" or other errors → paste them to Claude and ask for the fix.

Closing: legible, lean, and unafraid

So that is discovery in the new age. Indexed for the old web, legible to the new machines, cleaned of its ghosts, mapped for efficiency, and you, finally, unafraid of the last screen that scared you. You can take money, the people paying you are glad to, and now the world — human and machine alike — can actually find you.

Notice that the single biggest efficiency win of this part, the map that saves your tokens, exists because someone else built and shared an open-source tool, and other builders wrote down honestly where it helps and where it does not. I did not invent it. I found it, because I was looking, in the open, alongside other people. That is the entire thesis of these talks in one example.

Come build with us at AIStoryLab. Twenty thousand naira a year, still too cheap, and inside you get the how-tos, the prompt techniques, and the current tooling that other builders have already tested so you do not waste tokens learning the hard way. Bring your scars. Take what you need.