AI search visibility, generative engine optimisation and technical SEO as a standing measurement

What AI visibility is

A customer asks an assistant which clinic, lender, resort or supplier to use, what it costs, whether it is licensed, and whether it serves their suburb. The assistant answers in a paragraph, cites a few pages, and the customer acts on it. The business never sees the question or the answer, and finds out when a caller quotes a fee it has not charged for a year. AI visibility is the name for what those answers contain, and for the search results page that often opens with an AI Overview above the links. Both can be measured, and the measurement is what makes the rest of this practice possible.

Measurement here means a fixed set of customer questions put to each assistant on the same day each week, with the full answer and its cited sources kept; the full results page pulled for a fixed list of search terms from a fixed location; a scripted assistant set the same customer tasks on the site and on comparable sites; and the site's own crawl, Search Console, analytics, Business Profile and Bing data pulled into the same file. Each pull is a row. The rows are a series. The series is the record, and every row of it belongs to the business as plain CSV.

The dimensions of the record

Each dimension has its own page in this section or its own part of this page, and each one ends in the same place: a finding that names something on the site or on a surface the business controls. Recording what AI assistants say covers the question set, the weekly ask and the claim-by-claim check against the business's own pages. The sources assistants cite covers whose pages the assistants trust, and why a business goes missing from its own answers. Testing whether an agent can use your website covers the scripted assistant, the benchmark sites and the transcript.

On the search side, measuring your place in AI Overviews reads the whole results page, and Search Console as a weekly record keeps what Google reports as a series the console itself forgets. Business Profile, Bing and your site is the entity record, the short list of facts that drift between surfaces. Crawl health and Core Web Vitals is what the site actually served that week. Turning findings into engineering tickets is where all of it goes.

The sources AI assistants cite when they describe you

For a current fact an assistant fetches pages while it answers. The cited list shows which pages it trusted, and whether your own site was one of them.

Where do AI assistants get their information about a business?

From what the model already holds and, for anything current, from pages it fetches while it answers. For a price, an opening hour or a licence the assistant usually fetches, and the list of sources it cites shows which pages it trusted and whether your own site was among them.

The cited list changes week to week. Tallied over time it shows the share of answers about a business that rest on the business's own pages, on directories, on review sites or on competitors.

Three kinds of fetch

The vendors publish their user agents, and the names matter because each one does a different job. One crawler gathers pages for training, and what it collects shapes what the model holds months later. One crawler builds a search index that the assistant consults when it answers. One fetcher goes to a page because a user asked a question right now and the assistant decided to read the page before replying. OpenAI documents these as three separate agents, and Google publishes its crawlers and its user-triggered fetchers separately, with the Google-Extended robots token controlling training use.

A site can allow one and block another, on purpose or by accident. A robots rule written years ago to keep training crawlers out can also keep the live fetcher out, and from then on the assistant answers questions about the business from everyone's pages except the business's own. The way to see which agents reach the site, and what they are served, is in the access logs, which auditing AI bot traffic covers.

Reading the cited list over time

Each weekly answer carries a list of sources. Record the domain of each one against the question it answered. After a month the tally shows, per question, how often the business's own site was cited, how often a directory or an aggregator was, how often a review site, a news article, a government register, or a competitor. That share is a dimension of the record in its own right. It moves when the pages change and it moves when the assistant changes how it searches, and the series shows both.

The tally also shows which pages on the business's site are doing the work. The tally shows which pages are cited, and they are often not the ones the business considers its most important. Pages whose facts sit in HTML text are cited more often in the record than pages whose facts sit in PDFs or behind script.

When the site is absent from its own answer

The reasons are mechanical and they can be checked. The live fetcher is blocked at the firewall or in robots.txt. The page returns its text only after JavaScript runs, and the fetcher does not run it. The fact sits in a PDF or an image. The page exists under two URLs and the canonical points at the wrong one. The page is thin on the question and the assistant found a fuller answer elsewhere. The page describing machine-readable delivery sets out how a site serves agents the same content a browser gets.

What to change

Allow the retrieval and search agents you want to be read by, and decide separately about the training crawler. Put every fact a customer asks about into HTML text on the page where a customer would look for it. Mark the page up with the structured data that describes the fact. Keep the fact identical on every surface the business controls, because an assistant that finds two values hedges or picks the wrong one. These are the changes that put the business's own pages back into the cited list. Whether the assistant then cites them is recorded, week by week, and never promised.

The work described here is the source dimension of AI Visibility Management. The adjacent dimension, what the assistants actually state once they have read the pages, is covered in recording what assistants say.

How to read the sources behind an assistant's answer

