{"id":29189,"date":"2026-05-29T14:30:03","date_gmt":"2026-05-29T19:30:03","guid":{"rendered":"https:\/\/www.jasminedirectory.com\/blog\/?p=29189"},"modified":"2026-05-29T14:32:42","modified_gmt":"2026-05-29T19:32:42","slug":"a-technical-seo-audit-a-non-developer-can-actually-do","status":"publish","type":"post","link":"https:\/\/www.jasminedirectory.com\/blog\/a-technical-seo-audit-a-non-developer-can-actually-do\/","title":{"rendered":"A technical SEO audit a non-developer can actually do"},"content":{"rendered":"

The technical SEO guide earlier in this series set out what technical SEO is and which technical matters genuinely affect a small business. This article is the practical follow-through: the actual audit, carried out step by step, that a small business<\/a> owner with no technical background can run on their own site.<\/p>\n

The word “audit” can sound forbidding, as though it required a specialist. The audit described here does not. It is a sequence of plain checks, performed with free tools, that any attentive owner can complete in an afternoon \u2014 and its purpose is not to fix everything but to find what is wrong and sort it, which is a task an owner is well placed to do.<\/p>\n

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<\/a> research that is not peer-reviewed is cited and explicitly labelled; and any claim resting on the common practice of the SEO field is identified as practitioner consensus.<\/p>\n

What this article covers<\/h2>\n

This article covers a technical SEO<\/a> audit scaled to a small business and to a non-developer \u2014 a defined sequence of checks an owner can run on their own site, together with what to do with what the checks find. It is a how-to companion to the technical SEO guide, which a reader who wants the underlying explanation of each matter should treat as the foundation.<\/p>\n

The article first sets the honest scope of what such an audit can and cannot do. It then lists what an owner needs before starting, works through the audit as six steps, and treats what comes after the checks: recording the findings, sorting them, acting on them, and repeating the audit on a sensible schedule.<\/p>\n

What a non-developer audit can and cannot do<\/h2>\n

It is worth being honest, at the outset, about what this audit is and is not \u2014 because a clear scope is what makes it genuinely useful rather than falsely reassuring.<\/p>\n

What the audit can do is find problems and sort them. An attentive owner, running the checks described here, can discover whether the site’s pages are indexed, whether the site works on a phone, whether it is fast and secure, whether its structure is sound \u2014 and can tell, for each problem found, whether it is the kind an owner can fix or the kind that needs a developer. The audit produces a clear, sorted account of the site’s technical health<\/a>.<\/p>\n

What the audit cannot do is fix the deep faults. Some technical problems, once found, are genuinely developer work, and this audit does not pretend otherwise; it does not teach an owner to rebuild a slow site or to resolve a complex indexing fault. That is not a weakness of the audit but the point of it \u2014 finding and sorting the problems is precisely what lets a business fix the simple ones itself and brief a developer accurately on the rest.<\/p>\n

An audit understood this way is worth far more to a small business than the vague unease it replaces. A business that has run it knows the state of its site; a business that has not is guessing, and a business that calls a developer without it is paying someone to find what the business could have found for nothing.<\/p>\n

There is a second thing the audit cannot do, and it is worth naming so that expectations are right. The audit is a technical audit; it checks whether a search engine can reach, read, and serve the site, and it does not assess whether the site’s pages are good answers or whether the business has earned authority. A site can pass this audit completely and still rank poorly, because its content is thin or its competitors are stronger. The audit confirms that the technical foundation is sound; it does not, and cannot, confirm that the building on the foundation is well made.<\/p>\n

Why a systematic audit beats noticing problems as you go<\/h2>\n

A reasonable objection to the idea of an audit is that a business already notices problems as it goes — a page that looks wrong, a complaint from a customer — and fixes them. Why set aside an afternoon for a formal sequence of checks when problems announce themselves anyway?<\/p>\n

The answer is that the problems that matter most do not announce themselves. The technical faults treated in this series are quiet: a page missing from the index, a site slow on phones, a structure that buries the service pages — none of these produces a visible error or a customer complaint. They produce only an absence of traffic, and an absence is not something a business notices, because there is nothing there to notice.<\/p>\n

Ad-hoc fixing also has no coverage. A business that fixes what it happens to notice has checked whatever happened to catch its eye, and nothing else — which means it has no idea what it has missed, and a fault can sit undisturbed for years simply because it never happened to surface. A systematic audit, by contrast, checks the same defined set of things every time, so that a business knows not only what it found but what it looked for.<\/p>\n

None of this is an argument against also fixing problems as they are noticed; a business should of course fix a fault it stumbles on. It is an argument that ad-hoc noticing is not enough on its own, and cannot be, because it only ever covers the visible. The audit is what covers the rest — and the rest, in technical SEO, is most of it.<\/p>\n

This is the case for the audit in one sentence: it converts the technical health<\/a> of the site from something a business hopes is fine into something a business has actually checked. The afternoon it costs buys a kind of knowledge that ad-hoc attention, however diligent, cannot produce.<\/p>\n

Before you start: what you need<\/h2>\n

The audit needs very little, and none of it costs money. It is worth gathering the few things in advance, so the checks themselves run without interruption.<\/p>\n

The first is the free service that the major search engine provides for site owners \u2014 a console that reports how the search engine sees the site. Setting it up takes a little time and a one-time verification that the business owns the site, and it is the single most valuable thing in the audit, so it is worth doing first and properly. The second is a free page-speed testing tool, of which several exist; it needs nothing but the address of a page to test.<\/p>\n

The third and fourth are things the business already has: an actual mobile phone, for checking the site as a customer on a phone would see it, and an ordinary web browser on a computer. The audit uses no specialist software<\/a> beyond the two free tools, and a business that has set up the site-owner console has done the only preparation that takes any effort.<\/p>\n

It is worth setting aside a single, uninterrupted block of time for the audit rather than spreading it across odd moments. The six checks are quick individually, but an audit done in fragments — a check here, a check there, over a fortnight — tends to lose its thread, and the business ends unsure which checks it actually completed. An afternoon, start to finish, with the findings recorded as they are made, produces a complete and trustworthy result; the same checks scattered across two weeks often do not.<\/p>\n

The figure below sets out the shape of the audit that follows: six checks, and then the sorting of whatever the checks reveal.<\/p>\n

\n\n \n \n <\/path>\n <\/marker>\n <\/defs>\n <\/rect>\n Stage one — run the six checks<\/text>\n <\/rect>\n <\/rect>\n <\/rect>\n <\/rect>\n <\/rect>\n <\/rect>\n 1. Is the site indexed?<\/text>\n 2. Does it work on a phone?<\/text>\n 3. Is it fast enough?<\/text>\n 4. Is it secure?<\/text>\n 5. Is the structure sound?<\/text>\n 6. Broken links and faults?<\/text>\n <\/line>\n Stage two — sort what you found<\/text>\n <\/rect>\n <\/rect>\n <\/rect>\n Fix now, yourself<\/text>\n Fix later, yourself<\/text>\n Hand to a developer<\/text>\n<\/svg>
Figure 1.<\/strong> The audit has two stages. The six checks find what is wrong; the sorting decides what happens to each finding. A non-developer can do all of stage one and the sorting, and most of what lands in the first two boxes of stage two.<\/figcaption><\/figure>\n

Keeping the audit honest: find first, fix later<\/h2>\n

One discipline makes the difference between an audit that works and one that quietly fails, and it is worth stating before the checks begin: during the audit, find problems; do not fix them.<\/p>\n

The temptation runs the other way. A business that, at step one, discovers a page missing from the index will feel the natural urge to stop and resolve it there and then. The urge is understandable and it should be resisted, because giving in to it turns a structured audit into a scattered afternoon of half-finished repairs — and a business that stops to fix the first problem often never reaches steps four, five, and six at all.<\/p>\n

There is a further reason to keep the two apart. The sorting stage, which decides what to fix and in what order, works on the whole list of findings; a business that fixes problems as it finds them is fixing them in the order it happened to find them, which is not the order of how much they matter. A page missing from the index found at step one is more urgent than a broken link found at step six, and only an audit that finished before it started fixing can see that.<\/p>\n

The rule, then, is to run all six checks first, recording what each one finds, and to begin fixing only once the audit is complete and sorted. The finding and the fixing are different tasks, and the audit works when they are kept that way.<\/p>\n

The audit, step by step<\/h2>\n

The audit proper is six checks, taken in the order below. The order is deliberate \u2014 it runs from the most fundamental matter to the least \u2014 and a business should work through the six in sequence rather than jumping among them.<\/p>\n

Step one: is the site indexed?<\/h3>\n

The first check is the most fundamental, because a page that a search engine has not indexed cannot rank however good it is. The question is simply whether the search engine has the site’s important pages in its index at all.<\/p>\n

The site-owner console answers this directly. It reports how many of a site’s pages are indexed, lists which pages are not, and gives, for each excluded page, the reason it was left out. A business runs this check by opening that report and confirming that its important pages \u2014 the homepage, the main service pages \u2014 appear among the indexed ones.<\/p>\n

If a key page is missing, the console’s stated reason is the start of the diagnosis. Some reasons point to simple causes an owner can address; others point to deeper faults; the foundational accounts of how a search engine crawls and indexes pages explain why these failures matter (Brin & Page, 1998), and Google’s technical requirements describe what a page needs to be indexable (Google Search Essentials, 2022). For the audit, the task is only to record which pages are indexed and which are not.<\/p>\n

One practical note makes this check more useful. A quick way to see whether a specific page is known to the search engine, short of the full console report, is to search for the page’s exact address: if the page is indexed, it appears, and if it does not, that is a signal worth following up in the console. It is a rough check rather than a definitive one, but it is instant, and a useful way to spot-check an important page between full audits.<\/p>\n

Step two: does it work on a phone?<\/h3>\n

The second check is whether the site works well on a phone, which matters because most customers arrive on one and because a search engine judges the site largely in its mobile form.<\/p>\n

This check is done on an actual phone, not on a computer’s approximation of one. The business opens its own site on a phone and tries to do what a customer would: find a service, read a page, make contact. It looks for the common mobile faults \u2014 text too small to read without zooming, links and buttons too close together to tap reliably, content that runs off the side of the screen, pop-ups that cover a small screen and resist dismissal.<\/p>\n

The site-owner console contributes here too, since it reports mobile usability problems it has detected. Between the console’s report and the owner’s own inspection on a real phone, most mobile faults will be found. The task, again, is to record them.<\/p>\n

It is worth checking more than the homepage. A site can be acceptable on a phone at its front door and awkward deeper in — a service page with a form that is hard to complete on a small screen, an image that breaks the layout — and since the service pages are where customers decide, their behaviour on a phone matters most. The check should walk the same path on a phone that a customer would, all the way to the point of making contact.<\/p>\n

Step three: how fast does it load?<\/h3>\n

The third check is speed, run with a free page-speed testing tool. The business gives the tool the address of a page \u2014 the homepage and a main service page are the ones that matter most \u2014 and reads what it returns.<\/p>\n

A speed tool reports more than a single score. It states how long the page takes to load, rates the experience the page offers, and, most usefully, names the specific things slowing the page down \u2014 often distinguishing the simple causes, such as oversized images, from the structural ones. The next article in this series treats site speed in depth; for the audit, the task is to run the test on the main pages and record both the result and the named causes.<\/p>\n

The thing to note while recording is which causes are the easy kind. A speed report that blames oversized images has named an owner-level fix; one that points to how the site is built has named a developer-level one, and that distinction is exactly what the sorting stage will need.<\/p>\n

One caution applies to reading a speed result. A speed tool reports a score, and a score invites a business to chase it as a number; but the score matters less than the load time itself and the named causes beneath it. A business should record the load time, note which causes the tool has flagged, and resist treating the single headline number as the thing to optimise — the next article in this series explains why the load time, not the score, is what the visitor experiences.<\/p>\n

Step four: is it secure?<\/h3>\n

The fourth check is the quickest. The business looks at its own site’s address in the browser and confirms two things: that the address begins with the secure protocol, and that the browser shows the small padlock rather than a “not secure” warning.<\/p>\n

The check should be made on the main pages and, with particular care, on any page that asks a customer for information. A site that is secure passes this check in seconds; a site that is not has found a problem worth recording as urgent, because an insecure site costs both a small amount of ranking and a larger amount of customer trust.<\/p>\n

If the check fails, the matter is worth treating as urgent rather than routine, and it is also usually quick to resolve. A secure connection requires a certificate, and most modern hosting either includes one or makes adding it straightforward; the fix is often a matter of the business asking its host or enabling a setting rather than commissioning real work. An insecure site is a problem to record at the top of the list and, usually, one of the easier problems on that list to clear.<\/p>\n

Step five: is the structure sound?<\/h3>\n

The fifth check concerns the site’s structure \u2014 whether its pages are organised sensibly and well connected. This check is less a tool’s job than the owner’s judgement, exercised by navigating the site as a customer would.<\/p>\n

The business starts where a customer starts, usually the homepage, and tries to reach its important pages. It asks whether the main service pages can be reached in a click or two, whether the navigation reflects how customers actually look for things, and whether the site falls into sensible sections rather than a loose pile of pages. A structure that buries important pages several clicks deep, or that is organised by the business’s internal logic rather than the customer’s, is the finding to record here.<\/p>\n

A useful way to make this check less subjective is to ask someone who does not know the site to find something on it. A business owner knows where everything is and so cannot easily see what is buried; a person seeing the site fresh, asked to find a particular service, will reveal in a minute whether the structure is genuinely navigable. The places they hesitate are the structural faults the check is looking for.<\/p>\n

Step six: are there broken links and other small faults?<\/h3>\n

The sixth check gathers the smaller technical matters the previous guide named. The business checks for broken links and broken images \u2014 links and images that no longer lead where they should \u2014 using one of the free tools that crawl a site and list them.<\/p>\n

It is also worth confirming, while here, that the site has a sitemap and that nothing important is being accidentally blocked from crawlers \u2014 both matters the site-owner console will help with. None of these smaller faults is likely to be decisive on its own, but they accumulate, and recording them completes the picture of the site’s technical health.<\/p>\n

A note on proportion belongs with this final check. Broken links and the other small faults are worth finding and worth fixing, but they are rarely what is holding a site back, and a business should not let the tidy, finite work of clearing them crowd out the larger matters found in the earlier steps. This step completes the picture; it is not, for most sites, where the picture’s main problem lies.<\/p>\n

Recording what you find<\/h2>\n

The audit produces value only if its findings are written down. An audit done in the head produces a vague impression \u2014 the site is “probably fine,” or “a bit slow” \u2014 and a vague impression cannot be acted on or checked.<\/p>\n

The record need not be elaborate. A simple list will do: for each of the six checks, what was found, and on which pages. The point is that the audit ends with a document \u2014 a concrete, specific account of the site’s technical state \u2014 rather than with a feeling.<\/p>\n

This written record is what the rest of the work depends on. It is what gets sorted in the next stage; it is what a developer is briefed from, if one is needed; and it is what the next audit, months later, is compared against. A business that has run the six checks and written nothing down has done the looking and kept none of the result.<\/p>\n

It helps to record, alongside each finding, the evidence for it — the console’s stated reason, the speed tool’s flagged causes, a note of what was awkward on the phone. The evidence is what makes the finding actionable later: it is what the sorting stage reads to decide whether a problem is owner-fixable, and it is what a developer is briefed from. A finding recorded as “the site is slow” is far less useful, months later, than one recorded as “the service page loads in eight seconds; the speed tool blames three oversized images.”<\/p>\n

Sorting the findings: fix now, fix later, call a developer<\/h2>\n

With the findings recorded, the audit’s second stage begins, and it is a sorting task. Each finding is placed into one of three groups, and the sorting is what turns a list of problems into a plan.<\/p>\n

The first group is fix now, yourself: problems that an owner can address and that matter enough to address soon. An insecure site, an oversized image slowing an important page, a key page missing from the navigation \u2014 these are within an owner’s reach and consequential, and they belong at the top of the list.<\/p>\n

The second group is fix later, yourself: problems an owner can address but that are not urgent. A handful of broken links on minor pages, a small structural untidiness \u2014 worth fixing, not worth dropping other work for. The third group is hand to a developer: the problems the audit has found but that genuinely need a developer’s skill \u2014 slowness rooted in how the site is built, an indexing fault whose cause is not obvious, a site that does not adapt to phones because of its construction.<\/p>\n

The sorting itself is mostly straightforward, because the checks were designed to make it so. A speed report names which causes are simple; the console states whether an indexing problem has an obvious cause; a structural untidiness is plainly owner-fixable. The audit, run properly, hands the business a list that nearly sorts itself.<\/p>\n

One judgement does require care, and it is worth flagging. A finding can be owner-fixable in principle and still be worth handing to a developer in practice, if the owner’s time is genuinely scarce and the developer’s is affordable — the three groups sort by who can do the work, but a business may sensibly move an item from the second group to the third because its own afternoons are better spent on the business itself. The sorting is a guide, not a rule; the business’s own time is a real cost, and a plan that ignores it is not the better plan for being tidy.<\/p>\n

What to do with each kind of finding<\/h2>\n

The sorted list is a plan, and acting on it differs by group. For the fix-now group, the business does the work, in order of how much each problem matters \u2014 and the technical guide and the article on site speed describe the common owner-level fixes, chiefly the reduction of oversized images, the removal of plainly unnecessary weight, the correction of navigation and structure.<\/p>\n

For the fix-later group, the business schedules the work rather than abandoning it. An item written on a list and given a rough time is far more likely to be done than an item held as a good intention; the record from the audit is what makes that scheduling possible.<\/p>\n

For the developer group, the business briefs a developer \u2014 and briefs them well, which the technical guide argued means describing the symptom and showing the evidence rather than prescribing a fix. The audit’s written record is exactly the brief a developer needs: it states what was found, where, and with what tool, and a developer given that can diagnose the cause efficiently and a business can tell whether the work succeeded.<\/p>\n

How often to repeat the audit<\/h2>\n

The audit is not a single event. A site that was technically sound can develop faults, quietly, as it changes \u2014 a change breaks something, a page drops out of the index, the site slows as content and images accumulate \u2014 and a fault that goes unnoticed is a fault that goes uncorrected.<\/p>\n

The first audit is the substantial one, because it works through a backlog of problems that may have been accumulating for years. After that, the audit becomes a much lighter, periodic re-check: the same six steps, run quickly, to confirm that nothing has broken and to catch what has. A reasonable rhythm for a small business is a light re-check every few months, and a fuller one after any significant change to the site.<\/p>\n

The principle is the one the technical guide stated: technical SEO, once the initial work is done, is maintenance rather than a project. A business that audits once and never again is, after a year or two, guessing about its site’s technical health exactly as it was before the first audit.<\/p>\n

The re-checks are also the moment to catch the faults that a change introduces. The most common time for a site to develop a technical problem is just after it has been altered — a new page added, the design<\/a> changed, a plugin installed — and so the most valuable re-check is the one run shortly after any significant change, while the cause is still recent and easy to trace. A periodic rhythm catches the slow drift; a check after each change catches the sudden fault.<\/p>\n

A common worry: what if the audit finds a lot?<\/h2>\n

A business approaching its first audit sometimes hesitates, worried that the audit will uncover a long list of problems and that the list will be discouraging. The worry is understandable and it is also misplaced.<\/p>\n

Finding the problems is the entire point of the audit. The problems exist whether or not the audit finds them \u2014 they are already costing the business traffic and customers \u2014 and the only difference the audit makes is whether the business knows about them. A long list is not the audit failing; it is the audit succeeding, by making visible what was costing the business in silence.<\/p>\n

A long list is also less alarming once sorted. The sorting stage separates the urgent from the minor and the owner-fixable from the developer’s work, and a list of twenty findings usually resolves into a few things to fix now, several to schedule, and a handful to brief out. The business does not face twenty problems at once; it faces a short, ordered, manageable sequence \u2014 which is a far better position than the comfortable ignorance it replaced.<\/p>\n

It also helps to remember that the business does not have to act on the whole list at once. The fix-now group is addressed first, the fix-later group is scheduled, the developer group is briefed when the business is ready — and the audit’s value does not depend on everything being fixed quickly. A business that has run the audit and addressed only its most urgent findings is already in a better position than one that never looked, because the remaining problems are now known, recorded, and waiting rather than hidden and unattended.<\/p>\n

The audit checklist<\/h2>\n

The table below sets out the six checks as a working checklist: the step, the tool it uses, and what a problem looks like when the check finds one.<\/p>\n\n\n\n\n\n\n\n\n\n\n
Step<\/th>\nThe tool to use<\/th>\nWhat a problem looks like<\/th>\n<\/tr>\n<\/thead>\n
Is the site indexed?<\/td>\nThe search engine’s site-owner console<\/td>\nImportant pages missing from the indexed list<\/td>\n<\/tr>\n
Does it work on a phone?<\/td>\nAn actual phone; the console’s mobile report<\/td>\nSmall text, cramped links, content off-screen, intrusive pop-ups<\/td>\n<\/tr>\n
Is it fast enough?<\/td>\nA free page-speed testing tool<\/td>\nA slow load time, with named causes<\/td>\n<\/tr>\n
Is it secure?<\/td>\nThe browser’s address bar<\/td>\nNo secure protocol; a “not secure” warning<\/td>\n<\/tr>\n
Is the structure sound?<\/td>\nThe owner’s own navigation of the site<\/td>\nImportant pages buried; navigation that does not match how customers think<\/td>\n<\/tr>\n
Broken links and faults?<\/td>\nA free link-checking tool; the console<\/td>\nLinks or images leading nowhere; a missing sitemap<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Concluding remarks<\/h2>\n

A technical SEO audit is within the reach of a small business owner with no technical background, because the audit is not the fixing of technical problems but the finding and sorting of them. Run with two free tools, a phone, and a browser, it is a sequence of six plain checks that an attentive owner can complete in an afternoon.<\/p>\n

The six checks ask whether the site is indexed, whether it works on a phone, whether it is fast and secure, whether its structure is sound, and whether small faults have accumulated. Their findings are written down \u2014 the audit ends in a document, not an impression \u2014 and then sorted into what to fix now, what to fix later, and what to hand to a developer.<\/p>\n

This is worth far more to a business than the vague unease it replaces. A business that has run the audit knows the state of its site, can fix the simple problems itself, and can brief a developer accurately on the rest \u2014 and a long list of findings is the audit succeeding, not failing, because the problems were costing the business already and now, at last, can be addressed.<\/p>\n

The next article in this series stays with the technical side and treats site speed in depth \u2014 what it is, what it costs a business in visitors and sales, and what a small business can do about it.<\/p>\n

Future developments<\/h2>\n

The technical audit described here is durable, because the things it checks are durable. Whether search is a list of links or an AI-composed answer, a site still has to be reachable, readable, fast, secure, and sensibly built \u2014 and the six checks test exactly those properties.<\/p>\n

What is likely to change is the tooling. The free tools that support the audit improve over time, and increasingly use automated analysis to find faults and to explain them in plainer terms \u2014 which makes the audit, if anything, more accessible to a non-developer rather than less. A business should expect the checks to stay the same and the tools that perform them to get better.<\/p>\n

The steadier point is the habit. A business that has learned to run this audit, and to repeat it on a sensible rhythm, has acquired something the next change in search will not take away: a reliable way of knowing the technical state of its own site, rather than guessing at it. That habit is worth more than any single tool, because it outlasts the tools.<\/p>\n

Related reading<\/h2>\n