Technical SEO for small business: what actually matters

The on-page SEO articles in this series treated what a page says. This guide treats something prior to that: whether a search engine can reach the page, read it, and is willing to serve it at all. That is the domain of technical SEO.

Technical SEO has a reputation, among small business owners, for being the difficult and developer-only part of search optimisation. Part of that reputation is deserved and part of it is not, and one purpose of this guide is to separate the two — to set out what technical SEO a small business genuinely needs, how much of it the owner can handle, and where a developer is actually required.

A note on sources is in order. Peer-reviewed research is cited by author and year and listed at the end; Google’s own published guidance is cited as a primary source and identified as such; industry research that is not peer-reviewed is cited and explicitly labelled as such; and any claim resting on the common practice of the SEO field is identified as practitioner consensus.

What this guide covers

This guide is the pillar of the technical SEO articles in this series. It covers what technical SEO is, the principle that organises it, and the specific technical matters that genuinely affect whether a small business’s site performs in search.

It treats, in turn, whether a search engine can find and read a site’s pages; whether the site works on a phone; how quickly it loads; whether it is secure; and whether it is structured sensibly. It then addresses the smaller technical matters briefly, asks how much technical SEO a small business actually needs, and sets out honestly where the line falls between what an owner can do and what calls for a developer.

What technical SEO is

Technical SEO is the part of search optimisation concerned with the site as a technical object — with whether a search engine can crawl it, read it, and present it, and with the qualities of the site, such as its speed and its behaviour on a phone, that affect how it is treated.

It is the third of the three parts of SEO, alongside the two the series has already treated. On-page SEO concerns what each page says and whether it is a good answer. Off-page SEO, treated in a later article, concerns the authority a site earns from beyond itself. Technical SEO concerns neither the content nor the authority but the machinery — the conditions that have to be met before good content and earned authority can do their work.

The distinction matters because technical SEO sits, in a sense, beneath the other two. A page can be an excellent answer and a site can have earned real authority, and neither will help if a search engine cannot crawl the page, or cannot read it, or finds it so slow that visitors abandon it. Technical SEO is the part that ensures the other two parts are not wasted.

This also explains the reputation technical SEO carries, and why the reputation is only half right. Technical SEO can involve genuinely difficult, developer-level work, and at the scale of a large site it often does — which is the half that is true. The half that is false is the implication that a small business therefore cannot approach it: most of what technically matters for a small site is checking and organisation rather than engineering, and the difficult edge of the discipline is a problem the small site mostly does not have.

The principle: technical SEO removes obstacles

Technical SEO is easier to approach once its governing idea is clear, and the idea is a modest one. Technical SEO is not, for a small business, about being clever or advanced. It is about removing obstacles.

The picture to hold is this. Between a business’s good content and the customer who would value it, there is a search engine, and the search engine has to be able to do several things — reach the page, read it, understand it, and judge it worth serving. Each of those can be obstructed by a technical fault, and technical SEO is the work of finding and removing those obstructions.

This means technical SEO is, for most small businesses, defined by the absence of problems rather than the presence of cleverness. A site with no technical obstacles is not doing anything advanced; it is simply not standing in its own way. The goal is not a technically dazzling site but an unobstructed one — and that is a far more reachable goal for a small business than the word “technical” tends to suggest.

One consequence of this framing is liberating for a small business. If technical SEO is the removal of obstacles, then a small site with few obstacles is already most of the way there — it does not need to acquire technical sophistication, only to confirm that the ordinary things are not broken. The work is more like inspection than construction, and inspection is something an attentive owner can do.

The figure below shows where the obstacles tend to sit. A search engine moves a page through stages — it crawls, it indexes, it ranks, and the page appears to the customer — and technical SEO does most of its work at the early stages, making sure the page is not lost before it ever reaches the point where its content can compete.

Figure 1. A page moves through crawling, indexing, and ranking before it appears to a customer. Technical SEO works mainly at the first two stages — its job is to make sure a page is not lost before its content has the chance to matter.

Can the search engine find and read your pages?

The most fundamental technical question is also the one most often taken for granted: can a search engine actually find a site’s pages, and read them? If it cannot, nothing else in this guide matters, because a page that is never crawled and indexed cannot rank however good it is.

