> ## Documentation Index
> Fetch the complete documentation index at: https://docs.obvlo.com/llms.txt
> Use this file to discover all available pages before exploring further.

# AI Visibility Health Check methodology

> How Obvlo measures AI visibility readiness, how the 0-100 score works, and how Agentic Browsing parity is tracked.

The **AI Visibility Health Check** measures how ready a site is to be discovered,
understood, cited, and used by search engines and AI assistants. It combines
technical crawlability, structured machine-readable signals, content quality,
and agent-readiness checks into a practical view that teams can act on.

The methodology is designed around two separate outputs:

| Output | What it means |
| - | - |
| **Obvlo AI Visibility Score** | A weighted 0-100 readiness score focused on commercial AI visibility. |
| **Agentic Browsing parity** | A separate pass-ratio style signal for applicable agent-readiness checks. |

## Overview

The health check audits your domain and one representative page on it across
**3 categories** and **23 individual check results**. Some checks are
informational and do not affect the 0-100 score.

| Category | Checks | Raw max | Displayed weight |
| - | - | -: | -: |
| Infrastructure | SSL, Sitemap, Robots.txt, Indexability, AI Crawler Accessibility, PageSpeed Performance, Layout Stability, PageSpeed Accessibility, PageSpeed Best Practices, PageSpeed SEO | 45 | 25 |
| AI readiness | Structured Data, FAQ Markup, WebMCP Schema Validity, llms.txt\*, Registered WebMCP Tools\*, Forms Missing Declarative WebMCP\* | 22 | 25 |
| Page analysis | Semantic HTML, Content Structure, Content Depth, Content Freshness, Citation Readiness, Internal Linking, Accessibility for Agents | 68 | 50 |
| **Total** | **23 check results** | **135** | **100** |

\*These checks are informational or non-scoring. They can still appear in
Agentic Browsing parity when the implementation marks the signal as applicable.

## How the score works

Each scored check produces a raw score. Raw scores are summed within their
category, then normalized to that category's displayed weight. This keeps the
headline score on a stable 0-100 scale even as individual check weights change.

The category weights are:

| Category | Score weight |
| - | -: |
| Infrastructure | 25 points |
| AI readiness | 25 points |
| Page analysis | 50 points |

For example, an Infrastructure raw score of 36 out of 45 becomes
`round((36 / 45) * 25) = 20` of the 25 Infrastructure points. The three
normalized category scores are then added together and capped at 100.

Individual check statuses usually follow these thresholds:

| Status | Threshold |
| - | - |
| Pass | At least 90% of the check's max score |
| Warn | At least 50%, but below pass |
| Fail | Below 50% |
| Info | Informational signal with no score impact |

Some checks have explicit outcome-based statuses where the implementation needs
to distinguish blocked, unavailable, or not-applicable results.

## How we choose the page to analyse

You enter a domain, not a page URL. Infrastructure and AI readiness checks look
at your domain, but page analysis needs one specific page — and your homepage is
usually a poor subject for content depth, freshness, and citation readiness.

To pick a page, Obvlo:

1. Looks for your sitemap at `/sitemap.xml`, `/sitemap_index.xml`,
   `/wp-sitemap.xml`, and any `Sitemap:` entry in your `robots.txt`.
2. Follows up to three child sitemaps when the sitemap is an index, preferring
   ones that look like post or article sitemaps.
3. Scores the URLs it finds and picks the strongest editorial page. Blog and
   article paths, `/YYYY/MM/` date segments, and descriptive slugs score higher.
   Listing pages, paginated archives, tag and author pages, and utility pages
   such as `/about` or `/pricing` are excluded.
4. Falls back to your homepage when no sitemap exists or the sitemap contains no
   article-like pages. When this happens the widget tells you, so a low content
   score is never read against a page you did not intend to test.

The page Obvlo picked is always shown in the results header.

<Note>
  Only pages on the domain you submitted are eligible. A sitemap that lists URLs
  on another host is ignored.
</Note>

### The same page, however you start the check