• Training crawlers, search crawlers and live fetchers are different agents. The vendors publish them separately. A rule meant for one commonly blocks another, and the live fetcher is the one that answers a customer's question today.
• The cited domains, tallied per question, are a measurement. The share of answers resting on the business's own pages, on directories, on review sites or on competitors changes over time and the series shows it.
• A few pages carry most of the citations. The tally shows which of the business's pages are cited, and pages whose facts sit in HTML text are cited more often than pages whose facts sit in PDFs or behind script.
• Absence from the cited list has a mechanical cause. Blocked agents, script-only text, facts in PDFs, wrong canonicals and thin pages are the usual ones, and each one is checkable and fixable on the site.

The pages an assistant cites about a business are a measurable dimension. Tallied weekly they show whose word the assistant takes, and the reasons a business's own site is missing are mechanical faults in delivery that engineering can correct.

Questions about AI assistant sources

Can structured data make an assistant cite us?

No one can promise that. Structured data states a fact in a form a machine reads without guessing, which removes one reason for an assistant to prefer another page. Whether the assistant then cites the page is what the weekly record shows.

How long before a changed page shows up in the cited list?

A live fetcher can read a changed page the same day. A search index may take longer, and what the model holds from training changes only when the model does. The record shows the date each assistant's answer changed, which is the timeline the record supports.

Testing whether an AI agent can use your website

An agent test puts a scripted assistant to a customer's task on your site and on comparable sites, keeps the transcript, and shows where the site stopped it.

Can an AI agent actually complete a task on your website?

Give a scripted assistant a defined task, such as finding the fee for a service or checking availability for a date, let it browse the site under a named user agent, and keep the transcript. The transcript shows where it succeeded, where it guessed, and where the site stopped it.

Some customers now delegate the first pass of a purchase to an assistant. A site that a browser renders perfectly can still be one that an agent cannot read, and nothing in analytics reports it.

What the test is

An agent test is a fixed set of tasks, written as a customer would phrase them, run by a scripted assistant against the business's site and against a benchmark set of comparable sites. The assistant reads pages the way an assistant does: it fetches HTML, follows links, and tries to extract the answer. Every run keeps the transcript, the pages fetched, the status codes returned, and whether the final answer was correct against the business's own published facts. The same tasks run on the same day each week, so the result is a series beside the answer record.

The benchmark set is the point. A site that passes four tasks in ten is a different story when the comparable sites pass eight, and a different story again when they pass two. The task set is written for the industry, because the tasks a customer gives an assistant about a clinic are not the tasks they give it about a lender or a resort.

Where agents fail

The same kinds of failure recur. Text appears only after JavaScript runs, so the fetched HTML is a shell. A consent or cookie interstitial cannot be dismissed by the agent. A bot management rule challenges every unfamiliar client and serves the agent a challenge page. A fee table is published as a PDF or an image. A price appears only after a date picker is used. A tab component leaves its other tabs out of the HTML. Infinite scroll hides the second half of a list. A form is the only route to an answer the site could have stated.

Each of these is invisible from inside the business, because the people who work there use a browser, accept the cookie banner once, and never see the challenge page. Google's own documentation on JavaScript explains the three-phase processing that lets its crawler eventually render script, and most assistant fetchers do less than that. The practical rule is that the fetched HTML has to carry the answer. The page on machine-readable delivery describes what that takes.

The test never submits a form

The scripted assistant reads. It submits nothing. It runs under one named user agent so that it can be found in the access logs and, if the business wishes, allowed or blocked as a known client. Cloudflare and other edge providers publish how they verify known bots, and the test client is configured to be identifiable in the same spirit.

Reading the transcript as an engineering ticket

A failed task maps to a change in the site. A challenge page maps to a bot rule. A script-only tab maps to server rendering. A PDF fee table maps to an HTML table with structured data. A wrong canonical maps to the CMS template that generates it. The ticket names the transcript as its evidence and the mechanism as its diagnosis. The method for writing those tickets is set out in turning findings into engineering tickets, and the agent test is one of the measurements inside AI Visibility Management.

What the test does not do is say what the site should offer. If the task cannot be completed because the business has never published the fact, that is recorded as unverifiable and handed back as a question for the business. The engineering begins once the fact exists.

How to run an agent task test

A first pass that shows whether an assistant can get a customer's answer from your site at all. The first pass takes a day.

