236-URL Multi-Practice Oral Surgery WordPress Build

Client (end user): Legacy Oral Surgery — Union City, NJ (consolidated multi-practice presence)
Engagement: White-label development for a US marketing agency
Delivered: May – August 2025 · 90 days · 103 hours

The Craft of a Build

236 URLs across 12 templates, built for a two-domain oral-surgery consolidation on Kinsta — the workbook carried 302 sitemap rows with per-row hour estimates tracking a 103-hour engagement, and the redirect map reconciled 349 unique URL pairs from two acquired practice domains folded into a single new brand at legacyoms.com.

This case study is a record of that consolidation build — delivered for a US marketing agency in the oral-surgery segment, where two acquired practice sites collapsed into a single multi-location brand on a new domain.

Snapshot

The Brief

A US marketing agency, retained by the Legacy Oral Surgery group as it brought two acquired practices — formerly trading at unioncityoralsurgerygroup.com and elizabethoralsurgerygroup.com — onto a single new brand at legacyoms.com, handed us a Google Sheets workbook with a sitemap of 302 rows, a 12-template Figma library, a 39-item launch checklist, and a pre-populated issues backlog. The build sat on the agency’s Kinsta environment; the page builder was Elementor; the design source was Figma.

The ask was a single-phase build with a multi-source redirect tail. First, build out 236 unique URLs — landing, services, doctors, locations, patient hub, blog corpus, plus default-template supporting pages — into the agency’s 12 standard templates. Then reconcile the two legacy domains’ worth of internal links and 301-mapping against the workbook’s redirect tabs, close the SEO and account-manager issue backlogs in parallel, and sign off the launch checklist before the cutover. Throughout, remain outside the end-client-facing loop, surface ambiguity back to the agency, and do not improvise design or SEO decisions.

How We Did It

1. Twelve templates, 236 pages, one build pipeline. Legacy’s pages spread across the agency’s standard dental template library with three additions for the consolidation pattern: Home, About, Services Lander, Service Page (the heaviest — 88 service pages), Doctor Profile (4 doctors), Contact Us, Locations Lander (multi-location index), Patient Hub, Aesthetic Lander, Blog Lander, Blog (the second-heaviest — 128 blog posts), and a Default Template that caught 10 supporting pages. We extended the library with those three templates rather than building the consolidation pages outside the template system, so every location, hub, and lander page inherited the same component library as the core brand pages. Each page was built on its assigned template from the sitemap row; no page was hand-rolled outside the template system, and the 128-post blog corpus was migrated row-by-row through the same pipeline as the structural pages.

2. Spec followed line-for-line — including the per-page Hours Estimated column. The agency’s workbook carried an Hours Estimated value for every row in the 302-row sitemap. We implemented against that value. The shape of the budget matched the shape of the work: 13h on the Home template (the heaviest single page), aggregate 89.5h spread across the 128-post Blog template (mostly content-import time, not bespoke layout), 19.8h on the 88 Service Pages, and a small fixed budget per Doctor Profile and Default page. The 75-hour dev quote was the row-sum of the build-touched rows; the remaining 28h covered QA, project management, and post-launch fixes.

The principle is the same as on any pre-costed build: the workbook is the contract, and the dev team’s job is to deliver inside the row-level budgets, not to re-open the pricing conversation page by page. On a 236-URL multi-practice consolidation that discipline matters more, not less, because the cost of letting any one row spill is the cost of two backwards stress-tests, not one.

3. Internal-link redirect reconciliation across 349 unique URL pairs from two legacy domains. The redirect work was sourced from two workbook tabs. The Sitemap tab carried a Redirect-After-Launch flag and a status column on every legacy → legacyoms.com row; that produced 288 unique pairs. A separate redirect-map tab (Sheet8) carried the body-link audit from both elizabethoralsurgerygroup.com (60 rows) and www.unioncityoralsurgerygroup.com (57 rows) — one row per old-path hyperlink discovered in scraped body content. Because the audit tab was unnamed and the redirect mapping arrived as two independent sources rather than a pre-reconciled list, our team manually cross-checked every body-link row against the live legacy sites to catch pairs where the scraped URL no longer resolved or the destination had been updated in the workbook sitemap. After deduplication against the Sitemap tab the redirect-map tab added 61 net-new pairs, for a combined 349 unique URL-to-URL pairs. All 290 sitemap-side redirects closed with status ✅ Redirect OK before handoff; the body-link audit was applied through the same redirect table, so each old URL — whether at the page level or referenced inside another page’s body — resolved to its new home under legacyoms.com.

4. Two parallel QA loops, one launch checklist. Issues were tracked in two agency-side backlog tabs — the main Issues Backlog (152 rows, priorities 01. Highest through 04. Low, surfaced by the dev team and AM together) and a separate AM Issues Backlog (55 rows, the account manager’s targeted review of the staging build, screenshot-flagged). Of those 207 items, 107 / 152 closed as Completed in the main backlog (40 carried to QA, 3 To Do at the time of launch, 2 Info-Needed waits on the end client) and 50 / 55 closed as Completed in the AM backlog (3 To Do, 1 Info-Needed, 1 in QA). The 36-row launch checklist — Design, Functionality, Pre-Migration, Post-Migration columns — closed behind both backlogs. Eight hours of post-launch fixes (location-page layout, QA-sheet updates, content rows) ran inside the same engagement under follow-on tickets.

Working across two independent redirect sources — the Sitemap tab’s 288 pairs and the Sheet8 body-link audit’s 117 rows from both legacy domains — meant deduplication came before any redirect could go live. The cross-check added 61 net-new pairs that neither source carried alone, and catching those before cutover was what kept the predecessor brand URLs from surfacing as 404s after go-live.

Results

The outcome, restated plainly: two acquired oral-surgery practice domains collapsed into a single multi-location brand on the agency’s Kinsta environment, inside the 103-hour quoted budget. 236 unique URLs shipped across 12 templates, 349 redirect pairs reconciled across both predecessor domains, two QA backlogs worked down to agency-acceptance levels and the launch checklist closed before cutover.

Operational Integrity at handoff

URL-structure hygiene carried the pre-handoff QA load on this consolidation build — the Issues Backlog opened with an 01. Urgent directive to search-and-replace both legacy domains («Don’t forget about www version too»), backed by 21 High-priority items flagging body links still pointing to the old site and 20 High-priority 404 findings across blog and service pages; all cleared before staging was released. 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 — the redirect-reconciliation work began before every build-phase QA item had closed, and post-launch follow-ons ran in parallel with the agency’s own client-acceptance window. The 90-day calendar reflects that overlap rather than the sum of individual phases.

Team

Delivery team

• Nikita Tumasevic — lead developer across the build, the consolidation redirect logic, and post-launch fixes
• Pavel Sazhin — QA iterations, staging-site review, scope estimation
• Anna Polunina — late-phase development support (location pages, layout 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