65-Page Multi-Specialty Dental Template Customisation in 41 Days — White-Label for a US Marketing Agency
65-page multi-specialty dental template customisation delivered in 41 days — 5 templates, 25 URL restructurings, 45-item checklist signed off, 40 hours.
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 Template Customisation
65 pages of a multi-specialty dental template customisation on the agency’s Template 6, plus 25 service URL restructurings from flat legacy paths into a five-branch sub-specialty taxonomy. The URL architecture work ran as a dedicated parallel Redmine task — #165 (link audit pass) — verified independently before the main handoff, because a misconfigured redirect on any of the 25 moves would have dropped established patient search paths.
Snapshot
| Field | Value |
|---|---|
| End-client industry | Healthcare — Multi-Specialty General Dentistry |
| End-client | Dental Associates of Jersey City (Jersey City, NJ) |
| Engagement | White-label template customisation for a US marketing agency specialising in local-business websites |
| Project Type | WordPress template customisation (agency’s Template 6 on WP Engine) |
| Scope | 65 pages — homepage, services lander, 42 service pages, 22 supporting pages (about, contact, appointment, gallery, staff, educational resources); plus 132 legacy blog posts migrated |
| Timeline | 41 days (23 Jan – 5 Mar 2025), on schedule |
| Effort | 40 hours — development, QA iterations, and project management |
| Team | 6 specialists |
| Templates | 5 reusable templates — Homepage, Service Page, About Us, Blog, and Default Template — applied across the 65 pages |
| Tech Stack | WordPress · Elementor · WP Engine hosting · Rank Math SEO · Gravity Forms · Site Checker (xaverPRO QA plugin) |
| QA discipline | 45-item launch checklist signed off across pre-migration and post-migration phases; post-launch fix rounds for brand-colour consistency and client content corrections |
| Engagement cadence | 5 agency-raised issues · 3 of 5 closed by project close |
| Review rounds | ≈3 review rounds across the 41-day calendar window |
| Launch checklist | 45 items, signed off before cutover |
The Brief
A US marketing agency delivered us a WP Engine deployment target and their branded Template 6 configuration for Dental Associates of Jersey City. Design approval, hosting setup, and the content plan were already settled on the agency’s side. The gap they needed filled was a build team that could hold the template to their spec across a site far larger and more tangled than a typical single-specialty dental practice.
Dental Associates of Jersey City operates across five clinical areas — general dentistry, periodontics, endodontics, orthodontics, and cosmetic dentistry — each with its own procedure sub-pages. The legacy site had accumulated those pages over time under flat, top-level slugs (/arestin, /biopsy, /bridges, /crowns, and so on). The agency’s template required reorganising those URLs into a proper sub-specialty tree: /periodontic/periodontal-disease/arestin/, /dental-implants/bridges/, /endodontic/apicoectomy-surgery/, and so on across 25 affected pages.
The ask was operational. Apply the template, execute the URL restructuring, handle the 45-item launch checklist, and raise QA findings back to the agency’s shared workspace. Don’t close items without sign-off.
Risk context. A multi-specialty practice with an existing patient base and 25 legacy URLs being moved from flat paths into a sub-specialty taxonomy carries a specific failure mode: the restructuring looks correct on staging but silently drops redirect coverage on the paths that an established dental audience has bookmarked or that third-party directories already reference. A
/bridgespage that redirects to/dental-implants/bridges/on staging will break only if the redirect is misconfigured at DNS cutover or if internal links still resolve to the old slug. With 25 URL changes spanning five sub-specialty branches — periodontics, endodontics, orthodontics, dental implants, and cosmetic dentistry — the scope for a missed redirect or a lingering internal link using the old flat path was non-trivial. That is the risk the agency was hedging against, and it is what the link-verification task and the full Screaming Frog crawl comparison documented in the checklist were designed to catch.
How We Did It
1. Figma-as-contract, template-as-canvas. Template 6 gave us the structural skeleton each page sat on. From there we matched it to the agency’s spec one page at a time: a default layout that already lined up was left alone, and anything the spec drew differently we adjusted to fit. No design call started with us.
2. URL restructuring as a first-class deliverable. Reorganising 25 service page URLs from flat paths into a five-branch sub-specialty taxonomy was not a cosmetic change — it was the structural backbone of the new site. Each affected page required both the new destination URL and a redirect from the legacy slug. We kept URL restructuring as a separate track from template customisation rather than merging them into a single build task, because each redirected path needed independent verification — a misconfigured redirect on any of the 25 restructured URLs would have broken the practice’s established search presence. The link-verification task ran as a parallel workstream during the main build, ensuring the internal link map was consistent before handoff rather than corrected post-launch.
3. QA cycle at template-customisation scale. Customise a template cleanly and you don’t get there by building once and reviewing once. Over the course of this project, the 45-item launch checklist covered browser compatibility, navigation integrity, contact form notifications, image and video rendering, meta-data accuracy, Screaming Frog crawl comparisons against the original site, redirect verification, and multi-viewport responsive checks. The checklist ran in two phases — pre-migration and post-migration — with each item signed off independently before the site was cleared for launch. The initial handoff shipped with brand colours applied per-page rather than globally because the template had been customised for a PPC landing page before the site-wide deployment was scoped — this gap surfaced post-launch as a dedicated colour-propagation task across all 65 pages.
4. Post-launch fix rounds. After the initial handoff, the agency surfaced two follow-on tasks through the shared issue backlog: a single-page brand-colour correction that expanded to a site-wide colour update, and a consolidated list of client-driven content corrections (practitioner credential updates, photo replacements, gallery scrolling behaviour, hours-of-operation accuracy, promotional copy). Each round was closed only after the agency’s reviewer confirmed the fix was complete.
5. Cross-device verification. We put each customisation through Chrome, Firefox, Safari, and Edge at desktop, tablet, and mobile widths. A given QA round looked only at the pages that round’s delta had touched — the way a build this many pages deep holds its coverage without grinding to a halt.
The link-verification track was what kept the 25 URL moves safe. Mid-build it became clear that redirect coverage needed its own workstream — not mixed into the main build ticket — so a dedicated link-audit pass ran in parallel and closed independently before the handoff. Without that separation, a misconfigured redirect on any of the five sub-specialty branches would have surfaced as a post-launch fix, not a pre-handoff check.
Operational Integrity at handoff
Pre-handoff QA centred on URL integrity — 25 flat-to-nested redirect moves across five sub-specialty branches ran as a dedicated parallel Redmine task to confirm every chain before submission. A site-wide brand-colour gap (template initially deployed in PPC single-page mode) surfaced post-handoff through the agency review and went through the fix loop. Pre-handoff QA ran through Site Checker — see our QA approach for the categories and the zero-defect bar we clear before a build leaves our hands. Once we handed off, the agency ran its own review and logged findings into the shared backlog, which we worked until they were satisfied.
Customisations stayed in the per-client overrides. We did not modify the agency’s shared Template 6 components.
Additional verifications documented in the workbook checklist:
– Screaming Frog crawl of the original site archived as baseline reference
– Screaming Frog crawl of staging compared against the original to confirm page/post URLs, title tags, and meta descriptions matched
– Internal links verified post-DNS cutover (staging URLs replaced with the live domain)
– Rank Math SEO settings verified
– Google Analytics / Tag Manager scripts confirmed in place
Results
| Metric | Outcome |
|---|---|
| Pages delivered | 65 — 1 homepage, 1 services lander, 42 service pages, 22 supporting pages (about, contact, appointment, gallery, dental staff, educational resources, testimonials) |
| Blog posts migrated | 132 blog posts migrated under the agency’s Blog template with URL preservation |
| Templates applied | 5 of 5 — Homepage, Service Page, About Us, Blog, Default Template |
| URL restructurings | 25 flat-to-nested URL moves across five sub-specialty branches, each with redirect coverage |
| Launch checklist | 45 items signed off (pre-migration + post-migration phases) |
| Timeline | 41 days (23 Jan – 5 Mar 2025), delivered on schedule |
| Effort | 40 hours against a 36-hour core estimate + 4 hours post-launch fix rounds |
| Team | 6 specialists |
| Hosting handoff | Live on WP Engine |
The upshot: we applied the agency’s Template 6 across 65 pages for a five-specialty dental practice, migrated 132 legacy blog posts with URL preservation, restructured 25 service-page URLs from flat paths into a sub-specialty taxonomy, and closed the engagement in 41 days inside 40 hours total.
Process
| Phase | Duration | Outcome |
|---|---|---|
| Brief & estimation | ~2 days | Template access confirmed, URL restructuring scope agreed, scope set at 36h |
| Template customisation + URL restructuring | ~2 weeks | Page-by-page template customisation; 25 URL moves with redirect map; link-verification task run in parallel |
| QA & launch checklist | ~1 week | 45-item checklist completed (pre-migration + post-migration); Screaming Frog crawl comparison; internal-link audit |
| Delivery (initial handoff) | Day 22 (2025-02-14) | Site closed as resolved on Redmine; agency received the build |
| Post-launch fix rounds | ~3 weeks | Brand-colour update across all pages; practitioner credential and photo corrections; gallery and hours-of-operation fixes |
Development and QA ran concurrently throughout — the link-verification task was opened as a parallel Redmine issue and closed independently before the main issue handoff.
Team
Delivery team
- Nikita Tumasevic — lead developer (template customisation, URL restructuring, Figma-to-layout mapping)
- Anna Polunina — developer (QA iterations, design verification, image sourcing)
- Evgeniy Karpov — developer (QA support, link verification)
- Alexey Melkov — implementation support
- Natalia Bogatel — developer (post-launch content corrections)
- Anton Hersun, xaverPRO — project lead (estimation, agency-side communication, sign-off)
Agency-side project management, design, hosting, and client communication remained with the partner agency throughout. Dental Associates of Jersey City knew only the agency it had hired; our team and its tickets never showed up in any conversation the practice took part in. All customisation requests came through the agency’s shared issue backlog. A fix round stayed open until the agency’s own reviewer signed off that the delta had been cleared.
For agencies with a branded template system
On a branded template system for a multi-specialty practice, the boundary between the shared template layer and the client-layer customizations is where delivery risk lives. For this practice — a multi-specialty group under a consistent template set; for others — a single-location deployment with page-level overrides. The risks are quiet: child-theme overrides break on the next vendor update, ACF schemas drift and shared modules disappear, brand tokens stop propagating into hardcoded fallbacks.
The question to ask a dev partner before committing is not “can you deploy the branded template?” — it is “how exactly will you audit the layer boundary so client customizations survive the next update?”
Send us the template source or template ID and your brand spec. We will map the override layer, check field schema alignment, 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.