63-URL Dental WordPress Rebuild, Shipped to Spec in 19 Days — White-Label Delivery for a US Marketing Agency

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 way we held the build to spec is what earned that retention.

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 49-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. When the agency needs to change something later, each page type has a single place to change it.

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 49-item launch checklist. We implemented each row as written. Any value the sheet carried showed up on the rebuilt site exactly as recorded. If a field came back empty, we raised it with the agency rather than guessing. No “creative interpretations” shipped.

There’s a straightforward rule underneath this: on a rebuild, the spec stands as the contract the agency made with its client. The development team is there to keep that contract intact, not to rewrite its terms.

3. Crawl-based verification, not “looks fine to me”. Ahead of the DNS cutover, we pointed Screaming Frog at both the old production site and the staging rebuild and compared the two crawls. We checked status codes, broken links, redirect chains, and meta-tag differences, reconciling each discrepancy against the agency’s spec. We verified the 4 redirect rows in the workbook individually: each old path landed on the correct new destination without chains or collisions. Once the site went live, a follow-up crawl confirmed that every internal link resolved on the production 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. QA spanned four browsers — Chrome, Firefox, Safari, Edge — and six viewports: 1920, 1280, 1024, iPad, mobile portrait, and 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 short version: we implemented the agency’s spec 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 we patched it 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 approach for the categories and the no-fails threshold the staging build had to meet. After handoff, the agency re-checked the build on its own stack, routing anything it found into the shared backlog for our fix loop until sign-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)

White Pine and its patients only ever dealt with the agency; we built and cut over the Reno site from behind that relationship, and our name never appeared in front of the practice. The agency made every call on URL preservation and redirect strategy; our part was building faithfully to the spec they handed us.

For agencies considering a white-label WordPress rebuild