The two terms name two stages. Crawling is the search engine fetching a page — its automated crawler following links and retrieving pages, much as the original description of a large-scale search engine set out (Brin & Page, 1998). Indexing is the search engine then storing and making sense of what it fetched, so that the page becomes a candidate to be shown for relevant searches.

Things can go wrong at either stage, and the failures are not always visible. A site can, through a misconfiguration, instruct search engines not to crawl parts of it; a page can be left out of the index; a page can be reachable by a customer who has its link and yet effectively invisible to a search engine that has no path to it. Google’s own technical requirements describe what a page needs in order to be crawlable and indexable (Google Search Essentials, 2022).

A few specific causes account for most indexing failures, and they are worth knowing. A site can carry, from when it was being built, an instruction that tells search engines not to index it — an instruction that was correct during construction and was never removed. A page can sit with no link pointing to it from anywhere else on the site, so that a crawler following links never arrives. And a page can be blocked, by accident, in the file that tells crawlers what they may fetch. Each of these is a fixable cause, and each is the kind of thing the free tools are built to surface.

For a small business, the practical reassurance is that this is checkable. A search engine’s own free tools for site owners report which of a site’s pages have been indexed and flag problems that prevented others — and so a business does not have to guess whether its pages are being found. Confirming that the important pages are indexed is the first technical task, because it is the foundation the rest stands on.

Does your site work well on a phone?

The second technical matter is whether a site works well on a phone, and it is no longer a secondary consideration. For most small businesses, a large share of customers — often the majority — arrive on a mobile device, and a site that works poorly on a phone is working poorly for most of the people who see it.

There is a search dimension to this as well as a customer one. Search engines now assess a site substantially as it appears on a mobile device rather than a desktop one, which means the mobile version of a site is, for practical purposes, the version that is judged. A site that is acceptable on a desktop and awkward on a phone is being evaluated on its weaker form.

Working well on a phone is not a matter of having a separate mobile site; it means the ordinary site adapts to a small screen — text that is readable without zooming, buttons and links that can be used with a thumb, content that does not overflow or require horizontal scrolling. Most modern websites are built to adapt in this way by default, but a business should not assume it; it should look at its own site on an actual phone, as a customer would.

The problems to look for are specific. Text so small it must be zoomed to read; links and buttons set so close together that a thumb cannot reliably hit the right one; content that runs off the side of the screen and forces sideways scrolling; pop-ups that, on a small screen, cover the page entirely and are hard to dismiss — these are the common mobile faults, and a business doing what a customer would do on its own site will meet whichever of them the site has.

The practical task here is honest inspection. A business that opens its own site on a phone and tries to do what a customer would do — find a service, read a page, make contact — will discover most mobile problems quickly. The fixes vary in difficulty, but the discovery is free and within anyone’s reach.

How fast does your site load?

The third technical matter is speed, and it earns its own attention because it affects both of the things a business cares about — whether the site ranks, and whether the visitors it attracts stay.

The effect on visitors is well documented. An industry analysis by Google with the performance firm SOASTA, using a large body of mobile data, found that the likelihood of a visitor leaving rises steeply as a page slows: as load time stretches from one second to three, the probability of a mobile visitor bouncing rose by about a third, and by five seconds it had roughly doubled (Google/SOASTA Research, 2017; industry research, not peer-reviewed). The same body of work reported that more than half of mobile visitors abandon a page that takes longer than about three seconds to load.

The effect on ranking is also real, though more measured. Search engines treat the speed of a page, and the broader quality of the experience it offers, as a genuine factor in how it is ranked — not the largest factor, and not one that will lift a poor page above a good one, but a real one, and a tie-breaker between pages otherwise comparable. A slow site is at a disadvantage on both fronts at once: it ranks slightly worse, and it loses more of the visitors its ranking earns.

It is worth being clear about what “fast enough” means, because speed is a matter of diminishing returns. The large gains come from moving a genuinely slow site — one that takes many seconds — into the range of a few seconds or less; the difference between a fast site and a marginally faster one matters far less. A small business should aim to clear the low bar comfortably, and should not pour effort into shaving fractions of a second from a site that is already quick.