1. Write the tasks in customer language. Take real enquiries and turn each into one task with one checkable answer: the fee for a named service, whether a date is available, which location serves a suburb. This step takes two hours.
2. Choose the benchmark sites. Pick comparable businesses a customer would also ask about. The task set must make sense on every site, so keep the tasks generic to the industry. This step takes an hour.
3. Run a scripted assistant under a named user agent. Use an agent framework that fetches HTML and follows links, set a user-agent string you can find in the logs, and never let it submit a form. Setting it up takes half a day.
4. Score against published facts and keep the transcript. Mark each task as correct, wrong or unverifiable against the site's own pages. Keep every fetched URL, status code and the full transcript. Each run takes an hour.
5. Trace each failure to a mechanism. Challenge page, script-only text, PDF, interstitial, canonical, missing fact. Write the mechanism beside the failure, because that is the ticket. This step runs as failures arise.

The tools are real customer enquiries, an agent framework with HTML fetching, access logs to confirm the agent's requests and a benchmark list of comparable sites.

What an agent test shows that a browser cannot

• A site a browser renders perfectly can still be one an agent cannot read. Script-only text, consent interstitials, bot challenges, PDFs and tab components all look fine to staff and stop a fetcher cold.
• The benchmark set gives the result its meaning. A pass rate only reads against comparable sites doing the same tasks, so the task set is written for the industry and run on every site alike.
• The test reads and never submits. One named user agent, no forms, no bookings, so it can be found in the logs and treated as a known client.
• Each failure maps to a site change, and a missing fact maps to a question. Challenge pages, rendering, PDFs and canonicals are tickets. A fact the business never published is handed back before any engineering starts.

A scripted assistant running fixed customer tasks against a site and its comparables, with transcripts kept, shows where the site stops an agent. Every failure traces to a mechanism the site controls, and the transcript is the evidence the ticket carries.

Questions about agent task tests

Does the test touch our booking or enquiry systems?

No. It reads pages, follows links and extracts answers. It does not submit forms, create bookings or place orders.

What if the task cannot be done because the fact is not on the site?

The result is recorded as unverifiable and handed back as a question for the business. Whether to publish the fact is the business's decision. Publishing it in a form an agent can read is the engineering that follows.

Turning visibility findings into engineering tickets

A finding names a mechanism the business controls and the evidence that it is failing. A recommendation tells the business what to say. The record produces the first and leaves the second to the business.

What separates an engineering finding from a marketing recommendation?

An engineering finding names a mechanism the business controls and the evidence that it is failing: a fact an assistant cannot read, a page that redirects in a loop, two copies of the address that disagree. A marketing recommendation tells the business what to say. Only the first becomes a ticket.

A weekly record produces findings in volume. Without a fixed shape and a fixed line about what counts, the action list fills with opinions about copy and the engineering never starts.

The shape of a finding

A finding has a stable key, so that the same fault found in three consecutive weeks is one finding. It has a severity, so that the list can be read from the top. It has the evidence row, which is the line in the record that showed it: the answer with the wrong fee, the transcript where the agent hit a challenge page, the crawl row with the two-hop redirect. It has the mechanism, which is the thing on the site or on a surface that produced the evidence. It has the proposed change and the owner. And it carries forward week to week until the record shows that the mechanism works, at which point it closes with the date.

The ranking is by what fixing the finding is worth. A fee that two assistants quote wrongly from a third-party page ranks above a missing description tag, because one of them sends customers away with a wrong number and the other does not. The ranking is a judgement, made by an engineer reading the record, and it is written down so it can be argued with.

Three findings and their tickets

A clinic's fee schedule is a PDF linked from the services page. Two assistants quote the fee from a comparison site that copied an old version. Evidence: the answer rows and their cited sources. Mechanism: the fact is not in HTML on the clinic's own page. Ticket: publish the fee table on the service page as HTML with structured data, keep the PDF as a download, and watch the cited list.

A retailer's product page shows delivery times in a tab that renders from script. The agent test fails the task of finding delivery to a regional postcode on every run. Evidence: the transcript and the fetched HTML, which contains no tab content. Mechanism: client-side rendering of the tab. Ticket: render every tab's content in the HTML and let script switch the view.

A firm's opening hours differ between the Business Profile and the contact page after a seasonal change. One assistant gives the old hours and another hedges. Evidence: the surface diff and the two answer rows. Mechanism: two copies, edited separately. Ticket: make the CMS record the source, generate the structured data from it, and push the profile from it through the API.

What is not a finding

Writing more pages about a topic, targeting a particular search term, changing the tone of the service description and getting links from a particular kind of site are marketing decisions. The record can inform them, because it shows which questions the assistants answer from other people's pages, and the business may act on that however it chooses. The engineering service does not make those decisions and does not write that copy. When a fact is missing from the site altogether, the finding says so and hands the question back. Publishing the fact is the business's call. Publishing it in a form a machine can read is the ticket that follows.

Closing the loop

