Website Health Check: 9 Technical Problems SMEs Miss

In August 2026 we ran a technical health check on a small education-services company website. It was a long-running WordPress site with roughly 1,000 blog posts, a good-looking homepage, and a genuinely respectable amount of content. The owner asked a simple question: we pay to publish articles and we run paid ads, so why does none of it seem to work?

We got stuck on the first check. The site carried a Universal Analytics tag and nothing else. No GA4 anywhere. Google stopped processing new data in standard Universal Analytics properties on 1 July 2023 and then permanently deleted the interface and all historical UA data on 1 July 2024. Which means this site had accumulated a thousand articles while running roughly three years with no traffic data at all. Nobody knew which article worked, which one nobody read, or which page produced enquiries.

Two things before we start. First, this is one case study, not a statistic. We are not claiming most small-business websites look like this, because we have not run a survey at that scale. What follows is an honest record of one real audit, plus one additional near-universal item we added, making nine things every owner should check for themselves. Second, most of these problems are neither scary nor expensive. Six of the nine can be fixed in an afternoon by someone with basic HTML familiarity. Only two or three genuinely need developer time. The point of this article is not to alarm you. It is to hand you a checklist you can run yourself.

For each item you get five things: what the symptom looks like, why it actually matters, how to check it yourself using nothing but a browser, how to fix it, and roughly how long the fix takes. At the end there is a printable self-check table and a priority table ordered by impact against difficulty. If the question you are really asking is whether to rebuild from scratch, that is a different decision, covered in redesign versus rebuild. If you want to size the budget first, see how to read a website quote.

Problem 1: the site runs Universal Analytics only, so you may have three years of nothing

Direct answer: if your site carries a UA- tracking tag and no G- measurement ID, it stopped recording page views in July 2023, and the historical data was permanently deleted in July 2024. This was the most expensive finding of the audit and also the easiest to miss, because the website itself looks completely normal.

The timeline is worth reading in full, because many people remember that UA was retired but do not realise the archive went with it.

Google states this plainly in its own help centre: standard UA properties stopped processing hits on 1 July 2023, and after 1 July 2024 users lose access to all current and historical UA data (Google Analytics Help). Industry press documented the shutdown as it happened (MarTech).

Why this is worse than it looks. Missing analytics does not simply mean you do not know your traffic number. It means every content decision becomes a guess. If twenty of those thousand articles drive eighty percent of enquiries, this company has no way to identify which twenty, and therefore no way to concentrate resources on the right topics. Worse, they were spending on ads the whole time, so landing page behaviour, bounce, and post-click paths were all a black box.

How to check it yourself, three minutes:

1. Open your homepage and press Ctrl+U (Cmd+Option+U on a Mac) to view page source.
2. Press Ctrl+F and search for G- as two characters. With GA4 installed you will see a measurement ID that looks like G-XXXXXXXXXX.
3. Now search for UA- . If you find UA- and no G-, this is you.
4. To be sure, sign in to analytics.google.com, check whether any property is labelled GA4, and confirm that active users over the last seven days is not zero.

How to fix it. Create a GA4 property, take the G- measurement ID, install it through a tag manager or your theme header, then confirm it actually fires using a browser tag-assistant extension. Connect Search Console at the same time, because it is the only free source that shows which queries people used to find you, and Search Console keeps only 16 months of performance data (Google documentation). Every month you delay is a month of history you never get.

How long: one to two hours to install the tag. One to two days to configure form submissions, phone-number clicks, and quote requests as conversion events.

The part that hurts, and the part to remember: analytics data cannot be backfilled. Installing GA4 today gives you data from today. The years 2023 to 2026 stay empty forever. Which is why, whatever priority order you adopt, this item should be done today.

Problem 2: one misspelled letter in the ads tag, so the money keeps going out

Direct answer: on the same site, the Google Ads enhanced-conversions parameter was written as allow_enchanced_conversions, one extra c compared with the correct allow_enhanced_conversions. A wrong key throws no error; it is silently ignored. The feature had never worked once since installation, while the company kept paying for clicks.

Errors of this class are dangerous precisely because they have no visible symptom. The page works, the ads serve, the dashboard still says the tag is installed. Keys in a JavaScript configuration object are matched exactly. A misspelled key triggers no warning; the browser simply treats it as a field nobody will ever read. Every parameter in Google's gtag.js parameter reference has to be character-for-character correct. There is no fuzzy matching and no autocorrect.

