I have spent a long time getting websites to rank and I was good at it. You learn the rules, the rules shift, you learn them again, and over years you get reasonably good at the dance.
Then the traffic changed. Not all at once and not in a way that set off alarms. A shift in the shape of it.
So I did what I do when something changes, which is read. About AI first, then about answer engine optimization, and I found an entirely different world underneath.
The proof arrived before the theory did. A client hired me for a large project and told me he had asked Perplexity for a ghostwriter and my name came back. He did not find me through a search and did not click a link from a list. He asked a machine and the machine recommended me.
It was not a fluke, because a second client came the same way. Different engine, same story.
How is answer engine optimization different from SEO?
There is no big bang, and that is the thing most likely to throw somebody arriving from search.
With SEO there is eventually a moment. A day comes when Google decides to rank you and the traffic appears, and you can point at it on a chart.
This does not work that way. There is no single day and no visible switch. What happens instead is quieter. A trickle here and a trickle there. An engine names you in one answer, then in another.
And before you quite notice it has happened you are seeing more of the right people finding you, and more conversations that started with a machine saying your name.
Anybody waiting for the moment will conclude it is not working and stop about four months before it starts.
The book on this: The Day Your Website Died covers optimizing for AI answer engines, from identity and structured data through the content that earns citations, written so the technical parts can be handed to somebody else.
What was the author’s first mistake?
Assuming this was SEO with a new name.
I had been ranking pages for years, so when the answer engines arrived and people began talking about citations, my brain did the obvious thing and filed it as another shift in the same discipline. Learn the new rules, apply them, carry on.
That is not a tactical error. It is a wrong picture of what the work is, and a wrong picture sends every hour of effort afterward in the wrong direction.
It is also the mistake almost everybody makes, which is why the chapter is early and why the book spends real time on what carries over from search and what does not.
Why is this work harder than it looks?
Because there is no single judge.
The techniques are mostly simple. That is not where the difficulty lives. With search there was one arbiter, with rules that were knowable and reasonably stable, and you optimised for it.
Here you are optimising for several engines at once, and they do not agree with each other. They weigh different signals, update on different schedules, and produce different answers to the same question on the same day.
That is why the book argues for corroboration instead of for any single dramatic move. Something stated once in one place is a claim. The same fact stated consistently across many places is something a machine can rely on.
What is the density principle?
The idea that turns a hundred small tasks into one structure.
The first half of the book is the problem. The shift, what ignoring it costs, why it is a separate lane, the moving targets, the bots. Everything after that is the work, and all of the work obeys a single principle.
Understand it and every technique in the rest of the book stops reading as a checklist and starts reading as one thing being built a piece at a time. Miss it and the same chapters look like busywork, a hundred tasks with no visible reason to do any particular one.
That is the difference between a book of tactics and a book you can act on when a situation appears that the tactics did not cover.
What does the identity layer do?
It gives a machine one place to look and one answer to find.
A chunk of the book is about stating who you are in a form software can read without guessing. One organisation, one author, declared once and pointed at consistently from everywhere else. The chapter on sameAs treats it as the equals sign of the web, which is what it functions as. This profile and that profile and this listing are the same entity.
Then the harder identifiers, and Wikidata, which the book calls the keystone.
None of that is glamorous and all of it is the difference between an engine that can state a fact about you and one that can only find text near your name.
What content earns a citation?
Something the machine can lift, and something only you could have produced.
There is a chapter on building a page a machine can take an answer from, and one on the evidence that earns the citation in the first place. Those are separate problems. A page can be perfectly structured and contain nothing worth quoting.
The strongest position is original research, because it is the one thing that can only be attributed to you. Everybody can restate what is already known. Nobody else can cite your numbers.
Alongside that sits the trust layer the engines check for, which is not a trick and cannot be manufactured quickly. Experience, expertise, authority and trust, evidenced instead of claimed.
What happens off your own site?
More than most people running a website expect.
Listings and reviews are an off-site layer you have real control over. Local matters when the customer is physically nearby and works differently from everything else in the book. Social profiles are additional nodes in the same web, valuable for corroboration instead of for audience.
And there is a chapter on video as a citation source, which is the one most readers do not see coming. A platform most businesses treat as marketing turns out to be somewhere machines go looking for answers.
All of it is the same principle again. One fact, stated consistently, in enough places that a system with no reason to trust any single source can trust the pattern.
Do you need to be technical to use the book?
No, and the note explaining why comes before the first chapter for a reason.
Parts of the book get technical. There is a chapter on domains and DNS, one on the code that describes your pages to machines, one on reading server logs. Some readers see a word like schema and quietly decide the whole subject is beyond them.
That conclusion is wrong and it costs them the part that matters, because almost everything difficult in this book is difficult in a technical way, and the technical parts are exactly the parts you hand to somebody else.
What is left, the part nobody can do in your place, requires no technical skill at all.
Which parts of AEO can only you do?
Decide the facts and write the content. Everything else is delegable.
The settled facts about your business are yours. The name, the founding year, what you do. Nobody can determine those for you and a machine cannot state them consistently until you have.
The real content is yours too, because only you know the work. The answers your customers ask for cannot be produced by somebody who has never done the job.
The structured data is built by a plugin from a form you fill in instead of typed by hand. The DNS is ordinary administration your host handles. The rendering fix belongs to whoever builds your site. Reading the logs is optional and delegable.
So the reading instruction is simple. Is this a fact only I can decide, or content only I can write? Then it is mine. Is this machinery? Then it is somebody else’s, and I need to understand it well enough to ask for it and check it got done.
The Guides That Get Your Book Written, Published, and Sold
Four short, practical guides on writing, publishing, and selling your book, plus the occasional note when there's something worth your time. No fluff, no daily inbox clutter. Drop your email and they're yours.
We use MailerLite to manage our list and send these emails. Your address is used only to send you what you signed up for. We will not sell it, share it, or use it for anything else, and you can unsubscribe anytime.