What 70 static pages taught us about building for a local business

A local service business does not need a web app. It needs to be found, trusted, and called. Last quarter we shipped a 70-page site for a small contractor with no framework, no CMS, and no build step — just HTML, one CSS file, and a lot of restraint. Here is what actually mattered.

1. The page count comes from the shape of the business, not from SEO folklore

The temptation is to write "10 tips" blog posts and hope. What worked was multiplying the real things the business sells by the real places it serves:

• 8 services × 4 towns = 32 landing pages
• the rest: home, about, contact, service index, town index, blog index, articles

That is it. Every URL answers one question a customer actually types. No page exists "for keywords".

2. One JSON-LD block beats a hundred meta tags

The only structured data that paid for itself was LocalBusiness, with the exact same name, address and phone that appear on the page and on every directory we later registered:

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "Example LLC",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "401 N Federal Hwy",
    "addressLocality": "Hallandale Beach",
    "addressRegion": "FL",
    "postalCode": "33009"
  },
  "telephone": "+1-561-000-0000",
  "url": "https://example.com/"
}

The hard part is not writing it. The hard part is that this string must match, character for character, what goes into the 10-40 directories later. One digit off and you have created two businesses as far as the map is concerned.

3. Static is not a compromise

The whole site is a folder of .html files on shared hosting. No database, no PHP, no plugin updates, nothing to patch. Consequences we liked:

• TTFB is the disk. There is no application to be slow.
• Deploys are file copies. No migration step, no "works on my machine".
• Nothing breaks while you sleep. No plugin auto-update, no expired license.

The trade-off is real: the client cannot edit copy in a WYSIWYG. For a business that changes its text twice a year, that trade is worth it. For one that posts weekly, it is not.

4. What we deleted

The first draft had a slider, a testimonial carousel, a cookie banner for analytics we were not using, and a "chat with us" widget that loaded 300 KB to show a form. All gone. The page is now: header, hero, three proof points, services, phone number, footer.

Deleting is the part juniors skip and seniors do first.

5. The 10 % that is not code

A site that is fast and correct still does not rank if nobody links to it. The invisible work is:

1. one inbox per business (signups send confirmation codes),
2. a single source of truth for name/address/phone,
3. 10 directory listings that all say the same thing,
4. a slow drip of real links from places a human would plausibly read.

That last line is where most "SEO automation" breaks: it optimises step 4 and forgets that steps 2 and 3 are what make step 4 count.

6. Numbers, since this is dev.to

• 70 HTML pages, one ~40 KB CSS file, zero JS frameworks.
• Build: a Python script that renders Jinja templates into folders.
• Hosting: shared, $3/month, static document root.

No lighthouse screenshot, no "100/100" claim — just a site that loads before you finish blinking and does not break.

I build these for local businesses at Brixel Proyect. If you are shipping something similar, the services page shows the structure we settled on: service × town, nothing more.

Happy to answer questions about the static pipeline or the directory side in the comments.