What our own research taught us about measuring AI-search visibility, and why a reassuring brand answer can hide a discovery problem.
Ask an AI search tool about your company and the answer can look convincing. It knows your name. It describes your services. It links to your website. Someone screenshots it, and the team has a small win to share.
We saw that in our own testing. Then we asked the questions a buyer might ask before they knew we existed.
The results were different.
On September 17, 2026, we collected 66 valid answers from two search-enabled APIs. When the question explicitly named SVZ, both providers consistently mentioned us and returned a source on our domain. Across a separate set of 26 discovery questions, OpenAI mentioned us once and Perplexity mentioned us twice.
We also checked the returned sources against our 37-post article library. None of those individual blog-post URLs appeared in the sample.
This was a small, dated observation, not a verdict on AI search or the value of publishing. But it exposed something worth paying attention to: testing whether a system recognizes your company is not the same as testing whether it will introduce you to a buyer.
The question changes what you are measuring
Our prompt panel contained 33 questions. We kept them in three groups: 26 discovery prompts, four explicitly branded prompts, and three comparison prompts.
The discovery group included questions such as:
- “best webflow agency for b2b saas”
- “webflow enterprise partner agency”
- “Recommend a design agency that combines brand design and Webflow development for B2B”
These are different jobs from “what is SVZ Design.” The branded question supplies the company. The discovery question asks the system to decide which companies belong in the answer.
Both matter. A buyer who has heard of you may use AI to investigate your work. Another may ask for a shortlist without knowing your name. Mixing those questions into one number makes it difficult to tell which part of that journey you are measuring.
For our four branded prompts, both available providers mentioned SVZ and returned an SVZ-domain source in all four answers. The discovery results were much thinner:
OpenAI, GPT-5.4 API with web search: one mention across 26 answers; no returned source on the production svz.io domain.
Perplexity, Sonar API: two mentions across 26 answers; one answer returned a source on svz.io.
We counted mentions and source appearances separately. Neither count tells you, by itself, whether the answer made a strong recommendation.
A staging URL changed the meaning of a zero
The OpenAI discovery answer that mentioned SVZ did include a link. It pointed to our enterprise page on a Webflow staging domain rather than svz.io.
Our frozen domain rule correctly recorded no production-domain citation. But stopping at that flag would have missed the actual behavior: the system had found a relevant SVZ page, just not at the production address we were measuring.
That distinction changes the follow-up. “We were not found” suggests one problem. “A staging page was returned instead of our production page” suggests an investigation into the two URLs, their content, canonical signals, links, and indexing state.
The observation did not establish why that URL was selected. It did tell us where to look.
Reading the answer added another distinction. SVZ appeared as an alternative while another agency received the primary recommendation. A name-matching script counted the mention. It could not replace the editorial judgment needed to understand our position in the response.
This is why we retain the answer and exact sources, not just the resulting score.
Thirty-seven articles did not equal thirty-seven sources
None of the 37 individual article URLs appeared among the sources returned in these 66 answers. Our blog index appeared, but an index link is not evidence that a particular article supported an answer. The homepage and enterprise page appeared more often.
There are several possible explanations. The panel emphasized agency selection and services, so commercial pages may have been a better match than many of the articles. Retrieval varies by provider. Our sample did not isolate the effects of content quality, internal linking, authority, or implementation.
It would be a stretch to conclude that the articles were useless. It would be just as much of a stretch to assume that publishing more articles would solve the observed gap.
The useful question is more specific: what decision should this page help someone make, and what does it contribute that they cannot get from a generic overview?
For a service page, that might be a clear account of fit, scope, constraints, and relevant work. For an article, it might be an original test, an implementation tradeoff, a documented failure, or a method someone can apply.
Counting those pages is easy. Evaluating their contribution takes more care.
Do not let one score stand in for five observations
We find it more useful to keep five questions visible.
Were we mentioned? A name appearing in an answer is a useful observation. It can be a recommendation, an alternative, or a passing reference. Record which.
Were we recommended for the actual need? Being listed as an agency is different from being suggested for a specific enterprise migration, brand problem, or ongoing website relationship.
Which sources were returned? Preserve exact URLs. A production service page, a staging page, a directory, and an individual case study are not interchangeable.
Was the description accurate? A citation makes a claim easier to inspect. It does not certify the claim. Read the source and check whether it supports what the answer says.
Did anything commercially useful happen? A referral visit, a relevant enquiry, and a new client are separate outcomes. An answer-level observation does not prove any of them.
A combined score can help summarize a stable measurement process. It should not make these differences disappear.
Missing data is not a bad result
We originally planned to collect answers from three providers. Gemini, accessed through OpenRouter, was unavailable after an access error. The remaining requests for that provider were blocked locally rather than repeatedly sent.
That left 66 valid answers from 99 planned prompt-provider pairs. We did not turn the unavailable observations into answers where SVZ was absent. We also did not lower the study's predefined coverage requirements to produce a complete-looking result.
The combined study did not qualify for an overall score.
That is an ordinary measurement decision, but an important one. A dashboard should distinguish between a system that returned an answer without your brand and a system you did not successfully observe. Otherwise, a collection failure can look like a change in market visibility.
What this means for a Webflow website
The website work starts with the information a buyer needs, then checks whether the implementation actually delivers it.
Make the relevant service pages clear about who the work is for, what is included, where the limits are, and what supports the claims. Connect useful articles and case studies to those pages with links that make sense to a reader. Keep important explanations available as text rather than only inside video or imagery.
Then inspect the published output.
A populated CMS field does not prove that the template displays it. A saved SEO title does not prove that it became the page's title tag. A successful request from a script does not prove that a provider's real crawler received the same response.
Check the rendered page, its title and description, canonical URL, links, image treatment, and content. Where structured data is used, make sure it agrees with what the reader can see.
Google's guidance for AI Overviews and AI Mode says a supporting page must be indexed and eligible to appear in Search with a snippet. It specifies no additional technical requirements. Its recommendations include crawlability, internal links, useful textual content, page experience, and structured data consistent with the page.
That guidance applies to Google's features. It is not a universal ranking formula for every answer engine, and our study did not test Google AI Overviews or AI Mode.
A practical way to run your own check
Start with a small panel of questions grounded in real buyer conversations. Separate branded questions, discovery questions, and comparisons before collecting anything.
Keep the wording stable. For each observation, save the provider, model, API or consumer channel, collection time, search-enabled state, complete answer, returned URLs, and any failure. Record geography or personalization settings where they can be controlled; state when they cannot.
Read the answers before deciding what the numbers mean. Follow the sources. Check whether the response describes your current offer accurately and whether the recommendation fits the question.
Repeat the panel to understand variation. If you change the website between runs, record what changed and when. Do not assume every subsequent difference was caused by that work.
A useful record is simple enough to inspect:
Question → collection conditions → answer → exact sources → interpretation → next check.
For the staging-page observation, the next check is technical. For a vague or inaccurate service description, it may be editorial. For an apparently accurate mention that produces no relevant enquiries, it may be a question about the audience or offer. The same generic “publish more content” response does not fit all three.
The question we would start with now
Our sample showed that the systems could identify SVZ when prompted by name. It gave us much less evidence that they would introduce us in the selected discovery questions.
The work is to understand that gap, not decorate it with a more flattering score.
When a buyer describes the work they need, does the answer give them an accurate reason to consider you? If it does, which evidence supports that recommendation? If it does not, what can you actually verify and improve?
That is a more useful brief for the next page, the next article, and the next measurement.
Study notes and sources
Download the complete prompt panel and 99-row results summary (CSV). Read the collection method and field definitions (TXT).
Collection: September 17, 2026, approximately 05:36 to 05:41 UTC. This article reports that historical snapshot, not current visibility.
Providers: OpenAI GPT-5.4 Responses API with web search and Perplexity Sonar API. One answer per prompt and available provider. These were not consumer-interface observations. Geography and personalization were not controlled.
Prompt groups: 26 discovery prompts, four brand prompts, and three comparisons. All comparisons were excluded from the discovery group, including comparisons that did not name SVZ. The complete prompt panel and row-level result summary are provided below.
Definitions: A mention was a configured SVZ-name match, not necessarily a recommendation. An SVZ-domain source meant a returned hostname matching svz.io or a subdomain, not necessarily sentence-level attribution. The Webflow staging URL did not meet that production-domain rule.
Coverage: 66 valid answers; 33 unavailable planned observations. No overall cross-provider score. The study does not establish causality, current rankings, referral traffic, or revenue impact. No direct trend comparison is made with our earlier tests because collection methods and model provenance differed.
Source material: SVZ's retained prompt panel, provider responses, exact returned URLs, collection records, and the accompanying 37-article audit. SVZ is reporting on its own website and has a commercial interest in the findings. External guidance: Google Search Central, AI features and your website, checked October 15, 2026.
Research and writing by Zay, SVZ's AI system, using retained SVZ research. Illustration adapted from SVZ's existing website artwork; it is not a visualization of measured data.
If your website needs to make a clearer case for the work you do, talk with SVZ.