For a small business, speed is partly within reach and partly not. Some causes of slowness are simple — oversized images are the most common, and reducing them is genuinely an owner-level task. Others are deeper, in how the site is built, and belong to a developer. The first step, as with indexing, is measurement: free tools report how fast a site’s pages load and name the specific things slowing them, which tells a business which of its speed problems are the easy kind.

Is your site secure?

The fourth technical matter is security, and for most small businesses it reduces to one specific thing: whether the site is served over a secure connection — whether its address begins with the secure protocol, shown in browsers as a small padlock.

This matters for two reasons. It is, mildly, a ranking consideration: search engines have for years treated a secure connection as a small positive signal, and its absence as a small negative one. It matters more as a trust signal to the customer — modern browsers visibly mark sites that are not secure as “not secure,” and a customer who sees that warning, especially before entering any details, may simply leave.

The reassuring point is that this is, for most small businesses, a solved problem or an easily solved one. A secure connection requires a certificate, and most modern website hosting either includes one by default or makes adding one straightforward. It is rarely a difficult or expensive matter; it is, more often, a matter a business simply needs to confirm has been done.

The practical task is to look at the site’s own address and check for the secure protocol and the padlock, on the main pages and especially on any page that asks the customer for information. If the site is not secure, that is a problem to resolve promptly, because it undermines both the ranking and the trust the rest of the site is working to build.

Is your site structured sensibly?

The fifth technical matter is the site’s structure — how its pages are organised and connected, and whether that organisation makes sense to a customer and a search engine alike.

A sensibly structured site is one whose pages are arranged into logical groups, where a visitor can move from any page to the things related to it, and where the address of a page reflects its place in the whole. The opposite is a site that has grown without a plan — pages added wherever was convenient, navigation that does not reflect how a customer thinks, important pages buried several clicks deep.

Structure has a technical effect because a search engine uses a site’s internal links and organisation to discover pages and to understand how they relate. A page that is well connected to the rest of the site is easier for a search engine to reach and to place in context; a page that almost nothing links to is harder to find and harder to weigh. Sound structure also serves the customer directly, by making the site navigable.

A simple guide to good structure is that important pages should be shallow rather than deep — reachable in one or two steps from where a customer arrives, not buried five clicks down. A customer, and a crawler, should not have to dig to reach the pages that matter; a service page that a visitor can find quickly from the homepage is doing its job, and one that requires a hunt is, in effect, partly hidden.

For a small business, structure is largely an owner-level concern, because it is more a matter of organisation and clear thinking than of technical skill. The task is to ensure the site is arranged into sensible sections, that navigation reflects how customers actually look for things, and that the important pages — the service pages above all — are reachable in a click or two from the places customers start.

The smaller technical matters

Beyond the five matters above, a handful of smaller technical items are worth a business’s awareness, even though none of them needs to dominate its attention.

A sitemap is a file that lists a site’s pages for search engines, and helps them discover everything a site contains; most website systems generate one automatically, and a business mainly needs to confirm it exists. A robots file is a small instruction to crawlers about what they may and may not crawl; it is useful and also, if misconfigured, capable of accidentally hiding a site, which is why it is worth knowing it exists.

Broken links — links that lead to pages no longer there — and broken images accumulate quietly as a site ages, and they degrade the experience for both the customer and the search engine; an occasional check for them is sensible. Redirects, which send a visitor from an old address to a new one, matter when a business changes a page’s address or restructures its site, so that the value and the links pointing at the old address are not simply lost.

None of these smaller matters should alarm a small business, and none should be the first thing it attends to. They are mentioned so that a business knows they exist and knows the words, because a problem a business has heard of is a problem it can ask about — and most of these are either handled automatically by a modern website system or checked with a free tool.

The reason to keep these matters in proportion is that they rarely decide anything on their own. A missing sitemap or an occasional broken link will not, by itself, hold back a site whose larger technical health is sound; these are matters of tidiness rather than of consequence. They are worth a periodic check and not worth anxiety, and a business that has the five larger matters in order can treat the smaller ones as routine maintenance.

How much technical SEO does a small business actually need?

It is worth stating plainly, because the word “technical” invites overestimation, how much technical SEO a small business genuinely needs. The honest answer is: the basics, done properly, and little beyond them.

