Writing
What a website audit actually finds on a site that looks fine
What a small business website audit finds on a site that looks fine, from two real audits: broken share cards, missing headers, wasted image weight.

Two websites were audited on the same day, 15 August 2026. One was a client's new site, not yet launched: twenty pages, carefully built, scoring roughly 78 out of 100. The other was floautomate.com, my own live site, which scored roughly 55. Both looked fine in a browser. Neither of them was.
That gap is the whole point of a small business website audit. A site can load fast and look smart on a phone while quietly leaking, because the faults live where nobody looks: the head of the document, the response headers, the file sizes, the sitemap. Here is what the two audits found, including the findings on my own site.
What a small business website audit actually is
A website audit is a systematic pass over a live site that checks what the code actually sends to browsers, search engines and social platforms, rather than what the site looks like to a visitor. It is not a design review and it is not an opinion on your copy. It checks the machinery underneath, across four layers:
- Technical: can search engines reach and correctly identify every page? Canonicals, redirects, robots rules, sitemaps.
- On-page: does each page say what it is, where machines read first? Titles, headings, descriptions, structured data.
- Delivery: how much weight is the site shipping, and how fast does the important part appear? Image sizes, caching.
- Sharing: what happens when someone pastes your link into WhatsApp? Open Graph tags, share images, share URLs.
Two real audits, one day
The first was a client's new build, twenty pages, deliberately kept out of Google's index until launch day, and in genuinely good shape for its stage. The second was my own company site, live and public, which is the harder one to publish. Both audits were read-only: fetches of the raw HTML search engines receive, file sizes measured on disk, headers inspected on every response.
What was not measured, and why
Neither audit has Core Web Vitals field data. The PageSpeed Insights API returns a 404 without a key, and the machine had no Python runtime, so the scripted tooling could not run. Everything below is a measured byte count, header or grep result. What could not be measured is marked as such, not estimated.
Links that arrive as bare text

Facebook, WhatsApp and LinkedIn do not read your page the way a visitor does. They read three lines in the head of the document: og:title, og:description and og:image, defined by the Open Graph protocol. With those lines missing there is nothing to build a preview from, so a shared link collapses to a naked address. A website audit finds this constantly, because it is invisible in a browser. The page looks perfect. It only misbehaves once somebody forwards it.
On the client's unlaunched site, not one of the twenty pages carried an og:image, an og:url or a Twitter card, and one page had no Open Graph block at all. My own site had the mirror image of the fault: the tags were there, but og:url pointed at the homepage on every page, and one generic picture served for all of them. A shared case study showed the brand card, not the project.
0 of 20
pages on the client's new site carrying an og:image, og:url or Twitter card
For a business that wins work through personal recommendation, the link a customer forwards to a friend is the shop window. Shipping it as a bare address is not cosmetic.
The pricing page that introduced itself as a different page
The same audit turned up a copy-paste error no amount of proofreading the visible page would catch. The pricing page carried another service page's og:title and og:description, so every share of the pricing link announced a completely different service.
It is the right parcel with someone else's address label on it. The contents are correct, the label is not, and the label is the only part anyone reads. It never shows up in a browser, which is exactly why it survives.
No website security headers, and why a small business should care
Neither site sent security response headers beyond HSTS. No X-Content-Type-Options: nosniff, no Referrer-Policy, no frame protection, no Content-Security-Policy. Two consequences, in plain English. Someone can load your site inside a frame on their own page and pass it off as theirs, the standard setup for a convincing fake booking form. And every outbound click leaks the full address of the page the visitor came from.
Frame protection shipped as X-Frame-Options: SAMEORIGIN. The Content-Security-Policy did not, and that was a decision rather than an oversight.
The honest version of a trade-off
A Content-Security-Policy was deliberately deferred on the client site. Between inline scripts, Google Fonts, a third-party widget and a Maps iframe, an untested policy risked breaking a live site with no tests to catch it. That is a real cost, carried knowingly, and worth saying out loud rather than claiming the site is fully fixed.
Four hundred kilobytes of pixels nobody sees
This is where audits pay for themselves, because the waste is measurable and the fix is cheap. The client homepage was shipping roughly 400KB of image payload no visitor could perceive. The worst offender was an accreditation badge:
3,780 × 2,126
pixels delivered, 101,251 bytes, to fill a slot 48 pixels wide. Achievable under 8KB.

Roughly 79 times wider than the space it occupies. The browser downloads all of it, then throws nearly all of it away. On the same page a 1,200 × 1,286 image weighing 147,280 bytes filled a 360 × 330 slot, while a 62KB near-duplicate sat unused in the same folder. And everything was served with max-age=0, must-revalidate, so returning visitors re-downloaded the lot. None of this is exotic advice: Google's own image guidance has said to size and compress properly for years.
My own site was worse in one specific way. Thirteen of fourteen video poster images exceeded 200KB, averaging around 475KB, and the same files serve at roughly 27KB through the image optimiser the site already runs. The optimiser works. The posters were never handed to it.
883KB → ~27KB
the worst poster on floautomate.com, against what the same file weighs once optimised
The one before-and-after with a measured outcome: a hero photograph at 1,400 × 2,100 and 297KB, filling a 760-pixel slot, was the largest element to paint on mobile, arriving at 5.3 seconds. Replaced with WebP at 800 wide (47KB) and 1,400 wide (167KB).
Headlines that are slogans, not signposts
Both homepages had the same disease. The H1, the most important line on the page, was the company tagline. On the client site the phrase describing what the business does, and where, had been demoted to a small paragraph above it. On mine the H1 was a brand slogan, no page named the town or county I work from, and my own name appeared nowhere in the live HTML. The location and the founder are on the site now. The slogan H1 has not moved yet.
Think of it as a shop sign. The sign says something warm about the brand; the small print says what the shop sells. Google and AI assistants read the sign. The fix is not to bin the slogan, it is to swap their jobs: put the what and the where inside the H1, keep the slogan beneath it. A dental practice website I built is the shape to copy.
The page that was missing from the sitemap
The client's pricing page was built on 13 August. The sitemap had been generated on 4 August and never regenerated, so the newest and most commercially important page was absent from the file whose entire job is listing pages.
Nobody decided that. It is drift: two artefacts, both correct when made, that stopped agreeing the moment one changed. Reviewing pages one at a time never surfaces it, because every page is fine. My own sitemap had the same fault, listing two of five live URLs.
Three things you can check on your own site today
No tools, no subscription. Ten minutes and a phone will tell you whether it is worth looking harder.
- Paste your homepage address into a WhatsApp message to yourself. Do you get a card with a title, a description and a picture, or a bare blue link?
- Do the same with your pricing or contact page. A different card, the homepage's card again, or another page's entirely?
- Open your biggest homepage image in a new tab and compare the dimensions the browser reports to the space it fills. Wildly different means you are paying to send pixels nobody sees.
Share tags, headings and image sizes are usually a content job you can do yourself. Headers, caching and sitemaps live in the code and need whoever built the site. For the record, my own list is not finished: per-page share images and those video posters were still open when this was written.
If you would rather someone read the machinery for you, that is part of what I do when I build custom software and websites for service businesses. A website audit for a small business is short, cheap work, and a lot less painful than finding the problem after a year of leaking enquiries.
Zahir Ibrahim is the founder of FloAutomate, building custom software and websites for service businesses from Ainsdale, Southport, Merseyside. More about how I work. Both audits were run on 15 August 2026; the figures are measured, and this post will be re-dated when they are re-measured.