We audited our own site and every page failed

There is an obvious way to test whether an audit is worth buying: run it on yourself first and publish the result.

So we ran the full pass over smart-ui.pro. Security, code, SEO and indexing, accessibility, UX, performance. Our own site, built by us, maintained by us, with nobody to blame.

Thirty pages out of thirty had at least one fault. Here is what they were, because the categories matter more than the specifics.

The ones that reported success

The most expensive class, and the reason a scanner does not find them. Every one of these returned a 200 and looked correct from the outside.

Unknown URLs answered 200. The 404 page was a route that rendered 404-looking markup with a success status. Every mistyped address on the site was a real page as far as a crawler was concerned. An unknown case-study slug was worse: it read past an empty result and returned a 500.

FAQ answers were in no page. The accordion returned null while collapsed, so not one answer reached the served HTML. Meanwhile eight pages carried FAQPage structured data declaring all of them. The markup validated. Google's own testing tool passed it. The content it described did not exist in the document.

Five of six tab panels were absent too. Same mechanism, different component. Content a visitor reaches in one click, that no crawler had ever seen.

A feed link that reached zero pages. Declared once in the root layout, and Next merges metadata per field, so every page that set its own canonical replaced the parent's block wholesale and dropped it.

That last one has now happened four times on this site. Once it took the feed link. Once it took og:image and the large-card type on all fifteen pages, so every share on LinkedIn rendered as bare text for months. Once it took the alternates. And most recently it took the noindex off exactly one Ukrainian page, which then served English articles at a second URL until Search Console reported it as a duplicate.

Nothing errored on any of those four occasions. The source looked right every time.

The ones that leak

Two of four sameAs profiles were 404s. The Organization schema pointed at a LinkedIn company page and a Behance profile that did not exist. Anything following the entity graph to confirm who we are was finding missing pages. That is a worse signal than a shorter graph.

Seven portfolio cards linked out to places they should not. A Figma working file. Two WP Engine staging sites. Two preview deploys. One of our own staging subdomains, which we had deliberately deindexed. And a client's site on a bare IP over plain http.

Thirty-eight client staging subdomains were indexed. Found earlier, through Search Console: six of the top ten pages by impressions were client staging environments rather than our own site.

The ones that are just old

Three of ten cards on the CMS page sold Netlify, whose CMS was archived and renamed two years ago, on a site that deploys to Vercel. The backend page offered Ruby on Rails and Java, which nobody here writes. The agency page listed Gatsby, unmaintained since 2023, and InVision, which shut down in 2024.

Four service pages shared one paragraph, including the backend page, where it described a CMS. Duplicate content between four URLs, and none of them saying anything a competitor could not.

The QA page headline never used the word QA. It read "Transform Your Business with Tailored Digital Solutions".

Ten portfolio descriptions were placeholders. One card read "Jva - description". One project was publicly titled "Draft website Influencer".

What none of this needed

No specialist tooling found any of it. The whole method is one habit:

Fetch the live thing. Look at what came back. Compare it to what you intended.

Not the source. Not staging. Not the CI log. What the server actually sent, to the address a visitor actually uses.

That is the difference between a scanner and an audit. A scanner reports what is machine-checkable, which by definition excludes markup that is well-formed and untrue, a status code that is correct and meaningless, and a valid API key being used by somebody who is not you.

What we changed as a result

Every finding is fixed, and the checks that would have caught them run against production on every deploy. That script started at 65 assertions. It is at 172 now, and it has caught four things since, including one it found in itself: a check for first-person writing was matching /\bus\b/i and flagging "the UK, US and Australia".

The current state of the same audit is thirty-three pages, none flagged.

The uncomfortable part

We built this site. We know every corner of it. It still took a structured pass across six dimensions to find any of the above, because none of it was visible from the inside, and most of it reported success.

If that is true of a site whose authors are auditing it, it is worth asking what a site nobody has looked at in two years is currently reporting.

We now run this as a fixed-scope engagement on other people's systems: the audit, across the same six dimensions, delivered as ranked findings with the steps to reproduce each one. Five to ten working days, priced before it starts, with no obligation to have us do the fixes.

If you want to try the method before you buy it, start here: pick the three strings you are most confident are on your production pages, and grep the served HTML for them.