Selection works identically whether the check starts from the public AI readiness
checker, from a domain you add in the Obvlo portal, or from a scan an admin runs
on your behalf. Give any of them a bare domain and they pick the same page and
report the same scores.

Naming a specific page is the one thing that changes this: when you supply a URL
with a path, Obvlo analyses that page and skips selection entirely.

## How we fetch pages

Most checks need the analysed page's HTML. Obvlo uses a two-layer fetch model:

1. **Direct HTTPS fetch** with realistic browser headers. This mirrors the kind
   of request many search and AI crawlers send.
2. **Residential proxy fallback** when direct fetches are blocked by WAF or
   bot-protection systems such as Cloudflare or Sucuri.

**Access problems are reported once.** If we had to use the fallback to reach
your page, access is graded once.

**A HEAD request is never used to decide you are blocked.** We may send a quick
`HEAD` first as a hint, but a refusal there is only ever confirmed by attempting
the real `GET`. Content delivery networks routinely refuse or mishandle `HEAD`
while serving `GET` perfectly, and treating that as a block reported healthy
pages as firewall-blocked.

If both the direct request and the fallback fail, that is reported as an access
problem, with a confidence level attached rather than as a flat certainty — and
named for what actually refused us: bot protection, a rate limit, a certificate
fault, or a geographic restriction are four different problems.

Infrastructure checks can be cached briefly at domain level, while page-level
analysis uses the selected entry URL so the result reflects the specific page
being graded.

## Infrastructure

Infrastructure checks verify whether crawlers and agents can reach, trust,
render, and revisit the page reliably.

### 1. SSL certificate

**Max score: 3**

This check establishes a TLS connection to the domain on port 443 and reads the
certificate expiry and issuer chain.

| Outcome | Score | Status |
| - | -: | - |
| Valid certificate, chain verifies, more than 7 days until expiry | 3 | Pass |
| Valid certificate, fewer than 7 days until expiry | 2 | Warn |
| Certificate valid but the chain does not verify (usually a missing intermediate) | 1 | Warn |
| Certificate expired | 0 | Fail |
| Connected over TLS but no certificate could be read | 0 | Fail |
| No TLS handshake at all — the site is not served over HTTPS | 0 | Fail |

<Note>
  **An unverifiable chain is not a missing certificate.** If your server does not
  send its intermediate certificate, browsers quietly fetch the missing piece
  themselves, so visitors see nothing wrong — but strict clients, including many
  crawlers, cannot verify the connection and fail. That is reported as a chain
  problem, naming the intermediate as the likely cause.

  The expiry warning fires inside **7 days**, not 14. Automated issuers renew
  around 30 days out, so a longer window flagged healthy auto-renewing setups.
</Note>

HTTPS is a prerequisite for modern search and AI crawler access. A missing,
expired, or incomplete certificate can make a site unreachable to automated
clients even when it appears to load in a human browser.

Incomplete certificate chains matter because browsers often cache or fetch
missing intermediate certificates automatically. Standard crawler clients often
do not. The fix is to configure the server or CDN to present the full certificate
chain.

### 2. Sitemap

**Max score: 4**

This check probes common sitemap locations, then falls back to sitemap directives
inside `robots.txt`:

* `/sitemap.xml`
* `/sitemap_index.xml`
* `/wp-sitemap.xml`
* `Sitemap:` entries in `robots.txt`

| Outcome | Score | Status |
| - | -: | - |
| Valid XML sitemap found | 4 | Pass |
| Blocked by WAF or bot protection | 0 | Warn |
| No sitemap found | 0 | Fail |

A sitemap gives crawlers a machine-readable index of the pages a site wants
discovered. Without one, crawlers must rely on links alone, which can miss new,
deep, or orphaned pages.

### 3. Robots.txt

**Max score: 4**

This check fetches `/robots.txt` and evaluates validity, sitemap references,
blanket blocking, and AI crawler directives.

| Signal | Score impact |
| - | -: |
| Valid robots.txt with a sitemap reference | +2 |
| AI directives present and no search-mode bots blocked | +2 |
| AI directives present but some search-mode bots blocked | +1 |
| No AI-specific directives | +0 |
| Blanket `Disallow: /` | Fails the check |

