76-Page Family Dentistry WordPress Build in 130 Days — White-Label Delivery for a US Marketing Agency

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 49-item launch checklist, all closed before the site went live on WP Engine.

The 96-row original-site crawl informed the build from the first issue; the two-track QA backlog structure — a separate SEO Issues track and an Account Manager Issues track — ensured 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. We worked inside the WP Engine setup they already owned, built the pages in Elementor, and routed every form 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. And the whole way through: keep clear of the practice’s own channels, hand any unclear point back to the agency, and never freelance a call on copy, imagery, or how the menus were laid out.

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). The sitemap row told us which template each page belonged to, and that’s the template it got — not a single page was assembled by hand off-system.

2. Spec followed line-for-line — with the original-site crawl as content-fidelity baseline. Hours were budgeted row by row in the workbook for the core build issues — 41h on the primary build, 9h on project management, and separately tracked time for the content and fix rounds. Sitting alongside those numbers was an Original Site Backup (SF) tab: a 96-row Screaming Frog export holding the H1 text and meta data for every indexable page the existing site had. We read that tab as the target to hit — a rebuilt page’s H1 and meta description were expected to match the crawl unless the agency said otherwise. 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.

Put plainly, on a same-domain build the crawl baseline binds us every bit as much as the hours figure does. Build the pages while ignoring the crawl and you get a site that photographs well and then fails the agency’s QA 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). We signed off the 49-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 — across both Pre-Migration and Post-Migration phases before the production go-live.

The 96-row Screaming Frog crawl was the fixed reference 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 49-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. Before any of that reached the agency, the build went through Site Checker on our side — how we run QA sets out the categories and the standard we keep: nothing leaves with a finding still open. Once it was in the agency’s hands, they ran their own review and logged findings into the shared backlog, which our fix loop cleared until sign-off.

Process

The phases ran into one another: content updates and the live-fix round landed while both QA backlogs were still open. That overlap is why the calendar reads 130 days and not the figure you’d get by adding the phases up.

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)

Project management and every word that went to the client stayed on the agency’s side from start to finish. When the practice took delivery, it was the agency’s name on the work; our build team was nowhere in the handoff.

For agencies commissioning a white-label WordPress build