What a Local Business Website Needs in 2026: The Anatomy of a Build We Launched Yesterday

Yesterday we put a new local business website live: 23 pages for Lincolnshire Chauffeur Services, a chauffeur firm that has been doing executive airport transfers since 2006. It scores 99 on mobile PageSpeed with every Core Web Vital green, carries nine individually written town pages, and shipped its AI Discovery Files on day one. This post is a walkthrough of what "first-class from day one" actually means for a local business website in 2026: the design, the content, the performance numbers and the machine-readable layer, with every figure real and dated. One thing you will not find here is a ranking claim. The site is one day old, and one day is a launch date, not a data set.

What a Local Business Website Is Judged On in 2026

Search for "what a local business website needs" and you will find the same ten-point listicle rewritten fifty ways: mobile responsive, clear contact details, testimonials, fast loading. None of it is wrong. All of it is generic, and generic is precisely what stopped working. We watched Google's 2026 updates punish templated content on real client sites, and we wrote up what Google rewards instead: lived experience, real numbers and content a rival could not copy-paste.

There is also a second audience now. When someone asks ChatGPT or Gemini for a chauffeur service in Lincolnshire, the assistant composes an answer from whatever public, machine-readable material it can find. We have measured how AI assistants recommend local businesses across months of dated tests, and the pattern is consistent: the sites that get cited are the ones that are fast, specific, honest and structured. Which happens to be the same list Google rewards.

So rather than write listicle number fifty-one, we are going to walk through a single build that treats all four of those qualities as launch requirements. Everything below shipped on 21 July 2026 and can be checked on the live site today. The full build story, including the brief and the honesty rules, is in the Lincolnshire Chauffeur Services case study; this post is about what it demonstrates for any local service business.

Design Flair With a Job: The Split-Flap Departures Board

Almost every chauffeur website sells glamour: gold on black, champagne, a peaked cap. This one sells certainty, because certainty is the product. Nobody books a pre-dawn car to Heathrow for the leather seats; they book it because the alternative is driving the A1 at 3am. The design language is borrowed from the two objects this audience actually stares at, the departures board and the dashboard, and it repeats with a different job on every page type.

The homepage carries a split-flap departures board that cycles through the nine towns the firm serves. Each town page has a destination board flipping through the ten airports and seaports the business covers, with example drive times. The airport and seaport transfers page adds a live flight-monitor instrument, because tracking the inbound flight and adjusting the pickup is a real part of the service. The service pages carry numbered spec panels instead of vague promises, and the quote form has a live "Your journey" summary panel that fills in as you type.

Two disciplines keep the flair honest. First, every board and instrument carries information the customer needs: real terminals, example times with a stated margin, the actual arithmetic of an early start. Decoration would be cheaper and worth less. Second, every colour pairing was measured before use, the same process from our brand colour accessibility audit: body text on the night background sits at 11.09:1, the amber accent at 7.88:1, both past WCAG's stricter AAA bar. The buttons are dark text on amber rather than white on amber, because white on amber fails AA. It also reads more expensive, which is a happy accident of doing it properly.

This is the sector page it belongs to, if you want the pattern rather than the single build: chauffeur service website design sits in our transport portfolio alongside the rest of the fleet.

Nine Town Pages: Local Content a Template Can't Fake

The commercial heart of the site is nine town pages under one locations hub: airport transfers from Boston, the Lincoln page with its ring of bypasses and the A46, executive travel from Grantham, airport runs from Sleaford, the long cross-county run from Skegness, 3am starts from Woodhall Spa and their neighbours. The old site had location pages too. Three of them were word-for-word identical apart from the town name, which is the definition of a doorway page and exactly the pattern Google has spent two years demoting.

The rebuild enforces one rule: if a page could have its town name swapped and still read correctly, it is not finished. Every page is grounded in its real geography, real routes and real pickup considerations. One town even repairs an old wound: the outgoing site's homepage had linked a Bourne page that was never actually built, so the link 404'd for years. Bourne finally got its page, individually written like the rest, and the old dead path now redirects to it.

"Does the content provide original information, reporting, research, or analysis?"

Google Search Central, self-assessment question from Creating helpful, reliable, people-first content