Why it matters. Enhanced conversions hash first-party data that a customer voluntarily provides, such as an email address at checkout, and send it back to Google Ads to recover conversion attribution lost to browser privacy restrictions (Google Ads Help). When it silently fails, the consequence is not a missing feature. It is that your ad performance is systematically understated and the bidding system is optimising on incomplete signals. You may well have switched off a campaign that was working, or concluded that paid search does not work for your category.

How to check it yourself, five minutes:

1. View page source and search for enhanced. Compare it letter by letter against allow_enhanced_conversions, watching for a stray c before the h.
2. While you are there, search for gtag, AW- and conversion, and confirm the conversion tag actually exists on the pages where you believe it exists, especially thank-you and form-success pages.
3. In Google Ads, open Goals then Conversions then Summary and read the status column for each conversion action. "No recent conversions" or "Tag inactive" is a red light.
4. Broaden the check: for every third-party tag you believe is installed, whether Meta Pixel, a chat widget or a heatmap tool, search the source the same way. Believing and verifying are different activities.

How to fix it: change one letter, then confirm the status turns green in the Google Ads diagnostics view.

How long: thirty minutes including verification.

The larger lesson: nobody was signing off on the tracking. Every technical component on this site had been installed by someone, and not one of them had ever been opened afterwards to confirm it was running. This is exactly why tracking and conversion events belong in the acceptance clause of the website contract rather than in the pile of things people intend to do after launch. How to word that is in the website RFP and acceptance checklist.

Problem 3: the language declaration was wrong, so a Chinese site announced itself as English

Direct answer: a traditional-Chinese site aimed at local parents declared lang="en-NZ" in its opening HTML tag, telling every machine that reads it that this is a New Zealand English website. This is almost always a theme or template default that nobody changed. It is the cheapest, fastest fix on the list and the one most often overlooked entirely.

Why it matters. The lang attribute is the first signal any machine uses to determine what language a page is in. It affects three things. Search engines use it when deciding which audience a page suits, and Google's documentation on localized versions requires language signals to match the actual content. Screen readers choose a pronunciation engine from this attribute, so a page of Chinese declared as English is unusable for a blind visitor. And browser translation prompts misfire, meaning your own readers may be asked whether they want the page translated into the language it is already written in.

Honestly, the direct ranking impact is usually small, especially on a single-language site whose content is obviously in one language. But it is an excellent proxy indicator. A site where nobody changed lang is a site where nobody changed the other defaults either. The template favicon, the template meta description, the template footer copyright year are usually all still there. In an audit we treat it as litmus paper for whether the site was ever properly handed over.

How to check it yourself, one minute: view page source and read the first few lines. You are looking for the html tag and its lang attribute. It should match the actual content language of the page. If you run a bilingual site, also confirm the two versions reference each other with hreflang.

How to fix it: in WordPress, Settings then General then Site Language usually propagates correctly to the theme output. If the theme hard-codes it, edit header.php or override it with a plugin.

How long: five minutes. This is the highest return-on-effort item in the entire article.

While you are in there, check the other defaults in the same block: whether the page title still says the template name or just "Home"; whether the meta description is empty or still the template placeholder; and whether og:image is set, because without it your link previews on social and messaging apps render as a blank rectangle. All of it lives in the same few lines of source and costs five more minutes to review.

Problem 4: six H1 tags on one page, so the heading hierarchy means nothing

Direct answer: the homepage carried six H1 tags, because every FAQ category heading had been marked up as an H1. Be clear about what this is and is not: Google has said repeatedly that multiple H1s will not get you penalised, so this is not a ranking problem. It is a structure and readability problem, and structure carries more weight now than it did five years ago.

Let us get the facts straight so nobody scares you with this one. Google's position has consistently been that its systems work with the HTML they find, whether that means one H1, several H1s, or styled text with no semantic markup at all. Industry guidance on header tags reaches the same conclusion: correct semantic hierarchy mainly serves accessibility and content organisation rather than acting as a direct ranking factor (Search Engine Journal on header tags). So if an agency quotes you a large SEO overhaul on the strength of "you have six H1 tags," that is a sales tactic.

So why fix it at all? Three practical reasons. AI extraction: systems like ChatGPT and Perplexity pull passages, and heading hierarchy is their main clue about what a passage covers and what it sits underneath. Six parallel H1s tell a machine this page has six equally important topics, with the result that none of them is clearly attributed to you. Accessibility: screen reader users navigate by heading, and a scrambled hierarchy destroys their map of the page. Internal discipline: if H1 is being used as a font size, nobody in the editorial process is distinguishing between a heading and text somebody wanted slightly bigger, and that habit will have spread across all thousand articles.

How to check it yourself, two minutes: press F12, open the Console tab, paste document.querySelectorAll('h1').length and press Enter. The answer should be 1. To see the actual text, paste [...document.querySelectorAll('h1')].map(h=>h.innerText). Swap h1 for h2 or h3 to review the rest of the hierarchy.

