How every number in the data section is produced

Every contractor website we audit goes through the same automated checks: Google's PageSpeed test on the phone setting, a real screenshot at 390 x 844 pixels, a tap test of that first screen, a certificate check on every form of the address, a set of nearby competitors found on the open map and measured the same way, and an answer-engine check of the page's code.

The monthly pieces in the data section are the sums of those checks across every site audited that month. Nothing is estimated and nothing is sampled by hand.

Which sites are measured

Two sources. Contractors who request the free audit on this site, and contractors in roofing, HVAC, plumbing, electrical and remodeling whose public business listings we audit before offering them the same written audit by email. A site enters the monthly numbers when its audit completes; sites that could not be reached at any address, or that turned out not to be a contractor, are counted separately and left out of the shares. We do not choose which sites to include after seeing the results.

The trade is read from the site itself (its words, its structured data, its listing category), not from the list we started with, so a plumber who also does HVAC is counted where the homepage says he is.

Load time on a phone

This is the measurement behind the speed guide. We call Google's PageSpeed Insights API with the mobile strategy and read the lab result: a simulated mid-range Android phone on a throttled connection, as Lighthouse defines it.¹ Two values are kept: the performance score (0 to 100) and the Largest Contentful Paint in seconds, the time until the biggest piece of content is on the screen.² We report against Google's own thresholds: 2.5 seconds or less is good, over 4 seconds is poor. A result is cached for seven days, so a site audited twice in a week is measured once.

What this is not: it is not the experience of a specific person on a specific phone. Lab numbers move a little between runs; the bands they fall in do not. Google's field data (what real Chrome users saw) exists for large sites but almost never for a local contractor, which is why we use the lab test for everyone.

The first phone screen

This is the measurement behind the first phone screen guide. A headless Chrome with a 390 x 844 pixel phone-sized window loads the page with certificate errors ignored (so the screenshot shows the page, and the certificate problem is reported on its own). It waits for the page to settle, then takes the screenshot the audit shows. A second pass runs a script on the same page that:

• finds every element inside the first 844 pixels that would place a call or open a booking: tel: links, and buttons or links whose text matches call, phone, schedule, book, estimate, quote, inspection, service;
• records the first one's size and position, or, if none is on the first screen, how far down the first one is;
• measures how much of the first screen is covered by any fixed or overlaid element that appeared after load (a pop-up, a cookie card, a chat window), as a share of the screen;
• compares a fingerprint of the page it tested with the page in the screenshot, so a redirect or a different pop-up on the second load does not get reported as a fact about the first.

A site counts as no call button on the first screen when the tap test found none there and the pages matched. A site counts as pop-up covers the first screen when the covered share is 25% or more. When the two pages did not match, the audit falls back to reading the page's code for a phone number in the first 700 characters, and the site is left out of the first-screen shares in the data pieces.

Security warnings

Before anything else, the audit tries the address four ways: https://, https://www., http:// and http://www., following redirects. The first that answers becomes the address for every later check. If the secure form answers but its certificate is expired, issued for a different name or not trusted, that is recorded as a certificate problem, because a phone shows a full-screen warning before such a site. A site counts as security warning in the data when that was recorded for the address a homeowner would type.

Nearby competitors

The audit confirms the site's town from the page itself (address, footer, service-area text) and only then searches for competitors; if the page does not confirm a town, no competitor comparison is made and the site is left out of the competitor shares. Competitors come from OpenStreetMap: businesses tagged with the same trade within the area around the confirmed town, found through the Overpass API, with the town located through Nominatim.³ Each competitor's homepage is fetched to confirm it is live and in the trade, then measured with the same PageSpeed test. "2 of 3 nearby competitors load faster" means that among competitors with a valid measurement, that many had a lower Largest Contentful Paint than the audited site by more than 0.05 seconds. Competitor speeds are cached for seven days; the competitor set for a town and trade for thirty.

The answer-engine check

This is the check behind the AI answers guide. A separate service reads the homepage's code and its robots.txt and records: which named AI crawlers are disallowed (GPTBot, ClaudeBot, PerplexityBot, Google-Extended and others), whether /llms.txt exists, which structured-data types are present and whether a business entity is declared, whether the headings form an outline, the content system the site runs on, the HTTP version, whether SSL is active, and whether the page names its town. It gives a score out of 100 that the audit prints; the data pieces report the individual shares, not the score, because the shares are the facts and the score is our weighting of them.

Built and not yet running: asking Google's AI the question a homeowner would ask about the trade in the confirmed town, recording which businesses it names, and checking the audited site and its competitors against that list; and the site's rank in Google Maps for the same query. Numbers from those checks appear in the data pieces only once they run for the whole month, and this page will describe exactly how the question is asked.

The jobs-a-year figure

The audit turns a slow load into "about N jobs a year" with every assumption printed: 500 visits a month, 65% on a phone, a share of phone visitors lost that rises with the load time (0% under 2.5 seconds, 5% to 4, 10% to 6, 15% to 10, 20% beyond), 3% of visits becoming a lead, 25% of leads becoming a job, and a category ticket per trade (for example $9,600 for a roof replacement). It is a scenario, labeled as one. The data pieces do not sum it; it depends on the assumptions and the trade, and we would rather publish the measured load times and let a reader apply their own numbers.

What is left out

• Sites that answered at no address, and sites that turned out not to be contractors.
• Any site whose audit failed partway (the screenshot service down, a timeout); it is retried, and counted when it completes.
• Sites audited more than once in a month are counted once, from the latest completed audit.
• Any measurement where the pages did not match, as described above.
• Our own site and our demo sites.

A monthly piece is published only when at least 300 sites in the trade completed in the month, so that a share is a share and not three sites.

Questions about the method