Build a mobile-first homepage for a local business in one afternoon

Most local business homepages we look at were designed on a 27-inch monitor and then squeezed onto a phone. The hero slider shrinks to a strip, the phone number sits in a footer nobody scrolls to, and the "Book now" button is a 30-pixel link in a hamburger menu.

That is backwards for this kind of site. People find a plumber, a dentist or a nail salon on their phone, usually with a specific job in mind: call, book, or check whether the place is any good. Google also treats the phone version as the real one. Its documentation says plainly that it "uses the mobile version of a site's content, crawled with the smartphone agent, for indexing and ranking."

So here is the template we keep coming back to when we sketch a homepage for a local service business. It is plain HTML and CSS, no framework, and you can get a solid first version done in an afternoon. The examples use a fictional plumbing company so the code has something concrete to hold onto.

The afternoon, roughly

You won't hit these times exactly, but this is the order that keeps you from polishing a footer while the hero is still empty.

The first row is the one people skip. If you start coding before you have the real phone number, the real hours and at least two reviews you are allowed to quote, you end up with lorem ipsum in production. Ask the owner for those first, by text if that is how they like to talk.

Above the fold: four things, nothing else

On a typical phone screen you have room for about four things before the visitor has to scroll. For a local service business we use them like this:

1. The business name and a call button in the header.
2. One sentence that says what they do and where. "Emergency plumbing in North Austin, same-day visits" beats "Quality You Can Trust."
3. A primary action: book online, request a quote, or call. Pick the one the owner actually answers.
4. A trust signal you can verify: years in business, licence number, or a review count that links to the source.

What we leave out: sliders, autoplay video, a newsletter popup, and a mission statement. None of them help someone with a leaking water heater.

Here is the skeleton:

<!doctype html> <html lang="en"> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1"> <title>Harbor Lane Plumbing | Same-day plumbing in North Austin</title> <meta name="description" content="Licensed plumbers in North Austin. Same-day visits, upfront pricing. Call 512-555-0142."> <link rel="stylesheet" href="/css/site.css"> </head> <body> <header class="top"> <a class="brand" href="/">Harbor Lane Plumbing</a> <a class="btn btn-call" href="tel:+15125550142">Call</a> </header> <main> <section class="hero"> <h1>Same-day plumbing in North Austin</h1> <p>Leaks, water heaters, drains. Licensed, insured, upfront prices.</p> <div class="actions"> <a class="btn btn-primary" href="/book">Book a visit</a> <a class="btn btn-ghost" href="tel:+15125550142">512-555-0142</a> </div> <p class="trust">Licence #M-00000 (example) · Open Mon to Sat, 7am to 7pm</p> </section> <!-- reviews, services, area, footer --> </main> </body> </html> 

(Harbor Lane Plumbing is a fictional example. The number uses the 555-01xx range reserved for fiction.)

Two details matter more than they look. The viewport meta tag is what stops a phone from rendering the page at desktop width and zooming out. And the tel: link should use the full international format, so it dials correctly no matter how the visible text is formatted.

Tap targets that thumbs can hit

Buttons on these sites are often styled links with 14px text and no padding. web.dev's guidance on tap targets suggests a minimum of "around 48 device independent pixels", spaced about 8 pixels apart. WCAG 2.2 sets a lower floor of 24 by 24 CSS pixels at Level AA. We aim for 48 and treat 24 as the line you never cross.

