I scanned 154 company websites. 109 had technical defects

Last month I needed new clients, so I did what anyone in my position would: I went looking through Google for firms with neglected websites. Except I didn't open them one by one. I wrote a scanner, fed it 154 addresses across twelve trades, and collected the results in a table.

This article is that table. Plus the part nobody publishes: twice, my own tool handed me false numbers. Catching them took longer than writing the scanner.

Of 154 sites that responded, 109 had at least one verifiable technical defect. What was missing most often takes a quarter of an hour to fix — a title, a description, a heading. And the most useful conclusion wasn't about their sites at all. It was about which of my own measurements survive a second check.

How I measured

The list didn't come from a purchased database. I searched Google.ro for twelve trades — car repair, carpet cleaning, vehicle inspection stations, painting and decorating, commercial cleaning, air-conditioning service, car washes, upholstery cleaning, auto body shops, towing, metal fabrication, industrial flooring — and took the results from pages 4, 5 and 6. I removed directories, classifieds, Facebook pages and foreign companies. What remained were Romanian firms with their own site, mostly around Bucharest.

The scanner makes three requests per domain plus one connection for the certificate. It doesn't crawl, doesn't follow links, doesn't load images. It checks what can be read from the front page and two public files: whether HTTPS works and how long the certificate has left, what status the page returns, time to first byte, how much the code weighs, whether robots.txt and a sitemap exist, whether the page has a title, a description, an H1 and a mobile viewport setting, whether it sends noindex, whether it loads resources over http, whether the www and non-www addresses both answer, and what year is printed in the footer.

One site answered 403 with the title "Just a moment..." — that one was defending itself against bots, not broken. I left it out.

What this article isn't

It isn't an X-ray of Romanian company websites, and I'd rather it wasn't read that way.

The list wasn't picked at random. I deliberately searched pages 4, 5 and 6 — precisely where the sites nobody has touched in years accumulate. Had I taken the top three results, the percentages would look entirely different. The numbers below describe a sample chosen to be neglected. That's all they claim.

The table

Forty-five sites had nothing wrong at all. They weren't necessarily good sites — some looked like 2009 — but the technical basics were in order, and that matters, because that part can be checked objectively.

The rest split almost evenly: 46 with a single defect, 34 with two, and 29 with three or more. Five sites had six defects each.

Three things that cost money now

Most of the defects in that table are small. Three aren't.

Three sites have no working HTTPS. The https:// address doesn't respond at all; only the old version works. Chrome writes "Not secure" next to the address, and on a phone some people get a warning screen before they can enter. This isn't about appearances: it's a first impression, and one delivered by the browser rather than the site. The certificate itself is free. The work is installing it properly and moving every old address onto the new one without losing what you've earned in Google.

Three sites send noindex on their front page. That tells Google explicitly not to put them in search results. All three are firms that obviously want customers from search. It's usually left over from the build, when somebody ticked "discourage search engines" and never unticked it. It's the cheapest defect on the list to fix and the most expensive to leave.

Four sites aren't adapted for phones. They don't even carry the one line of code that tells a browser how wide the page is. On a phone they render like a shrunken sheet of A4, with text you have to pinch to read. More than half the people searching for a car mechanic are searching from a phone.

The footer tells the truth

Ninety-nine sites had a year in the footer. Thirty of them showed a year older than 2025. The oldest: 1999, on two different sites. Another twelve predated 2015.

The footer year isn't a technical defect. It doesn't lower you in Google and it breaks nothing. But it's the only public statement a site makes about when somebody last looked at it. A person shopping for an industrial flooring contractor who sees "© 2011" in the footer isn't thinking about SEO. They're wondering whether the company still exists.

The part where my own tool lied

This is what I actually learned, and it has nothing to do with anyone else's website.

Lie no. 1: speed measured once

After the first run I had a tidy list of slow sites. Twenty-five of them looked like they had serious server problems. Before writing to anyone about it, I measured them again.

Of the 25 re-measured sites, 11 had looked slower than a second on the first run and came in under a second on the second. Twelve differed by at least a factor of two between measurements. The record is the first row: a site that showed 1,161 milliseconds answered the second time in 22. Fifty-two times faster.

Nobody fixed anything in between. The first request caught a cold server: shared hosting that only starts its process when somebody asks for the page, an empty cache, an unwarmed database, an unresolved DNS record. The second request, hours later, found a server already working.

Among the sites I measured twice, the median is 104 milliseconds. Fifteen stay above 1,200 milliseconds on both measurements, and three of those above two and a half seconds. Those are the real problems. The rest was noise I had mistaken for data.

Had I sent emails after that first run, I'd have told someone their site answers in three seconds. They would have opened it, found it instant, and been right to ignore me and everything that followed. You don't just lose that client. You lose the right to be believed.

Lie no. 2: 38 sites with insecure resources. Actually six

My scanner reported 38 sites loading resources over http inside a secure page. That worked out to 24.7% — the largest figure in the whole table, so exactly the number I'd have put in the headline.

It was wrong by a factor of six.