The next week's measurement is the test. A ticket closes when the record shows the mechanism works: the fetch returns the fact in HTML, the agent completes the task, the surfaces agree. Whether an assistant's answer then changes is recorded on the same series, with the date of the change marked, and it is never promised, because the assistants and their sources change for reasons nobody controls. That is the discipline that keeps the list honest. The sources that feed it are described across the assistant answer record, the agent test and the weekly crawl, together with the indexing verdict per URL that Search Console provides, and the whole of it, with the engineering days attached, is AI Visibility Management.

What makes a finding actionable

• A finding carries a key, a severity, the evidence row, the mechanism and an owner. The same fault found in three weeks is one finding, and it carries forward until the record shows the mechanism works.
• Rank by what fixing it is worth, and write the ranking down. A wrongly quoted fee outranks a missing tag because of what it costs a customer, and a written ranking can be argued with.
• The line is the mechanism. A finding names something on the site or a surface that produced the evidence. Advice about what to say, which terms to target or where to get links is a marketing decision the record informs and the engineering does not make.
• A ticket closes on the measurement and never on the promise. A ticket closes when the next measurement shows the mechanism works, and whether an answer changes afterwards is recorded with a date.

Findings with a stable key, a severity, an evidence row, a mechanism and an owner turn a weekly record into an engineering backlog. The line between a finding and a recommendation is the mechanism, and a ticket closes when the next measurement shows the mechanism works.

Questions about findings and tickets

Who decides the severity?

A senior engineer reading the record, and the reasoning is written beside the ranking. The business can disagree, and the list is then reordered with a dated note.

How do we know a ticket worked?

The next weekly measurement. The crawl row no longer shows the chain, the transcript shows the task completed, the surface diff is empty. An assistant's answer changing afterwards is recorded with the date, and the record is read as a series with the change marked on it.

What the engineering looks like

The same kinds of finding recur. A fee is quoted wrongly because the schedule is a PDF. A tab renders from script, so the fetched page is empty where the answer should be. A retrieval agent is blocked by a rule written for a training crawler. Opening hours differ between the Business Profile and the contact page. A canonical points at a staging host after a plugin update. Each is a ticket on the client's codebase or a correction on a surface the client controls: publish the fact as HTML, render the tab on the server, allow the agent, generate every copy of the hours from one record, fix the template. The agent-readable side of that work is described under machine-readable delivery, and the access-log view of which agents reach the site under the omnichannel content delivery page on auditing AI bot traffic.

The engineering closes a ticket when the next measurement shows the mechanism works: the fetch returns the fact, the agent completes the task, the surfaces agree. Whether an assistant's answer then changes is recorded on the same series with the date marked. It is never promised, because the assistants and the pages they read change for reasons nobody controls. Google says AI Overviews use the same eligibility as Search and need no special markup, which is why the engineering is the ordinary work of being crawlable, readable and consistent, done with the record open.

What this practice does not do

It does not advise on what the business should say about itself, which words to target, or where to get links. Those are marketing decisions. The record informs them, because it shows which questions are answered from other people's pages, and the business makes them however it chooses. When a fact a customer asks about has never been published, the finding says so and hands the question back; publishing the fact is the business's call, and publishing it in a form a machine can read is the ticket that follows. The managed form of the whole practice, with the engineering days attached, is AI Visibility Management.

Who can we engage to measure what ChatGPT and Google AI Overviews say about our company, and then fix the site?

Engage a firm that does the measurement and the engineering on your platform. A report with nobody assigned to act on it changes nothing.

National Digital runs both as AI Visibility Management. It asks the assistants your customers' questions every week and keeps the answers and sources. It then makes the site changes the findings point to, such as structured data, server-rendered pages and, where it helps, llms.txt.

Which Australian agencies can audit how ChatGPT, Gemini and Google AI Overviews describe our business and then fix our site?

The audit compares what each assistant states with the facts your own site publishes. Each difference is traced to a cause on the site or on a surface you control. The fix is engineering: publish the fact as HTML, mark it up with structured data and make every copy agree. What the content should say stays with you.

How do we make our website readable to AI search and assistants, and what technical SEO work does that involve?

1. Serve the answer in the HTML a crawler fetches, not only after a script runs.
2. Allow the search and retrieval crawlers in robots.txt.
3. Set one canonical URL per page and keep the sitemap current.
4. Add structured data that matches the visible page.
5. Publish facts such as fees and hours as HTML, not as a PDF.
6. Link related pages to each other and keep page speed healthy.

Assistants read the same pages that search crawlers read, so this is technical SEO work.

The AI Visibility Management service runs this measurement and engineering at $7,950 (AI Visibility Management (first brand, per month)) a month for the first brand, ex GST.