62-Page Dental WordPress Build

Client (end user): Roman Dental Arts — Hackensack, NJ
Engagement: White-label development for a US marketing agency
Delivered: Mar – May 2025 · 53 days · 58 hours across build and content integration

The Craft of a Build

62 pages of a dental-practice WordPress build across five branded templates — 21 blog posts, 26 service pages — where the engagement’s signature discipline was not page construction but URL-path restructuring. 46 legacy paths under /procedures/ and /about/blog/ were flattened to a new hierarchy and verified against staging row by row, a reconciliation the agency’s workbook had not foreseen with a dedicated redirects tab. 58 hours, 53 days, no overrun.

This case study is a record of a build where the path reconciliation and blog migration were treated as part of the delivery scope, not an afterthought — a comprehensive-care dental practice in Hackensack, NJ, delivered for a US marketing agency specialising in local-business dental clients.

Snapshot

The Brief

A US marketing agency retained by Roman Dental Arts — a comprehensive-care dental practice in Hackensack offering cosmetic, restorative, family, oral-maxillofacial, and implant dentistry — handed over a Google Sheets workbook with a full URL map, a templates catalogue, a launch checklist, and a pre-populated Issues Backlog. The build ran on their WP Engine environment; the page builder was Elementor; forms ran through Gravity Forms.

The ask: build 62 URLs across 5 standard templates, restructure the URL paths to consolidate the previous /procedures/ and /about/blog/ hierarchies into flatter, cleaner paths, migrate 21 blog posts to the new path structure, and work down the agency’s issues backlog until the agency accepted the site. Shortly before launch, the agency relayed a client request for new procedure content across an additional set of service pages — a mid-engagement content block that arrived against a live launch date target.

Throughout, remain outside the end-client-facing loop; surface ambiguity back to the agency; do not improvise content, navigation, or URL structure decisions.

How We Did It

1. Five templates, 62 pages, one build pipeline. Roman Dental Arts’ pages spread across a compact, well-defined template library: Homepage, About Us (4 pages — main about, meet the doctors, meet the team, and office tour), Service Page (26 individual service pages across five care categories), Blog (21 migrated posts), and a Default Template (10 supporting pages including patient resources, testimonials, contact, and appointment request). 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 — including the per-page Hours Estimated column. The agency’s workbook carried an Hours Estimated value for each sitemap row. The blog corpus at 21 posts was the load-bearing row: blog content migration and path reconciliation across the /about/blog/ → /blog/ restructure drove the dev budget for that template more than the individual post count suggests. Service-page rows were estimated at lower hours per page once the template baseline was established.

The principle: on a build with a pre-costed sitemap, the workbook is the contract. A dev team’s job is to deliver inside the row-level budgets, not to re-price the blog row after the migration reveals how many posts carry legacy path references. We chose to absorb the blog-migration complexity inside the agreed row-level hours rather than request a re-estimate, because reopening a costed sitemap mid-build would have shifted calendar pressure onto the agency’s launch window.

3. URL path reconciliation across 46 unique pairs. The sitemap carried 62 rows in the Completed state. Of those, 46 pairs had differing Current URL and New URL values — reflecting the agency’s decision to flatten the /procedures/ service hierarchy and consolidate the /about/blog/ archive. We mapped each source path to its target path, set the internal-link redirects, and verified each pair in the workbook before handoff. All 46 pairs were tracked to resolved status before the launch checklist closed.

4. Mid-engagement procedure content integrated without schedule slip. Late in the engagement, the agency relayed that new procedure content was required across additional service pages — some of which were already built and in the QA queue. The content task was opened as a standalone Redmine issue, tracked with its own hours, and integrated against the live staging environment in a parallel thread to the QA backlog. Pages that received new content were returned to the QA queue for a second pass. The launch date was preserved.

5. Issues Backlog and pre-launch review, closed before go-live. Issues were tracked in the agency’s Issues Backlog (9 rows, all Completed before launch) and the AM QA of Staging Site tab. The 39-row checklist — Design, Functionality, Content, Pre-Migration, and Post-Migration columns — was signed off before the production go-live. The pre-launch review task confirmed the site was ready for the agency’s account manager to give final sign-off before cutover.

The blog-path conflict — posts at date-slugged URLs under /about/blog/ on the source, flattening to /blog/ on the build — had no dedicated redirects tab to bulk-map from; each of the 46 pairs had to be verified against staging in the sitemap Action column before the checklist could close. That row-by-row verification was what kept the URL path equity intact at handoff.

Results

Operational Integrity at handoff

During the pre-handoff QA pass, a duplicate-H1 structural defect was found in the “Related Procedures” block across service-page templates — the block heading was tagged as a second <h1> rather than a <div>, a template-level issue that would have affected every service page in the dental taxonomy. 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 — blog migration and path reconciliation ran alongside the service-page build, which is why the calendar is 53 days rather than the sum of individual phases.

Team

Delivery team

• Nikita Tumasevic — lead developer across build, blog migration, and fix phases
• Pavel Sazhin — project management and QA iterations
• Anna Polunina — developer support on service-page content integration and QA rounds
• Alexey Melkov — implementation support
• 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