Index methodology — how the Digital Visibility Score is measured

Every Local Digital Visibility Index is built the same way — same pillars, same weights, same data sources, same snapshot discipline. This page documents that method so the league tables stay comparable across cities and sectors, and so any reader (or any business that appears in one) can reproduce the numbers and judge what a score actually means.

The headline metric is the Digital Visibility Score — a 0–100 figure built from six pillars of objective, publicly-observable signals.

The six scoring pillars

Pillar	Weight	Signals (all programmatically gettable)
Speed & Core Web Vitals	20%	PageSpeed Insights / CrUX API — LCP, INP, CLS, mobile performance score
Technical foundation	20%	HTTPS, mobile-friendly, indexable, XML sitemap present, robots hygiene, valid structured data
Local presence	20%	Google Business Profile completeness, review count, average rating, review velocity (new reviews / 90 days), NAP consistency
Visibility	15%	Ranking visibility for a fixed local keyword basket; local-pack appearance
AI search presence	15%	Appearance in AI Overviews, ChatGPT search, Perplexity and Gemini for core local queries (see below)
Content & trust	10%	Indexed page count, about / team / credentials present, content freshness

Each pillar is scored 0–100, then combined by the weights above into the Digital Visibility Score. Pillar scores are always published alongside the headline number so a single figure never stands alone.

The “AI search presence” pillar

This pillar measures whether a business is actually surfaced by AI search engines for the queries its customers use. For each business we run a fixed basket of core local queries (for example “estate agents Bristol”, “best estate agent Clifton”) across AI Overviews, ChatGPT search, Perplexity and Gemini, and score the percentage of queries in which the business is named or cited.

Measuring this puts PYC in a deliberately meta position: we are the firm that measures who wins AI search in the South West. The pillar is re-run every quarter alongside the rest of the index, because AI-search visibility moves faster than classic rankings.

The deep scorecard

A single 0–100 number is thin. Every business in an index gets a diagnostic scorecard, not just a row in a table. The required format:

ACME ESTATE AGENTS — Bristol Estate Agent Digital Visibility Index, Q2 2026
Digital Visibility Score: 66 / 100   ·   Rank 12 of 18   ·   ▼ down 4 from Q1

PILLAR              SCORE   SECTOR MEDIAN   READING
Speed & CWV          51        78          ✗ Fails mobile CWV (LCP 4.8s vs 2.9s median)
Technical            70        85          ⚠ No LocalBusiness schema; sitemap stale
Local presence       62        74          ⚠ 38 GBP reviews vs leader's 412; 0 in 90d
Visibility           74        69          ✓ Above median on local-pack appearance
AI search presence   40        55          ✗ Absent from AI Overviews for 6/8 core terms
Content & trust      68        72          ⚠ No team/credentials page; blog stale 14mo

KEY FINDINGS  (self-contained, attributed, quotable)
• Mobile homepage LCP 4.8s — slowest quartile; likely losing mobile conversions
• No structured data — invisible as an entity to Google and LLMs
• Review velocity flat: 0 new reviews in 90 days vs sector median of 7
• Cited by zero AI engines for "estate agents Bristol" — 5 competitors are

VS THE LEADER (Beta & Co, 87)
Beta loads in 1.9s, has full schema, 412 reviews, appears in 7/8 AI answers.
The gap is almost entirely speed + reviews + structured data — all fixable.

TOP 3 FIXES (ranked by impact)
1. Cut mobile LCP below 2.5s (images / render-blocking) → biggest score + ranking lever
2. Add LocalBusiness + Review schema → entity visibility for Google and LLMs
3. Restart review generation → close the trust + local-pack gap

Every scorecard must include: the score and percentile rank within the sector; a pillar breakdown against the sector median; specific findings with measured values; quarter-on-quarter movement; the competitive gap to the leader; and prioritised, concrete fixes. Depth is deliberate — the more granular and stat-rich each scorecard is, the more useful it is to the business and the more extractable, citable facts it provides to AI search engines.

What counts as a measurement

A pillar signal is only used in a published index when it is:

Publicly observable — gathered from the live site, the public Google Business Profile, public SERPs, or public AI-search answers.
Machine-measured — produced by a documented tool or API, not a human judgement.
Dated — every index carries the snapshot date and names the source (“Measured 18 Jun 2026 via PageSpeed Insights API”).

