The State of Kansas City Small-Business Websites (2026)
I build websites for small businesses in Kansas City, so I wanted to know — honestly, with real numbers — what shape the local field is actually in. Not a hunch, not a sales line. A measurement.
So I took a random sample of 105 locally-owned KC small-business websites across seven categories, ran each through Google's PageSpeed Insights three times, and pulled the real-user data where it existed. No cherry-picking: the sample comes from public map data with a fixed, reproducible method — the whole method and the exact query are at the bottom, so you can check my work. I'm not naming a single business; this is about the market, not any one shop.
Here's what I found, good news first.
What real visitors actually experience
The most honest measure of a website's speed isn't a lab test — it's what real people on real phones actually get. Google collects that (it's called field data, or CrUX), but only for sites with enough traffic to fill out a sample. In my sample, 40 of the 105 sites had it.
Among those 40, the picture is genuinely okay. Twenty-two rate 'fast' overall, 13 'average', and 5 'slow'. 57.5% pass all three of Google's Core Web Vitals — the actual pass/fail bar Google uses. The median real-user LCP (how long until the main content shows up) is 1.85 seconds; median responsiveness (INP) is 97 milliseconds; median layout shift is 0.005, which is to say basically none.
If that were the whole story, KC small-business websites would be in fine shape. It isn't the whole story. It's the best part of it — and it only covers a minority of the sites.
The invisible majority
Here's the catch: 62% of the sites I tested — 65 of 105 — don't have enough traffic for Google to report any real-user data at all. There simply aren't enough monthly visitors to build a sample.
That's a finding in itself. Most small-business sites are quiet. And it has a hard practical consequence: when there's no real-user data, the only number that exists — the number a prospective customer sees if they ever check your site on Google's own tool — is the lab test.
What a prospect actually sees: the lab score
Google's lab test (the score at pagespeed.web.dev) loads your site on a simulated mid-range phone throttled to a slow mobile connection, and grades it 0 to 100. It's deliberately harsh — a stress test, not a stopwatch of real life. I want to be clear about that: the lab number is not what your visitors on good phones and good wifi experience.
But it matters, for two reasons. First, for the 62% of sites with no field data, it's the only score that exists. Second, it's the number that shows up when anyone — a customer, a competitor, a web developer writing a study — types your address into Google's checker. Fair or not, it's the visible grade.
Across all 105 sites, the median lab mobile speed score is 55 out of 100. 39% score under 50, Google's 'poor' band. Only 7.6% score 90 or above, the 'good' band. The median lab LCP is about 10 seconds — again, that's the throttled test, not lived experience — but ten seconds is what the stress test returns for half of these sites.
About that gap
You may have noticed the gap: median real-user LCP was 1.85 seconds, but median lab LCP was about 10. That gap is real, and it's mostly the throttling — the lab deliberately simulates a weak phone on a weak connection, so it always looks worse than a typical visitor's experience.
Neither number is a lie; they answer different questions. Field data answers 'what do my actual visitors get?' The lab answers 'how does this hold up under stress, and what does the public grade say?' The honest way to read this study: trust the field data where it exists, treat the lab score as a stress test and as the visible number — and remember that for most of these sites, the stress test is the only test there is.
What a plugin can fix — and what it can't
Here's the pattern that ties it all together, and it's the real story. The parts of a website you can automate with a plugin look fine — and they look fine everywhere. The one part you can't, doesn't.
Look at what's uniform. The median SEO score is 92 — identical, in every single category. Structured data (the schema markup that helps Google and AI understand a page) is present on 60.2% of sites. Even llms.txt, the new file that summarizes a site for AI, already shows up on 26.7% of them — and at least 8 of those 28 are literally stamped 'Generated by' an SEO plugin, with most of the rest looking the same. None of that took intent. WordPress SEO plugins — Yoast, Rank Math, All in One SEO — generate all of it automatically. Install the plugin, and your site 'has good SEO' and structured data and even an AI file, whether or not anyone thought about it for a second.
Now look at what's all over the map: speed. Median mobile score 55, only 7.6% in the green, and category medians spread from 45 to 68. Performance is the one thing a plugin can't paper over. It comes from how the site is actually built — the theme, the image sizes, the stack of scripts, the hosting. You cannot install your way to fast. That's exactly where most of these sites fall down, and because it's the hardest part to fake, it's the truest signal of whether a site was built with any care.
By category
Every category carries the same flat, plugin-generated SEO score of 92 — and then splits hard on the thing plugins can't do. Professional services, auto shops, and salons hold up best on speed. Medical and dental, restaurants, and retail fare worst, with 60% of both medical and restaurant sites scoring under 50 on the lab test.
The table below puts the automatable columns (SEO, structured data, llms.txt) next to the one that isn't (speed). Read across any row and you see the same thing: the plugin stuff is present, the speed is where it lives or dies.
Every category is 15 sites. I'm reporting category-level numbers because the sample was built to support them — and no cell falls below the 10-site floor I set for reporting anything.
How I measured this
A study like this is only worth anything if you can check it, so here's the whole method.
Sample frame: I pulled businesses from OpenStreetMap — the public, free map database — through its Overpass query service. Not Google, on purpose: anyone can re-run the exact query and get the same frame, whereas Google's data can't legally be redistributed or reproduced by a third party. I took a 20-mile box around downtown Kansas City, across seven categories, each mapped to specific map tags. I kept only businesses with a website, and excluded chains and franchises using OpenStreetMap's 'brand' tag.
Sample: from that pool I drew a random 15 per category — 105 sites — using a fixed random seed (20260708) so the draw is reproducible. Before measuring, I checked each site was reachable and a real page, dropping dead domains, parked pages, and links that just redirect to a Facebook page.
Measurement: each site went through Google's PageSpeed Insights API three times on mobile (Lighthouse 13.4.0), and I took the median of the three to control for lab noise. Real-user (CrUX) field data came from the same responses, where Google had it. A few cheap extra checks — HTTPS, a valid mobile viewport, structured-data presence, and llms.txt — came from a direct fetch of each homepage; two of the 105 homepages wouldn't return cleanly even after retries, so the viewport and structured-data rates are computed over the 103 that did.
One honest limitation: OpenStreetMap under-maps service-area trades — plumbers, roofers, HVAC — because they don't have a storefront customers walk into. So the contractor and auto samples come from a thinner pool than, say, restaurants, and they lean toward the businesses organized enough to be on the map with a website in the first place. If anything, that flatters those two categories, not the reverse.
All of this ran on July 8, 2026. I'm publishing aggregates and category breakdowns only — no business is named, and no single site's score appears anywhere in this piece.
How to check your own site
You can run the same top-line test I did, for free, in about a minute. Go to pagespeed.web.dev, paste in your web address, and read it the way this study does. If there's a section labeled real-user or field data, that's what your actual visitors experience — trust that most. The big 0-to-100 score below it is the lab stress test: the visible grade, and for a lot of small sites the only number there is. Under 50 is a problem worth fixing; the green zone starts at 90.
If your site scores badly, it usually isn't bad luck — it's how it was built, and that's fixable. I've written before about what a good site should actually cost in Kansas City, and more recently about making a site legible to AI, the frontier this study only touches at the edges. I'm not going to pitch you at the bottom of a data piece. The numbers are the point: most local sites look maintained and aren't fast, and the distance between those two things is where the real work is.
Reproducibility appendix
Everything here is reproducible. Source: OpenStreetMap, queried through the public Overpass API. Geographic frame: a bounding box of 38.8098, -94.9517, 39.3896, -94.2055 (south, west, north, east) — a 20-mile radius around downtown Kansas City at 39.0997, -94.5786.
Categories and the map tags each used: home-service contractors (craft = plumber, electrician, hvac, roofer, carpenter, painter, builder, gardener, floorer, tiler, plasterer, handyman); restaurants and food (amenity = restaurant, cafe, bar, pub, ice_cream); salons and personal care (shop = hairdresser, beauty, nails, massage, tattoo); auto services (shop = car_repair, tyres, car_parts); medical and dental (amenity = dentist, doctors, clinic, veterinary; healthcare = dentist, doctor, physiotherapist, chiropractor); retail (shop = clothes, shoes, jewelry, gift, florist, furniture, books, bakery, butcher, antiques, art, bicycle, hardware); professional services (office = lawyer, accountant, insurance, estate_agent, financial, tax_advisor, architect, it, consulting, employment_agency).
Inclusion: any business tagged with a website. Exclusions: anything carrying OpenStreetMap's brand or brand:wikidata tag (the standard chain/franchise marker), plus duplicate domains. Sampling: 15 businesses per category, drawn with a fixed random seed of 20260708 after sorting by map ID, so the draw is deterministic. Measurement: Google PageSpeed Insights API (v5), mobile strategy, Lighthouse 13.4.0, three runs per site with the median taken; real-user data from Google's CrUX report where present. Run date: July 8, 2026.
Business location data © OpenStreetMap contributors, used under the Open Database License (ODbL).
| Category | Median mobile speed (lab) | Scoring under 50 | SEO score | Structured data | llms.txt |
|---|---|---|---|---|---|
| Professional services | 68 | 13.3% | 92 | 60.0% | 20.0% |
| Auto services | 64 | 33.3% | 92 | 60.0% | 33.3% |
| Salons & personal care | 60 | 20.0% | 92 | 33.3% | 13.3% |
| Home-service contractors | 54 | 40.0% | 92 | 86.7% | 33.3% |
| Retail | 50 | 46.7% | 92 | 53.3% | 53.3% |
| Restaurants & food | 48 | 60.0% | 92 | 60.0% | 6.7% |
| Medical & dental | 45 | 60.0% | 92 | 66.7% | 26.7% |
Frequently asked questions
How were these 105 sites chosen?
A random sample from OpenStreetMap — 15 per category across seven categories, inside a 20-mile box around downtown Kansas City, chains and franchises excluded, drawn with a fixed random seed. The full method and exact query are in the post so anyone can reproduce the frame.
Why don't you name any of the businesses?
Because the study is about the market, not any one shop — and publishing a named business's failing score would be punching down in a community I work in. I report aggregates and category breakdowns only; no single site's score appears anywhere.
Is a bad PageSpeed score really a big deal?
Don't panic over one lab number — it's a throttled stress test, not what your visitors on good phones experience. Check your real-user (field) data first. But half of these sites have no field data at all, so the lab score is all a prospect can see, and a genuinely slow site does lose mobile visitors before the page even loads.
Can I reproduce these numbers?
Yes — that's the whole reason I used OpenStreetMap instead of Google's data. The exact query, the bounding box, the category tags, and the random seed are all in the post, and PageSpeed Insights is free. Same frame, same tools, same numbers.