How to fix it: change non-primary H1s to H2 or H3 and let CSS handle the visual size. In the WordPress block editor, select the heading block and change the heading level in the right-hand panel. If that changes the appearance, the theme has bound styling to the tag, and a front-end developer should rebind it to a class instead.

How long: fifteen minutes for a single page. Half a day to a day across all templates.

Problem 5: 81 of 84 images had no usable alt text

Direct answer: scanning the homepage and main pages we found 84 images, of which 14 had no alt attribute at all and 67 had an empty string. Three had meaningful alternative text. Images are the largest content asset on a site like this, and to a machine they were almost entirely transparent.

Why it matters. Alt text does three jobs. Accessibility: a screen reader cannot see the picture, and alt text is the only bridge. Image search: Google's image SEO best practices state directly that alt text helps Google understand the subject of an image, and for service and manufacturing businesses image search is a persistently underrated entry point. And the most commercially relevant one in 2026: language models cannot read text baked into pictures. If your course schedule, spec sheet, or price list is a beautiful JPEG, that information does not exist as far as an AI system is concerned. Publishing a full specification table as an image is the most common act of self-harm on manufacturer websites.

One technical nuance matters here: an empty alt is not automatically wrong. Purely decorative images such as dividers, background blocks and ornamental icons are supposed to carry an empty alt so screen readers skip them. So some of those 67 empty strings may be legitimate. The problem is the distribution: three out of 84 is almost certainly not a deliberate design decision, it is nobody filling the field. Moz's guidance on alt text offers a useful test: if removing the image would force you to explain in a sentence what the reader is missing, it needs alt text. If nothing is lost, leave it empty.

How to check it yourself, three minutes: press F12, open Console, and paste document.querySelectorAll('img').length for the total. Then paste [...document.querySelectorAll('img')].filter(i=>!i.alt||!i.alt.trim()).length for the number with no usable alt. Comparing the two numbers tells you the scale immediately. Append .map(i=>i.src) to the filter to list the offending files.

How to fix it: do not try to backfill a thousand articles at once. Work in this order: homepage and main service pages first, typically 20 to 40 images and an afternoon of writing; then your top twenty pages by traffic, which you can only identify once GA4 is running, which is why Problem 1 comes first; then fold the rest into normal editorial process and require alt text on every new upload. Write alt text that describes content and context rather than stuffing keywords. "Close-up of a dark grey stainless steel valve showing the threaded connection" is far more useful than a string of product and country keywords, which additionally risks being read as keyword stuffing.

How long: half a day for key pages. Site-wide belongs in ongoing content operations and is measured in months.

Problem 6: no structured data at all, so AI cannot tell what you sell

Direct answer: the site had a full FAQ section, clear company information and course products, and not one line of JSON-LD structured data. No FAQPage, no Organization, no Course. Everything a human could read, a machine had to guess.

Why it matters, plus an important caveat. You need to know the current state of FAQ structured data or outdated advice will mislead you. Google narrowed FAQ rich results to authoritative government and health sites back in August 2023, and as of 7 May 2026 FAQ rich results stopped appearing entirely, with a deprecation notice added to the official documentation. So if somebody tells you FAQ schema will win you extra real estate in the search results, that advice is from 2022 and no longer holds.

So why bother? Because the value of structured data has shifted. Its main job now is not to buy visual space in search results, it is to let language models parse your page without ambiguity. Organization schema tells a machine what this company is called, where it is, how to contact it and which social accounts belong to it, which is the foundation on which an AI decides whether you are the entity it should name in an answer. Course, Product and Service markup lift your actual offering out of prose and into structure. Google still maintains dozens of valid markup types in its search gallery, and most of them remain fully supported.

How to check it yourself, three minutes:

1. Fastest route: open the Rich Results Test, paste your URL and run it. What is detected and what is broken appears immediately.
2. Cruder route: view page source and search for ld+json. Nothing found means zero structured data.
3. Advanced: look for an Enhancements section in the Search Console sidebar. An empty section usually means nothing is marked up.

How to fix it: in priority order, Organization first, sitewide and on the homepage; then the markup type matching your core offering, whether Course, Product or Service; then FAQPage, now purely for machine readability rather than for search appearance. WordPress plugins generate most of this; on a custom build, ask a developer to output JSON-LD in the templates. The one unbreakable rule is that markup must match what is visible on the page. Marking up content a visitor cannot see violates Google policy. Full implementation steps are in our AEO technical setup guide.

