To check if your website is mobile-friendly, open it on your phone and see whether you can read it, tap the buttons, and call the business without pinching or squinting. If any of that is fiddly, it is fiddly for customers too, and most local visitors are on a phone. A mobile-friendly site is not a bonus feature. It is the main version, because that is where local searches happen and how Google judges the page.
Here is how to test it properly, why tap-to-call matters for trades, and what Core Web Vitals mean without the jargon.
Why does mobile matter more than the desktop version?
For a Hassocks tradesperson, a Burgess Hill shop or a Haywards Heath builder, the typical visitor is not sitting at a desk. They searched on a phone, often outdoors or in a van, and they will leave if the page is slow or awkward. The desktop view still matters for you, and for the odd customer at a laptop. It is not the version that wins or loses most of the work.
Google agrees, in a mechanical way. It looks at the mobile version first when it decides how to rank and how usable the page is. A site that looks polished on a 27-inch monitor and breaks on a 6-inch screen is a poor site. You lose the customer and you give Google a worse page to evaluate.
Local search makes this sharper. “Electrician near me” is a phone query. The next action is a call, not a long browse. If the number is a picture, or a tiny link under a cookie wall, you have built a brochure that cannot do its only job.
I see this on rebuilds. BW Electrical, Oilfire in Uckfield, Ruby’s Bakery in Burgess Hill and Sindall in Haywards Heath all needed a page that works one-handed. That is the job, not a design fashion.
How do I test whether my site is mobile-friendly?
Start with the phone in your pocket. Leave the office wifi if you can, or switch to mobile data, because that is the network customers use.
Can you read the first screen without zooming? Can you tap the phone number with a thumb? Can you tap the menu, the buttons and the form fields without hitting the wrong thing? Does anything stick out the side so the page scrolls left and right? Does a pop-up cover the number and refuse to close?
Then try a second phone if you have one, ideally a different size. Layouts that look fine on a large iPhone fail on a smaller Android, and the reverse.
After the human test, use a tool. Paste the address into a page-speed or mobile report and read the failures, not the vanity score. Our website speed test is built for that: it runs on a phone-sized viewport and talks in plain English. Google’s own PageSpeed Insights does a similar job if you want a second opinion.
If it fails the thumb test, you already know enough. A green score on desktop does not save a page you cannot tap.
Common failures, in order of how often I see them:
- Text set at a size that looks elegant on a monitor and unreadable on a phone.
- Links and buttons packed so close that a thumb hits both.
- A phone number that is not a
tel:link, so you cannot press to call. - Images saved at desktop width, which load late and push the layout sideways.
- Pop-ups, cookie banners and chat widgets that cover the first screen.
- A sticky header so tall that half the phone is chrome and none of it is the number.
Each is fixable. None of them need a rebrand.
Why does tap-to-call matter so much for trades?
Tap-to-call means the number is a real link (tel:+44... or tel:01273...). On a phone, a tap opens the dialler with the number filled in. That is the whole feature. It sounds trivial until you watch someone try to copy a number off a picture, or retype it from a footer in 8px grey.
For electricians, heating engineers, locksmiths, builders and anyone whose work starts with “can you come out”, the call is the conversion. A contact form is useful for planned work. It is a poor substitute for a tripped fuse or a dead boiler. Put the number at the top, keep it visible as the page scrolls if you can, and make the tap target large.
Do not hide it behind a “click to reveal” trick. Do not use a tracking number that breaks on mobile. Do not put the only number in an image of the van. Repeat it near the end of the page as well, because some people read the proof first and call second.
Shopfronts still need a tappable number and a clear address. Service-area firms need it more, because the customer is not coming to you. Keep any form short: name, contact, a box for the job. This is why we build websites for tradespeople mobile-first. The number, the trade and the towns have to work on a small screen or the site is decoration.
What are Core Web Vitals in plain English?
Core Web Vitals are three measurements Google uses to describe how a page feels to load. The names are ugly. The ideas are not.
LCP (Largest Contentful Paint) is how long it takes the main thing on the screen to appear. On a local site that is usually a heading, a photo or a banner. If that takes several seconds on mobile data, people leave. Huge hero images are the usual culprit.
INP (Interaction to Next Paint) is how quickly the page responds when you tap something. A button that does nothing for a second feels broken. Heavy JavaScript, chat widgets and bloated page builders cause this. You tap “Call” or “Send” and the page thinks about it.
CLS (Cumulative Layout Shift) is whether the page jumps while it loads. You go to tap the number and an image appears above it, so you tap the cookie banner instead. That is CLS. Reserve space for images and do not shove banners in above content after the page has started.
You do not need to memorise the thresholds. You need a page that shows its main content quickly, responds when tapped, and does not jump. Fix the cause (image weight, extra scripts, layout) rather than chasing a 100 score. A page can fit the screen and still be slow or jumpy. You want both: a layout that fits, and a load that does not punish a phone on 4G.
What usually needs fixing, and what does not?
Fix the phone test first. Then fix the vitals that real users hit.
Worth doing: readable type, spacing between tap targets, a tappable number, compressed images, fewer pop-ups, a cookie banner that does not eat the screen, and removing scripts you cannot name a reason for.
Not worth doing: a separate “mobile site” on an m. subdomain. One responsive site is the job. If the layout cannot be patched without fighting the builder, a clean rebuild is cheaper than another year of lost calls. A Page Forge one-page site is £99 to set up and £29 a month, or £299 a year, built mobile-first from Hassocks. If you only want a diagnosis, the free website audit is the honest starting point.
Frequently asked questions
How do I know if my website is mobile-friendly?
Open it on your phone, ideally on mobile data. If you can read it, tap the buttons and call the business without zooming or fighting a pop-up, it is broadly fine. If any of that is awkward, fix it. A speed test confirms the technical side.
Does mobile-friendliness affect Google ranking?
Yes. Google judges the mobile version of the page, and poor usability or weak Core Web Vitals can hold rankings back as well as losing you the tap. For local firms it is one of the more important things to get right.
Why does my site look fine on a computer but bad on a phone?
It was probably built desktop-first, or it is an older design. The fix is a layout built for a small screen first: readable text, thumb-sized targets, a tappable number and images that fit. Shrinking a wide page is not the same job.
What is tap-to-call?
It is a phone number coded as a link so a tap on a mobile opens the dialler. For trades it is often the difference between a job and a bounce. Put the number at the top, make the tap target large, and do not hide it in an image.
What are Core Web Vitals?
Three measures of how a page feels: how fast the main content appears (LCP), how quickly it responds to a tap (INP), and how much it jumps while loading (CLS). In plain English: appears soon, reacts at once, does not shift under your thumb.
Do I need a separate mobile website?
No. One responsive site should fit phones and desktops. A separate mobile site doubles the maintenance and usually falls out of date. If the current site cannot be made to fit, rebuild it as one site rather than bolting on an m. address.