Dental Website Redesign — Multi-Page Adobe XD-to-Elementor Pro, White-Label for a US Marketing Agency
A multi-page dental website redesign from Adobe XD to Elementor Pro — ~15 pages built, 16 tracked issues resolved, 60 hours across a 124-day engagement.
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 →
Redesign multiple pages against the agency Figma. Draft-first delivery; principal post-review round; launch only after sign-off.
The Craft of a Website Redesign
A dental practice redesign that opened as a single homepage task — two Adobe XD files, one for the homepage and one for additional pages — and accumulated fifteen pages and twelve follow-on issues over four months. The additions arrived one at a time: a Results gallery, service-page copy from a Google Drive folder, H1 and meta updates from a spreadsheet tab. We treated all sixteen issues as a single continuous engagement, not a sequence of disconnected requests.
Snapshot
| Field | Value |
|---|---|
| End-client industry | Healthcare — General Dentistry |
| End-client | Club K Dental (dental practice, Missouri) |
| Engagement | White-label dental website redesign for a US marketing agency specialising in local-business websites |
| Project Type | Multi-page Adobe XD-to-Elementor Pro redesign |
| Scope | ~15+ pages — homepage, About Us, Blog, Contact Us, Doctor’s Page, Financing, Dental Services lander, individual service pages, Your First Visit, Dental Technology, New Patient, Results gallery, Patient Resources, plus ongoing content additions |
| Timeline | Core build: ~25 days (1–26 Apr 2025); full engagement with follow-on content: ~124 days (Apr–Aug 2025) |
| Effort | ~60 hours — development, QA, and post-launch content additions across 16 issues |
| Team | 3 specialists (lead developer + QA + project lead) |
| Design handoff | Adobe XD mockups (agency-owned; URLs withheld — agency design IP) |
| Tech Stack | WordPress · Elementor Pro · WP Engine · Site Checker (xaverPRO QA plugin) |
| Build mode | Design-faithful — each page built from the Adobe XD reference; per-page content supplied by the agency |
| Delivered | Full dental practice site redesigned and live at clubkdental.com — homepage, service pages, results gallery, and ongoing client edits shipped across 16 tracked issues |
| Review rounds | ≈9 review rounds across the 25-day calendar window |
The Brief
A US marketing agency managing a dental client in Missouri needed the existing WordPress site redesigned to match a new Adobe XD brief. The brief covered the homepage and a full set of supporting pages: About Us with a doctor bio, a Blog lander, Contact, a Financing page, a Dental Services lander with individual service sub-pages, a Your First Visit page, a Dental Technology page, a New Patient page, and a Patient Resources section. The agency also planned a Results gallery showing before-and-after treatment photography.
The staging environment was already provisioned on WP Engine. Our job was to build each page in Elementor Pro against the approved Adobe XD frames, integrate the content the agency supplied via Google Docs, and maintain consistency as the scope expanded with post-launch additions. The ask was concise: match the design on every page, stay outside the end-client-facing loop, and treat each new request as part of the same engagement rather than a disconnected ticket.
Risk Context. A redesign that starts as a single-page task and quietly absorbs a full site’s worth of follow-on work carries a specific risk: not that any one page fails, but that the fifteenth page drifts from the design language of the first. When an agency commissions a “homepage” build that turns into a multi-page refresh, the dev partner that treats each new page as an isolated ticket risks inconsistency in spacing, typography, and CTA placement across the surface. The protection against this is to hold one engagement open — the same team, the same reference file, the same QA check for every issue, whether it is the homepage or a preventive-dentistry content addition three months later.
How We Did It
1. Adobe XD-to-Elementor Pro, page by page. We built the homepage and each supporting page in Elementor Pro against the approved Adobe XD frames. Natalia Bogatel led the core build, working through the homepage, About Us, services lander, contact, and financing pages in sequence. Nikita Tumasevic handled the additional pages pass — individual service pages, the Results gallery with before-and-after photography, and the post-launch content additions from the agency’s Google Drive folders. Because Elementor Pro was already installed on the WP Engine staging site, the build slotted into the existing infrastructure without introducing new dependencies.
2. Content integration per agency-supplied docs. The agency provided per-page content in Google Docs and Google Sheets — one document per page type, detailing copy, headings, and CTA structure. Content was applied to the correct Elementor blocks per the design. The individual service pages required the most judgement — each carried distinct procedural copy (amalgam mercury removal, ozone therapy, same-day CEREC crowns, all-ceramic implants, fluoride-free cleanings) that had to be formatted consistently within the same service-page template. The agency did not supply all page content upfront — individual service-page copy arrived in separate documents and folder uploads across successive Redmine issues, requiring several content-integration passes rather than a single insertion.
3. Post-launch content additions tracked as part of the same engagement. After the core homepage and supporting pages shipped in late April, the agency continued to request additions: missing content blocks, a Results gallery with ten before-and-after photos, service-page content from a shared folder, H1 and meta-description updates from a Google Sheets tab, client edits, and sitemap XML adjustments. Rather than opening a new project, we tracked each request as a follow-on issue in the same Redmine project — 12 additional issues beyond the initial four — keeping the same developer and QA context.
4. QA rounds before each handoff. Internal QA ran with Pavel Sazhin on every issue before it moved to “Sent, awaiting response.” The QA surface expanded as the site grew: early issues focused on homepage fidelity against the Adobe XD, while later issues verified that new service-page content matched the existing template, that the Results gallery displayed correctly across viewports, and that sitemap XML changes did not break the live index.
16 issues across 124 days, each passing through the same QA gate — ‘to test’, then Pavel’s review, then ‘ready to send’ before it moved to the agency. Running every issue through that one gate is what kept the fifteenth page consistent with the first: same reference file, same QA surface, whether the issue was the homepage build in April or a preventive-dentistry content addition in August.
Operational Integrity at handoff
On this staging build, QA ran on every ticket before it moved to “Sent, awaiting response” — the two core issues (#444 homepage, #445 additional pages) each passed through an explicit QA status gate, with URL structure and permalink routing for the /dental-services/ sub-pages verified against the agency’s sitemap spreadsheet before those tickets closed on Apr 26. Pre-handoff QA ran through Site Checker — see how we run QA for the categories and the no-open-issues bar a ticket had to clear. Post-handoff, the agency ran its own checks, and we worked every item it flagged through to sign-off.
Results
| Metric | Outcome |
|---|---|
| Site redesign | Shipped — Adobe XD applied in Elementor Pro across homepage and all supporting pages |
| Build mode | Design-faithful — no visual decisions made outside the brief; deviations flagged to agency before implementation |
| Pages delivered | ~15+ pages — homepage, About Us, Blog, Contact, Doctor’s Page, Financing, Dental Services lander, individual service pages, Your First Visit, Dental Technology, New Patient, Results gallery, Patient Resources, plus ongoing additions |
| Post-launch additions | Results gallery with before-and-after photography, service-page content from agency folders, H1/title/meta updates, client edits, sitemap XML adjustments |
| QA rounds | Internal QA by Pavel Sazhin on every issue before handoff |
| Timeline | Core build: ~25 days (1–26 Apr 2025); full engagement: ~124 days (Apr–Aug 2025) |
| Effort | ~60 hours — distributed across design implementation, content integration, QA, and post-launch additions |
| Team | 3 specialists — no dedicated strategist, no design lead (agency-owned), no SEO lead (no migration scope) |
| Site status | Live at https://clubkdental.com/ — verified June 2025. |
Plainly put: we applied the agency’s Adobe XD brief to every page type on a dental practice site, built and populated the Results gallery, integrated all post-launch content additions, and the site stayed live and serving at the verified production URL.
Process
| Phase | Duration | Outcome |
|---|---|---|
| Brief & estimation | ~3 days | Adobe XD reviewed, page inventory confirmed, Elementor Pro and WP Engine staging verified |
| Core build | ~3 weeks | Homepage and all supporting pages built against Adobe XD; per-page content applied from agency docs |
| Internal QA & handoff | ~1 week | Pavel Sazhin QA pass on all core pages; issues logged and resolved before agency handoff |
| Post-launch additions | ~3 months | Results gallery, service-page content, meta updates, client edits, sitemap adjustments — tracked as follow-on issues in the same engagement |
Phases overlap — post-launch additions began while core QA was still closing, and the engagement ran as a single continuous thread rather than a discrete handoff-and-restart. The 124-day calendar reflects the full span from first issue open to final follow-on issue close.
Team
Delivery team
- Natalia Bogatel — lead developer (homepage and core pages, Elementor Pro build, post-launch content additions)
- Nikita Tumasevic — additional pages and service content (individual service pages, Results gallery, content from agency folders)
- Pavel Sazhin — QA and project coordination (internal QA rounds on every issue, agency communication, issue tracking)
- Anton Hersun, xaverPRO — project lead (estimation, agency-side sign-off, coordination across 16 issues)
Agency-side project management, design, and client communication remained with the partner agency throughout. Every email Club K Dental sent went to the agency; our name appeared on no ticket the practice ever saw, and no developer of ours corresponded with them. All design decisions were owned by the agency; our role was design fidelity across every page and consistent handling of each follow-on addition.
For agencies commissioning a white-label WordPress redesign
On a dental practice redesign that opens as a single-page task and absorbs a whole project scope, the agency risk is visual drift — not on the first page but on the tenth. For this practice — a single-location practice adding service pages incrementally; for others — a multi-location group refreshing simultaneously. Typography and spacing from the initial build will quietly diverge from pages added months later. A “visual only” brief can leave URL slugs unmanaged, dropping rankings the agency secured. Component-library tokens stop at the homepage layout, leaving archive sidebars and widgets in the legacy skin.
The question to ask a white-label dev partner before signing is not “can you redesign a single page?” — it is “how exactly will you enforce a shared design system and redirect map across a phased build?”
Send us your current URL inventory or your design files. We will audit every page type against the design language, flag the points where legacy templates and redirect gaps pose the highest risk, and return a fixed-hours quote.
Don't have a spec yet? Send a one-paragraph description — we'll come back with the questions worth asking. Send a description →
draft page
This case is multi-page. The same discipline applies to single-page.
Homepage Redesign and Multi-Page Redesign share the same core methodology — Figma-led, tool-ecosystem-matched, draft-first. Scale differs; discipline does not.