A small business is not a large one, and it does not face the technical problems a large one faces. The advanced and laborious end of technical SEO exists to address the difficulties of sites with many thousands of pages, complex systems, and large engineering teams — and a small business with a modest site has few of those difficulties. Pursuing enterprise-grade technical SEO on a small site is effort spent solving problems the site does not have.

What a small business needs is the foundation this guide has described: pages that can be crawled and indexed, a site that works on a phone, reasonable speed, a secure connection, a sensible structure. A small business that has those five things in order has done the technical SEO that genuinely affects it, and the marginal return on anything more advanced is, for most small sites, slight.

There is a real risk in the opposite direction worth naming. A business that becomes absorbed in technical SEO can spend on it the attention that the content and authority work needed more — polishing the machinery of a site whose pages still do not answer their questions well. Technical SEO earns its place by clearing a finite set of obstacles; once they are cleared, further technical effort is usually effort taken from where it would do more good.

This is a reassuring conclusion, and it is also a true one. The technical SEO that matters for a small business is a finite, reachable list — not an endless or arcane discipline — and a business that has worked through that list can turn its attention, with a clear conscience, to the on-page and off-page work where its remaining effort returns more.

When to call a developer

Some of the technical SEO this guide has described is genuinely within an owner’s reach, and some of it is not, and a business is served by an honest account of the line between them rather than by either false confidence or false helplessness.

An owner can, without a developer, do a great deal. Confirming that pages are indexed using a search engine’s free tools; checking the site on a phone; reducing oversized images; verifying the secure connection; organising the site’s structure and navigation; checking for broken links — these are matters of attention and organisation, not of code, and a business that does only these has done most of what technically matters.

A developer is genuinely needed for the deeper faults. Slowness rooted in how the site is built, problems with crawling or indexing that the free tools report but whose cause is not obvious, a site that does not adapt to phones because of its underlying construction, structural changes that require redirects to be set up correctly — these reach past attention into the building of the site, and attempting them without the skill can create worse problems than it solves.

The practical rule is one of diagnosis. A small business can, and should, do the checking — running the free tools, inspecting its own site, finding the problems. The checking is what reveals which problems are the simple kind an owner can fix and which are the deeper kind a developer should. A business that has done the diagnosis can then call a developer for specific, identified faults, which is a far better position than calling one in vague unease — it knows what it is asking for, and can tell whether the work was done.

It helps, when a developer is called, to brief them in the language of the problem rather than the language of the solution. A business is on firm ground describing the symptom — a page that is not indexed, a site slow on phones, a report from a free tool — and on far less firm ground prescribing the fix. A good developer, given a clear account of the symptom and the evidence, will diagnose the cause; a business that instead asks for a particular technical change it has half-understood may get the change and not the result.

The tools that do the checking

This guide has referred repeatedly to free tools that let a business check its own technical health, and they deserve a section of their own, because they are what make the checking possible for an owner with no technical background.

The most important is the free service a search engine provides for site owners — a console through which a business can see how the search engine treats its site. It reports which pages have been indexed and which have not, flags the reasons pages were excluded, and surfaces problems with crawling, mobile usability, and more. It is the single most useful technical tool a small business has, and it costs nothing but the setting up.

Alongside it are free tools that test page speed. A business gives such a tool the address of a page, and it reports how quickly the page loads, scores the experience it offers, and — most usefully — names the specific things slowing the page down, often distinguishing the easy fixes from the structural ones.

The value of these tools is that they replace guesswork with evidence. A business does not have to wonder whether its pages are indexed, or whether its site is slow, or why — the tools answer those questions directly, in plain reports. A small business that has set up the free site-owner console and learned to read a speed report has acquired most of the technical visibility it needs, and acquired it for nothing.

Where to start, and in what order

A business that has read this far has a list of technical matters and a reasonable question: in what order should they be addressed? The matters are not equally urgent, and a sensible sequence saves effort.

The first thing to check is crawling and indexing, because it is the foundation everything else stands on. There is no point improving the speed or the structure of pages that a search engine is not indexing at all — so a business should begin by confirming, with the free tools, that its important pages are in the index, and resolve any failure there before moving on.

