A Clinic Site From 8/100 To 100/100 Site Health

What The Old Site Was Carrying

The site hadn't been touched in years. It scored 8 out of 100 on Ahrefs site health. That's not a design problem, it's a structural one: 1,429 pages missing alt text, 1,321 with no meta description, 776 pages with nothing linking to them, and a homepage that took 18.5 seconds to show its main content on a phone.

Google treats 2.5 seconds as the threshold for a good load. Mobile visitors were waiting more than seven times that long.

The Problem That Hides On A Desktop

Run the old site through Google's speed test on a desktop and it scored 84, with the main part of the page showing up in one second. Run the same page on a phone and it scored 53, and that same content took 18.5 seconds to appear. Same site, same content, same day.

That spread is the whole diagnosis. Oversized images are invisible on a laptop with an office connection and punishing on a phone on mobile data. Most people searching for a chiropractor are on a phone.

What The Rebuild Changed

Moving onto Cliniverse Sites changes where the work happens. Alt text, meta descriptions and heading structure stop being per-page chores and become part of how a page is built, so coverage failures resolve as a class rather than one at a time. Images route through a component that serves the right size and format for the device asking. The structured data that tells Google what a clinic is, its hours, the conditions it treats and its FAQs, ships with the template rather than being bolted on per page.

The old site had 1,541 pages for Google to work through. The new one has 548, and 517 of those are blog posts. That drop's deliberate: what came off was duplicates and junk that gave Google more to read and less worth ranking, while the archive itself moved across intact. A rebuild that drops a few hundred posts takes their rankings and internal links with them.

The reason a site like this sits untouched for years is usually cost. A web design company quotes thousands for a rebuild, and the quote covers how the site looks rather than the technical work underneath it: the crawl errors, the image weight, the schema, the redirects. Those are the things that decide whether the site can be found. Cliniverse Sites carries them in the template, which is what brings a rebuild into reach.

The Number In The Middle

The first crawl after launch came back at 30, not 100. Nothing on the site was broken. Every page was telling Google its own address with a slash on the end, while the site serves those pages without one. So each page pointed Google at an address that bounced straight back to where it came from. That address appears in four places on every page, the canonical tag, the Open Graph URL, the schema and the sitemap entry, and one shared helper was building all four wrong. Ahrefs counted it 1,116 times: 569 canonicals pointing at a redirect, 547 redirects sitting in the sitemap.

This clinic was the first site on the platform, so the bug sat in our shared template rather than in their site. We found it and shipped the fix the same day, with a regression test that fails the build if a trailing slash ever comes back. Because the template is shared, no clinic that launched afterwards inherited it.

That's the honest argument for building on a platform instead of a one-off site. The first client's problem gets solved once, and it stays solved for everyone behind them.

Where It Landed

Site health went from 8 to 100 on a full recheck of 982 pages. Mobile performance moved from 53 to 89 and mobile load from 18.5 seconds to 3.7. Accessibility went from 68 to 100, and SEO from 85 to 100 on mobile and 77 to 100 on desktop. Desktop now scores 100 on all four PageSpeed categories: Performance, Accessibility, Best Practices and SEO.

Desktop load is the number worth watching, because it didn't move in a straight line. The first measurement after launch was 1.3 seconds against the old site's 1.0, slower, on the one device where the old site had nothing wrong with it. Routing images through the size-aware path took it to 0.8 seconds, faster than what it replaced.

Mobile took the longest to fix, and the last of it came from one attribute. The main image on the page was set to load lazily, which is right for anything below the fold and wrong for the one image a phone is waiting on: the browser held off fetching it until it had worked out the layout, so the file spent a second queued and a seventh of a second downloading. Loading it eagerly took mobile from 77 to 89 and the load from 6.6 seconds to 3.7. Like the canonical bug, it was in the shared template, so the fix went to every clinic on the platform.

At 3.7 seconds it is still above the 2.5 Google treats as good, so the phone experience is the work that continues.

What We Are Not Claiming

Search results move on their own timeline. This clinic's traffic was already declining before the rebuild, so any recovery over the coming months is partly the rebuild and partly a trend we didn't cause. The numbers above are the ones a rebuild changes directly: crawl health, load time, accessibility, structure. Rankings and booked patients are the slower half. We'll show those when there's enough data behind them to be worth showing.