Prior quarters stay published so movement is visible. The most-shared asset each quarter is the movers and fallers table that diffs the current snapshot against the last.

Context data that is recorded but never scored

Three further sources are collected alongside the pillars. None of them carries any weight in the Digital Visibility Score, and none can move a ranking. That separation is deliberate: a published score must never change because a third party enabled an API key, or because a business is small enough to be absent from someone else’s dataset.

A first-party crawl. Each site is crawled from its homepage — obeying robots.txt, one page at a time with a delay, capped by page count, depth and total time, identifying itself as PYCLocalIndexBot with a link to this page. It records click depth to key pages, internal links per page, the share of anchors that name nothing (“click here”, “read more”), and pages listed in the sitemap that were never reached by following links. Orphan counts are only reported when a crawl finished naturally: a crawl stopped by the page cap has unvisited pages by construction, and calling those orphans would be false.

Chrome UX Report (CrUX). The Speed pillar uses PageSpeed lab data — a synthetic run on Google’s hardware. CrUX is the field equivalent: real Chrome users, 28-day p75. Where both exist, the index publishes both.

CrUX has a coverage limit that matters here. Google only reports origins with enough traffic to be statistically meaningful, and most small local firms do not reach it — of the first twelve Gloucester accountancy practices tested, none had CrUX data, while a Bristol estate agency with far more traffic did. Absence therefore correlates with being small. Scoring on it would systematically penalise exactly the businesses least able to change it, which is why it is context and not a pillar.

Companies House. Company number, incorporation date, status and SIC code, matched on an exact normalised name against an active company — anything less confident records no match rather than guessing. This gives each business an official registry identifier rather than a name we matched on, and lets a cohort be read with company age and size in view, which is the fairest answer to “you are comparing a three-person firm with a fifty-person one”. The SIC code also states, from an authoritative source, what a company is registered to do.

Professional-regulator registers (SRA, Gas Safe, Propertymark) are not used. Their published crawl policies disallow the register search endpoints, and this project will not take data it has been asked not to take. Where an official rating is genuinely open — the FSA’s food hygiene ratings, for example — it may be used and will be named.

What this method will not do

These are guardrails, not preferences:

No subjective quality or trustworthiness claims about the businesses. The indices measure digital presence, never service quality.
Only objective, reproducible signals. If a skeptic cannot reproduce a number from this page, it does not go in an index.
A correction process on every page. Each index and scorecard carries a “Spotted an error? Request a correction” link. Corrections are made on verification, and a changelog records them.
UK GDPR: indices process business (not personal) data from public sources. No personal data is stored beyond what the business already publishes, and correction requests are honoured.

Publication conventions — built to be cited in AI search

Because the indices are unique, structured datasets, they are engineered so that AI search engines surface and cite them. These conventions are part of the methodology, not an afterthought:

Branded entities. Each index is named as a proper noun (e.g. “The PYC Bristol Estate Agent Digital Visibility Index”), and the headline metric is consistently called the Digital Visibility Score, so the terms themselves get quoted back.
Quotable stat sentences. Each index page carries several self-contained, dated, attributed factual sentences — for example: “As of Q2 2026, 61% of Bristol estate agents fail Google’s mobile Core Web Vitals threshold (PYC Digital Visibility Index, measured 18 Jun 2026).” These are written to be lifted verbatim with attribution.
Question-shaped headings that mirror how people query AI (“Which Bristol estate agent has the fastest website?”).
Structured data. Each index hub emits Dataset and ItemList schema; each scorecard references the business as a LocalBusiness.
Machine-readable exports. Every index is published as downloadable JSON and CSV, and the site’s llms.txt points AI crawlers at the datasets and at this methodology.

How this connects to the rest of the site

Methodology → applies → Knowledge Base. Each pillar is a measurable application of the local-SEO, technical, and structured-data strategy in the KB.
Methodology → is analysed with → Glossary. Scoring itself is plain arithmetic — ratios, weighted sums, a clamp — so that any published figure can be recomputed from the open dataset without trusting a model. The statistical methods in the glossary are the toolkit for interrogating results once published, not the scorer.
Methodology → feeds → Local Indices. Every published index and scorecard is built to this method.

Every change to this method, and every index refresh, is dated in the changelog.

Browse the Local Digital Visibility Indices or read the Knowledge Base for the strategy each pillar measures.