GuideOct 12, 202611 min read
From AI Visibility Gap to Live Fix: How Diagnose-Build-Ship Works
A dashboard tells you which buyer question the engines skip you on. Here is what happens between that row and a fix going live on your site, walked through one published case: the query, the cause, the draft, the approval, and the next scan.
- 7.3% → 23.4%recommendation rate in vendor-evaluation queries after one 8-week loop (Deckard Technologies)
- 2 → 22ChatGPT recommendations of the same brand, 8 April to 19 May 2026
- ~30items the Engine ships a month on Growth; around 8 a month on Starter
- 1A visibility gap is one row in a tracked query set: a buyer question, the engines that skipped you, who they recommended instead and the pages they cited. Everything downstream starts from that row, so a dashboard that only hands you a score cannot start the loop.
- 2The cause is read from the cited sources and sits in one of three layers: technical, your own content, or off-site presence. In the published Deckard Technologies case the cause was entity conflation, the models folding a new product into an established one, and the fix for that differs from the fix for absence.
- 3Fixes ship as unpublished drafts in WordPress, HubSpot, Webflow or Contentful, or as a pull request on a brandviz-agent/ branch in GitHub. There is no auto-publish mode; a person on your team presses Publish or Merge.
- 4Deckard’s loop ran 8 April to 19 May 2026 on HubSpot: schema, metadata and page restructuring first, then 16 content pieces. Recommendation rate in vendor-evaluation queries went 7.3% → 23.4% and ChatGPT recommendations 2 → 22.
- 5On Growth the Engine ships around 30 items a month, on Starter around 8. An item is one unit a person can approve on its own, a schema block on a page or a single content piece, and the pace is deliberate: surgical, not mass.
An AI visibility fix starts as one tracked buyer question where the engines skip you, gets a cause from the sources they cited, is built as a schema, metadata or content change, lands in your CMS as an unpublished draft, waits for a person to approve it, and is measured by the next scan of the same question. BrandViz.AI runs that loop as diagnose, build, ship, measure.
Most teams I talk to already have a dashboard. Somebody has run the buyer prompts through ChatGPT, maybe through the other three engines as well, and there's a sheet or a tool showing the score and the rows where a competitor gets recommended instead. The question I get on nearly every call after that is what happens next, in practice: who writes the schema, where does it go, who presses publish, and how do you know it did anything.
This post answers that with one published case rather than a framework. Deckard Technologies, a govtech platform serving 500+ jurisdictions, launched a long-term rental compliance product in early 2026 and ran an 8-week loop with us on HubSpot. The numbers are on the case study page and everything below is drawn from there. I picked it because it has every step in it, including a cause that wasn't the obvious one. The screens and terms (Tasks, Activity, Ready for Review) are ours; the shape of the loop is what I'd hold any tool to.
The loop, from the tracked row to the next scan
- Step 1
Scan
One tracked buyer question, the engines that skipped you, who they recommended, the pages they cited.
- Step 2
Diagnose
Technical, content or off-site. Conflation needs a different fix from absence.
- Step 3
Build
Schema, metadata, restructured pages, content pieces, in that order.
- Step 4
Ship
A draft in WordPress, HubSpot, Webflow or Contentful, or a pull request on GitHub.
- Step 5
Approve
A person publishes in the CMS or merges the pull request. Revisions become learned rules.
- Step 6
Measure
Same questions, same engines, per stage. Rows that did not move become the next tasks.
The scan shows the query where you're skipped
A tracked query set is a fixed list of buyer questions, asked the same way every scan across ChatGPT, Claude, Gemini and Perplexity, with each answer logged for whether you were named, whether your site was cited, whether you were recommended, and who else was. The gap is one row in that list, and the row carries the four things the rest of the loop needs: the question, the engines that skipped you, the brands they recommended instead, and the pages they cited to do it.
For Deckard the set was 150 questions across the US long-term rental compliance buyer journey, and the rows that mattered were the vendor-evaluation ones, where a council or county officer asks the engines to compare compliance platforms. At the 8 April 2026 baseline Deckard was recommended in 7.3% of those answers. The brand had plenty of weight elsewhere, because its short-term rental product had been in market for years, and that is exactly what made the row interesting.
The row is more useful than the score above it. A score of 5 out of 100 tells you to worry; a row tells you which question, on which engine, lost to whom, with the sources attached. In our own report for the week of 8 October 2026 the same brand on the same prompts scored 2.7 on Gemini and 10.2 on Claude, so even the per-engine split changes what you'd build. Stage cuts the same way, and the post on reading competitor recommendations by funnel stage goes through that in more detail than I will here.
Read the cited sources to find the cause
The cause comes from the sources under the row, and it sits in one of three layers: technical (can the engines fetch, parse and attribute the page), content (does a page on your site answer that question directly enough to be quoted), or off-site (are the directories and write-ups the models lean on carrying someone else). Rushana's three-layer frame is how we triage, and the layer decides what gets built.
Deckard's cause was in the first layer and it wasn't absence. The models had read plenty about Rentalscape, and they folded the new long-term rental product into the established short-term one; the case study's wording is that they "routinely conflated Rentalscape LTR with Rentalscape STR." The site wasn't telling the engines there were two products. The key pages carried no JSON-LD, the meta descriptions described the old category, and the About and product pages weren't structured so a crawler could resolve LTR as its own entity. Mid-sprint a canonicalisation issue on the LTR product page turned up as well, which is the kind of thing you only find once you're reading the page the way a crawler does.
That diagnosis matters because the fix for a wrong picture differs from the fix for no picture. Absence usually wants a page that answers the question, whereas conflation wants the entity work first (schema, consistent naming, a product page that stands on its own), because any content you write before that gets folded into the wrong entity along with everything else. The entity resolution guide covers the mechanism; the short version is that the models will take a source and state it as fact, and they're confident from very little, so you want the first thing they read about a new product to be unambiguous.
Approve the task and the Engine builds the fix
In the app the diagnosis doesn't act on its own. An audit or a content plan turns each cause into a task in the Tasks queue, and Mission Control's "Waiting on you" card points you at anything needing a decision. On each task you can Approve, Revise (describe what to change about the brief and it's rewritten in about 20 to 30 seconds), Edit the title or context yourself, or Dismiss. You can tick several and approve them in bulk, and set the destination, a CMS or a branch, for the whole batch at once.
Once a task is approved the Engine builds it with the brand already loaded: the brand definition, the products, the latest report, and any style guides or example posts you've uploaded. A technical task takes the short path, audit → approve → fixed. Content adds a step in the middle, plan → approve → draft → review. For Deckard the build split into the two layers below, and the order was deliberate: the entity and schema work went first so that when the content published through HubSpot it carried proper structured data from the day it went live.
Layer 1, shipped first: technical
- •JSON-LD (Organization, Service, FAQPage, Article) across every key page
- •Meta descriptions rewritten for accuracy and category positioning
- •About Us and core product pages restructured so LTR resolves as its own entity
- •Canonicalisation fix on the LTR product page, found mid-sprint
Layer 2, after the foundation: content
- •16 LTR-focused pieces, one per buyer-journey question the engines were being asked and nobody was answering
- •Researched from Deckard's internal documentation, sales conversations and category research
- •Written to regulatory accuracy, since the readers were compliance officers across 500+ jurisdictions
- •The standout, How AI Discovers Unregistered Long-Term Rentals
"I had no idea how to approach fixing the schema part of this, and my own searches still left me confused. Having the team manage this was painless and filled me with confidence."
Chloe Sasson, Chief of Staff and Director of Go To Market, Deckard Technologies, from the case study interview.
What goes into those JSON-LD blocks, and why the Organization one is the first thing we check on most of the sites we look at, is in the guide to automated schema markup for AI citations.
The fix lands in your CMS as an unpublished draft
Every fix arrives in the place your team already works, in a form that cannot go live on its own: a draft post or page in WordPress or HubSpot, a draft CMS item in Webflow, an unpublished entry in Contentful, or a pull request on a brandviz-agent/ branch in GitHub, never a push to main. There is no auto-publish mode, the integrations cannot delete your content, and the credentials stay server-side.
| Platform | What arrives | Where the schema goes | Where you approve |
|---|---|---|---|
| WordPress | Draft posts and pages in your Posts and Pages queue: blog posts, FAQ pages, landing-page rewrites, entity corrections | A JSON-LD block injected into the page head | wp-admin, when your team presses Publish |
| HubSpot | Draft blog posts and site pages in HubSpot CMS, under Drafts; pillar content and FAQ modules | The custom code head module, as a JSON-LD block you can inspect before activating | The HubSpot content editor, when your team publishes or schedules |
| Webflow | Draft CMS collection items (posts, FAQ entries) and staged SEO fields, mapped to your existing collection fields at setup | Webflow's custom code head field | Webflow, when your team publishes the site |
| Contentful | Unpublished entries in your chosen content type, following your content model | Field-level structured data mapped to your content model | Your own Contentful publish workflow; roles and approval stages stay intact |
| Git (GitHub) | A pull request on a brandviz-agent/ branch: MDX or Markdown posts, JSON-LD schema files, robots.txt and llms.txt updates | As files in the repository, with the import paths your site already uses | GitHub code review under your branch protection and CODEOWNERS; your developer merges |
Last verified against brandviz.ai/integrations and the per-platform integration guides, October 2026. Platforms not on the list receive the same fix as a brief in the Activity feed or a Google Doc: the copy, the JSON-LD block, the metadata, and where each piece goes.
Deckard's drafts landed in HubSpot. In the Activity feed a finished job shows as Ready for Review with buttons matched to where the work went: View Changes for a before-and-after preview of a CMS edit, View PR for a pull request, View Report for an audit, and View Content or Copy Content for a draft delivered in the app. On the GitHub route your build checks run on the branch before anyone opens it, and if the build fails the Engine fixes its own branch and pushes again rather than handing you a red check. The longer write-up of what each platform accepts is the guide to GEO platform CMS integrations.
You review, ask for changes, and press Publish
The final click is never ours. For a CMS draft that means your editor opens it in the editor they'd use for anything else and publishes or schedules it; for a pull request it means a developer reviews the diff and merges. For teams with a formal approval chain, a govtech buyer for instance, the draft sits in whatever stages HubSpot or Contentful already enforce, because the integration creates the entry and stops there.
Changes are asked for rather than made around the Engine. You tell it in the command bar ("make the intro of that draft punchier", "we don't say council, we say jurisdiction") and it revises the same draft in place, the same HubSpot post or the same pull request, with the history threaded in the Activity feed. Each request gets reduced to the durable rule behind it and saved under Brand voice, so the correction doesn't need repeating next month; the Teaching the Engine doc has the detail. Revisions are free on every plan, which counts for more than it sounds: a review step people hesitate to use because it costs something stops being a review step.
"As a marketer, what impressed me about the content workstream was the quality, clarity and volume produced. If I had briefed an internal team, this would have been several weeks if not months of work."
Chloe Sasson, Deckard Technologies, from the case study interview.
The next scan re-runs the same question
Measurement is the same tracked set run again on the plan's cadence, weekly on Growth and monthly on Starter, with the same four signals logged per engine and per stage. Nothing about the question changes, so a move in the row is read against what shipped in between, give or take the week-to-week variance an unchanged set shows on its own. For Deckard the baseline was 8 April 2026 and the final sprint report 19 May 2026.
| Metric | 8 April 2026 | 19 May 2026 | Change |
|---|---|---|---|
| Recommendation rate in vendor-evaluation queries | 7.3% | 23.4% | tripled |
| ChatGPT recommendations of Deckard | 2 | 22 | 11× |
| ChatGPT mention rate | 8.0% | 22.7% | nearly tripled |
| ChatGPT citation rate | 6.0% | 14.7% | 2.4× |
| Recommendation count, all four engines | 41 | 80 | doubled |
| Total brand mentions | 94 | 147 | +56% |
| Own-site citations | 94 | 140 | +49% |
From the published Deckard Technologies case study: 150 questions, four engines, US market. By the final report Deckard held 45.9% of category mentions and 50.4% of category citations.
The caveat is timing. A shipped fix only changes what the engines read the next time they fetch the page, and on the sites we track the gap between a fix going live and the row moving has run anywhere from 4 to 12 weeks, depending on how often each engine re-fetches and how contested the question is. Deckard's rows moved inside 6 weeks. Technical fixes tend to move faster than that and off-site gaps slower, and the next scan is how you find out which you've got rather than guessing. Rows that haven't moved become the next tasks, which is the arrow in the diagram going back to Step 1.
"Before, I knew there was a gym and I needed to exercise. Now I know what exercises to do."
Chloe Sasson, Deckard Technologies, from the case study testimonial.
How many fixes ship a month, and what counts as one
On the Growth plan the Engine ships around 30 items a month, and on Starter around 8. An item is one shipped unit of work a person can approve on its own: a JSON-LD block on a page, a rewritten set of metadata, a restructured page, a content piece, or on Growth a landing page. Deckard's 8 weeks covered schema across every key page, the meta rewrites, the restructured pages and 16 content pieces, run as a sprint rather than on a plan's monthly allowance.
Thirty is a pace rather than a target to hit for its own sake, and it is a long way from mass publishing. You can't write 30 unique insights a day, and the engines have been quick to downgrade pages that exist for a ranking rather than a reader. The pieces are scoped to the rows that lost, one per question, which is the "surgical, not mass" line Rushana uses on calls. Both plans come with unlimited seats, so the person approving a draft can be whoever owns that page rather than whoever holds the licence.
Two things the loop does not do
Off-site gaps, where a review directory or a roundup is carrying a rival's recommendation, come back as a task with instructions for a person, because nobody should be writing your review listings from a script. And no shipped fix guarantees wording: the engines are probabilistic, and what the loop controls is the quality and consistency of what they read about you.
Frequently asked questions
Does anything the Engine ships publish automatically?
No. Every integration delivers something that cannot go live on its own: an unpublished draft in WordPress, HubSpot, Webflow or Contentful, or a pull request on a brandviz-agent/ branch in GitHub, never a push to main. A person on your team presses Publish in the CMS or merges the pull request. The integrations cannot delete content and there is no auto-publish setting to turn on.
What if our site is not on WordPress, HubSpot, Webflow, Contentful or GitHub?
The Engine still builds the fix. It arrives as a complete brief in the Activity feed or as a Google Doc: the copy, the JSON-LD block, the metadata and where each piece goes, and your team applies it in the CMS. Sites built on Lovable, v0, Bolt or another AI app builder connect through their GitHub repository and get the pull request route.
How long after a fix goes live does the next scan show a change?
Across the sites BrandViz.AI tracks the gap between a fix publishing and the row moving has run roughly 4 to 12 weeks, depending on how often each engine re-fetches the page and how contested the question is. In the published Deckard Technologies case the vendor-evaluation recommendation rate went from 7.3% to 23.4% between the 8 April and 19 May 2026 reports, inside 6 weeks. On Growth the tracked set is refreshed weekly, so you see the row move rather than infer it.
Can someone who is not a developer approve a fix?
Yes, for every CMS route. A WordPress, HubSpot, Webflow or Contentful draft is reviewed and published in the same editor the team uses for its own content, and schema for those platforms is delivered as a JSON-LD block the reviewer can inspect in the head module or field before activating it. Only the GitHub route needs a developer, because the fix is a pull request reviewed under your branch protection and merged by whoever owns the repository.
If you've got a dashboard and a backlog, the test for any tool is whether it can carry one row through Steps 3 to 5 without your team doing the writing or waiting on the developer queue. That loop is what we built BrandViz.AI to run. Starter is $200 AUD a month for 50 tracked queries in one market, refreshed monthly, with around 8 items shipped a month; Growth is $1,000 AUD a month for 150 queries across up to 3 markets, refreshed weekly, with around 30. Nothing goes live without your approval. The free snapshot runs 25 buying scenarios on ChatGPT in about 10 minutes and hands you the rows to start from, and the Deckard case study has the full before-and-after if you want to see what one loop produced.
No credit card