That question is the first one on Google's own self-assessment list, and we have effectively turned it into a build gate. It reads like compliance box-ticking until you apply it to a town page: "original" means the Lincoln page knows the A46 points at the A1, not that it swapped "Lincoln" into a template. In twenty-five years of building and reviewing local business sites, the town-name-swap test fails more of them than any other single check, and the firms are usually paying good money for those pages.

Then came the part most launches skip: checking the finished pages against the queries they need to win. The day after launch we audited all nine rendered town pages programmatically and found "airport transfer(s)" appearing only 2 to 4 times per roughly 1,400-word page, around 0.2% density, and the H1 was the only heading carrying the target phrase. Every other H2 was rhetorical. Well written, and invisible to search intent. The fix went in at template level: the board heading became "[Town] airport transfers, every terminal.", the exact word order customers search, and one "airport transfer" and one "executive car" were woven into each town's unique prose with distinct phrasing per town. After the pass: 6 to 9 occurrences per page, roughly 0.5% density, with no stuffing and all nine pages still individually written. Write for the reader first, then audit the rendered page against the queries. Coverage you assume is coverage you usually do not have.

PageSpeed 92 to 99: Every Core Web Vital Green

Performance is a launch gate on everything we ship, not a post-launch aspiration. The launch-day mobile Lighthouse run came in at 92. Respectable, and not good enough, because a slow-ish site undermines every other signal: users bounce, Google measures the bounce-shaped vitals, and AI crawlers time out on bloated pages. Three fixes took it to 99. Here is where it landed, against Google's own thresholds:

Metric	Result (mobile)	Google's "good" threshold
First Contentful Paint	0.9s	Under 1.8s
Largest Contentful Paint	2.0s	Under 2.5s
Cumulative Layout Shift	0	Under 0.1
Total Blocking Time	0ms	Under 200ms
Speed Index	1.2s	Under 3.4s

"To provide a good user experience, sites should strive to have Largest Contentful Paint of 2.5 seconds or less."

web.dev, Largest Contentful Paint (LCP), Google

I keep that sentence pinned because of what it does not say. It does not say "score 100 on Lighthouse". Google's guidance has always been about thresholds users can feel, yet the industry treats the score as the product. On this build that distinction stopped being philosophical: the last Lighthouse point was on the table, and taking it would have meant trading a Cumulative Layout Shift of zero back for a fraction of a second of paint time. We banked 99. Every vital is comfortably green, the page is rock stable, and Google measures vitals, not vanity. That decision is dated in the project log, and it is the opposite of what most agencies would do with a 100 within reach and a screenshot to sell.

The Responsive Hero Fix: 286 KB Down to 37 KB

The single biggest win deserves its own section, because it is the most common failure on local business websites and one of the cheapest to fix. The homepage hero was one 286 KB WebP served at 2560px wide to every device, which meant a phone was downloading a desktop-sized image as its largest paint. The fix is responsive images: generate proportional variants at 800, 1280 and 1920 pixels wide (aspect ratio preserved, WebP quality 70) and let the browser pick. The pattern, trimmed to its working parts:

<!-- In the head: preload the hero with the SAME srcset the img uses -->
<link rel="preload" as="image" fetchpriority="high"
      href="/assets/img/hero-drive-800.webp"
      imagesrcset="/assets/img/hero-drive-800.webp 800w,
                   /assets/img/hero-drive-1280.webp 1280w,
                   /assets/img/hero-drive-1920.webp 1920w,
                   /assets/img/hero-drive.webp 2560w"
      imagesizes="100vw">

<!-- The hero image itself -->
<img src="/assets/img/hero-drive.webp"
     srcset="/assets/img/hero-drive-800.webp 800w,
             /assets/img/hero-drive-1280.webp 1280w,
             /assets/img/hero-drive-1920.webp 1920w,
             /assets/img/hero-drive.webp 2560w"
     sizes="100vw"
     width="2560" height="1440"
     fetchpriority="high"
     alt="Executive car on a Lincolnshire road at dusk">

The result: a phone now fetches the 37 KB variant instead of the 286 KB original, and Largest Contentful Paint dropped from 3.2 seconds to 1.4. The preload and the srcset must mirror each other exactly, or the browser preloads one candidate and renders another, downloading both.

Then the win exposed a second fault, which is how performance work usually goes. With the hero arriving that fast, the site's three custom fonts were now swapping in visibly, nudging Cumulative Layout Shift from 0 to 0.097. Preloading the three font files fixed the shift back to a flat zero, but the font preloads compete with the hero for early bandwidth, which moved LCP from 1.4s to 2.0s. Still well inside the threshold, and that chain of trade-offs is precisely the 99-not-100 decision described above. If your own site has never had this treatment, it is the first thing we look at in a speed optimisation engagement, and on WordPress the same fix applies through properly configured image sizes.

E-E-A-T in Practice: Honesty as a Trust Signal

E-E-A-T gets discussed as if it were a checklist of page furniture: bylines, about pages, review widgets. The furniture matters, but on this build the deeper implementation is factual restraint, in three places.

Journey times are labelled estimates. The boards run on drive times the client has not yet verified from his own runs, so every figure on the site is presented as an example with a margin built in for traffic, and the data layer flags each one as unverified until he confirms it. Publishing desk research as operational fact would have looked more authoritative and been invented precision. This audience does the Heathrow run monthly; one fantasy number and every instrument on the site loses its credibility.

The facts carry the trust, not the adjectives. The about page states that Bart Griemink has been trading since 1 September 2006 and holds British Chauffeurs Guild permit 2722CT. "Trading since 2006" beats "years of trusted experience" every single time a sceptical customer reads it, because one is checkable and one is filler.

And no ranking claims. This site is one day old. We claim no rankings, no traffic, no AI citations for it, not even the brand query, and the case study says so in as many words. That is not modesty; it is the trust signal. An agency that will not invent results for its own showcase is an agency that will not invent them for your monthly report either. The evidence that this playbook produces rankings comes from builds old enough to have data, which brings us to the machine-readable layer.

AI Discovery Files: The Part Most Local Websites Skip

The full set of AI Discovery Files went live at the site root on launch day: llms.txt, a designed and indexable llms.html, ai.txt, ai.json, identity.json, brand.txt, faq-ai.txt, developer-ai.txt and robots-ai.txt, implementing the AI Discovery Files specification. They encode exactly who the business is and, just as usefully, what it is not: the files carry the "never a taxi, never a minicab" positioning and the quote-only pricing policy, so an AI assistant describing the business cannot honestly get those facts wrong. You can check the site's implementation in about a minute: run the domain through the free AI Visibility Checker or open its public AI visibility profile on the directory.

Why bother before a single ranking exists? Because AI assistants do not wait for rankings, and we have dated evidence of how fast the groundwork pays. Lockerfella, a locksmith site we built on the same playbook, hit number one on Google, ChatGPT and Gemini for its target phrase within 21 days of launch, with zero backlinks. We make no promise this build repeats that, and the honest position is that we cannot know yet. But the mechanism is not mysterious: an assistant answering "chauffeur service in Lincolnshire" reads whatever structured, first-party material exists, and a site that shipped its discovery files on day one has been legible to those systems from its first crawl.

The 2026 Local Business Website Checklist

Here is the build distilled into the checklist we actually work to. It is shorter than the listicles and harder to fake:

• One signature design idea that carries real information, executed with discipline, instead of a template plus stock photos.
• Accessibility measured, not eyeballed: every text and button colour pairing computed against WCAG 2.2 before design sign-off.
• A page per service area that fails the town-swap test: real roads, real routes, real local knowledge, individually written.
• Core Web Vitals green on mobile as a launch gate: LCP under 2.5s, CLS under 0.1, with responsive images doing the heavy lifting.
• Facts over adjectives: founding dates, accreditations and permit numbers instead of "trusted" and "professional".
• Estimates labelled as estimates, and nothing published as fact that the business has not verified.
• Full schema and AI Discovery Files from day one, so search engines and AI assistants read the same truth the page shows.
• A post-launch keyword audit of the rendered pages, closing the gap between what you wrote and what people search.

Nothing on that list requires a big budget. All of it requires deciding, before launch, that the website is evidence of how the business operates rather than an advert for it.

Frequently Asked Questions