72-Page Dental WordPress Rebuild
72-page dental WordPress rebuild on WP Engine — 18-day core span, 58 hours, 71 redirects and meta descriptions matched to spec, 10-week retained tail.
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.
Client (end user): Pharr Road Dentistry — Dr. Keya Patel and Dr. Paul McDonald DDS, Atlanta, GA
Engagement: White-label development for a US marketing agency
Delivered: March 2025 · 18-day core build with 10-week retained tail · 58 hours · no scope creep on original spec
The Craft of a Rebuild
Seventy-two pages of a dental practice website rebuilt as individual visual reproductions — each page matched to the original design, not collapsed into generic templates, across an 18-day sprint on WP Engine. The agency owned the URL map and the meta-data spec; our team reproduced every page block for block, comparing staging against the original with a visual diff tool before cutover.
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 (Dental) |
| End-client | Pharr Road Dentistry (Dr. Keya Patel and Dr. Paul McDonald DDS, Atlanta, GA) |
| 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 | 72 URLs migrated as individual original-design reproductions, with 17 specialty service pages, blog archive, and booking integration |
| Timeline | 18-day core build (27 Dec 2024 – 14 Jan 2025), with retained fix-and-refinement cycle through March 2025 |
| Effort | 58 hours — no scope creep on original spec |
| Team | 2 specialists (46h dev · 12h 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 — 71 redirects, 71 meta titles, 70 meta descriptions, 50 launch checklist items |
| Retained engagement | 7 further refinement rounds across the next 10 weeks — homepage fixes, 404 cleanup, pre-launch issues, booking-link updates, staff headshots, and widget corrections — each delivered in additive sprints inside the same agency relationship |
| Engagement cadence | 12 agency-raised issues · 11 of 12 closed by handoff (74-day active span, 2025-01-13 – 2025-03-27) |
| Review rounds | ≈4 review rounds |
| Per-ticket effort | 9 internal Redmine tickets · median 20m / P75 20m per ticket |
| Launch checklist | 54 items, signed off before cutover |
The Brief
Pharr Road Dentistry operated an established WordPress site with a broad specialty footprint — seventeen service pages covering everything from dental implants and Invisalign to sleep dentistry and TMJ treatment — plus a busy blog archive and integrated booking flow. The agency had already produced the sitemap, audited the meta data, and specified the design reproduction. Our job was to rebuild the site on WP Engine as a visual replica of the original, page by page, without collapsing the bespoke layout into generic templates.
The spec we received was a Google Sheets workbook with six tabs: a full sitemap mapping old URLs to new staging paths, repeating content blocks, template reference, settings, a 54-item launch checklist, and an issues backlog. We were asked to stay outside the client-facing loop, reproduce every design decision as written, and flag any data inconsistencies back to the agency. The agency stayed the visible vendor; our team remained invisible to the end client throughout cutover and migration.
The risk the agency was hedging against was not SEO collapse — they had that handled. It was the dev shop that would treat a rebuild as a one-and-done launch, missing the data rot that accumulates after cutover: wrong phone numbers in footers, fake buttons that never linked anywhere, third-party copyright lines left behind, archive pages that clutter the crawl. On a site with seventy-two pages and a long post-launch fix cycle, the real test is not whether the homepage loads on day one.
Risk context. On a rebuild of this scale, the risk surface does not close at launch — it extends across the weeks that follow, as edge cases that passed cutover quietly begin to surface: stale third-party integrations, images that 404 on secondary pages, booking-system links that reference a scheduler the practice no longer uses. The risk is not the launch itself — it is the accumulated noise that remains after launch: wrong phone numbers in footers, fake buttons that never linked anywhere, third-party copyright lines that should have been removed, archive pages that clutter the crawl. Each of these surfaced in actual post-launch fix rounds for this project — the deprecated booking links, the third-party footer copyright, and the unlinked social icons each required separate cleanup tickets outside the original sitemap. On a site with dozens of service pages and a retained engagement running for months, the real test is not whether the homepage loads, but whether every page is still correct three months later. The agency hired us because the rebuild had to stay clean under sustained attention.
How We Did It
1. Design-faithful reproduction, page by page. The original site carried a bespoke design language that the agency wanted preserved exactly — not templated, not reinterpreted. Rather than forcing the layout into reusable templates, we rebuilt all 72 pages as individual visual reproductions, matching the original design block for block:
- Homepage — hero, trust signals, and service overview
- Specialty service pages — 17 individual treatment pages (implants, veneers, Invisalign, sedation dentistry, and more)
- Reviews page — patient testimonial integration
- Blog archive and posts — article grid and individual post layouts
- Contact page — location, form, and booking integration
72 pages, each reproduced to match the original. Future design edits on the agency’s side are managed per page, preserving the bespoke visual identity.
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 design assignment, every client-specific integration (CallRail, Google Analytics 4, reCAPTCHA, live chat, NitroPack, footer copyright verification). 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. All decisions on URL preservation and redirect strategy belonged to the agency; our role was implementation fidelity to the spec they delivered.
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. The crawl also surfaced ~800 extraneous archive pages that were cleaned from the index before handoff.
4. 50 launch checklist items, closed before handoff. Seven categories: Design, Functionality, Content, SEO & Analytics, Responsive, client-specific integrations, and a 7-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).
Nine issues across 74 days — core build plus booking-link updates, 404 cleanup, homepage fixes, and staff headshots, each delivered in its own sprint against the same agency relationship. The retained cadence meant defects that surfaced in production had a clear path to resolution, not a negotiation about whether they were in scope.
Results
| Metric | Outcome |
|---|---|
| Spec fidelity — redirects | 71 / 72 content URLs redirected, as specified |
| Spec fidelity — meta data | 71 / 72 meta titles and 70 / 72 meta descriptions placed, as specified |
| Spec fidelity — templates | Original Design reproduced across all 72 pages |
| Launch checklist | 50 / 50 items signed off before cutover |
| Timeline | 18-day core build, with retained tail through March 2025 |
| Effort | 58h — no scope creep on original spec |
| Responsive verification | Zero layout issues across 4 browsers × 6 viewports |
| Internal QA | All agency-scoped issues closed before handoff (13 of 13 flagged; 0 remaining) |
| Handoff | Site live on WP Engine, no downtime |
| Site status, one year later | pharrroaddentistry.com still live, still indexed by Google |
| Retained engagement | 7 further refinement rounds across the next 10 weeks — homepage fixes, 404 cleanup, pre-launch issues, booking-link updates, staff headshots, and widget corrections — each delivered in additive sprints inside the same agency relationship |
The outcome, restated plainly: the agency’s spec was implemented as written, inside the quoted hours, with all agency-scoped issues closed. A year on, the build remains in production.
Operational Integrity at handoff
The pre-handoff parity diff ran across all 70 URLs — original vs staging — and surfaced two defect categories before the agency saw the build: slug mismatches (/services/ instead of the original /specialty/ path prefix) and a third-party copyright line (© Copyright 2025 GrowthPlug, Inc) in the footer that was not on the original site and had to be stripped before handoff. 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; 58h quoted and agreed |
| Development | ~12 days | Full site rebuilt as 72 individual page reproductions |
| Internal QA & review | ~4 days | 13 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 18 days rather than the sum of individual phases.
Team
Delivery team
- Nikita Tumasevic — lead developer (full site build and design reproduction)
- Anton Hersun, xaverPRO — project lead (estimation, agency-side communication, sign-off)
Agency-side project management and SEO strategy remained with the partner agency throughout. Our team was invisible to the end client.
For agencies considering a white-label WordPress build
This engagement started with a 6-tab sitemap workbook and an 18-day core build; the retained relationship that followed ran for ten weeks, closing booking-link updates, headshot uploads, and archive cleanup as individual sprints. If that model fits your pipeline — a spec-led build followed by per-issue refinement — send the workbook and we will return a fixed-hours quote on the core build within 24 hours. No cost. No obligation to proceed.
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.