76-Page Family Dentistry WordPress Build

Client (end user): David Eskow, DDS Family Dentistry — Olney, MD
Engagement: White-label development for a US marketing agency
Delivered: Feb – Jul 2025 · 130 days · 57 hours across build and fix-and-feedback phases

The Craft of a Build

76 pages of a new Elementor build for a Maryland family dental practice, delivered against a 96-row Screaming Frog crawl — the live original was VPN-restricted, so the crawl served as the content-fidelity baseline for every page. The agency ran two parallel QA tracks and a 58-item launch checklist, all closed before the site went live on WP Engine.

This case study is a record of a build where a 96-row original-site crawl informed the build from the first issue, and where the two-track QA backlog structure — a separate SEO Issues track and an Account Manager Issues track — ensured that both the agency’s technical requirements and its client-facing quality bar were met before the site went live.

Snapshot

The Brief

A US marketing agency retained by David Eskow, DDS — an established family dental practice in Olney, MD offering cosmetic, preventive, restorative, and specialty services — handed over a Google Sheets workbook with a full URL map, a Screaming Frog crawl of the original site as a baseline tab, a templates catalogue, a launch checklist, and pre-populated QA backlogs. The build ran on their WP Engine environment; the page builder was Elementor; forms ran through Gravity Forms. The workbook included an 8-tab structure with a dedicated Original Site Backup (SF) tab — a 96-row Screaming Frog export providing H1 text, meta data, and structural signals for every page on the existing site. The crawl tab was a pragmatic substitute: the original live site was region-restricted during development, meaning our team relied on this export rather than direct browser access as the primary reference for page-level content fidelity.

The ask: build 76 URLs across 10 standard templates, treating the Screaming Frog crawl as a content-fidelity baseline for each page, populate 11 staff profile pages from agency-provided content, migrate 17 blog posts to the new template structure, add agency-sourced content updates across service pages, and work down two separate QA backlogs — a technical SEO backlog and an Account Manager’s client-facing review backlog — until the agency accepted the site. Throughout, remain outside the end-client-facing loop; surface ambiguity back to the agency; do not improvise content, photography, or navigation decisions.

How We Did It

1. Ten templates, 76 pages, one build pipeline. David Eskow’s pages spread across the agency’s full dental template library: Homepage, About Us, Contact Us, Services Lander (4 pages — cosmetic, preventive, restorative, and specialty dentistry), Service Page (24 individual service pages), Doctor Page (11 staff profile pages covering doctors, hygienists, and support staff), Blog Lander, Blog (17 posts), Blog Category (7 category index pages), and a Default Template (9 supporting pages including patient resources, insurance, payment options, and privacy policy). Each page was built on its assigned template from the sitemap row; no page was hand-rolled outside the template system.

2. Spec followed line-for-line — with the original-site crawl as content-fidelity baseline. The agency’s workbook carried an Hours Estimated structure for the core build issues: 41h for the primary build task, 9h for project management, and tracked hours for content and fix rounds. The workbook also included an Original Site Backup (SF) tab — a 96-row Screaming Frog export — providing H1 text and meta data for every indexable page on the existing site. That tab served as the fidelity target: each rebuilt page’s H1 and meta description should match the crawl output unless the agency explicitly changed it. We chose to anchor each page against the crawl data rather than rebuilding from workbook descriptions alone — because on a same-domain build without URL migration, the primary risk is content drift that looks correct on visual first pass but surfaces weeks later during the agency’s QA reconciliation.

The principle: on a same-domain build, the crawl baseline is as binding as the hours estimate. A dev team that builds the pages but ignores the crawl produces a site that looks correct visually but fails the agency’s QA pass on content accuracy.

3. Staff profile corpus — 11 pages built from agency-provided content. The Doctor Page template was the deepest part of the team-roster build: 11 profiles covering doctors, hygienists, certified dental assistants, and the practice manager. Each profile required custom content supplied by the agency. Mid-engagement, new client images were received and integrated across the live site in a dedicated update task, requiring the homepage and several profile pages to be revisited after the initial QA pass.

4. Content updates and staging edits absorbed without schedule slip. Two separate content tasks arrived mid-engagement: a content update round that brought new copy for service pages against a Screaming Frog parity spreadsheet the agency assembled, and a staging-edits round covering minor text adjustments and layout fixes. Both were absorbed as standalone Redmine issues with tracked hours and worked down in parallel with the QA backlogs. The live-fix round — urgent post-launch corrections flagged by the client — was similarly contained and closed before the AM Issues Backlog was finalized.

5. Two-track QA, both closed before handoff. Issues were tracked in two separate agency-side backlog tabs: the Issues Backlog SEO (14 rows, all Completed before handoff) and the AM Issues Backlog (14 rows, all Completed before handoff). The 58-row launch checklist — covering Design (browser compatibility, favicon, images and videos), Functionality (broken links, navigation, forms, social media), and Content (page migration, meta, structured data, sitemap) columns — was signed off across both Pre-Migration and Post-Migration phases before the production go-live.

The 96-row Screaming Frog crawl was the discipline that held both QA tracks together. The original site was VPN-restricted during development — the crawl tab was the only reliable fidelity reference per page — so anchoring H1 text and meta descriptions to its output before either backlog opened meant both the SEO track and the AM track were reviewing against the same baseline, not against what the page happened to look like.

Results

Operational Integrity at handoff

The QA load on this build ran across two parallel agency-side backlogs — 14 Issues Backlog SEO rows and 14 AM Issues Backlog rows — plus a 58-item launch checklist covering Design, Functionality, and Content across both Pre-Migration and Post-Migration phases; all three closed to zero before the site went live on WP Engine. 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 — content updates and live-fix rounds arrived while the QA backlogs were still open, which is why the calendar is 130 days rather than the sum of individual phases.

Team

Delivery team

• Nikita Tumasevic — lead developer across build, content integration, and fix phases
• Pavel Sazhin — project management and QA iterations
• Anna Polunina — developer support on content updates, staging edits, and QA rounds
• Evgeniy Karpov — developer support on live-fix round and image updates
• Anton Hersun, xaverPRO — project lead (estimation, agency-side communication, sign-off)

Agency-side project management and client-facing communication remained with the partner agency throughout. Our team was invisible to the end client.

For agencies commissioning a white-label WordPress build