Work / Rebuild / 81-Page Dental WordPress Rebuild

81-Page Dental WordPress Rebuild

81-page dental WordPress rebuild shipped to spec in 19 days across 10 templates — 50 hours, 80 redirects, 48-item checklist, crawl-verified before cutover.

Industry Healthcare (Dental)
Engagement White-label · US marketing agency
Delivered 19 calendar days · on schedule
Live site drhardt.com
50h across 19 days
drhardt.com · desktop
drhardt.com · mobile

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 →

— The brief

Rebuild the site on a new stack. Implement the spec. Don't improvise. Hand it back ready for cutover.

Client (end user): Live Oak Dental — Dr. Richard Hardt DDS, Porterville, CA
Engagement: White-label development for a US marketing agency
Delivered: March 2025 · 19 days · 50 hours · on schedule, no overrun

The Craft of a Rebuild

81 pages of a dental practice WordPress rebuild, collapsed into ten templates and executed line for line against the agency’s workbook specification — every URL migrated, every meta title preserved, every 301 redirect implemented. The build shipped in 19 days across 50 hours, with crawl-based verification against the original site before DNS cutover. A year later, the site remains in production, serving the same practice in Porterville, California.

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 & Cosmetic Dentistry
End-client Live Oak Dental (Dr. Richard Hardt DDS, Porterville, CA)
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 The whole site — services, doctor bios, blog, custom smile gallery
Timeline 19 days (24 Feb – 15 Mar 2025), on schedule
Effort 50 hours against a 50-hour estimate — no overrun
Team 3 specialists (40h dev · 5h PM · 4h fixes · 1h SEO implementation)
Tech Stack WordPress · Elementor Pro · Gravity Forms · WP Engine · Yoast · Screaming Frog · Site Checker ( 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 — 80 redirects, 81 meta titles, 48-item launch checklist
Engagement cadence 12 agency-raised issues · 11 of 12 closed by handoff
Review rounds ≈2 review rounds across the 19-day calendar window
Per-ticket effort 4 internal Redmine tickets · median 4.5h / P75 40h per ticket
Launch checklist 48 items, signed off before cutover

The Brief

The agency had a retained dental-practice client whose existing WordPress site needed a rebuild — modern page-builder, reliable forms, tidy template system. They’d already done the groundwork: a Google Sheets workbook containing every URL to migrate, every meta title and description to preserve, every design template to implement, and a 48-item pre- and post-migration launch checklist.

The ask was specific. Take the spec as given; rebuild the site on Elementor Pro; hand it back ready for cutover. Remain outside the client-facing loop. Implement the SEO decisions as written. Deliver inside the quoted hours.

The risk the agency was hedging against was not SEO collapse — they had that handled. The risk was handing the build to a shop that would quietly improvise around the brief: a missed redirect, a re-interpreted template, a “minor” revision to a meta title, a budget overrun, a slipped launch window.

Risk context. When a live dental practice site changes hands — even a same-CMS rebuild — every URL already in index, every internal link patients follow, every redirect the agency has carefully mapped becomes a potential casualty of a dev team that improvises instead of executes. The failure mode is not catastrophic; it is silent. A missed redirect. A meta title slightly reworded. A form integration re-wired. Each is defensible in isolation; together they erode the spec the agency staked its reputation on.

How We Did It

1. Template-first build. Rather than rebuilding 81 pages one by one, we collapsed them into ten reusable templates and fit every page into them:

  • Homepage, About, Contact, and a Default fallback
  • Services Lander + a single Service Page template powering 20 service pages across four categories (preventative, restorative, cosmetic, advanced-care dentistry)
  • Doctor Page — individual bio pages
  • Blog Lander + Blog Post templates
  • Smile Gallery — the practice-specific before/after template

Ten templates, whole site delivered. Future edits on the agency’s side live in one place per page type.

2. Spec followed line-for-line, from the agency’s sheet. The agency handed us a Google Sheets workbook: every URL to migrate with its target path, every meta title and description to port, every template assignment, every client-specific integration (GA / GA4 / GTM, reCAPTCHA, Nitropack cache). We implemented each row as written. Where the sheet had a value, that value landed on the new site. Where it didn’t, we flagged it back to the agency. No “creative interpretations” shipped.

The principle behind this is simple: on a rebuild, the spec is the contract between the agency and its client. A dev team’s job is to protect that contract, not to edit it.

3. Crawl-based verification, not “looks fine to me”. Before DNS cutover, we ran Screaming Frog on the old production site and the staging rebuild side-by-side. Status codes, broken links, redirect chains, meta-tag differences — every delta reconciled against the agency’s spec. A second crawl after go-live confirmed every internal link resolved on the live domain.

4. 48-item launch checklist, closed before handoff. Seven categories: Design, Functionality, Content, SEO & Analytics, Responsive, client-specific integrations, and a 12-step Domain & DNS migration to WP Engine. Nothing shipped until each line was signed off. Cross-device QA on Chrome / Firefox / Safari / Edge and six viewports (1920 / 1280 / 1024 / iPad / mobile portrait / mobile landscape). The contact form (Gravity Forms) tested end-to-end with a real submission.

Working under the 19-day window meant the meta verification had to be a separate formal pass, not an afterthought. Every meta title and description was checked against the original — blog posts with missing descriptions flagged and filled, capitalisation preserved per the agency’s spec — before the build moved to DNS cutover. The 19 days held because the meta pass ran in parallel with late-stage QA, not after it.

Results

Metric Outcome
Spec fidelity — redirects 80 / 80 content URLs redirected, as specified
Spec fidelity — meta data 81 / 81 meta titles and descriptions placed, as specified
Spec fidelity — templates 10 / 10 templates built and applied site-wide
Launch checklist 48 / 48 items signed off before cutover
Timeline 19 days, delivered on schedule
Effort 50h / 50h 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 (6 of 12 flagged; 6 were end-client-blocked or out of agency scope)
Handoff Site live on WP Engine on the scheduled cutover day, no downtime
Site status, one year later drhardt.com still live, still indexed by Google

The outcome, restated plainly: the agency’s spec was implemented as written, inside the quoted hours, on the scheduled cutover day. A year on, the build remains in production.

Operational Integrity at handoff

Pre-handoff parity review surfaced missing meta descriptions on blog posts and mismatched meta titles across all pages — both logged as High-priority items in the Issues Backlog and resolved through a dedicated fix pass before the agency saw the final staging build. Pre-handoff QA ran through Site Checker — see our QA discipline for the categories and the fail-zero gate. The agency’s own QA layer — their tools, their process — ran post-handoff and surfaced issues into the shared backlog for our fix loop until they signed off.

Process

Phase Duration Outcome
Brief & estimation 1 day Agency spec reviewed; 50h quoted and agreed
Development ~13 days Full site rebuilt across 10 templates
Internal QA & review 2 days 12 issues logged; all agency-scoped work closed
Spec verification 1 day Meta and redirect matches reconciled against sheet
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 19 days rather than the sum of individual phases.

Team

Delivery team

  • Nikita Tumasevic — lead developer (full site build and template system)
  • Pavel Sazhin — QA fixes and meta-data implementation
  • Anton Hersun, — project lead (estimation, agency-side communication, sign-off)

The agency stayed the visible vendor; we stayed invisible to the end client throughout cutover and migration. All decisions on URL preservation and redirect strategy belonged to the agency; our role was implementation fidelity to the spec they delivered.

For agencies considering a white-label WordPress build

This pattern fits agencies that arrive with a Google Sheets workbook — sitemap, template map, redirect rules, and a launch checklist — and a staging environment already provisioned on WP Engine or Kinsta. If your workflow looks like that, send the workbook. We will read it for spec gaps, surface any redirects or meta fields that need attention before build starts, and return a fixed-hours estimate within 24 hours. No cost, no obligation to proceed.

Request a spec review →

Don't have a spec yet? Send a one-paragraph description — we'll come back with the questions worth asking. Send a description →


— Pre-handoff QA gate

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.

Core settings verificationpass
Content & SEO surface auditpass
URL structure integritypass
Content-language sanitizationpass
Menus & widgets auditpass
Original-vs-rebuild content diffpass
Multi-resolution screenshot capturepass
xaver.pro · 2026 White-label · Agency not named
Scroll to Top