The second thing to check is the site on a phone, because most customers are on phones and a search engine judges the site largely in its mobile form. A site that is broken on mobile is failing most of its audience now, which makes it the next most urgent matter after indexing.

Speed and security come next — both genuinely matter, both are partly within an owner’s reach, and both are measured or confirmed quickly. Structure, the smaller matters, and anything a developer must handle follow after. The principle behind the order is simple: fix the faults that make the site invisible or unusable before the faults that merely make it less good, and check the cheap things before commissioning the expensive ones.

One last point about timing. This sequence is for a business approaching its site’s technical health for the first time; once the list has been worked through, technical SEO becomes a matter of occasional re-checking rather than a project. A site that was sound can develop faults — a change breaks something, a page falls out of the index, the site slows as it grows — so the free tools are worth a periodic look even after the initial work is done. The order above is how to start; a light, regular check is how to keep the foundation sound.

A technical SEO checklist

The table below gathers the technical matters this guide has treated, with the question to ask of each and an honest indication of who can usually handle it.

Technical matter	The question to ask	Usually handled by
Crawling and indexing	Are the important pages actually in the search engine’s index?	Owner checks; developer fixes deeper faults
Mobile	Does the site work well when used on a phone?	Owner checks; developer fixes if the build is at fault
Speed	Do the pages load quickly, within a few seconds?	Owner fixes images; developer fixes the rest
Security	Is the site served over a secure connection?	Owner confirms; host usually provides it
Site structure	Are pages organised sensibly and well connected?	Owner, mostly — it is organisation, not code
Sitemap and robots file	Do they exist, and is nothing hidden by mistake?	Owner checks; usually automatic
Broken links	Do links and images still lead where they should?	Owner, with a free checking tool
Redirects	When a page’s address changes, is the old one redirected?	Developer, when the site is restructured

Concluding remarks

Technical SEO is the part of search optimisation concerned with the site as a technical object — with whether a search engine can crawl it, read it, and is willing to serve it, and with the qualities, such as speed and mobile behaviour, that affect how it is treated. It sits beneath on-page and off-page SEO, and its job is to ensure that good content and earned authority are not wasted.

Its governing idea is modest: technical SEO removes obstacles. For a small business it is defined by the absence of problems rather than the presence of cleverness, and the problems that matter are a finite list — whether pages can be crawled and indexed, whether the site works on a phone, whether it loads quickly, whether it is secure, whether it is structured sensibly.

A small business does not need enterprise-grade technical SEO; it needs those basics done properly, and little beyond. A great deal of the checking is within an owner’s reach, and the value of doing it is precisely that it reveals which of the remaining problems are simple and which genuinely call for a developer. A business that has worked through the list can turn the rest of its attention to the content and authority work that the technical foundation exists to support.

The next articles in this series continue within technical SEO, treating the practical audit a non-developer can carry out and the matter of site speed in more detail, before the series turns to off-page SEO and the authority a site earns from beyond itself.

Future developments

Technical SEO is, of the three parts of SEO, the one whose underlying logic changes least, and that is worth saying plainly amid the noise about AI-driven search. Whatever composes the answer a customer sees, it must still reach the page, read it, and make sense of it — and the technical conditions that allow that are the same conditions this guide has described.

If anything, the technical foundation grows more important. An AI system that draws on web pages to compose an answer can only draw on pages it can crawl, read, and parse; a page that is technically obstructed is invisible to such a system exactly as it is invisible to a traditional search engine. The crawlability, the speed, the clean structure that this guide has urged are the same properties that let an automated system find and use a page.

What a small business should take from this is steadiness rather than anxiety. The advanced edge of technical SEO will continue to move, as it always has, and a small business does not need to track it. The technical basics — a site that can be reached, read, and used, on a phone, quickly, securely — are durable, and a business that has them in order has built a foundation that the next change in search will not undermine.

References

Brin, S., & Page, L. (1998). The anatomy of a large-scale hypertextual web search engine. Computer Networks and ISDN Systems, 30(1–7), 107–117.

Google Search Essentials. (2022). Google Search Central documentation. Google. [Primary source — official platform documentation, not peer-reviewed.]

Google/SOASTA Research. (2017). Mobile page speed and bounce rate analysis. Reported via Think with Google. [Industry research — not peer-reviewed.]