Small Business Website: Speed, Hosting and Getting Found on Google

You’re looking at a PageSpeed Insights report covered in red bars. Your web agency says everything’s fine. And the site hasn’t brought in a single enquiry in months. The problem sits somewhere between those three things, and it’s almost always hiding in a spot that none of the reports you’ve been sent even mention.

Plenty of small business owners treat their website like an online brochure. What matters is the look: the logo, the photos. Then they’re surprised to find that, to Google and to anyone opening it on a phone, that brochure is slow, badly hosted or simply invisible. This piece is about getting the site you already have to work, after someone else has built it.

A business website has three layers, and most small firms only look after one

Every business website runs on three stacked layers. The first is what you see: copy, images, design. The second is where the site physically lives, meaning the server that hosts it. The third is whether people can find it, meaning if and how Google shows it to someone searching.

Small businesses tend to pour their budget and attention into the first layer, the visual one, because it’s the only one they can actually see. The other two stay abstract, left to “whoever built the site”. That’s where an expensive misunderstanding starts: the belief that a prettier or faster site is enough to bring in customers.

A study on how website performance affects sales put exactly that belief to the test with a field experiment. The researchers followed two comparable restaurants for two months, one with a slower site and one with a faster site, tracking morning visits to the website and sales of the daily menu. The result is awkward for anyone selling “miracle optimisation”: speeding up the site produced no statistically significant increase in visits to the restaurant.¹

The takeaway is about what speed is for. It’s the baseline that makes a site usable. Sales come from somewhere else. A fast site nobody can find on Google is still a site nobody finds. A beautiful site on a sluggish server keeps losing people who open it on mobile. You have to look after all three layers, and to do that you first need to be able to tell them apart.

Why your PageSpeed score is misleading you

You open PageSpeed Insights, paste in your URL and get a number. 62. Red. Panic sets in, and you ring your developer asking them to “get it to 90”.

That number is a classic trap. The Lighthouse score at the top of the report is a lab test: a simulation run on a standard machine, over a fake connection, at one specific moment. It’s handy for the developer working in the code. Google judges you on something else.

Google looks at field data, the real-world performance recorded in the browsers of people who actually visited your site recently. In the same PageSpeed report you’ll find it in the section on real user experience, kept separate from the lab score. If that section is green and the lab score is red, Google thinks you’re doing fine. If it’s the other way round, you have a problem, however good the lab result looks.

Chasing a perfect Lighthouse score is a common mistake and a waste of money. Ask your developer for the field data, not the score. If your site gets too little traffic to have real-user data, the lab score becomes the only clue you’ve got, and tools like GTmetrix or a third-party speed test help you cross-check it. Even then, treat it as a provisional clue and read it carefully.

How fast does your business website need to be?

Field data is measured with Core Web Vitals, three metrics that describe what someone actually experiences when they open the page. Google publishes a threshold for each one, below which the experience counts as good, and it’s worth checking those against the official documentation.

LCP measures how long it takes for the largest element on the page, usually the main image, to appear. If your visitors sit staring at a white screen for ages, plenty of them have already left. INP measures responsiveness: how long a button takes to react when you tap it. CLS measures visual stability, that maddening jump where the text shifts just as you go to tap a link and you end up on the cookie banner.

There’s a fourth metric that isn’t a Core Web Vital but explains a lot of slow sites. It’s called TTFB, the time the server takes to send its first response. A high TTFB means the delay starts before the browser has downloaded a single image, and compressing your photos won’t touch it. TTFB usually points straight at your hosting. The three Core Web Vitals, read page by page, are the technical side of the job.

Hosting is a decision, and it matters more than you’d think

Hosting rarely gets treated as a decision at all. It shows up as one line in a checklist (“choose fast hosting”) or as a list of brand names. Yet when TTFB is high and the server takes half a second to respond, you can optimise images and code forever without moving the needle an inch.

There’s a clear sign that the problem is infrastructure rather than presentation. If TTFB stays consistently high even on simple pages, the problem sits upstream of any optimisation. You’re paying for an overcrowded shared server or a plan that’s too small for the traffic you get. At that point no amount of compression will save you, and spending more on “speed optimisation” is like polishing the car while the engine’s smoking.

Before you sign or renew, here are the questions any decent provider should answer without breaking a sweat:

• Is the plan shared, VPS or dedicated, and how many resources are guaranteed?
• Where is the data centre physically located? If your customers are in Italy and the server is on another continent, you start with a built-in delay.
• Is server-side caching included, along with a CDN to serve content closer to whoever is loading it?
• What average TTFB do they guarantee, and how do they measure it?
• What happens to the site when traffic spikes, say after a campaign?

