If You're Hiring for AI Visibility, Here Are the Questions I'd Want You to Ask Me
I read a lot of job specs in this field. They mostly ask for a list of tools, a number of years, and "experience with GEO/AEO". None of those predict the thing you actually need, which is whether the person can tell you that the work produced revenue — and tell you when it didn't.
So this is written from the wrong side of the table on purpose: the six questions I would want a hiring manager to ask me, why each one separates reporting from measurement, and my own answers including the parts where they are thin.
What would failure look like in your reporting?
Ask this first. It is the single most diagnostic question in the field.
Anyone can produce a chart that goes up. AI visibility is unusually easy to flatter, because the headline metric — how often your brand appears in AI answers — is produced by a vendor sampling its own prompt list. Change the list, change the number. I have watched a frozen metric in one panel fall from 194 to 25 while receiving no new data at all, because the vendor was recomputing its index behind the scenes.
My answer: failure shows up as the pages-cited count going flat. In one six-week series, AI responses citing a client rose from 63 to 2,605 while pages-cited went 13 → 14 → 17 → 22 and then stopped. Responses were saturating against a fixed set of pages. If I report a rising response count while pages-cited is flat, I am reporting nothing, and that is exactly the situation I would flag rather than present.
Which instrument produced this number?
There are four different things people call AI visibility, they are measured by four different instruments, and three of them can rise while revenue does not move.
A candidate who cannot name which instrument produced a given figure will hand you numbers that cannot be acted on.
My answer: crawler access from a server log; live answer fetches from the same log, split from background crawling by user agent; answer presence from a paid prompt sampler; and revenue from a first-touch mark carried into the CRM. I publish the full breakdown, including which instrument is blind to what.
Why should you ask for a number they had to correct?
A candidate with no corrections has either never measured anything or does not tell you when they are wrong. The second is worse.
My answers, both public: I had a strong contrarian finding — zero requests for llms.txt across two sites and 6,676 AI agent requests — and threw it out, because llms.txt is served as a static file and my logger runs inside PHP, so the zero was guaranteed before the window opened. And on the same site I published a metric as two different numbers because I quoted two different windows without naming either; I went back and reconciled them in the text rather than quietly changing one. Both are written up on the site.
What can their measurement not see?
Everything real has a blind spot. A candidate who lists none is selling.
My answer: a fetch is not a citation — my log proves an assistant pulled the page, not that it was quoted, which is why I keep paying for a prompt sampler. Classification is by user-agent string, which is a claim: requests for config-file backups have arrived carrying assistant user agents, so the correct word for my counts is claimed. Static files are invisible to a PHP-level logger. And two sites in one industry over eight days is a probe, not a study.
How would they know the tracking broke?
This is the question that separates engineers from analysts, and it costs more money than any of the others.
The expensive failures in this work do not throw errors. A first-touch mark that stopped surviving brand searches three weeks ago still produces a confident report. An availability check that silently sees 600 of 7,801 calendar events returns a perfectly valid answer, every time, and it is wrong — that one I found in a live voice agent that was booking jobs onto technicians who were marked off.
My answer: monitor the shape of the output, not the exception log. Expected ranges, expected counts, expected distributions, and an alert when a field that is never empty starts being empty. Written up here.
What happens to the work if they leave?
If the answer involves a dashboard only they can log into, you are buying a dependency.
My answer: everything runs on the company's own infrastructure with credentials in company accounts. The log stays, the tracking stays, the documentation is written for whoever comes next. Tooling that only works while I am on the payroll is a hostage, not an asset — and saying so is easier than proving it, so ask for the handover doc from a previous engagement.
What I would want you to know about me before an interview
Since I have listed the questions, here are the answers a spec usually asks for, plus the parts that are genuinely limitations.
What I do: search and AI visibility as one job, and the measurement layer that ties both to revenue. I do not treat GEO, AEO and SEO as separate practices — they are one sequence with different failure modes.
Where I test: multi-location home services in the US, because it is the hardest configuration — the conversion is a phone call, jobs are created by hand with no source field, and nobody links to a repair company. A method that produces a traceable booked job there transfers to easier setups.
What I build: server-side AI logging, attribution chains that reach the invoice, and operational automation — paid-lead dispute pipelines, call classification at volume, document parsing. Real numbers from that work are on AI automation.
How I work: written-first and asynchronous. I would rather send a document than attend a meeting, and I write down what I measured and how to recheck it so nobody has to take my word for it.
Where I am weak: I am one person, so I am the wrong hire if you need a team managed rather than a system built. I have no enterprise procurement experience. My published dataset is two sites in one industry — broad benchmarking across verticals is not something I can claim. The public code I can show is a deliberately anonymised version — call-audit-demo — because the working pipeline runs against client accounts and I will not publish those; judge the structure and the guardrails, not the scale.
If any of that fits what you are hiring for, the terms I work under and what I am looking for are on work with me.
I take full-time and contract work covering search, AI visibility and the attribution layer that connects them to revenue. The role, the format and the compensation frame are on work with me. If you want to test any claim on this page against a real dataset before talking, the open crawler data is published in full.
Related: