The 11ty Local SEO Blueprint: How We Build Local Business Sites That Rank

Most local business websites are built to look finished. Ours are built to rank — and stay honest while they do it. Over the last year we’ve distilled every local SEO build we’ve shipped into a single reusable recipe: a fast, static, 11ty-powered architecture that turns one town into a genuinely unique, search-ready page without a single line of doorway spam.

Here’s the whole blueprint, top to bottom.

TL;DR: Our 11ty local SEO blueprint builds a plumber, dentist, bridal boutique or garage site as thin, data-driven pages that compose a shared macro library. A service×location internal-linking mesh does the ranking; build-time anti-doorway contracts and a single verified fact sheet keep every page unique and truthful; E-E-A-T signals, JSON-LD structured data and Core Web Vitals floors are enforced, not aspirational. Clone the architecture, swap only the content.

Why Local SEO Needs a Different Kind of Website¶

Ranking a national brand is a content-and-authority game. Ranking a local business — one that serves a handful of towns and wants to show up for “emergency electrician in Chichester” — is an architecture game.

Google’s local results reward three things above almost everything else: relevance (does this page genuinely cover this service in this place?), trust (is this a real business with a real address, phone and reputation?), and speed (does the page load instantly on a phone with one bar of signal?). Miss any one and you’re invisible.

The trap most agencies fall into is the doorway page: take one template, swap the town name 40 times, publish 40 near-identical pages. Google has punished this since 2015. It looks like coverage; it reads like spam; it tanks the whole domain.

Our blueprint is engineered specifically to make the right version of this — real coverage at scale — cheap to build and impossible to fake.

The Stack: Static-First, Zero Framework¶

The foundation is deliberately boring, because boring is fast and boring lasts.

• Eleventy (11ty) + Nunjucks + plain CSS. No React, no SCSS, no build pipeline beyond a single command. Fewer moving parts means fewer things to break and nothing to slow the page down.
• Static-first, always. Every meaningful word on the page renders with zero JavaScript. JS is only ever progressive enhancement — a mobile menu, a count-up animation, a reveal-on-scroll. A content page that’s blank without JavaScript fails both SEO and accessibility, so we never ship one.
• One source of truth for business facts. Name, phone, email, full address, opening hours and star rating all live in a single site.json file. Every page reads from it. Change the phone number once, it changes everywhere — no stale copies hiding in a footer.

The payoff is raw speed. Static HTML served straight from disk gives us Core Web Vitals headroom that a database-driven CMS simply can’t match on a small hosting budget.

Thin Pages, One Shared Component Library¶

Here’s the part that makes a 30-page local site maintainable by one person.

Each service or location page is almost entirely frontmatter — a short block of structured data at the top of a markdown file (the town, its postcodes, a local project, an intro paragraph, a real testimonial). There is essentially no hand-written HTML in the page itself.

That data flows into a section-macro library — a single file of reusable visual blocks: the hero, the intro-with-spec-ledger, the process steps, the FAQ accordion, the coverage map, the call-to-action. Every macro takes the same shape of data whether it’s rendering a flooring page in Chichester or a dental page in Leeds.

The magic is in the cascade: edit one macro and the change ripples across every service and location page automatically. Per-page files only ever carry content, never layout. Adding a new town is writing one small markdown file — not rebuilding a page.

To keep that component library visible, every build ships an internal Partial Catalogue: a hidden preview page that renders every block with mock data, labelled with its name. It’s living documentation and a design sandbox in one — we (or the client) can tune a section in isolation before it ever touches a real page.

The Ranking Engine: A Service × Location Mesh¶

Individual pages don’t rank on their own — the link graph between them does.

• Every location page links out to all services and weaves nearby towns and postcodes into its copy as real, contextual anchors.
• Every service page links to the locations it covers and to related services inline.
• Two hub pages — /services/ and /locations/ — tie the whole thing together.

The result is a dense internal mesh where every town reinforces every service and vice versa. This is the core local-SEO signal, and because it’s generated from the same frontmatter that builds the pages, it scales for free. Add a town, and it automatically joins the mesh.

The mesh in the wild: a real West Sussex flooring build now surfaces for dozens of service-plus-town searches — several already inside the top 10 — without a single doorway page. (Google Search Console)

The Anti-Doorway Guardrail (Our Favourite Trick)¶

This is the single highest-leverage part of the whole blueprint, and it runs at build time.

The build is configured to fail loudly if a page pretends to be finished without the proof to back it up. A non-stub location page must carry a named local project (real street, real postcode), a specific local testimonial and a locally relevant photo. Miss any of them and the build prints a red “ANTI-DOORWAY WARNING” naming the exact page.

Pages that genuinely aren’t ready yet don’t get faked — they’re flagged as a stub: an honest, thin coverage page (hero, coverage notice, call-to-action, nothing invented) that’s excluded from the check and clearly marked. Promote it to a full page once real local content exists. We never pad a stub with fabricated projects to silence the warning — that’s the exact behaviour the guardrail exists to prevent.