Obvlo distinguishes search-mode bots from training-mode bots:

| Category | Examples | Blocking impact |
| - | - | - |
| Search-mode bots | OAI-SearchBot, PerplexityBot, Bingbot | Penalized because content may lose AI answer visibility. |
| Training-mode bots | GPTBot, ChatGPT-User, Google-Extended, ClaudeBot | Treated as a legitimate content-protection choice. |

Robots.txt is the gatekeeper for automated access. A forgotten staging rule or
overbroad AI-blocking policy can quietly remove a site from AI discovery.

### 4. Indexability and snippet eligibility

**Max score: 4**

This check scans the entry page for directives that prevent indexing or prevent
the page from being shown with snippets. It checks:

* `<meta name="robots">`
* `<meta name="googlebot">`
* `X-Robots-Tag` response headers
* `data-nosnippet` attributes in page content

| Outcome | Score | Status |
| - | -: | - |
| Indexable, no snippet restrictions | 4 | Pass |
| `data-nosnippet` present on some content | 3 | Warn |
| Restrictive `max-snippet` from 1 to 49 characters | 2 | Warn |
| `nosnippet` or `max-snippet:0` | 0 | Fail |
| `noindex` or `none` | 0 | Fail |
| WAF or SSL issue prevents verification | 0 | Warn |

Google's AI features require pages to be indexed and eligible for snippets.
These directives are easy to leave behind from staging builds, CMS defaults, or
privacy settings, and they can cap visibility regardless of content quality.

### 5. AI crawler accessibility

**Max score: 5**

This check asks for your page three times, as three different kinds of client,
and compares the answers:

| Identity | What it tells us |
| - | - |
| An ordinary browser | Whether the page works for people at all |
| A declared AI crawler (GPTBot) | Whether AI crawlers are being allowed or refused |
| A plain script (`curl`) | Whether a refusal is aimed at AI specifically, or at all automation |

Asking as only one client cannot tell those apart, and the distinction changes
the answer completely. A site can refuse a generic scraper while welcoming
GPTBot — because verified crawlers arrive from published IP ranges that many
firewalls allowlist by default. A site can also serve browsers perfectly while
refusing GPTBot **by name**, which is the case that actually costs you AI
visibility.

| Outcome | Score | Status |
| - | -: | - |
| Served to browsers and to AI crawlers | 5 | Pass |
| Our generic scraper refused, but the AI crawler served in full | 5 | Pass |
| Automation refused, but search indexing shows crawlers do get through | 4 | Warn |
| A JavaScript challenge stands between crawlers and the content | 3 | Warn |
| All non-browser clients refused, AI crawlers included | 2 | Warn |
| Access could not be established either way | 1 | Warn |
| AI crawlers refused by name while other clients are served | 0 | Fail |
| Nothing could retrieve the page | 0 | Fail |
| Rate-limited during the scan | 3 | Info |

<Note>
  **What this check can and cannot prove.** We hold GPTBot's user agent but not
  OpenAI's IP ranges. So a **successful** AI-crawler fetch is proof that your page
  is being served; a **refused** one is a strong signal, not a certainty, because
  the real crawler may still be allowlisted by address. Every result carries a
  confidence level — `confirmed`, `likely`, or `unverified` — and we never state
  that AI assistants cannot cite you, because assistants also cite pages from
  search indexes without fetching them directly.
</Note>

**Rate limiting is not a block.** If your server replies with HTTP 429 or 503
while we are scanning, that is about request throughput, not bot policy. It is
reported as informational and does not count against you.

**We check for a second opinion.** When a page looks blocked, we also check
whether a major search engine already has it indexed. If it does, some crawler
has plainly fetched it, so the block is not absolute and we cap the severity
accordingly rather than overstating it.

**We compare your stated policy with what actually happens.** If your
`robots.txt` welcomes GPTBot but your firewall turns it away, the two disagree
and you almost certainly did not intend that — so we say so explicitly, rather
than telling you to go and review your firewall settings.

