What the audit found
We ran the same crawl on ourselves that we run on a prospective client. It was not a comfortable morning.
| What the crawl found | Why it mattered |
|---|---|
| Lighthouse performance 64 on mobile, largest paint at 10.2 seconds | Most visitors on a phone were looking at nothing for ten seconds |
| 82 of 85 pages had no meta description | Google was writing our search snippets for us |
| 17 pages returned server errors under a normal crawl | A crawler at ordinary speed could knock pages over |
| 286 images with no alt text | Unusable with a screen reader, and invisible to image search |
| A robots file listing 21 sitemaps that did not exist | Every one of them a wasted crawl request |
| Placeholder text and debug output on live pages | Visible to anyone who scrolled far enough |
The uncomfortable part was not any single item. It was that we sell SEO services, and a prospect capable of running one free crawl would have found all of this in about four minutes.
Why the old site was slow
The single most useful clue was a response header: every page came back marked as dynamic, with no page caching in front of it. That means the server rebuilt each page on every request, for every visitor and every crawler.
That one fact explains both symptoms. It explains the ten second paint on a mobile connection, and it explains the server errors, because a crawler making a few requests a second was enough to overwhelm a server doing work it never needed to do twice.
What we changed
Every page is now built once at deploy time and served as a static file. There is no server rendering a page while a visitor waits, which removes the slow paint and the server errors in the same move.
The rest is ordinary discipline that any site can apply. Images in modern formats at the size they are actually displayed. Fonts that do not block the first paint. Almost no JavaScript shipped to content pages, because a page of text does not need a framework running in the browser to be read. No third-party tags competing with the content for the connection.
Content moved into MDX files in the repository, so a page is a file, a change is a commit, and there is no database to migrate or admin panel to keep patched.
The part that matters more: making it stay fixed
Sites do not degrade because someone decides to break them. They degrade one hurried change at a time, and the checks that catch it are exactly the ones that get skipped when someone is in a hurry.
So the checks are in the build, and they fail it:
- A page without a title or meta description does not build. Nor does one whose description is under 70 or over 160 characters, since both are ways of writing one badly.
- Content is validated against a schema. A missing field, a malformed date or an image without alt text stops the build with the filename and the reason.
- A lint step blocks placeholder text and debug output. The exact thing that shipped to the old site cannot ship to this one.
- Performance budgets run in CI, so a heavy image or a new dependency shows up as a failing check rather than as a quiet regression somebody notices in six months.
None of this is clever. It is the difference between a site that was fixed once and a site that stays fixed, and it is the piece almost every rebuild leaves out.
What this does not prove
It does not prove anything about rankings yet. The site launched days ago, search responds over months, and we will publish the Search Console data when there is enough of it to mean something, including whatever does not go our way.
It also does not prove that a rebuild is the right answer for you. It was right here because the problem was architectural. When a site is structurally sound and simply neglected, fixing it is cheaper and faster, and that is what we recommend more often than not.
Check the numbers yourself
Run Lighthouse against this domain. Crawl it. View the source of any page and look for the title, the description and the structured data. Open the sitemap and see that every URL in it resolves.
We put our own site in the case study section precisely because you can verify all of it in the next ten minutes, which is not true of any client project we could have written up instead.