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

What The Old Site Was Carrying

The clinic came to us with a WordPress site scoring 8 out of 100 on Ahrefs site health. That is not a design problem, it is a structural one: 1,429 pages missing alt text, 1,321 with no meta description, 776 orphan pages with nothing linking to them, and a homepage that took 18.5 seconds to load 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 PageSpeed on a desktop and it scored 84, with the largest piece of content painting in one second. Run the same page on mobile and it scored 53, and that same paint took 18.5 seconds. Same site, same content, same day.

That spread is the whole diagnosis. Oversized images and render-blocking resources 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. Schema for a medical clinic, opening hours, conditions and FAQs ships with the template.

The old site's 1,541 crawled URLs came down to a 548-URL sitemap. That drop is deliberate: the tail was duplicate and junk URLs that gave Google more to crawl and less to rank.

The Number In The Middle

Here is the part most case studies leave out.

The first crawl after launch came back at 30, not 100. Nothing on the site was broken. Every canonical tag, Open Graph URL, schema URL and sitemap entry was being built with a trailing slash, while the site itself serves pages without one. Every page was pointing Google at an address that redirected straight back to the page it came from. One bug, 569 canonical errors and 547 sitemap redirect errors.

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 is 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 re-crawl of 982 URLs. Mobile performance moved from 53 to 70 and mobile load from 18.5 seconds to 7.5. Accessibility went from 68 to 96, and SEO from 85 to 100 on mobile and 77 to 100 on desktop.

One number moved the wrong way. Desktop load went from 1.0 seconds to 1.3. The desktop site was already fast, and the rebuild traded a fraction of a second there for eleven seconds on mobile. We would make that trade again, but it is a trade, not a clean sweep.

Mobile at 70 is better, not finished. The weight that remains is images on interior sections that have not moved onto the optimized path yet.

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 next quarter is partly the rebuild and partly a trend we did not cause. The numbers above are the ones we can attribute directly: crawl health, load time, accessibility, structure. Rankings and booked patients get measured at 30, 60 and 90 days, and we report what they say.