63-URL Dental WordPress Rebuild

Client (end user): White Pine Family Dental — Family and Cosmetic Dentistry, Reno, NV
Engagement: White-label development for a US marketing agency
Delivered: December 2024 · 19 days · 82 hours · on schedule, no overrun

The Craft of a Rebuild

63 URLs across 6 templates, delivered to a spreadsheet spec — the rebuild of a Reno family dental practice included a patient-education library whose AJAX category-filter the native page builder could not deliver. We built the dynamic block from scratch against Elementor’s data layer and shipped the full 63-URL surface in 19 days, on an 82-hour estimate with no overrun.

This case study is a record of one such rebuild, in which the agency owned the strategy and we owned the execution. It also records something rebuilds at this scale tend to surface: an engagement does not always end at cutover. After the site shipped, the agency retained us through a 13-month tail of further refinement, refresh work, and templated design development. The discipline of the build is what made that retention possible.

Snapshot

The Brief

The agency had a retained dental-practice client — a family and cosmetic dentistry practice in Reno, Nevada — whose existing WordPress site needed a full rebuild on Elementor Pro. The agency had completed the strategic work: a Google Sheets workbook mapping every current URL to its rebuilt path, every meta title to carry forward, a full template list, and a 59-item launch checklist covering pre- and post-migration validation.

The existing URL structure was largely preserved: of 63 URLs, only 4 required redirect handling — the rest were rebuilt in place on the same slugs. The agency’s brief included an explicit dynamic-content requirement: a patient-education library with category-filtered post loading, implemented as a custom HTML/CSS/JS block. Elementor’s native content tools could not deliver the category-filtered loading the spec required — the library had to be built as a hand-coded solution with inline CSS and JavaScript, pulling content from dedicated posts via AJAX fetch. Our scope was to rebuild the full site, implement the dynamic content, and hand it back ready for cutover.

The risk here was not a complex migration — the URL surface was stable. The risk was a dev shop that would rebuild the pages accurately but miss the dynamic-content integration, or break the patient-education library’s filter behaviour during the staging-to-production transition. A family dental practice’s acquisition channel is local search; a rebuild that preserves URLs but breaks the content experience still erodes the practice’s search visibility.

How We Did It

1. Template-first build. Rather than rebuilding 63 URLs one by one, we collapsed them into six reusable templates and fit every URL into them:

• Homepage — the practice’s primary entry point
• About Us / Doctor Page — team and principal dentist bios
• Service Page — the heaviest template, applied across 38 service and treatment URLs spanning restorative dentistry (dentures, implants, crowns), preventative care (gum disease treatment, exams), and cosmetic dentistry (Botox, Invisalign, teeth whitening, veneers)
• Blog — content archive and individual post template
• Default Template — patient-information pages, legal pages, and utility content
• Contact Us — the conversion page

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

The agency had an existing live site, so the project started with a structural choice: build on a staging duplicate or work in drafts on production. We chose a full staging environment on WP Engine — the live site stayed untouched during the build, and the cutover was a single event once every template passed verification.

2. Spec followed line-for-line, from the agency’s sheet. The agency handed us a Google Sheets workbook: every URL to rebuild with its target path, every meta title and description to preserve, every template assignment, and a 59-item launch checklist. 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. The 4 redirect rows in the workbook were verified individually: each old path landed on the correct new destination without chains or collisions. A second crawl after go-live confirmed every internal link resolved on the live domain.

4. 65 QA issues, all closed before handoff. The agency’s Issues Backlog tabs tracked two waves of QA: the original backlog (12 / 13 items closed) and the current backlog opened during the retained tail (53 / 53 items closed). Issues ranged from H1 wording mismatches and broken blog links to layout width corrections and mobile slider behaviour. Cross-device QA on Chrome / Firefox / Safari / Edge and six viewports (1920 / 1280 / 1024 / iPad / mobile portrait / mobile landscape).

Working under the 82-hour ceiling meant the dynamic-content implementation had to be resolved early — Elementor couldn’t deliver the category-filtered patient-education library, so the team wrote the AJAX block from scratch before the final pages were in build. Making that call in week one rather than at handoff is what kept the 19-day timeline intact.

Results

The outcome, restated plainly: the agency’s spec was implemented as written, inside the quoted hours, on the scheduled cutover day. The relationship continued for 13 months because the build held its shape under post-launch attention, not because it was patched into shape after the fact.

Operational Integrity at handoff

The parity diff run against the original site caught two issues a “looks fine” pass would have missed: a transposed letter in a slug (/patient-information/sheduling/ rebuilt instead of /scheduling/) and a broken booking button whose anchor pointed to #about-adress rather than the correct contact-page section — both found and fixed before the agency saw the 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

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, template system, and dynamic content)
• Natalia Bogatel — developer (footer, team page, and retained-tail updates)
• Pavel Sazhin — QA and post-launch fix implementation
• Timur Arbaev — developer (templated design development and retained refinement rounds)
• Anton Hersun, xaverPRO — 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