The check looked for any src= or href= beginning with http://. The trouble is that the second half has nothing to do with security. An href pointing at an old site is just a link: the browser doesn't open it until somebody clicks, and then they've left anyway. Worse, nearly every WordPress theme carries a line in its header pointing at a specification document over http. That line loads nothing. My scanner counted it as a defect on every WordPress site it passed.

Real mixed content means a resource the browser actually requests over http inside an https page: an image, a script, a stylesheet. I checked all 38 again, this time separating the tags and reading the rel attribute. Six remained.

And those six are worth seeing, because they're instructive. One was loading its logo over http from a folder dated 2015. Another was still pulling images from the demo site of the theme it had bought — which means it displays somebody else's demo photos, served from somebody else's server. A third was loading a LinkedIn script over http, which modern browsers block silently.

I fixed the check. It now counts only resources the browser genuinely requests, skips conditional comments meant for Internet Explorer, and prints the first offending address as evidence, so it can be verified on the spot.

What changed in how I work

Two rules, both paid for:

1. No speed figure leaves the house measured once. The scanner now takes two measurements and keeps the lower one. If the two differ sharply, the figure isn't used at all.
2. Any defect appearing on more than 20% of a sample gets checked by hand, on three sites, before I believe it. A high percentage is more often a sign of a badly written rule than of an epidemic.

What you can check yourself in ten minutes

You don't need a scanner and you don't need me. Open your own site and do these six, in order:

1. Look for noindex. In Chrome, press Ctrl+U to see the page source, then Ctrl+F and type noindex. If it's there, your site is asking Google to ignore it. Check this before anything else.
2. Type your address both ways: with www and without. If both open and both stay that way in the address bar, without one redirecting to the other, then as far as Google is concerned you have two sites competing with identical content.
3. Open yoursite.com/sitemap.xml and yoursite.com/robots.txt. If they 404, Google has to guess at your pages. It still finds the important ones, but with a lot of wasted effort on a large site.
4. Look at the title in the browser tab. If it's cut off, or if it says "Home", that's also the label people see in Google's results.
5. Open the site on a phone, on mobile data, not on the office Wi-Fi. Your desktop on fibre is not your customer.
6. Scroll to the footer and read the year. If it isn't the current one, fix it today. It's five minutes of work and it's the only item on this list your customers notice rather than Google.

If two or three of these come up, it's nothing serious and you can handle them yourself. If all six do, the question isn't what to fix any more — it's who looks at your site from time to time. For the full version, with written evidence for each problem and the order they get fixed in, that's exactly what a website audit is. The indexing and structure side belongs to technical SEO, and if your problem is the server, I've written separately about how fast a site actually needs to be.

Why I'm not naming the sites

Because they're real companies, with real people, who never asked anybody to put their defects on the internet.

I can do both things — write publicly about what I found, and write to them privately that I can fix it — only if I don't mix them. An article that names sites to show how clever its author is isn't analysis, it's a public execution. And it wouldn't work commercially either: nobody hires the person who used them as a bad example on his blog.

The numbers are true and verifiable. Anyone who wants to can reproduce them: the method is written above and the searches are public.

Frequently asked questions

How can I check myself against the same criteria?

The list in the section above covers everything visible without tools. For the rest, PageSpeed Insights gives you speed and Search Console shows what Google excluded from the index and why — those two are free and tell you almost everything. Just remember the double-measurement rule: run PageSpeed twice, hours apart.

If my site has none of the defects in the table, does that mean it's good?

No, it means it isn't broken. Forty-five sites in the sample passed technically and most of them still bring in no customers, because they have no content that answers anything, no properly kept Google Business profile, or no measurement of any action at all. The technical side isn't the goal. It's the condition for the rest to matter.

I get a lot of emails telling me my site has problems. How do I know which are serious?

Ask for the evidence and check it yourself. A message saying "you have SEO problems" means nothing. A message saying "your front page sends noindex, look in the source with Ctrl+U" gives you something you can confirm in thirty seconds without taking anyone's word. And if you're given a speed figure, ask how many times it was measured. Now you know why the question matters.

Are you releasing the scanner publicly?

Not for now. Not because it's any kind of secret — it makes three ordinary requests anybody could write — but because, as you've just read, I caught it lying twice. A tool that produces false numbers, in the hands of someone with no way to check them, does more harm than good.

What's left of all this

This sample confirmed what I suspected: on neglected company websites, the problems aren't exotic. They're a title, a description, a heading, a sitemap. Things that are quick to fix and went unfixed because nobody is looking.

But what I'm taking forward is the other half. I spent a few hours writing a scanner and a few days verifying what it told me, and the second part was the part that counted. A figure I'd have put in the headline — 24.7% — came out at 3.9%. A list of 25 apparently slow sites came out at nine, with a single one above two and a half seconds.

If you want to check your own site against these criteria and not everything comes out clean, write to me through the contact form with what you found. I'll tell you what it means and what I'd fix first, even if the answer is that you need nothing. And if this was useful, pass it on to someone who runs a company website and hasn't logged into it for two years.