### 6. PageSpeed and layout stability

**Max score: 25 total, split across 5 sub-checks**

Obvlo runs the analysed page through the Google PageSpeed Insights API in mobile
mode. Four Lighthouse categories are scored, and the Performance response also
provides the Cumulative Layout Shift signal used for Layout Stability.

| Sub-check | Source | Max score |
| - | - | -: |
| PageSpeed Performance | Lighthouse Performance score | 5 |
| Layout Stability | Lighthouse Cumulative Layout Shift audit | 5 |
| PageSpeed Accessibility | Lighthouse Accessibility score | 5 |
| PageSpeed Best Practices | Lighthouse Best Practices score | 5 |
| PageSpeed SEO | Lighthouse SEO score | 5 |

For the four Lighthouse category scores, percentages are mapped to 0-5 points:

| Lighthouse score | Mapped score | Status |
| - | -: | - |
| 90-100 | 5 | Pass |
| 50-89 | 3-4 | Warn |
| 20-49 | 1-2 | Fail |
| 0-19 | 0 | Fail |

If a PageSpeed category request fails, the check returns a warning result worth 2
out of 5 rather than failing the whole health check.

Layout Stability maps the Lighthouse Cumulative Layout Shift audit score to 0-5
points. A stable layout helps agents click and type into intended elements
reliably, because buttons and fields are less likely to move between detection
and interaction.

## AI readiness

AI readiness checks evaluate whether the page provides structured signals that
help AI systems understand content, extract answers, and identify agent-usable
actions.

### 7. Structured data

**Max score: 12**

This check extracts JSON-LD structured data from the homepage and the selected
entry page. Schema types are grouped into site-level and page-level signals.

| Group | Schema types scored | Purpose |
| - | - | - |
| Site-level | Organization, LocalBusiness, Hotel, LodgingBusiness, WebSite, WebPage | Establishes entity identity. |
| Page-level | Article, BlogPosting, NewsArticle, HowTo, FAQPage, BreadcrumbList, TouristDestination, Event, Product, Review | Describes the page content type. |

| Condition | Score |
| - | -: |
| 2 or more site-level types | 6 |
| 1 site-level type | 4 |
| 2 or more page-level types | 6 |
| 1 page-level type | 4 |
| No structured data | 0 |

Structured data is not a special prerequisite for Google's AI features, but it
does help with rich results and entity understanding. It is especially useful for
non-Google AI engines and travel or hospitality pages where business, location,
property, event, review, and article entities need to be unambiguous.

### 8. FAQ markup

**Max score: 6**

This check looks for machine-readable FAQ schema and visible FAQ-style HTML.

| Outcome | Score | Status |
| - | -: | - |
| `FAQPage` JSON-LD found | 6 | Pass |
| FAQ-style HTML found without schema | 3 | Warn |
| No FAQ content or schema | 0 | Fail |

FAQ-formatted content gives AI assistants liftable question-and-answer units.
Google has deprecated FAQ rich results for most sites, so this check has a
moderate weight. The broader value is in clear, question-led content that can be
extracted and cited.

### 9. llms.txt

**Max score: 0**

This check requests `/llms.txt` and, when present, also checks for
`/llms-full.txt`.

| Outcome | Score | Status |
| - | -: | - |
| `llms.txt` found | 0 | Info |
| `llms.txt` and `llms-full.txt` found | 0 | Info |
| `llms.txt` missing | 0 | Info, not applicable |
| Retrieval blocked or server error | 0 | Warn |

The file is treated as optional because evidence of broad crawler adoption is
still mixed and Google does not require special AI files. Missing `llms.txt` does
not reduce the AI Visibility Score. Retrieval failures can still produce a
warning because they may indicate that machine-readable resources are not
consistently reachable.

### 10. Registered WebMCP tools

**Max score: 0**

This informational check looks for WebMCP-style tool registration signals:

* Declarative elements with a `toolname` attribute
* Imperative calls to `document.modelContext.registerTool(...)`

Registered tools help capable agents understand which site actions exist, but
the signal is experimental and currently does not affect the 0-100 score.