How long: two to four hours for Organization plus one core type. One to two days for full coverage.

Problem 7: a 1,700-word article with exactly one H2

Direct answer: we sampled three articles of 1,500 to 1,750 words and every one of them contained a single H2. Fifteen hundred words behind one signpost means a human faces a wall of text with no landmarks, and a machine has the same difficulty cutting out a quotable passage.

Why it matters. This is the same illness as Problem 4 seen from the other side. Heading hierarchy is the table of contents of a piece, and it serves three readers at once. Humans scan on phones, and without subheadings there is nothing to grab; bounce rate reflects it. Search engines use headings to understand section topics, and Google's SEO starter guide recommends headings to create a hierarchical structure that helps both people and machines find their way. Language models extract whole passages, and they need a heading to decide what question a passage answers before selecting it as a citation. A long article with one H2 is, to an AI, one large undifferentiated block.

The working rule is simple: a subheading every 200 to 300 words. A 1,700-word article should carry five to eight H2s, subdivided with H3 where needed. And each heading has to state its own topic. "Part three: advanced applications" is a bad heading. "How blank tolerance drives downstream machining cost" is a good one, because it still makes sense when pulled out on its own.

How to check it yourself, two minutes: open three of your own articles at random, press F12 and paste document.querySelectorAll('h2').length into the Console. Or do it the manual way: if you can scroll three screen heights without meeting a subheading, you have this problem.

How to fix it: you do not need to rewrite anything, you need to re-segment. Break the existing text by topic, give each block a heading that stands alone, and while you are there add a 40 to 60 word direct answer at the top of the article. This is editing work, not writing work, and settles at fifteen to twenty minutes per article once you have the rhythm. Again, fix your highest-traffic pieces first, which loops back to Problem 1: without GA4 you do not know which ones those are.

How long: fifteen to twenty minutes per article. Twenty priority articles is about a week of spare time.

Problem 8: nobody has ever measured the site speed

Direct answer: speed is not a problem only when it feels slow. It has published thresholds. Largest Contentful Paint should land under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift under 0.1, measured at the 75th percentile of real users (Google web.dev Web Vitals). Most small-business sites have never had those three numbers measured once.

Why it matters. Time to kill a common myth: many owners assume speed only affects rankings, so if rankings are acceptable they let it go. Speed's primary effect is on conversion and experience; ranking is a side effect. Mobile users abandoning during the wait is the most expensive kind of loss, because that is traffic you already paid for. This bites hardest on advertisers: two extra seconds on a landing page erodes the effective arrival rate of every click you buy, and that erosion appears in no column of any ads dashboard.

The second myth is that a slow site must be rebuilt. Usually not. The three most common causes on small-business sites need no rebuild at all: oversized uncompressed images, where a 4MB original photo used as a hero background is the classic culprit; too many plugins and third-party scripts, since every tracking tag, chat widget and font service is another network request; and no caching or CDN. Clearing those three normally brings the numbers into acceptable range.

How to check it yourself, five minutes: paste your URL into PageSpeed Insights and read the Mobile tab first, not desktop, which will only give you false comfort. If a real-user experience section appears at the top, trust that over the lab score below it; the lab score is a simulation useful mainly for its recommendations. Write down LCP, INP and CLS and compare against the thresholds above. Then run your three main competitors and you will know where you stand within a minute.

How to fix it: in order, compress images and convert them to a modern format, remove unused plugins and tags, enable a caching layer and a CDN, and defer non-essential scripts. Only if that fails do you need a conversation about theme or architecture, at which point you are into the redesign versus rebuild decision, or reconsidering the WordPress versus SaaS platform trade-off entirely.

How long: half a day to a day for images and plugins. Architectural optimisation is a project measured in weeks.

Problem 9: HTTPS and the mobile basics

Direct answer: these two are the pass mark, not bonus points. A site without a padlock triggers a "not secure" warning shown directly to your visitors, and since 5 July 2024 Google crawls with the mobile Googlebot only, so content that does not load on a phone is content that does not get indexed.

On HTTPS first. Google announced HTTPS as a ranking signal back in 2014, but in 2026 the real issue is not ranking, it is trust: mainstream browsers display a prominent insecure warning on non-HTTPS pages, especially pages containing form fields. A quote form asking for a phone number with the words "not secure" beside it loses far more conversions than any ranking difference could cost you. The common variant is a certificate that was installed but installed badly, where the homepage is served over HTTPS while some images or scripts still load over HTTP. Mixed content removes the padlock just as effectively.

