Website Teardown: How to Audit Your Own Business Website

The difference between a business website that generates enquiries and one that merely exists is almost never a single dramatic flaw. It is eight or ten small failures compounding, each of them individually defensible, none of them visible to the person who commissioned the website. That is why owners are so often surprised. They look at their website and see something that looks fine, because it does look fine.

What follows is the teardown we run on any website before quoting on a redesign. It is deliberately sequenced, it takes about an hour, and you can run it yourself. The point is not to produce a score. It is to find out which of the eight layers is actually costing you money, because that determines whether you need a fix, a refactor or a rebuild, and those are very different invoices.

Before You Start: The Problem With Auditing Your Own Website

You cannot see your own website. You know what every abbreviation means, you know which service the third menu item refers to, and you know what your business does, so you unconsciously supply all the context a first-time visitor does not have. Every owner who has ever said “it is all there on the website” is describing a website they can read and a stranger cannot.

Two corrections help. Run the first pass on a device you do not normally use, ideally handed to someone unfamiliar with the business. And write down what you expect to find before each pass, then record what you actually found. The gap between the two is the most valuable output of the whole exercise.

Pass One: The Five Second Test

Open the homepage on a phone. Look at it for five seconds. Close it. Now answer three questions from memory: what does this business do, who is it for, and what am I supposed to do next.

What good looks like. All three answers are available from the first screen without scrolling, in language a customer would use rather than language the industry uses. The primary action is obvious and singular.

What failure costs. This is the cheapest failure to fix and the most expensive to leave. A visitor who cannot place you in five seconds does not scroll to find out. They return to the search results and open the next website, which is one of your competitors. Everything downstream in this teardown is irrelevant if pass one fails, because most visitors never reach the rest of the website.

The most common failure we see is a hero section carrying a slogan instead of a statement. “Excellence delivered.” “Your partner in growth.” These are not positioning. They are what a website says when nobody was willing to decide who the business is for, which is the same reason so many websites cannot communicate value fast enough.

Pass Two: The Real Device Pass

Not the responsive preview in your browser. An actual phone, and specifically a mid-range Android phone, because that is what the South African market is holding. Statcounter put Android at roughly three quarters of South African mobile traffic in August 2026, and the meaningful share of that is not flagship hardware.

Work the website like a customer. Tap the menu. Tap a service. Tap a phone number. Fill in a form field. Try to close whatever pops up.

What good looks like. Every tap target is comfortably hittable with a thumb, including the small ones in the footer and the close button on any overlay. Nothing requires horizontal scrolling. Form fields bring up the correct keyboard, so an email field produces the email keyboard and a phone field produces the number pad. Text is readable without pinching.

What failure costs. Mobile failures are silent. They do not produce complaints, they produce a bounce rate you interpret as a traffic quality problem. The classic version is a contact form that is technically functional but miserable on a phone, on a website where the analytics show most visitors arrive on a phone.

A useful reference point: the accessibility guidelines set a floor of 24 by 24 CSS pixels for a tap target, while Apple’s own guidance recommends 44 points and Google’s Material guidance recommends 48dp. The floor is a floor, not a target. And it is the tappable area that counts, not the size of the icon inside it, which is why a generous-looking button where only the text responds still fails.

Pass Three: Speed, and the Two Kinds of Data

Run your homepage and your most important service page through Google PageSpeed Insights. Then ignore the score, which is the part everybody fixates on and the part that matters least.

What matters is the distinction between the two data sets on that page. Field data comes from the Chrome User Experience Report: real visits by real Chrome users to your website, aggregated over a rolling 28 day window and reported at the 75th percentile, which means it describes the experience of your slower quarter of visitors rather than your typical one. Lab data is a single simulated load on a throttled connection in a data centre. Google’s page experience signals use the field data. The lab data is a diagnostic that tells you why, not a measurement of what your visitors experienced.

That 75th percentile detail explains something that confuses a lot of owners: a website can post a strong lab score and still fail its Core Web Vitals assessment, because the lab test ran on Google’s infrastructure and the assessment is built on what actual visitors on actual devices went through. Interaction to Next Paint is the metric where this catches WordPress websites most often.

What good looks like. Field data is present at all (low-traffic websites often have none, which is its own signal) and the core metrics sit in the green on mobile. Lab diagnostics do not show a single enormous unoptimised image or a wall of render-blocking scripts.

What failure costs. Speed failures are compounding rather than catastrophic. They do not stop anyone, they just make every subsequent step slightly less likely, across every visitor, permanently. The commercial damage is invisible precisely because it is distributed.

