An SEO audit tool spits out a list of red and amber flags in a couple of minutes, and the list always looks alarming. The trouble is that these tools do not know your site: they look for patterns, and whatever they cannot interpret they mark as an error. Anyone who works straight down the list spends most of their time on pointless work – and in the worse cases breaks something that was working fine.
In September 2026 I ran three different audit tools against my own site, eaglesolutions.ro. Between them they flagged 16 errors and warnings. Of those I fixed six and left ten alone. I did not decide any of them by gut feeling: I measured each one. This article is about how.
Why run an audit on a site that is already finished?
Because you are blindest to your own work. I designed the site, I wrote the code, I filled in the content – I know exactly where everything is supposed to be, and that is precisely why I do not notice when something is not there after all. An external tool does not know any of that, and that is what makes it useful: it looks at things I have stopped looking at.
It is only useful, though, if you fix the problem rather than the list.
What turned out to be noise – and why
"Your keywords are not well distributed"
The tool listed the most frequent words on the page and took me to task for not having them in the title. At the top of the list stood the Hungarian word for "and", with 24 occurrences, followed by "not" with eight.
That is not an error but a linguistic blind spot: the tool has no list of Hungarian function words, so the emptiest words end up being treated as the most important keywords. Optimizing for that means optimizing for nothing.
The same check also surfaced phrases like "technical storage or access". I looked into it: that is the cookie consent banner text, which sits in the source of every page. The tool counted it as page content. Google does not treat it that way.
"You are not serving resources from a CDN"
This one simply was not true. I pulled the server response headers and there it was: `server: hcdn`, plus a request identifier pointing at a Frankfurt edge node. The content goes through a CDN, images included.
The tool did not see it because it looks for a separate CDN subdomain (something like `cdn.example.com`). My host's CDN, however, runs on the same domain at the edge, transparently. The test looked at the shape of the implementation rather than at whether it exists.
This is the most instructive type: the tool does not measure what its name promises.
What turned out to be real – and what it was worth
Blurry images on the reference cards
This was the most uncomfortable finding, because you can actually see it. The tool reported that I was serving improperly sized images. I measured the real rendering in the browser: the reference cards were getting a 300-pixel-wide variant into a 600-pixel-wide slot. Scaled up two-fold, blurry.
The cause was a one-line decision in the template: the code asked the media library for the "medium" size, while the card had grown in the meantime. Exactly the kind of mistake I would never have caught on my own, because I knew the image was there – what I never checked was how sharp it was.
After the fix every image is served at exactly its display size and comes with an `srcset` list, so a phone does not download the desktop variant.
An indexable duplicate in the portfolio archive
The tool flagged duplicate content. I looked: the address `/referenciak/page/2/` returned HTTP 200, open to indexing, with a canonical link pointing at itself, and served the same 17 references as page one. In all three languages.
The cause: the template prints every reference through its own query, while WordPress's main query paginates ten at a time – so at 17 items a second page "exists", it just shows the same thing. From Google's point of view, three full copies in three languages.
The fix: paginated addresses now issue a 301 redirect to the archive.
Invalid structured data
On two pages it reported faulty business data. The error sat in the head of the About page: the employer field of the person record held an incomplete copy of the business – only a name and a web address, without the required postal address. Since that type counts as a business entity, it is invalid without an address.
The fix was not to fill in the missing field but to turn it into a reference: the complete, correct business data is already on the same page, and the person record now points at it. That way the same thing does not need maintaining in two places.
The same link text pointing to different pages
According to the tool, dozens of pages were competing with each other because of identical anchor texts. That was partly true: in my articles the phrase "in a separate article" pointed at three different pieces, and the same was true in the Hungarian and Romanian versions.
Link text is one of the strongest signals about what lies on the other side of a link – for the search engine and for a reader using a screen reader alike. "In a separate article" tells neither of them anything. I replaced 18 such anchor texts with ones that name the destination.
The "Read more" button on the blog listing I did not want to spoil, though – there the article title went into the link as visually hidden text. The visitor sees the same short label, but the machine knows where it leads.
Page titles that were too long
Ten page titles ran past 60 characters, so Google would have truncated them in the results. A small fix, but a cheap one: the distinctive keyword stayed everywhere and the redundant repetition came out. All 96 pages are now under 60 characters.
Thin content, where it genuinely was thin
The "too little text" warning was noise overall, but in two places it was right. On the home page the actual content ran to 885 words, and the city pages to roughly 450 – for a commercial site that is too little for a search engine to take seriously.
Here, though, I did not manufacture a word count. The home page gained a "Who this is for – and who it is not" section, and the city pages got genuine professional content that differs from city to city: in one place the logic of product pages in the woodworking trade, in another tourism seasonality, in a third how a B2B quote request is built.
That has a measurable side effect I am rather pleased with: after the expansion, the pairwise textual similarity between the city pages fell from 31.9% to 19.2%. There is more text, yet they resemble each other less – the exact opposite of what happens with template-driven content production.
How can you decide what is real?
You do not need to be a developer. Four questions cover most cases:
1. What is the tool actually measuring – is it only looking at the shape of the implementation? The CDN test failed because it looked for a subdomain, not for a CDN. If a finding takes you to task over one specific way of solving something, be suspicious.
2. Can you see the problem on the site? A blurry image you can see. "And" as a keyword is nowhere to be seen, because it does not exist.
3. Does a real visitor ever meet it? The duplicate archive lands in Google's index, so it has real consequences. A rate limit that only a crawler triggers does not.
4. What do you lose if you "fix" it? This is the most important one. If the fix removes a working feature – a contact button, your structured data, a local keyword – then the cure is worse than the disease.
In numbers
The work took one day in total, coding and measuring included. The result, verified across all 96 pages:
- Titles over 60 characters: 10 → 0
- Indexable duplicate archives: 3 → 0
- Images served upscaled: 3 → 0
- Generic anchor texts with multiple destinations: 18 → 0
- Invalid structured data items: 2 → 0
- Heading level skips: 2 → 0
- Home page content: 885 → 1355 words
- Textual similarity between city pages: 31.9% → 19.2%
- Missing image alt text, orphan pages, missing hreflang: all were already 0
And what did not change, because it did not need to: the site is still 75 kilobytes in total, loads in 0.85 seconds, with no console errors.
The takeaway
An audit tool is neither an enemy nor an oracle. It is a good list of questions, from which you have to filter out what applies to you. In this round the ratio was 6 to 10 in favour of noise – and had I worked straight down the list, I would have done the larger part of the work for nothing while removing things that were working.
If you have a website and have been handed an alarming audit report about it, send it over – I will tell you for free which points in it are real and which you can ignore. And if you have not run one yet, start with my case study on the PageSpeed measurement: that one shows what it looks like when the technical foundation is in place.