On mobile. Google's mobile-first indexing documentation treats parity as a baseline requirement: desktop and mobile content must match, and anything missing from the mobile version is content that cannot be indexed. The most common small-business failure is not the absence of responsive design, it is quietly hiding things on mobile for the sake of a cleaner layout, typically specification tables, certification lists and contact details. As far as Google is concerned, that content no longer exists.

How to check it yourself, five minutes:

1. On your own phone, on mobile data rather than office Wi-Fi, open your homepage, a main service page and the contact page. Check the padlock, check whether the text is too small, whether buttons are tappable, and whether the form can actually be completed.
2. On a computer, press F12 and click the device-toolbar icon to switch to a mobile viewport, then compare against desktop to see whether any content disappears.
3. Click the padlock to check the certificate expiry date, and confirm that an http:// address automatically redirects to https://.

How to fix it: almost every host now offers a free certificate, after which you set a sitewide forced redirect. Mixed content is usually cleared with a database search-and-replace across old http links. Hidden mobile content should be converted to collapsible sections rather than simply not rendered.

How long: thirty minutes to two hours for SSL. Half a day for mixed content. One to three days for mobile content parity, depending on the site.

The printable self-check table

Direct answer: the table below is meant to be printed. All nine items need only a browser and two free online tools, and one person can work through the whole thing in half a day with no development background. Run it three times: once against your homepage, once against a main service page, once against an article.

One practical suggestion: screenshot everything as you go. This is not ceremony. It serves two purposes. You will need a before state to verify a vendor's fixes against later. And if you intend to change agencies or put the work out to tender, that folder of screenshots is the most persuasive brief you can write, a hundred times more effective than telling somebody the site feels off. To turn those findings into a formal document, use the format in the website RFP and acceptance checklist.

What to fix first, ordered by impact against difficulty

Direct answer: if you can only do one thing, install GA4. If you have an afternoon, do items 1, 2 and 3. If you have a week, finish the top six. The ordering logic is not which problem is most severe, it is which loss accumulates over time and cannot be reversed.

Notice where items 8 and 9 sit. They are not unimportant. It is that their return has to be established by data first. Optimising speed without analytics means you never learn how much you improved. Rewriting headings across a thousand articles without traffic data means 98 percent of the effort lands on pages nobody reads. That is why installing tracking is permanently number one: it generates no value by itself, but it determines the hit rate of every task after it.

One exception worth flagging: if you are currently running paid ads, item 2 should be done alongside item 1 rather than after it. Advertising is the only line item where real money leaves the account every single day, so a broken conversion tag is a direct financial loss rather than merely an informational one.

Three misconceptions about website health checks

Direct answer: an audit is not a rebuild, a score is not a result, and outsourcing is not the same as accepting delivery. These three misconceptions drive most of the expensive, wrong reactions small businesses have to an audit report.

Misconception one: there are so many problems, we may as well build a new site. This is the most expensive wrong reaction available. Of the nine items above, only speed work might, in the worst case, touch architecture. The other eight are configuration and content work done on the existing site. Fixing all nine on the site we audited cost dramatically less than rebuilding a site of that scale, and it preserved the URLs and accumulated authority of a thousand articles. Rebuild reasons should be strategic, meaning the business model changed, the information architecture is fundamentally wrong, or the platform is genuinely unmaintainable, rather than "the list looks long." The full evaluation is in the redesign versus rebuild framework.

Misconception two: a PageSpeed score below 90 is a failing grade. The score is a means, not the goal. Google's own Web Vitals standard measures real users at the 75th percentile rather than a lab score. A site scoring 65 with a measured LCP of 2.1 seconds delivers a better experience than one scoring 92 whose real users wait four seconds. More importantly, the marginal cost of pushing a score from 85 to 95 is usually enormous, and those ten points move enquiry volume by approximately nothing. Pull every page below 60 up to 75 before chasing perfection anywhere.

Misconception three: this is the vendor's job, I just pay for it. The sharpest finding of this audit, one misspelled tracking parameter, proves the opposite. Every component had been installed by somebody, and not one of them was ever reopened to confirm it worked. An owner does not need to write code, but does need three capabilities: knowing what to check, knowing how to look at it personally, and knowing which contract clause covers acceptance. The self-check table above exists for the first two. The third is covered in the website RFP and acceptance checklist. If yours is a manufacturer site, run the industry-specific items in the B2B manufacturer website SEO checklist as well.

Back to that website one last time. After the report was delivered, what did they do first? Installed GA4, corrected the misspelled letter, and fixed the language declaration. Three tasks, under one working day in total, with no development spend at all. The three lost years of data are not coming back. But from that day they finally had evidence on which to decide what to do next, and that is what a health check is actually worth: not a list of problems, but the return of your ability to make decisions on something other than a guess.