One correction worth making here: a slow website is usually not slow for one reason. It is slow because of an accumulation of decisions, each of which seemed reasonable, most of which were made by installing something. Which is why the fix is rarely a plugin and frequently a rebuild of how the page is assembled.

Pass Four: The Entry Point Pass

Open your analytics and look at landing pages rather than page views. Which pages do people actually arrive on from search?

Now open the top three of those pages and run pass one on each. Does a stranger landing there cold understand what the business does, who it serves and what to do next, without having seen the homepage?

What good looks like. Every page that receives search traffic works as an entry point in its own right. It establishes context, it carries a path onward, and it does not assume the visitor arrived through the front door.

What failure costs. This is the most under-diagnosed failure on this list. Businesses design the homepage with care and treat every other page as an internal destination reached from the menu. In reality a large share of visitors never see the homepage at all. They land on a service page or an article from a search result, find a page written as though they already know the context, and leave from a page that was never designed to convert anyone. Thinking about strategic entry points across the website is what closes that gap.

Pass Five: The Conversion Path Pass

Pick the single action that matters most to your business. Then count the steps from an arbitrary page to completing it, and count the places a visitor could end up with nowhere obvious to go.

Then do the part almost nobody does: actually submit the form. Fill it in properly, send it, and verify that it arrived in a real inbox that a real person monitors. Then check the spam folder. Then do it from a different email address.

What good looks like. The primary action is reachable from any page in one or two steps. Forms ask for the minimum needed to start a conversation. Submissions arrive reliably, the confirmation message is unambiguous, and someone owns the response. Our guide to the anatomy of a high-converting contact page covers what that structure looks like in practice.

Website contact forms fail quietly for entirely mundane reasons: a mail configuration change, an expired integration, a plugin update, a full mailbox, a notification address belonging to someone who left. The website looks perfect throughout. It just stops delivering. Test your forms monthly. It takes two minutes and it is the highest-return maintenance task in existence.

If the path itself is sound and people still are not converting, the problem is usually further upstream, which is the subject of why websites do not convert.

Pass Six: The Trust Pass

Read your website as a sceptical buyer who has never heard of you and has three of your competitors open in other tabs. Ask what evidence exists here that this business is real, competent and still trading.

What good looks like. A physical address and a real telephone number. Named people with actual faces. Specific work, specific clients or specific outcomes rather than generic claims. Content with recent dates on it. Registration details where the sector expects them. Nothing that contradicts anything else.

What failure costs. Trust failures disqualify you at exactly the moment a buyer is comparing shortlisted options, which is the most expensive moment to lose. They are also cumulative: a stock photograph of a boardroom is survivable, and a stock photograph plus no address plus a copyright notice from three years ago plus a blog that stopped in 2023 is not.

That last one deserves its own mention. A dormant website is read as a dormant business. We have watched perfectly healthy companies lose work because their website’s most recent visible activity was two years old and the buyer drew the obvious conclusion.

Pass Seven: The Visibility Pass

Search Google for your business name. Then search for the service you sell plus your town, without your business name. Then take the exact title of one of your service pages and search for that phrase in quotation marks.

What good looks like. Your business name returns your website first, with a sensible title and description underneath rather than a truncated fragment or the theme’s default. Your service and location query returns you somewhere findable. The quoted title search confirms the page is indexed at all.

What failure costs. If a page is not indexed, nothing else about it matters. We have inherited websites where entire service sections were invisible to search for prosaic reasons: a staging website that went live with indexing switched off and nobody switched it back on, pages orphaned with nothing anywhere on the website linking to them, or titles duplicated across a dozen pages so that Google could not tell them apart.

Check your page titles specifically. Open three service pages and look at the browser tab. If they all say the same thing, or if they say “Home” and “Page” and “Services”, you have found real money lying on the floor.

Pass Eight: The Risk Pass

The last pass is not about performance. It is about whether the website is going to embarrass you.

Check that the padlock is present and the certificate is not near expiry. Check when the platform, theme and plugins were last updated. Click every link in the footer and the menu. Look at the copyright year. Find the privacy policy and read it, because a policy describing practices the business no longer follows is worse than none.

What good looks like. Everything current, everything working, no dead links, no placeholder text surviving from the build, and a visible maintenance rhythm.

What failure costs. This is where cost becomes non-linear. A website that is six months behind on updates is carrying a set of publicly documented vulnerabilities, and the cost of that is not a slow website, it is a compromised one, with all the remediation, reputation and notification consequences that follow. Small neglect and catastrophic neglect look identical right up until they do not.

Across seven website compromises we remediated during 2026, three patterns held without exception, and they are worth knowing before deciding that updates can wait another quarter.

