Technical SEO

Most small business websites fail a basic Google health check. Here is why that matters.

Open Google PageSpeed Insights and paste in any small business website built on WordPress, Wix, or Squarespace. The performance score will almost certainly land somewhere between 30 and 60 out of 100. That is not a guess. It is what I see on nearly every site I review.

Google measures three things when it evaluates page experience: how quickly the largest visible element loads (Largest Contentful Paint), how fast the page responds when someone taps or clicks something (Interaction to Next Paint), and whether the layout jumps around while loading (Cumulative Layout Shift). Together, these are called Core Web Vitals, and they have been a ranking signal since 2021. A site that fails them is not just slow for visitors. It is actively penalised in search results compared to a site that passes.

The technical side of SEO is everything that affects those scores and everything else Google needs to do its job: finding your pages, reading your code, understanding your site structure, and indexing the right content. It runs underneath on-page SEO (which handles content and keywords) and alongside local SEO (which handles location visibility). You rarely see it. Google always does.

What goes wrong under the surface

A plumber in Wolverton launches a WordPress site. It looks fine. The content is good. The phone number is right. But behind the scenes, the theme loads three JavaScript libraries the site does not use. The contact form plugin adds its own stylesheet to every page, even pages without a form. The slider on the homepage downloads six full-resolution images on load whether the visitor scrolls to them or not. A caching plugin conflicts with the hosting provider's built-in cache, doubling the work. There is no XML sitemap because nobody enabled the setting. The staging site's noindex tag was never removed, so Google has been told not to index the homepage for the past eight months.

None of this is visible to the business owner. The site looks the same as the day it launched. But the Lighthouse score sits at 38, the pages take 4.7 seconds to load on mobile, and Google has quietly stopped showing the site in local results because faster, cleaner competitors exist.

This is the kind of problem technical SEO solves. Not by adding something to the site, but by removing the friction that should not have been there in the first place.

How building in static HTML changes the equation

A hand-coded static site does not have these layers. There is no CMS generating pages on the fly. No database queries. No plugin stack. No JavaScript framework that needs to execute before Google can see the content. The HTML file is the page. The browser receives it, renders it, and the visitor sees it. Nothing in between.

That is why my sites consistently score 90+ on Lighthouse while the industry average for small business sites sits at roughly half that. The difference is not clever optimisation tricks applied after the fact. It is the absence of the platform overhead that creates the problems in the first place.

Static does not mean limited. The sites still have forms, responsive layouts, image pipelines that serve avif and webp depending on the browser, and all the interactive elements a small business site needs. They just do it with less code, fewer requests, and no dependency on a server-side application running on every page load.

The build-time decisions that most developers skip

Technical SEO is not a phase that comes after the site is built. It is a set of decisions made during the build, and getting them wrong means retrofitting later (or, more often, never fixing them at all).

When I build a site, the URL for each page is decided during the keyword research phase, not generated automatically by a CMS. The heading hierarchy is planned as part of the content structure, not styled randomly because an H3 looked better than a paragraph. Image files are named descriptively and compressed into modern formats before they touch the server. The XML sitemap is generated automatically by the build tool and submitted to Search Console on launch day. Every page gets a canonical tag. Every page gets an accurate robots directive.

Structured data goes in at this stage too. A LocalBusiness schema tells Google the business name, address, phone number, and service area in a format it can parse directly. If the site has an FAQ section, FAQPage schema can earn expanded search listings. These are small additions to the code that produce measurable results in how your pages appear in search.

The whole point is that by the time the site goes live, the technical foundation is already right. There is no audit needed. There is no "phase two" where an SEO consultant comes in to fix what the developer missed.

After launch, the monitoring does not stop

The Growth plan at £380 a month includes ongoing technical monitoring through Google Search Console. That means I am watching for crawl errors (pages Google tried to access and could not), indexing issues (pages Google found but chose not to index), Core Web Vitals regressions (performance dropping over time), and mobile usability warnings.

When something flags, I investigate and fix it. A new page that Google cannot reach gets its internal linking reviewed. A performance dip gets traced back to an image that was uploaded without compression. A 404 spike after a URL change gets resolved with a redirect. These are small interventions that prevent small problems from becoming ranking drops.

On the Business plan, the technical foundation is solid at launch and the hosting is maintained. The difference is that there is no ongoing Search Console monitoring or proactive technical work. The site stays fast because it was built fast, but nobody is watching the data month to month. That distinction is the core of what separates the two plans.

A quick way to check where your site stands right now

If you want to see how your current site performs technically, run it through Google PageSpeed Insights and Google's Rich Results Test. PageSpeed will give you a performance score and flag the specific issues dragging it down. The Rich Results Test will tell you whether Google can read any structured data on your pages.

If the performance score is below 70, the issues are almost certainly platform-related. If there is no structured data at all, Google is working with less information than it could be. Neither of those things means the site is broken in a way visitors will notice immediately, but both mean Google is ranking you lower than a competitor whose technical foundations are in order.

If the numbers concern you and you want a proper assessment, I am happy to run a full technical review. No charge, no obligation. It takes about fifteen minutes and I will tell you plainly what is fixable within your current setup and what would need a full rebuild.

Monday to Sunday: 24 hours

Call, Text or WhatsApp us anytime
for a free consultation call.