### 11. Forms missing declarative WebMCP

**Max score: 0**

This informational check counts page forms and whether each form includes both:

* `toolname`
* `tooldescription`

If the page has no forms, the signal is not applicable. If forms exist but lack
complete declarative WebMCP metadata, the result explains how many are missing
it. This does not affect the AI Visibility Score, but it helps teams identify
where agent-readable form metadata could improve future interaction readiness.

### 12. WebMCP schema validity

**Max score: 4**

This scored check validates whether WebMCP-style form metadata is complete enough
for agents to understand.

| Outcome | Score | Status |
| - | -: | - |
| Valid WebMCP tool forms found | 4 | Pass |
| No forms found | 4 | Pass |
| Plain forms found but no WebMCP tool metadata | 2 | Warn |
| Metadata is usable but has warnings | 2 | Warn |
| Blocking metadata issues found | 0 | Fail |
| Page cannot be fetched for validation | 0 | Warn |

Blocking issues include a tool form with `toolname` but no `tooldescription`, a
tool form with `tooldescription` but no `toolname`, or user-supplied fields in a
tool form without a `name` attribute. Warnings include named fields that lack a
label or `toolparamdescription`.

This check is scored because incomplete action metadata can make agent-operated
forms unreliable.

## Page analysis

Page analysis checks evaluate the actual content and HTML structure that
determine whether AI systems can select, summarize, cite, and operate the page.

Where possible, these checks focus on the primary content area rather than site
chrome such as headers, navigation, and footers.

### 13. Semantic HTML and meta

**Max score: 10**

This check evaluates page structure and metadata signals.

| Aspect | Max | What is checked |
| - | -: | - |
| Semantic elements | 3 | Presence of elements such as `<article>`, `<main>`, `<section>`, `<nav>`, `<aside>`, `<header>`, and `<footer>`. |
| Title and meta description | 2 | Title exists and is no more than 70 characters; meta description is 50-160 characters. |
| Canonical URL | 1 | `<link rel="canonical">` is present. |
| Open Graph and Twitter cards | 2 | At least three of `og:title`, `og:description`, `og:image`, and `twitter:card`. |
| Language declaration | 1 | `lang` attribute on the `<html>` element. |
| ARIA landmarks | 1 | Explicit landmark roles or implicit landmarks such as `<main>`. |

Semantic markup helps AI systems identify primary content, navigation,
supporting sections, and page summaries instead of treating the page as one
undifferentiated text block.

### 14. Content structure

**Max score: 12**

This check evaluates how well the content is organized for fragment extraction.

| Aspect | Max | Criteria |
| - | -: | - |
| Heading hierarchy | 3 | Single H1, no skipped heading levels, descriptive heading text. |
| Q\&A format | 2 | Headings phrased as questions. |
| Snippable content | 3 | Lists, tables, `<details>` elements, and inline-list paragraphs. |
| Front-loaded answers | 2 | Section-opening paragraphs are concise and answer-bearing. |
| Self-contained sections | 2 | Sections make sense without relying on phrases such as "as mentioned above". |

AI systems extract fragments rather than whole pages. Clear headings, lists,
tables, and concise section openings make content easier to match to user
queries and cite in answers.

### 15. Content depth

**Max score: 10**

This check evaluates whether the page has enough substance to serve as a
credible citation source.

| Aspect | Max | Criteria |
| - | -: | - |
| Word count | 3 | At least 800 words = 3, at least 500 = 2, at least 300 = 1. |
| Topic coverage | 3 | Unique H2/H3 sub-topics: at least 5 = 3, at least 3 = 2, at least 1 = 1. |
| Factual density | 2 | Statistics, percentages, dates, measurements, or currencies. |
| Content visibility | 2 | Penalizes substantive content hidden in accordions, tabs, or collapsed elements. |

If a page returns fewer than 300 words and shows client-side application
fingerprints such as empty root containers, `__NEXT_DATA__`, Nuxt markers, React
root markers, or Angular `ng-version`, Obvlo flags a high-impact recommendation
to add server-side rendering or pre-rendering.