None of them involved a single backdoor. The minimum was two separate components. The worst carried five distinct persistence mechanisms and two hidden administrator accounts. Another combined five malicious plugins with a database trigger that reinstated them. The cleanup that finds one bad file and declares victory is not a cleanup, and it fails within days.

Detection almost never came from a security tool. It came from a customer mentioning something odd, a browser warning, a hosting suspension, or a strange result appearing in a search for the business’s own name. By the time anyone looked properly, the intruder had been resident for months rather than days. In one case the website had been compromised for roughly six months before anybody noticed.

Cleaning the website does not end the incident: on more than one of those websites the attacker had verified ownership of the Google Search Console property. Removing the malicious files does nothing to that. They retain visibility into the search property and the ability to submit to it until somebody manually revokes their access. Almost no cleanup checklist mentions it.

The common thread across the worst of them was not a technically sophisticated attacker. It was that the website had been built by one party, migrated or edited by a second, hosted by a third, and actively maintained by nobody. Automatic updates had been switched off at some point by someone, and no monitoring arrangement existed. The compromise did not defeat anyone’s security. It landed in the gap between everyone’s assumptions about whose job it was.

Turning Eight Findings Into One Decision

The point of the teardown is to answer a commercial question: fix, refactor or rebuild.

Fix when the failures are concentrated in passes five, seven and eight. Broken forms, missing titles, dead links and overdue updates are maintenance work. They are cheap, they are fast, and they frequently produce the largest short-term change in enquiry volume of anything on this list, because they are the failures actively losing enquiries the website has already earned.

Refactor when passes one, four and six fail but the underlying website is sound. The structure works, the message does not. This is a content and positioning project with some design work attached, and it does not require throwing anything away.

Rebuild when passes two and three fail badly and the others fail alongside them. Fundamental mobile and performance problems are usually symptoms of how the website was assembled, and you cannot optimise your way out of an architecture. When we find a website that is slow because of what it is built on, patching it is spending money to arrive at a slightly less slow version of the same problem. That is the point at which a properly designed rebuild becomes the cheaper option.

Most websites we tear down need a fix and a refactor, not a rebuild, and saying so costs us the larger project. It is still the right answer more often than the industry admits.

Run It Again in Six Months

The single most useful property of this teardown is that it is repeatable. Websites do not fail all at once. They drift: a form breaks, a plugin ages, content goes stale, a competitor sharpens their positioning, a page quietly falls out of the index.

Running eight passes twice a year catches all of that while it is still cheap. It also gives you something most business owners never have, which is an evidence base for deciding when the website genuinely needs investment, rather than rebuilding every three years because it feels tired.

Frequently Asked Questions

How do I know if my website is actually working?

Judge it on evidence rather than appearance. Confirm enquiry forms deliver to a monitored inbox, check whether your key pages are indexed by Google, look at real-device mobile usability, and check the field data in PageSpeed Insights. A website that looks good and fails these is not working.

How often should I audit my website?

Twice a year for the full teardown, and monthly for the two checks that fail silently: submit every enquiry form and verify it arrives, and confirm the SSL certificate is valid. Those two take a few minutes and catch the most expensive faults.

What is the difference between field data and lab data in PageSpeed Insights?

Field data comes from real visits by real Chrome users to your website over the preceding period, and it is what Google’s page experience signals use. Lab data is a simulated load in controlled conditions, useful for diagnosing why something is slow but not a measurement of what your visitors actually experienced.

Should I test my website on a phone or use the browser preview?

Use a real phone, and ideally a mid-range Android one, because Android accounts for roughly three quarters of South African mobile traffic. The browser preview changes the viewport size but does not reproduce touch accuracy, real network conditions or the processing limits of the devices your customers actually hold.

When does a website need a rebuild rather than a fix?

When mobile usability and performance fail fundamentally and the causes trace back to how the website was assembled rather than to individual mistakes. Broken forms, missing page titles and overdue updates are maintenance. An architecture that cannot be made fast is a rebuild.

Why do website contact forms stop working?

Almost always for mundane reasons: a mail configuration change at the host, an expired third-party integration, a plugin update, a full mailbox, or a notification address belonging to someone who has left the business. The website carries on looking perfect, which is why the failure is usually discovered weeks later and by accident.

If my website was hacked and cleaned, is the incident over?

Not necessarily. Across the compromises we have remediated, attackers routinely left more than one backdoor, and in several cases had verified ownership of the Google Search Console property. Removing the malicious files does not revoke that access. Check Search Console users and owners, rotate every credential, and confirm nothing reinstates itself over the following fortnight.