If the answers are vague, you have your diagnosis. This is where AI earns its keep in a very specific way: it helps you prepare for the negotiation. Before you email your provider, draft your requirements with a prompt like this:

“You’re an independent technical consultant. My small business has a WordPress brochure site with around 4,000 visits a month, an Italian audience, and a measured average TTFB of 900 ms. The provider is suggesting I stay on my current shared hosting plan at €60 a year. List 8 specific technical questions I should ask to find out whether the hosting plan is the problem, and for each one tell me what counts as an acceptable answer and what should set off alarm bells.”

What you get back is an evaluation grid that puts you on equal footing with whoever’s trying to sell you the renewal. The decision is still yours, but now you’re making it against clear criteria.

Published and indexed are two different things

Now for the layer almost nobody connects to speed: showing up on Google. Your site can be live, fast and flawless and still not appear in any search. “Published” and “indexed” are two different states, and there are steps in between that nobody walked you through.

A site is published when you type in the address and it loads. It’s indexed when Google has visited it, read it and added it to its index. It’s ranking when Google decides to show it for a particular search. These are three hurdles in a row. You can clear the first and stay stuck at the second for months without noticing, convinced the site “is on Google” because it comes up when you search your exact company name (that’s just Google recognising your domain, which has nothing to do with ranking).

The tool that tells you which hurdle you’re stuck at is free and called Google Search Console. Connect your site, open the page indexing report, and you’ll see in black and white how many pages Google actually holds in its index and how many it has dropped, along with the reason. Among the statuses you might see are “Discovered – currently not indexed” and “Crawled – currently not indexed”, which often point to content too thin or too duplicated to earn a place.

Then there’s the opposite case, and the more frustrating one: indexed but not ranking. The pages are there, Google knows about them, but you don’t show up for the searches you care about. At that point the problem shifts to content and authority, and speed is only a secondary factor. For a local business, a good share of visibility also comes from your Google Business Profile, which lives outside your website and is a contact channel in its own right.

Symptom, cause, who fixes it

The point of all this is reaching a diagnosis that tells you whether the problem is something you can fix yourself, something to hand off, or a reason to change provider. This table sums up the most common symptoms.

Symptom	Likely cause	Who fixes it
Low PageSpeed score but green field data	Nothing, you’re chasing the wrong number	No action needed, keep an eye on real-user data
White screen for seconds before the image appears	High LCP, heavy images or a slow server	Your developer for images, your host if TTFB is high
TTFB consistently high	Hosting too small or too far away	Upgrade the plan or switch provider
Text jumps around while loading on mobile	High CLS, no space reserved for images and banners	Whoever looks after the theme or template
The site loads but doesn’t show up when you search for it	Pages not indexed	Check Search Console, then work on content
You only appear when searching your exact company name	Indexed but not ranking	Work on content and authority

A structured website review starts right here. It separates cosmetic symptoms from infrastructure ones, so you spend money where it counts.

Using AI to work out what’s wrong

In this job, AI stays well away from the site itself. It helps you read the data and make decisions. Copy the field values from your PageSpeed report and the reasons for non-indexing from Search Console, then hand them to a model with a prompt built around a decision:

“Here are my site’s field Core Web Vitals: LCP 3.8 s, INP 150 ms, CLS 0.02, TTFB 850 ms. And from Search Console: 34 pages indexed, 51 ‘Discovered – currently not indexed’. I’m not technical. Tell me, in order of priority, which of these problems come from hosting, which from content and which from the template, and for each one whether I should fix it myself, hand it to a provider or rethink my hosting plan. No jargon.”

The answer gives you a prioritised list to take to whoever works on your site, instead of a report you can’t decode. If you then want to understand how AI-powered answer engines see and cite your site, that calls for a separate look at that layer. It still comes after the diagnosis and never replaces it.

When the diagnosis says the problem is structural, and building or overhauling the site is beyond what your team can handle in-house, that’s the moment to consider managed support for hosting, performance and Google visibility. It’s the step that separates people who keep polishing a blown engine from people who get it fixed.

Sources

Further reading

• Google Search Console: a practical guide to finding out whether your site brings in customers
• How to get seen on Google Maps: a guide for restaurants and local businesses
• Why isn’t my business showing up on Google Maps? Causes, checks and fixes
• Google reviews: how to read them, manage them and ask for them without sounding desperate
• What is a landing page? Definition, types and when you actually need one
• Building websites and landing pages for small businesses: the complete guide
• How much does a cinematic website cost? A guide to real 2026 prices

Footnotes

1. THE IMPACT OF WEBSITE PERFORMANCE ON BUSINESS SALES. doi.org ↩