### 16. Content freshness

**Max score: 8**

This check evaluates whether the page shows current and recently reviewed
signals.

| Aspect | Max | Criteria |
| - | -: | - |
| JSON-LD date metadata | 3 | Recent `dateModified` earns the highest score; older or publish-only dates earn less. |
| Last-Modified HTTP header | 2 | Recent server-level modification headers earn more. |
| Visible dates | 1 | Publication or update dates visible to users. |
| Time-sensitive signals | 2 | Current year, "updated" language, or seasonal context. |

Freshness helps retrieval systems choose content that is likely to be current.
The `dateModified` signal is especially useful because it indicates active
review rather than one-time publication.

### 17. Citation readiness

**Max score: 10**

This check evaluates whether an AI system can confidently cite the page with
attribution.

| Aspect | Max | Criteria |
| - | -: | - |
| External references | 3 | Outbound links to authoritative external domains from primary content. |
| Statistics and data | 2 | Percentages, measurements, study references, or "according to" phrases. |
| Quotations | 2 | Blockquotes, `<q>` elements, or meaningful inline quotes. |
| Author and expertise signals | 2 | Author schema, byline elements, or `rel="author"` links. |
| Marketing fluff penalty | -1 | Penalizes excessive vague superlatives. |

Social media, CDN, font, and self-referencing links are excluded from the
external reference count. The goal is to measure verifiable supporting sources,
not navigation or branding links.

### 18. Internal linking

**Max score: 10**

This check evaluates whether the page connects to other useful pages on the same
site.

| Aspect | Max | Criteria |
| - | -: | - |
| Internal link count | 3 | Links from primary content to other pages on the same site. |
| Link text quality | 2 | Descriptive anchor text instead of generic labels such as "click here". |
| Breadcrumb navigation | 2 | Breadcrumb schema and visible breadcrumbs. |
| Linked page quality | 3 | Up to five linked pages are fetched to verify they are reachable. |

Internal links help crawlers and AI systems discover related pages and understand
how topics connect. Descriptive anchor text helps them decide which links are
worth following.

### 19. Accessibility for agents

**Max score: 8**

This check evaluates a focused accessibility subset that matters for agents using
the accessibility tree to identify controls and operate pages.

| Aspect | Max | Criteria |
| - | -: | - |
| Named interactive elements | 3 | Links, buttons, inputs, selects, textareas, and role-based controls have accessible names. |
| Labelled form fields | 2 | User-supplied form fields have labels or equivalent accessible names. |
| Visible interactive elements | 2 | Interactive elements are not hidden from the accessibility tree. |
| Valid role relationships | 1 | For example, `menuitem` roles appear inside `menu` or `menubar` containers. |

| Score | Status |
| -: | - |
| 7-8 | Pass |
| 4-6 | Warn |
| 0-3 | Fail |

This is separate from the Lighthouse Accessibility score. Lighthouse measures a
broader accessibility baseline; this check focuses on whether agents can name,
find, and operate key controls.

## Agentic Browsing parity

Google's Lighthouse Agentic Browsing category is experimental. Obvlo does not
fold it directly into the 0-100 AI Visibility Score.

Instead, Obvlo reports **Agentic Browsing parity** separately. The parity result
counts applicable agent-readiness checks and reports:

| Field | Meaning |
| - | - |
| Passed | Applicable checks with `pass` or `info` status. |
| Warnings | Applicable checks with `warn` status. |
| Failed | Applicable checks with `fail` status. |
| Applicable | Total checks included in the parity calculation. |
| Ratio | `passed / applicable`, rounded to two decimal places. |
| Status | `pass`, `warn`, `fail`, or `not-applicable`. |

The current parity calculation considers these check IDs when they are marked
applicable by the health-check implementation:

| Check | Category | Score impact |
| - | - | - |
| `llms.txt` | AI readiness | No 0-100 score impact. Missing files are not applicable; found files and retrieval warnings are applicable. |
| Registered WebMCP Tools | AI readiness | Informational. Currently surfaced as a discovery signal rather than a scored requirement. |
| Forms Missing Declarative WebMCP | AI readiness | Informational. Applicable when forms exist. |
| WebMCP Schema Validity | AI readiness | Scored, max 4. |
| Layout Stability | Infrastructure | Scored, max 5. |
| Accessibility for Agents | Page analysis | Scored, max 8. |

