63-URL Dental WordPress Rebuild, Shipped to Spec in 19 Days — White-Label Delivery for a US Marketing Agency
63 URLs rebuilt in Reno NV across 6 Elementor Pro templates — delivered in 19 days and 82 hours, spec-faithful, 65 QA issues resolved pre-cutover.
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
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
| Field | Value |
|---|---|
| End-client industry | Healthcare — Family & Cosmetic Dentistry |
| End-client | White Pine Family Dental (Reno, NV) |
| 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 — 63 URLs across 6 templates: homepage, about/team, services (restorative, preventative, cosmetic), patient information, blog, contact |
| Timeline | 19 days (12 Dec 2024 – 31 Dec 2024), on schedule for the rebuild delivery |
| Effort | 82 hours against an 82-hour estimate — no overrun on the rebuild phase |
| Team | 5 specialists (62h dev · 20h dynamic content · balance across QA and management) |
| Tech Stack | WordPress · Elementor Pro · WP Engine · Rank Math · ACF · 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 — 63 URLs rebuilt, 6 templates applied, 49-item launch checklist closed, 65 QA issues resolved |
| Retained engagement | Further refinement rounds across the next 13 months — dynamic content implementation, broken-link fixes, design-issue updates, website refresh, and templated design development — each delivered in additive sprints inside the same agency relationship |
| Engagement cadence | 53 agency-raised issues · all closed by handoff |
| Review rounds | ≈10 review rounds across the 19-day calendar window |
| Launch checklist | 49 items, signed off before cutover |
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.
Risk context. When a rebuild preserves the URL architecture but replaces the underlying stack — same slugs, new Elementor build, new dynamic features — the failure mode is invisible to a casual review. The homepage loads, the contact form works, the service pages render. But the patient-education library’s category filter might not load the correct posts after cutover. A meta title might shift by one word. A breadcrumb might reference the staging domain. These are not catastrophic failures; they are silent degradations that surface only when a patient clicks through from a search result and finds the wrong content. The agency was hedging against exactly that: a dev partner that validates the visible pages but not the dynamic behaviour underneath.
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
| Metric | Outcome |
|---|---|
| Spec fidelity — URLs rebuilt | 63 / 63 URLs rebuilt on the same slugs, as specified |
| Spec fidelity — redirects | 4 / 4 redirect requirements implemented as 301s |
| Spec fidelity — templates | 6 / 6 templates built and applied site-wide |
| Launch checklist | 49 items reviewed and signed off before cutover |
| QA backlog (original) | 12 / 13 items closed as Completed |
| QA backlog (current) | 53 / 53 items closed as Completed |
| Dynamic content | Patient-education library with category-filtered post loading implemented and verified |
| Timeline (rebuild phase) | 19 days, delivered on schedule |
| Effort (rebuild phase) | 82h / 82h estimate — no overrun on the rebuild |
| Responsive verification | Zero layout issues across 4 browsers × 6 viewports |
| Internal QA | All agency-scoped backlog items closed before handoff |
| Site status | Live on WP Engine at https://www.whitepinefamilydental.com/ — verified April 2026. |
| Retained engagement | Further refinement rounds across 13 months — dynamic content fixes, design updates, website refresh, and templated design development — each delivered in additive sprints inside the same agency relationship |
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
| Phase | Duration | Outcome |
|---|---|---|
| Brief & estimation | 1 day | Agency spec reviewed; 82h quoted and agreed |
| Development | ~13 days | Full site rebuilt across 6 templates on WP Engine staging; dynamic content block implemented |
| Internal QA & review | 3 days | 65 backlog items logged by the agency across two waves; all closed |
| Spec verification | 1 day | Meta and redirect matches reconciled against sheet; crawl confirmed |
| 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, 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
On a dental rebuild, the content inventory carries the agency’s search equity, not the design. For a single-location practice with deep patient-education content; for a multi-location group with shared provider pages — the risks are the same in kind. Meta titles will shift without notice. Content filters will stop matching the right articles. Breadcrumbs and schema will reference the staging environment. Form connections to the agency’s CRM will fail silently.
The question to ask a dev partner before committing is not “can you rebuild the pages?” — it is “how exactly will you guard the meta map, the filter logic, and the form connections?”
Send us a current production URL, a draft redirect map if you have one, or your design files. We will audit the meta map, test the dynamic filters, and return a fixed-hours quote. Free review, fixed quote in hours.
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.