--- url: /learn/from-ai-visibility-dashboard-to-fix title: "AI visibility dashboards show the problem. How do you fix it? — Siere Learn" description: "Monitoring tools tell you a model did not mention or cite you. They cannot tell you what an agent actually received from your URL, or repair it. This guide separates measurement from remediation and shows the loop that closes the gap." type: article language: en author: Tomislav Mladenov canonical: https://www.siere.ai/learn/from-ai-visibility-dashboard-to-fix last_modified: 2026-08-18 aeo_generated: 2026-08-24T15:05:05.518Z --- # AI visibility dashboards show the problem. How do you fix it? Monitoring tools tell you a model did not mention or cite you. They cannot tell you what an agent actually received from your URL, or repair it. This guide separates measurement from remediation and shows the loop that closes the gap. AuthorTomislav Mladenov Technical reviewerTomislav Mladenov Last verified2026-08-18 Evidence classObserved behaviour Audit dimensionFidelity Licence[CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) Scope · Any public website; observations about third-party AI answer engines are model- and date-dependent. Reading is optional. Running the check is the point. [See what an AI agent receives from your URL](/tools/agent-response-check) ## Two different questions An AI-visibility dashboard answers one question: *when a model was asked something relevant to us, did it mention, cite, rank or recommend us?* That is a downstream observation of a third-party system. It changes with the model version, the prompt, the date and the user's context, and the vendor does not publish how the answer was assembled. The delivery layer answers a different question: *when an AI agent requested one of our URLs, what did it actually receive?* That is a property of your own server. It is deterministic, inspectable and repairable, and you can show its state before and after a change. Both questions matter. Only the second one is something you control. ## What a dashboard cannot tell you Take a typical report line: "Brand X is cited in 12% of answers for query cluster Y." Useful as a trend. It cannot tell you: - whether the model's crawler ever received your product page, or only an empty application shell; - whether the crawler was blocked by `robots.txt`, a bot-management rule, a login wall or a geo redirect; - whether the response the crawler saw carried the same title, canonical URL, visible text and links as the page a person sees; - whether the structured data on the page was present in the source response or injected client-side after the fact. Each of those is a concrete, checkable delivery fault. Each of them can make the visibility number worse. None of them show up in a mention count. ## Why the delivery layer is where the fault usually is The main AI crawlers document that they fetch pages over HTTP with a declared User-Agent. [OpenAI](https://platform.openai.com/docs/bots), [Anthropic](https://support.claude.com/en/articles/8896518-does-anthropic-crawl-data-from-the-web-and-how-can-site-owners-block-the-crawler) and [Perplexity](https://docs.perplexity.ai/guides/bots) publish User-Agent strings, IP ranges and `robots.txt` tokens. None of them commit, on the verification date of this guide, to executing client-side JavaScript. Google documents rendering for Googlebot and, in its [JavaScript SEO guidance](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics), still recommends that important content and links be present in the server response. If your site is a client-rendered application — React, Vue, Angular, or a framework built on them without server rendering — the initial HTML response can contain a title, a script tag and very little else. A crawler that stops at the initial response receives that. What happens after that is unknowable from the outside and unlikely to be favourable. The failure is invisible in the browser because the browser executes the JavaScript. It is invisible in most SEO tools because they render pages. It is only visible if you look at the raw response with the request headers a crawler would send. ## The loop that closes the gap A monitoring product ends at "there is a problem". A delivery workflow continues: `Learn → Test → Find evidence → Fix → Verify → Monitor ` - **Test.** Request the URL as an ordinary client and again with a documented crawler User-Agent. Record status, redirects, `Content-Type`, title, canonical, visible text length, links and structured data for both. - **Find evidence.** Compare the two. A near-empty source response, a mismatched canonical, a missing title, an access gate returned only to the crawler, a `robots.txt` group that disallows the crawler — each is a specific finding with a specific remediation. - **Fix.** Server-render or prerender the route, adjust the crawler policy, or add a request-time path that serves recognized agents a complete, structured representation of the same content. - **Verify.** Run the same two requests again. The finding must be gone in the response, not in a screenshot. - **Monitor.** Sites regress: a deploy changes the shell, a WAF rule changes, a redirect appears. Re-run the comparison on a schedule and alert on drift. The free audit on this site runs step 1 and 2 for you and labels every observation with its evidence level (see [Recognized crawler versus verified crawler identity](/learn/recognized-vs-verified-crawler-identity)). Siere's middleware is one way to do step 3 without rewriting the human-facing page. Verification and monitoring are what the dashboard on your account is for. ## How to read the two kinds of evidence together Once you have both, use them in order: - **Delivery evidence first.** If the crawler receives a shell, is blocked, or gets a different page than a person, that is the fault to fix — regardless of what any model currently says. - **Visibility observations second.** After delivery is verified complete and consistent, mention and citation trends become a legitimate downstream signal. Treat changes as correlated with your fix, not caused by it, unless you have an experimental design that supports causation. - **Never the other way round.** Optimising copy or adding schema to a page a crawler cannot receive is work the crawler never sees. ## What "fixed" looks like A fixed URL has these properties in the raw source response, for both an ordinary request and a documented crawler request: Property Ordinary request Documented crawler request HTTP status 200 200 (no gate, no crawler-only redirect) Title and canonical present identical Visible text complete complete, or a complete structured representation of the same content Important links present present Structured data in the source in the source `robots.txt` — crawler group allowed for the path, if that is your policy Everything in that table is measurable without a browser and without a third party. That is what makes it proof rather than a report. ## What to do next Run the check at the top of this page on the URL your dashboard says is weakest. If the delivery evidence is clean, the visibility problem is content or authority and this site is not the tool for it. If it is not clean, you have found the thing the dashboard could not see — and a specific fix to make. ## What this proves - A visibility metric (mention, citation, ranking) is a downstream observation of a model, not a measurement of your site. - The agent-facing delivery layer of a URL can be inspected and repaired directly and its before/after state can be shown deterministically. ## What this does not prove - That fixing delivery will change any model's answer, citation, ranking or recommendation. - That any monitoring product is inaccurate; the point is what it measures. ## Reproduce it yourself - Pick a URL a dashboard reports as weak. Request it once as an ordinary client and once with a documented crawler User-Agent (see the crawler-testing guide). - Compare title, canonical, visible text and links between the two responses. - Run the free audit on the same URL and compare its dimension results with what the dashboard reported. ## Sources - [OpenAI — Overview of OpenAI crawlers](https://platform.openai.com/docs/bots) — OpenAI, accessed 2026-08-18 - [Google Search Central — JavaScript SEO basics](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics) — Google, accessed 2026-08-18 ## Change history - 2026-08-18First published. ## Related guides - [What AI agents actually receive from JavaScript websites Most AI crawlers fetch the initial HTML and move on. If your page is a client-rendered application, that response can be an empty shell. Here is what is in the response, how to inspect it, and how the free audit measures it.](/learn/what-ai-agents-receive-from-javascript-websites) - [Is llms.txt enough? Discovery versus delivery llms.txt tells an agent where to look. It does not change what the agent receives when it gets there. This guide separates the two problems and shows how each is checked.](/learn/is-llms-txt-enough) - [Recognized crawler versus verified crawler identity A User-Agent string is a claim, not proof. This guide explains the difference between recognizing a crawler and verifying it, which vendors publish verification methods, and why the audit labels every request with an evidence level.](/learn/recognized-vs-verified-crawler-identity) [What AI agents actually receive from JavaScript websites →](/learn/what-ai-agents-receive-from-javascript-websites) See what a recognized agent receives from your own URL. [See what an AI agent receives from your URL](/tools/agent-response-check) ## Structured Data ```json { "@context": "https://schema.org", "@type": "Organization", "@id": "https://www.siere.ai/#organization", "name": "Siere", "url": "https://www.siere.ai/", "logo": "https://www.siere.ai/social-square.png", "sameAs": [], "contactPoint": { "@type": "ContactPoint", "contactType": "customer support", "email": "contact@siere.ai", "url": "https://www.siere.ai/contact" } } ``` ```json { "@context": "https://schema.org", "@type": "WebSite", "@id": "https://www.siere.ai/#website", "name": "Siere", "url": "https://www.siere.ai/", "description": "Your website is invisible to AI agents. Siere fixes that. We make your site readable, structured, and optimized for the next generation of AI-powered search.", "publisher": { "@type": "Organization", "name": "Siere", "@id": "https://www.siere.ai/#organization" } } ``` ```json { "@context": "https://schema.org", "@type": "SoftwareApplication", "@id": "https://www.siere.ai/#software", "name": "Agent Experience Optimization", "url": "https://www.siere.ai/", "description": "Your website is invisible to AI agents. Siere fixes that. We make your site readable, structured, and optimized for the next generation of AI-powered search.", "applicationCategory": "BusinessApplication", "operatingSystem": "Web", "offers": [ { "@type": "Offer", "price": "0", "priceCurrency": "USD", "name": "Starter" }, { "@type": "Offer", "price": "99", "priceCurrency": "USD", "name": "Pro" } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "@id": "https://www.siere.ai/#faq", "url": "https://www.siere.ai/", "mainEntity": [ { "@type": "Question", "name": "What is Agent Experience Optimization?", "acceptedAnswer": { "@type": "Answer", "text": "AEO makes your website readable, structured, and reliably citable by AI agents like ChatGPT, Claude, Perplexity, and Gemini. Most modern websites are JavaScript-rendered and look like blank pages to AI crawlers — Siere fixes that without changing your visitor experience." } }, { "@type": "Question", "name": "How does Siere work?", "acceptedAnswer": { "@type": "Answer", "text": "Siere sits between your server and incoming requests. When an AI agent visits, Siere serves an optimized markdown version of your content. When a human visits, your normal page is served unchanged." } }, { "@type": "Question", "name": "Do I need to change my site?", "acceptedAnswer": { "@type": "Answer", "text": "No. Siere installs as middleware. There are no content changes or rewrites required." } } ] } ``` ```json { "@context": "https://schema.org", "@type": "TechArticle", "headline": "AI visibility dashboards show the problem. How do you fix it?", "description": "Monitoring tools tell you a model did not mention or cite you. They cannot tell you what an agent actually received from your URL, or repair it. This guide separates measurement from remediation and shows the loop that closes the gap.", "url": "https://www.siere.ai/learn/from-ai-visibility-dashboard-to-fix", "mainEntityOfPage": "https://www.siere.ai/learn/from-ai-visibility-dashboard-to-fix", "dateModified": "2026-08-18", "author": { "@type": "Person", "name": "Tomislav Mladenov" }, "publisher": { "@type": "Organization", "name": "Siere", "url": "https://www.siere.ai/" }, "license": "https://creativecommons.org/licenses/by/4.0/", "isAccessibleForFree": true, "keywords": "AI visibility, GEO tools, monitoring, remediation, Profound, dashboards", "citation": [ "https://platform.openai.com/docs/bots", "https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics" ] } ```