In other words: the architecture makes it harder to build a doorway page than to build a real one. That’s the whole point.

Trust Is the Load-Bearing Pillar (E-E-A-T)¶

Google evaluates content on Experience, Expertise, Authoritativeness and Trust — and Trust is the one that carries the rest. A page rich in expertise still fails if the business behind it looks fake.

So every site ships the non-negotiable trust infrastructure: HTTPS, an accurate footer with the real organisation name and address, a working contact path, and proper /about, /contact, /privacy and /terms pages. Editorial content carries visible dates. There are no deceptive patterns and no intrusive pop-ups.

On the content itself we insist on first-person voice, original photos (never stock), and specific dates, specs and place-names. For anything in a “your money or your life” category — health, finance, legal, safety — a named, credentialled author is mandatory, surfaced both in the byline and in the structured data.

Structured Data That Search Engines Actually Read¶

Every page ships a single JSON-LD @graph — the machine-readable summary Google uses to build rich results. For a local business page that means:

• LocalBusiness schema (or a precise subtype — Dentist, Store, HomeAndConstructionBusiness…) with the full address, phone, geo-coordinates, price range, area served and aggregate rating.
• BreadcrumbList for the Home → Locations → Town trail.
• Review structured data when the page carries a genuine testimonial.
• FAQPage built from the very same FAQ list that renders the on-page accordion — one source, no drift.

Every graph is validated against Google’s Rich Results Test before launch. This is what earns the star ratings, sitelinks and FAQ dropdowns you see in search results.

Speed and Accessibility as Floors, Not Targets¶

We treat the technical numbers as floors you don’t drop below, not goals you aim at:

• Core Web Vitals: Largest Contentful Paint under 2.5s, Interaction to Next Paint under 200ms, Cumulative Layout Shift under 0.1.
• Images in modern formats with width and height always set (no layout shift), lazy-loaded below the fold — including the map embed.
• WCAG 2.2 AA accessibility: body text pinned at a 4.5:1 contrast floor, keyboard-navigable menus, and every animation degrading gracefully when a visitor prefers reduced motion.

Because the stack is static and framework-free, hitting these floors is the default state of the site — not a performance sprint bolted on at the end.

The Rule That Keeps It Honest: One Verified Fact Sheet¶

Speed and schema mean nothing if the facts are wrong. The hardest-won lesson from every build is this: get one verified fact sheet from the client before writing a single committed word — founding year, team names, insurance, accreditations, lead times, hours, coverage radius, real rating and review count — and enforce it site-wide.

From that we hold a few hard lines:

• No lapsed or aspirational credentials. A trade-body membership that’s expired, an “as seen in” you can’t prove, a certification the firm sources but doesn’t hold — we phrase it precisely or drop it.
• Testimonials are immutable. Genuine reviews are never edited. If one names a team member who’s since left, we swap the whole testimonial for another real one — we don’t rewrite it.
• No invented projects. If a case study isn’t on the client’s verified list, it doesn’t ship. We flag the gap to the owner rather than fabricating a job.

Honesty isn’t just ethics here — it’s SEO. Trust signals that don’t hold up are exactly what Google’s quality raters are trained to catch.

Proof: What Happens When You Ship One¶

Blueprints are cheap; results aren’t. Here’s a real build running this exact architecture — a flooring specialist covering a cluster of West Sussex towns. We rebuilt the site static-first and rolled out the full service×location mesh, then watched Google Search Console.

The moment Google finished indexing the new location-page mesh in mid-July, the site’s search visibility changed gear:

Daily impressions sat flat at roughly 15–30 a day through May and June. Once the mesh indexed in mid-July they took off — peaking at 298 in a single day. (Google Search Console)

Zoom out to the monthly totals and the trajectory is unambiguous:

Monthly impressions grew 7.6× in 90 days — from 397 in May to 3,029 in July — as each new town page joined the mesh and started surfacing for its own local searches.

A caveat, in the honest spirit of the blueprint itself: these are impressions and rankings — the leading indicators of local visibility — captured in the first weeks after launch. Clicks and enquiries follow as positions climb out of the page-two wilderness and into the local pack, and those are what we track next. But the shape of the curve is exactly what the architecture is built to produce: real coverage, indexed fast, ranking for the towns that matter.

Why This Blueprint Wins¶

Put it together and you get something rare: local business sites that are fast, genuinely unique per town, structurally trustworthy, and cheap to extend — all at once. The architecture does the heavy lifting, so the only thing that changes from one client to the next is the content: the tokens, the services, the towns, the copy.

Thin frontmatter-driven pages compose a shared macro library; a Partial Catalogue documents and previews every block; build-time anti-doorway contracts and a verified fact sheet keep every page genuinely unique and honest; E-E-A-T, JSON-LD and Core Web Vitals floors are enforced, not aspirational. Clone the architecture, swap only the content.

That’s the blueprint. If you run a local or trade business and your current site is slow, thin, or reads like it was stamped out of a template — that’s exactly the problem this was built to solve.

Want your local business ranking in the towns you actually serve? Get in touch and we’ll show you what your site could look like.