:root { --brand: #0f5c8c; --ink: #14212b; --bg: #ffffff; font-family: system-ui, -apple-system, "Segoe UI", Roboto, sans-serif; } body { margin: 0; color: var(--ink); background: var(--bg); line-height: 1.5; } .btn { display: inline-flex; align-items: center; justify-content: center; min-height: 48px; padding: 0 20px; border-radius: 10px; font-weight: 600; text-decoration: none; } .btn-primary { background: var(--brand); color: #fff; } .btn-ghost { border: 2px solid var(--brand); color: var(--brand); } .actions { display: flex; flex-wrap: wrap; gap: 12px; } .actions .btn { flex: 1 1 160px; } 

The system font stack is deliberate. Body text in the phone's own font loads instantly and looks native. If the owner insists on a brand font, use it for headings only and load one weight.

The sticky call bar

For trades and emergency services, a bar pinned to the bottom of the screen with "Call" and "Book" gets used. Show it only on narrow screens, and add bottom padding to the page so it never covers the footer.

.callbar { display: none; } @media (max-width: 640px) { .callbar { position: fixed; inset: auto 0 0 0; display: grid; grid-template-columns: 1fr 1fr; gap: 8px; padding: 8px 12px calc(8px + env(safe-area-inset-bottom)); background: #fff; box-shadow: 0 -2px 12px rgb(0 0 0 / .12); } body { padding-bottom: 80px; } } 

The env(safe-area-inset-bottom) part keeps the buttons above the home indicator on iPhones. For it to return a value, add viewport-fit=cover to the viewport meta tag.

The booking button: link to what they already use

Don't build a booking system. Most local businesses already have something: a scheduling tool, a form that emails the front desk, or a phone. Ask which one actually gets answered, and link the button to that.

If you embed a third-party booking widget, put it on its own /book page rather than the homepage. Those widgets often pull in a lot of JavaScript, and you want the homepage to stay fast.

A plain fallback form is fine too. Keep it short:

<form action="/quote" method="post" class="quote"> <label>Name <input name="name" autocomplete="name" required></label> <label>Phone <input name="phone" type="tel" autocomplete="tel" required></label> <label>What's going on? <textarea name="issue" rows="3"></textarea> </label> <button class="btn btn-primary" type="submit">Request a callback</button> </form> 

type="tel" brings up the number pad. autocomplete lets the phone fill in name and number in one tap. Three fields is plenty. Every extra field is one more reason to give up and call a competitor.

Reviews: real, attributed, linked

The reviews block is where homepages get sloppy. A grid of five-star quotes from "John D." with no source reads as invented, even when it isn't.

What we do instead:

• Quote 2 or 3 real reviews, with the owner's okay, and show the reviewer's first name and the platform.
• Link to the full review profile so visitors can check.
• Show the date or at least the year. A glowing review from 2016 is a warning sign, not a selling point.
• Skip the star widget scripts. Plain HTML is enough.

<section class="reviews" aria-labelledby="reviews-h"> <h2 id="reviews-h">What customers say</h2> <figure class="review"> <blockquote>Came out the same afternoon and fixed the leak under our sink. Clear price before starting.</blockquote> <figcaption>Maria, March 2026 (example review)</figcaption> </figure> <a href="#" class="more">Read all reviews</a> </section> 

A side note if you are thinking about adding review markup for search: Google's guidelines say that when a business controls the reviews about itself on its own site, pages using LocalBusiness or Organization structured data are not eligible for star review snippets. Put the reviews on the page for humans and leave the star markup out.

Performance basics that take ten minutes

You don't need a build pipeline for this. Four things cover most of the gain on a page this simple.

Size the hero image properly. Export it at the size it is shown, serve WebP or AVIF with a JPEG fallback, and give it width and height so the browser reserves the space. The hero image is often the Largest Contentful Paint element, and Google's "good" threshold for LCP is 2.5 seconds at the 75th percentile.

<picture> <source type="image/avif" srcset="/img/hero-800.avif 800w, /img/hero-1400.avif 1400w"> <source type="image/webp" srcset="/img/hero-800.webp 800w, /img/hero-1400.webp 1400w"> <img src="/img/hero-800.jpg" alt="Plumber fixing a pipe under a kitchen sink" width="800" height="533" fetchpriority="high"> </picture> 

Don't lazy-load the hero. web.dev's advice is direct: "Don't lazy-load images that are likely to be in-viewport when the page loads, especially LCP images." Use loading="lazy" for gallery photos further down, and fetchpriority="high" on the hero, which is supported in current Chrome, Edge, Firefox and Safari.

Load almost no JavaScript. This page does not need any. If you add a cookie banner or analytics, load them with defer and check what they cost in the Network tab.

Test on a real phone. Lighthouse in DevTools is a good start. Then open the page on a mid-range phone over cellular and try to call the business from it. You'd be surprised how often the number turns out not to be tappable.

The handoff checklist

Before sending the link to the owner, we go through this list on an actual phone, not a resized desktop window.

When you send it, keep the message about what the owner cares about, not the tech. Something like:

Here's the new homepage on your phone: [link]. The call button works from anywhere on the page, and "Book a visit" goes straight to your scheduling page. Can you try both and tell me if anything looks off?

That last question matters. Owners often spot a wrong price or an old service area that you'd never catch.

Finding the businesses that need this

The template is the easy part. The harder part is finding owners whose current homepage fails these checks, and the manual way works: search a trade plus a town on Google Maps, open each site on your phone, and note which ones have no tap-to-call, no visible booking option or a page that doesn't fit the screen.

If you'd rather not open forty tabs, LeadReef finds local businesses whose sites are outdated, broken on mobile or missing, shows what's wrong with each one, and helps you draft a first mockup and outreach message. You choose who to contact and send everything yourself. The first 10 leads are free. Full disclosure: we build LeadReef. Everything above works fine without it.

Sources: Google Search Central, Mobile-first indexing best practices; web.dev, Accessible tap targets; W3C, Understanding SC 2.5.8 Target Size (Minimum); web.dev, Defining the Core Web Vitals metrics thresholds; web.dev, Browser-level image lazy loading; web.dev, Optimize resource loading with the Fetch Priority API; Google Search Central, Review snippet guidelines.