Websites
Mobile Friendly Website Checklist for Local Businesses
A phone checklist for local business websites: tap to call, readable type, short forms, hours, a map, speed, and a button that does not cover the page.
//CodeHunterz

A local customer usually meets your website on a phone, often with one hand, often while comparing two other companies. The page has a short job: say what you do, say where you do it, and make the next step a tap. A layout that looks finished on a laptop and awkward on a phone has not finished the job.
This checklist is the test we want a local site to pass before anyone spends more on ads or on new pages. The build itself is website development. The decisions about order, hierarchy, and what the first screen is for sit with UI/UX design. If the current site fails several items below, the longer feature list in 15 must-have features and the signals in signs you need a new website are the next reads.
Run the checks on a phone you did not use to design the page. A resized desktop window is a start. It will not show you a thumb missing a button, or the way a sticky bar sits on top of your hours.
Start with the phone you already carry
Load the homepage the way a customer would: type the name, or open the link from your Google Business Profile. Do not start from a logged-in editor. Editors hide the bars and the pop-ups that customers see.
Note three things before you scroll.
What the business does, in the words a customer would use. "Family plumbing in Dayton" is a sentence. A slogan with no service and no place is a delay.
How to reach you, without hunting. The number should be on the first screen. If the only path is a menu, then a contact item, then a page, you have added steps a person in a driveway will not take.
Whether you have to pinch or turn the phone sideways to read. That single gesture is the checklist failing in public.
Then open the page you most want a stranger to land on: the emergency service, the main procedure, the practice area, the signature dish. Homepages get the polish. The page tied to a search is the one that has to work.
Tap to call
The phone number should be text, not only a picture of a number, and it should be a link that opens the dialer. Tap it. If nothing happens, the link is missing or it points at a web page instead of a telephone link.
Show the digits. An icon of a handset with no number forces people to tap before they know who they are calling, and it fails when the tap target is small. Repeat the number in the header and on the contact page. Match it to the number on your Google Business Profile and on the van, the door, and the invoice. A website number that the front desk does not answer is a lead path in name only.
Make the tap target large enough for a thumb. Published interface guidance from Apple has long used about 44 points as a floor for a control, and Material guidance sits in a similar range. Treat that as a minimum for the call control and the form button, with space around them so a nearby link is not what gets tapped.
If you have two numbers, label them. "Emergency" and "office" are different promises. A single button that dials the office line at 9 p.m., when the emergency line is the one with a person on it, trains customers to call someone else next time.
After-hours behavior belongs in the same check. Call the number from the page outside your posted hours, or have someone do it. You want to hear what the customer hears: a person, a clear recorded message with the next step, or silence. The website cannot repair a number nobody answers. It should also not advertise a response you do not provide.
Type a person can read without pinching
Body text should be large enough that a customer is not zooming to read a sentence. A practical floor is 16 pixels for body copy and for form fields. On many iPhones, a field set smaller than that causes the browser to zoom the page when the field is focused, which shoves the layout around and hides the label just as someone is trying to type.
Keep lines from running edge to edge with no padding. Text that touches the side of the screen is harder to read and easier to miss with a thumb when it is also a link. A modest inset, consistent on every page, is enough.
Contrast is part of readable. Light gray on white fails in daylight, which is where a lot of local searches happen, in a truck or on a sidewalk. The Web Content Accessibility Guidelines use a contrast ratio of at least 4.5 to 1 for normal text if you are aiming at level AA. You do not need a lab to start. If you have to squint at the caption under a photo, darken the text or lighten the background until the sentence is obvious.
Do not put the only copy of the phone number, the hours, or the offer inside an image. Images of text do not resize cleanly, do not translate for someone who needs that, and break when the image is slow to arrive. Real text can be tapped, copied, and read by assistive tools.
Headings should say what the page is about in order. One main heading, then section headings a person can scan. A wall of bold phrases with no order makes the page feel busy on a phone, where you see fewer words at a time.
Forms that can be finished outside
A form on a phone is a favor the customer is doing you. Every extra field is a reason to call a competitor or to give up. Ask for the name, a phone number, the service they want, and a short note if you truly need it. Ask for an address when the job requires a visit and you cannot schedule without it. Leave essay questions, "how did you hear about us," and file uploads off the first form unless the business cannot proceed without them.
Labels, keyboards, and the confirmation
Put the label outside the field and leave it visible while the person types. Hint text inside the field disappears as soon as typing starts, so a field that uses only that hint loses its name halfway through. The label "Phone" should still be on screen when the number is half entered.
Set the field type so the phone offers the right keyboard. A telephone field should bring up a number pad. An email field should include the @ key. A name field should not open the number pad. These are small settings with a large effect on whether the form gets finished in a parking lot.
Show errors next to the field, in text, as soon as the person tries to send. A red border alone is easy to miss, and a generic "something went wrong" at the top of a long page is easy to miss when the top is off screen. Say which field failed and what to do.
The submit button should look like a button, sit where the thumb already is, and say what will happen: "Request a call" is clearer than "Submit." After a successful send, the page should say that the message arrived and what the office will do next, and it should show the phone number again for the person who would rather not wait. A blank screen or a return to an empty form makes people send a second request, or assume you never saw the first.
Test the form on the phone and then check the inbox the office actually reads. A form that animates and never arrives is a quiet loss. Send one test during the day and confirm who is responsible for answering it, including the backup when that person is out.
Hours, the address, and a map
Hours should be text on the page, including the days you are closed. "Call for hours" is a delay. If the hours change on holidays, the page and the Google Business Profile need the same update. Customers forgive a closed door. They do not forgive a website that said you were open.
Write the address as text: street, city, region, postal code. Pair it with a map the customer can open for directions. The pin should be the real door, not a rough center of the city, when you have a storefront people visit. Embedded maps are fine when they do not force the page to scroll sideways and do not shove the address below a tall interactive box. A text address plus a "directions" link is better than a map that dominates the screen and cannot be scrolled past.
Service-area businesses, the ones that go to the customer, should say the area in plain language: counties, a drive-time, or the cities you actually schedule. Hide nothing that the dispatcher needs the customer to know, such as a trip fee outside a core area. A map of the whole state with no sentence about where you will drive is not a service area.
Put hours and address on the contact page and in the footer, and make sure the footer is reachable. A sticky bar that covers the last lines is the next section of this checklist, and it is the usual way an address becomes impossible to read.
Speed a customer can feel
Speed on a phone is mostly weight and waiting. Large photos, a carousel that loads five of them, a row of chat and advertising scripts, and a video that plays on its own are the usual causes. The customer feels this as a white screen, a late photograph, or a button that jumps down just as they tap it.
Google publishes a set of page experience measures called Core Web Vitals: largest contentful paint, interaction to next paint, and cumulative layout shift. They are a shared vocabulary for "the main content showed up," "the page responded when tapped," and "things did not jump around." The thresholds Google publishes, and how to read them on a small business site, are in Core Web Vitals for small business websites. Use them as a checklist of symptoms, not as a trophy. A fast page that hides the phone number still fails the business. A slow page that shows the number immediately is at least useful while the rest arrives.
Practical cuts that help a local site:
- Export photos at a size close to how they appear, instead of uploading the camera original.
- Give every image width and height, or an equivalent reservation of space, so the text does not jump when the photo arrives.
- Do not autoplay video on a phone. Offer it behind a tap.
- Be selective with third-party scripts. Each chat widget, pixel, and review badge is another request on a cellular connection.
- Use a font plan you can explain. One family, loaded with intent, beats five families that delay the first sentence.
Test on a cellular connection at least once, not only on office wifi. Wifi hides weight. If you can, sit outside and open the homepage. The version you see there is closer to the customer who searched from a car.
A sticky call button that leaves the page usable
A bar or button that stays on screen while the customer scrolls is useful, because the number remains one tap away on a long service page. It is a problem when it covers the content the person came to read, or the control they need to finish.
Where the button should sit
The common pattern is a bar along the bottom, or a single button in a corner. Bottom bars match the way a thumb rests. They also collide with the browser's own controls and, on phones with a home indicator, with that indicator. Leave a little room so the label "Call" is fully visible and not cropped by the edge of the screen.
Keep the bar short. A call action, and maybe a directions or a book action, is enough. A sticky bar that also holds the full menu, a promo, and a chat bubble leaves a short strip of page in the middle. On a small phone that strip is where the customer is supposed to read your prices and your hours. If you need a menu, put it in a header that can collapse, and let the page have the rest.
One sticky element is usually the limit. A sticky header plus a sticky footer plus a chat bubble is how a service page turns into a tunnel. If a chat tool is on, place it so it does not sit on top of the call button. Two floating controls in the same corner will get mis-taps, and one of them will be the one you cared about.
What the button must not cover
Scroll to the bottom of the homepage, the contact page, and the longest service page. The last heading, the address, the hours, and any legal line should be readable. If the bar covers them, add padding at the end of the page equal to the bar's height, including a little extra for the home indicator. The customer should be able to scroll the content clear of the bar, not just almost clear.
Open the form and focus the last field. The submit button has to be tappable with the keyboard open and with the sticky bar present. This is the check teams skip, and it is the one that loses the lead. On many phones the keyboard consumes half the screen. A sticky bar on top of that can leave the submit button underneath one of them. If you cannot tap "Request a call" without closing the keyboard and hunting, the form is not done.
Check the bar on a short page too. A contact page that is only an address and a form can be shorter than the screen. A sticky bar then covers the only content there is, and padding at the bottom does nothing because there is nowhere to scroll. On short pages, put the bar in normal flow, or make sure the content is laid out above it from the start.
The button's number has to be the right number for the page. An emergency page should dial the emergency line. A page about scheduled estimates can dial the office. One global button that ignores the page is simple to build and wrong for companies that staff those calls differently.
No horizontal scroll
The page should move up and down only. Try to drag it sideways on the phone. If it moves, something is wider than the screen. That something is often small, and it makes the whole site feel broken.
Usual causes:
- A photo, logo, or iframe with a fixed width larger than a phone.
- An embedded map or video with a set pixel width.
- A table meant for a desktop, with many columns.
- A long word, a long URL, or an email address that cannot break.
- A slider or a row of logos that was built as a wide strip.
- A section with a negative margin or a padding value copied from a desktop layout.
The fix is to let images and embeds shrink to the screen, to allow long strings to wrap, and to turn wide tables into a simple stacked list on a phone. A map that is 800 pixels wide will drag the whole page sideways even when the text column is correct. Set the map to the width of its column.
Menus deserve a look here. A row of eight links that fit a laptop will either wrap into a tall block or force a sideways scroll. A compact menu that opens on tap keeps the first screen for the service and the phone number. The menu items themselves should have comfortable tap targets, including the close control. A menu that will not close is a trap.
Pop-ups and banners are the same test. A newsletter bar, a coupon, or a consent notice has to fit the screen, be readable, and be dismissible with a tap a thumb can hit. A banner that covers the call button until the customer finds a tiny close icon has chosen the banner over the job.
A single sitting that covers the real pages
Set a half hour aside and walk this list on one phone. Use the homepage, the most important service page, the contact page, and one page you suspect is old. For each page, confirm:
- The first screen names the offer and shows a tappable number.
- Body text is readable without pinch zoom, and form fields do not zoom the page when tapped.
- The form has few fields, visible labels, and a submit button you can reach with the keyboard open.
- Hours and the address are text, and they match the Google Business Profile.
- The page does not scroll sideways.
- The sticky call control, if you use one, does not cover the hours, the address, or the submit button.
- A test form arrives in the inbox the office checks.
Write down the failures in plain language, with the page name. "Contact form submit sits under the call bar on iPhone" is a task. "Make it pop" is not. Hand that list to whoever can change the site. If the theme fights every item, or the pages are images of an old brochure, you are in redesign territory, which is what signs you need a new website is for.
The free website audit can tell you whether the page sends a viewport tag and whether the HTML arrived over HTTPS. It cannot tell you that a thumb can hit the button. Do this list on a phone either way.
A site can pass this checklist and still need better sentences, better photos, and a clearer service list. Those are the next improvements, and they are worth doing on a page people can already use. Passing the checklist does not require a new brand. It requires that a person on a phone can read you, trust the hours, and reach you before they go back to the search results.
What else do people ask?
Q01What should I check first on a phone?
Call the business from the page, read the first screen without zooming, and try to send the form. If those three fail, the rest of the design is secondary.
Q02Is a sticky call button always a good idea?
It helps when the number stays visible and the button does not cover the form, the address, or the hours. Add space at the bottom of the page so the last lines can scroll clear of the bar.
Q03How do I know the page scrolls sideways?
Open it on a phone and try to swipe left and right. The page should move only up and down. A sideways nudge means some element is wider than the screen.
Q04Do desktop previews count as a mobile test?
A narrow browser window is a useful first look. A real phone on a normal connection catches font zoom, sticky bars, and tap targets that a resized window misses.
Q05Who should fix a site that fails this list?
The same people who can edit the live page and republish it. The Website plan starts at $6,000 one time after a 20% launch offer (regular starting price $7,500). Repairs still follow the current site. Limited-time launch offer, final quote after free strategy call.
Written for US small business owners by the CodeHunterz team. This is general information, not a promise of rankings, leads, or savings. The service behind this guide: continue to the service page.
