What should an AI visibility audit of a financial institution include?

The short version

An AI visibility audit of a financial institution should include five things. First, a fixed list of real customer questions and a defined set of AI engines. Second, repeated dated runs of each question. Third, a clear definition of named versus recommended versus merely mentioned. Finally, a report a colleague can read without you in the room. Everything else is optional. You can run the whole audit by hand with a spreadsheet and an hour a month.

Start with the questions, not the tools

The unit of an audit is the question. AI assistants answer questions, so your audit has to ask them. Pull yours from three places: the search queries in your own Search Console data, the questions your call center and branch staff hear weekly, and the phrasing people use in reviews and community forums.

Aim for questions a real customer would type. Examples: "best savings account rates near me," "is [your institution] good for a first mortgage," "credit unions that offer business checking in [city]." Include some where you expect to be named. Include some where you know you will not. The second group tells you who gets named instead, which is often the more useful finding.

Write each question down verbatim and freeze the list. If you change the questions between runs, you cannot compare runs, and the audit becomes anecdote.

Pick the engines and record what you run

Choose the assistants your customers plausibly use. That usually means the major general assistants plus Google's AI features in search, since Google reports AI-feature traffic within Search Console's overall web reporting, which means some of your existing traffic already arrives through AI answers.

Record which engines you ran for every run. This matters for arithmetic later: engines not run are excluded from denominators, so a question asked on three engines has three chances to be named, not five. If you skip an engine one month, say so in the log rather than silently shrinking the sample.

Run each question more than once, and date everything

AI answers vary. The same question asked twice can name different institutions, because the underlying results shift and the model rewrites each answer fresh. A single run tells you what happened once, not what usually happens.

So run each question on each engine several times across a short window, and log the date of every run. When you summarize, describe a range across runs rather than a single number. "Named in two of four runs" is honest. "We appear in AI answers" is not.

Repeat the full set on a schedule, monthly works for most teams, so you can see movement after you change something on your site. Without dated repeats, you have a snapshot. With them, you have a trend.

Define named, recommended, and mentioned before you start

Most audit arguments are definition problems. Settle three terms up front:

Named: your institution appears in the answer at all.

Recommended: the answer points the customer toward you, with language like "consider," "a good option," or a direct suggestion.

Mentioned: you appear in a list or comparison with no steer toward you.

A mention in a list of ten is not a recommendation, and treating it as one will flatter your results. The results page named ten; the customer still has to pick. Track the three categories separately, because the fixes differ. Not being named at all is usually a content or crawl problem. Being mentioned but not recommended is usually an evidence problem: the engine found you but found nothing specific enough to steer a customer with.

What to check when you are not named

When a run comes back without you, the cause is usually findable. Work through the likely suspects:

The facts are not on a page the engine can read. Rates in a PDF, a product table rendered as an image, or details behind a widget are often invisible. Put the fact in plain HTML text on a stable URL.

The page lacks an effective date. An undated rate page is weak evidence. Engines prefer facts they can place in time.

Third-party sources disagree with you. Directories, review sites, and aggregators carry your old address, old rates, or a predecessor brand. Engines read those too, and conflicting facts suppress confident answers.

Nobody publishes the fact at all. If no page anywhere states that you offer business checking in a given county, no engine can say it.

Note that Google says no special optimization or markup is required for AI features. The work is making your facts clear, current, and consistent, not adding AI-specific code. Where the content is regulated, rates, fees, disclosures, give changes the careful eye they deserve, as you already do.

Write the report for someone who was not there

The deliverable is a report a colleague or an executive can read cold. For each question and engine, record: the date, the run count, and whether you were named, recommended, or merely mentioned. Add one line on who was recommended when you were not, and one line on the likely cause.

Keep it to a page or two. A table of questions down the side and engines across the top, with N, R, or M in each cell, communicates more than any narrative. Close with the two or three fixes you plan to make before the next run, so the audit drives action rather than anxiety.

When the manual version runs out

A hand-run audit covers a modest question list across a few engines. When you want more questions, more engines, or more frequent runs, the logging becomes the job. That is the point where measurement tooling earns its keep. How Scanley measures AI search visibility follows the same discipline described here. It records the questions asked, engines, dates, run counts, and whether an institution was named, recommended, or merely mentioned. It does this at a scale a spreadsheet cannot. Whether you automate or not, the audit structure stays the same.

Questions people ask