Parity status is intentionally stricter than the 0-100 score summary:

| Condition | Parity status |
| - | - |
| No applicable checks | Not applicable |
| Any applicable check failed | Fail |
| No failures, but at least one warning | Warn |
| All applicable checks passed or were informational | Pass |

<Note>
  Agentic Browsing parity is a methodology signal. It is not a promise that any
  specific AI assistant will use a site in a specific way.
</Note>

## Score interpretation guide

The overall score is normalized to a 0-100 scale.

| Overall score | Rating | Interpretation |
| - | - | - |
| 90-100 | Excellent | The site is highly ready for AI visibility. Content should be competitive in AI-generated answers. |
| 75-89 | Good | Strong foundation with specific areas to improve. |
| 50-74 | Needs work | Significant gaps remain. Competitors with stronger foundations may be cited more often. |
| 25-49 | Poor | Major crawlability, structure, or content issues are limiting AI visibility. |
| 0-24 | Critical | The site may be effectively invisible or unusable for many AI systems. |

## What changed in the latest methodology update

The latest implementation update added Agentic Browsing parity while keeping the
AI Visibility Score normalized to 100.

**Added**

* **AI Crawler Accessibility** as a scored Infrastructure check worth 5 raw
  points.
* **Layout Stability** as a scored Infrastructure sub-check worth 5 raw points,
  derived from Lighthouse Cumulative Layout Shift.
* **Registered WebMCP Tools** as an informational AI readiness signal.
* **Forms Missing Declarative WebMCP** as an informational AI readiness signal.
* **WebMCP Schema Validity** as a scored AI readiness check worth 4 raw points.
* **Accessibility for Agents** as a scored Page Analysis check worth 8 raw
  points.
* **Agentic Browsing parity** as a separate stored and streamed result with
  passed, applicable, warning, failed, ratio, and status fields.

**Changed**

* Infrastructure raw max increased to 45.
* AI Readiness raw max increased to 22.
* Page Analysis raw max increased to 68.
* `llms.txt` remains non-scoring and optional, but blocked or server-error
  retrieval can now count as an applicable warning for parity.
* The 0-100 score remains category-normalized at 25 / 25 / 50, so new raw checks
  do not make the overall score exceed 100.

## Why scores may change over time

Scores can change when:

* A site changes templates, content, redirects, firewall rules, or analytics
  setup.
* Search engines and AI assistants change how they fetch and interpret pages.
* Obvlo updates the methodology to reflect stronger evidence or new public
  guidance.
* Optional emerging checks move from informational to warning-capable or scored
  once the underlying standard becomes more stable.

When methodology changes affect customer interpretation, Obvlo documents the
change and keeps the 0-100 AI Visibility Score separate from experimental parity
signals.

## How to improve your score

The most reliable improvements come from practical fundamentals:

* Keep pages crawlable without blocking legitimate search and AI crawlers.
* Publish clean sitemaps and avoid accidental `noindex` or `nosnippet` rules.
* Use HTTPS with a complete certificate chain.
* Improve mobile performance and reduce layout shift.
* Add structured data for key page types and business entities.
* Write useful, specific content with clear headings and citation-ready facts.
* Use semantic HTML, descriptive links, and accessible labels for controls and
  forms.
* Keep content fresh and internally linked.
* Treat WebMCP and `llms.txt` as emerging enhancements, especially for important
  forms and workflows.

The health check recommendations show which actions are most relevant for the
specific checks that failed or warned on your page, so you can focus on what
will move your score fastest.

## Related

* [Measure \u2014 AI Search Visibility](/product/insights/ai-search-visibility-measure)
* [Performance reporting](/product/delivery/microsite/performance-reporting)
* [Visibility reporting](/product/delivery/microsite/visibility-reporting)
  specific page being tested.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.