Multi-Doctor Dental Rebuild, 64 Hours Delivered in 17 Days — White-Label WordPress for a US Marketing Agency
Dual-practitioner dental WordPress rebuild with dedicated bio pages — 64 hours in 17 days, spec followed line-for-line, 48-item launch checklist closed.
Screenshots captured by automated tooling — some elements may not have loaded fully or may layer on top of each other. For the most accurate view, visit the live site →
Rebuild the site on a new stack. Implement the spec. Don't improvise. Hand it back ready for cutover.
The Craft of a Rebuild
A two-practitioner dental WordPress rebuild — dedicated bio pages for Dr. Preston Shurley and Patrice Robbins sat alongside service pages, each a distinct content type, making template completeness across every URL the binding constraint. We shipped the full Elementor Pro rebuild in 17 days, 64 hours, and a per-content-type verification pass surfaced both practitioner pages on the old styling, closed in a retained sprint.
This case study is a record of one such rebuild, in which the agency owned the strategy and we owned the execution.
Snapshot
| Field | Value |
|---|---|
| End-client industry | Healthcare — General Dentistry |
| End-client | Brightworks Dentistry (Dr. Preston Shurley and Patrice Robbins) |
| Engagement | White-label WordPress build for a US marketing agency specialising in local-business websites |
| Project Type | WordPress rebuild with Elementor Pro on WP Engine |
| Scope | Full site — services, multi-doctor team pages, blog, contact forms, PDF downloads |
| Timeline | 17 days (27 Dec 2024 – 13 Jan 2025), on schedule |
| Effort | 64 hours against a 64-hour estimate — no overrun |
| Team | 5 specialists (dev · QA fixes · PM) |
| Tech Stack | WordPress · Elementor Pro · Gravity Forms · WP Engine · Yoast · Screaming Frog · Site Checker (xaverPRO QA plugin) |
| Content parity check | Original-vs-rebuild content diff cleared before handoff — no missing copy, no broken internal links, no structural drift |
| Delivered | Spec followed line-for-line — redirects, meta titles, PDF library, multi-doctor team pages, 48-item launch checklist |
| Review rounds | ≈2 review rounds across the 17-day calendar window |
The Brief
Brightworks Dentistry is a two-practitioner dental office. The agency had been managing the practice’s web presence and needed the existing WordPress site rebuilt on a modern Elementor Pro stack — tighter templates, reliable Gravity Forms integration, and a PDF download library that had been grafted onto the old site with workarounds. The rebuild was a same-CMS project (WordPress to WordPress), which looks simpler than a platform migration on paper.
The agency handed us a Google Sheets workbook covering every URL to migrate, every meta title and description to preserve, every template to apply, and a detailed launch checklist. The ask was precise: execute the spec as written, stay outside the client-facing loop, deliver on the quoted hours. Brightworks Dentistry dealt only with the agency that managed their web presence; we built and cut over the site from behind that relationship, never named to the practice. We worked inside their coordination system.
The risk the agency was hedging against was not ranking loss — the SEO strategy was theirs and it was already handled. The risk was handing a multi-practitioner rebuild to a dev team that treats a same-CMS project as a low-stakes exercise. Same-CMS rebuilds carry a specific failure mode: because the destination platform is familiar, a team that improvises can quietly rewrite a meta title, re-route a form, or skip a redirect that doesn’t look important. On a single-doctor site, one missed page is a missed page. On a site with two practitioners, each of whom has dedicated bio and team pages that patients work through directly, partial template application is a less visible but equally damaging outcome.
Risk context. A same-CMS rebuild on a two-practitioner site produces a specific blind spot: the practitioner bio pages —
/team/dr-preston-shurley/and/team/patrice-robbins/— are their own content type, and a build pass that covers service pages without explicitly templating each doctor page leaves those URLs carrying the old site’s styling, visually intact on a Screaming Frog crawl but wrong. Dr. Shurley and Patrice Robbins each had dedicated team pages that were among the most visited non-service URLs on the legacy site — the kind of page patients share with family members and referrers land on. A rebuild that applies new templates correctly to service pages but leaves practitioner bio pages carrying the old site’s styling doesn’t look broken on a site-wide crawl; it surfaces in the agency’s QA pass, costing an unplanned correction sprint. This was not a hypothetical — during AM QA both doctor pages were still carrying the old template, logged as a dedicated fix ticket before cutover. The fix was to scope every content type, not just the high-traffic one, for complete template application.
How We Did It
1. Template-first build. Rather than rebuilding the full site page by page, we collapsed it into reusable templates applied across all content types:
- Homepage, About, Contact, and a Default fallback
- Services Lander + Service Page template powering the full service catalogue
- Doctor/Team Page template applied to each practitioner — Dr. Shurley and Patrice Robbins each with a dedicated, consistently styled bio page
- Blog template for ongoing content
- PDF library page — downloadable patient education resources integrated directly into the page structure rather than as external links
Every content type ran through a template. That means any later edit has one home per page type. We chose templates over per-page builds because the two-practitioner structure with dedicated bio pages made cross-page consistency the binding constraint — a constraint the agency’s page-level spec implicitly relied on but did not explicitly guard against.
2. Spec followed line-for-line, from the agency’s sheet. The agency’s Google Sheets workbook carried every URL, every meta title and description, every template assignment, and every integration note — including PDF file placement and Gravity Forms targets. We implemented each row as written. Every entry the sheet held was reproduced on the rebuilt site, value for value. Wherever a cell was blank, we sent the question back to the agency instead of filling the gap ourselves. No creative interpretations shipped.
The logic here is plain enough: in a rebuild, the spec functions as the agreement struck between the agency and its client. A dev team exists to honour that agreement, not to revise it.
3. Crawl-based verification, not “looks fine to me”. Before cutting over DNS, we crawled the old production site and the staging rebuild together with Screaming Frog. Every difference in status codes, broken links, redirect chains, and meta tags got checked back against the agency’s spec. A repeat crawl once the site was live verified that each internal link resolved on the production domain. That same comparison showed the PDF download paths were wired up correctly and the practitioner bio pages had picked up the new template.
4. 48-item launch checklist, closed before handoff. Categories covered design fidelity, functionality (forms, downloads, navigation), content accuracy, SEO and analytics, responsive display across six viewports, and a Domain and DNS migration sequence to WP Engine. Cross-device QA ran on Chrome, Firefox, Safari, and Edge. No line went out the door before it had been signed off.
The Doctor/Team Page template was what kept the two-practitioner structure from splitting along content-type lines. Without an explicit template per bio page, those URLs carry the old site’s styling after every service page takes the new design — exactly what happened during AM QA and why issue #233 existed. Templating every content type, not just the high-traffic ones, was the constraint the spec implied but did not enforce.
Results
| Metric | Outcome |
|---|---|
| Spec fidelity — redirects | All legacy URLs redirected as specified |
| Spec fidelity — meta data | All meta titles and descriptions placed as specified |
| Spec fidelity — templates | Complete template system built and applied site-wide, including practitioner pages |
| Spec fidelity — PDF library | Patient education PDFs uploaded and correctly linked on applicable pages |
| Launch checklist | 48 / 48 items signed off before cutover |
| Timeline | 17 days, delivered on schedule |
| Effort | 64h / 64h estimate — no overrun, no scope creep |
| Responsive verification | Zero layout issues across 4 browsers × 6 viewports |
| Internal QA | All agency-scoped issues closed before handoff; post-launch agency QA round addressed form and review-link corrections in a retained sprint |
| Site status | Live on WP Engine at https://www.brightworksdentistry.com/. |
Net of it: we implemented the agency’s spec as written, inside the quoted hours, on the scheduled cutover day. A retained sprint after the agency’s post-launch QA pass closed additional items — the build held its shape through that process.
Operational Integrity at handoff
The parity diff between the legacy site and the staging rebuild caught that /team/dr-preston-shurley/ and /team/patrice-robbins/ were still rendering the old site’s design — every other page had taken the new template, only those two URLs had slipped — and we logged both as a dedicated fix ticket before cutover. Pre-handoff QA ran through Site Checker — see how we run QA for the categories and the zero-defect bar we hold before handoff. Once the build was in their hands, the agency put it through a second pass on their own setup. Each thing that came up landed in the shared backlog, where we resolved it item by item ahead of their sign-off.
Process
| Phase | Duration | Outcome |
|---|---|---|
| Brief & estimation | 1 day | Agency spec reviewed; 64h quoted and agreed |
| Development | ~12 days | Full site rebuilt across all templates including practitioner bio pages |
| Internal QA & review | 3 days | Issues logged; all agency-scoped work cleared before handoff |
| Spec verification | 1 day | Meta, redirects, and PDF paths reconciled against workbook |
| Delivery & DNS cutover | 1 day | Site live on WP Engine, no downtime |
Phases overlap (QA ran alongside late development), which is why the calendar timeline is 17 days rather than the sum of individual phases.
Team
Delivery team
- Nikita Tumasevic — lead developer (full site build and template system, including multi-doctor team pages)
- Anna Polunina — implementation support and QA across the rebuilt pages
- Alexey Melkov — implementation support
- Ivan — supporting developer (repeating blocks and page duplication)
- Anton Hersun, xaverPRO — project lead (estimation, agency-side communication, sign-off)
Agency-side project management and SEO strategy remained with the partner agency throughout. Dr. Shurley’s office spoke to the agency and only the agency; our names never appeared in a thread, on the staging site, or at cutover.
For agencies considering a white-label WordPress rebuild
On a same-CMS rebuild, covering every content type is the structural trap. For this practice—a multi-practitioner clinic; for others—a multi-location DSO network with the same brand system. The trap is hard to spot. Secondary pages—practitioner bios, resource libraries—will carry the old styling into production. Schema drops off those pages; rich results your agency built disappear. New team pages added in month two don’t inherit the layout.
The question to ask a dev partner before committing is not “can you rebuild the site?”—it is “how exactly will you scope every content type for full template application?”
Send us a current production URL or your design files. We will map your content inventory against the rebuild scope, identify the pages that will quietly carry old templates, and return a fixed-hours quote.
Don't have a spec yet? Send a one-paragraph description — we'll come back with the questions worth asking. Send a description →
Site Checker runs before the agency sees anything.
Before handoff, every staging build runs through Site Checker — the WordPress QA plugin we built and maintain. It is a fail-zero gate: nothing goes to the agency with an open failure. Warnings are reviewed and judged non-blocking; the agency gets a clean slate to run their own QA layer against, not a staging site with known issues in the queue.