46-Page Dental Template + 145-Post Blog Migration
xaverPRO delivered a 46-page dental template customisation with 145-post migration — agency Figma, 7 templates, content-artifact cleanup, 62 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
Forty-six pages of the agency’s branded dental template customised to a per-page Figma spec, plus 145 legacy blog posts migrated into the agency’s Blog Post template — all on WP Engine in 42 days. The staging environment arrived with content artifacts from prior template deployments: Cyrillic-language developer comments in the slider code and Lorem ipsum sections in Elementor widget data. Both were caught and cleaned before handoff.
Done right, this approach buys an agency consistency without the slow grind of a full custom build. Done loosely, it costs them more than that custom build would have: a dev partner who reads the Figma as a loose suggestion, trims the review passes, or quietly bends the template’s design system away from its rules hands back something the agency now has to unpick.
The QA profile below shows what that takes.
Snapshot
| Field | Value |
|---|---|
| End-client industry | Healthcare — General and Cosmetic Dentistry |
| End-client | Drs. Chin and Pharar Dentistry (Las Vegas, Summerlin, NV) |
| Engagement | White-label template customisation for a US marketing agency specialising in local-business websites |
| Project Type | WordPress template customisation (agency’s branded template + per-page Figma design on WP Engine) |
| Scope | 46 URLs — homepage, 3 about pages, 30 service pages, 10 utility pages (patient forms, savings plan, FAQ, finance, testimonials, podcasts, appointment request, privacy), contact, blog lander |
| Blog posts migrated | 145 posts carried over under the agency’s Blog Post template (URL preservation only — no SEO-equity claim) |
| Timeline | 42 days (11 Feb – 25 Mar 2025), on schedule |
| Effort | 62 hours across development, QA, project management, and fix rounds |
| Team | 5 specialists |
| Templates | 7 reusable templates provided by the agency, all applied across the 46 pages (Homepage · About Us · Service Page · Default Template · Contact Us · Blog Lander · Blog) |
| Tech Stack | WordPress · Elementor · WP Engine hosting · Figma-driven per-page design · Screaming Frog crawl · Site Checker (xaverPRO QA plugin) |
| QA discipline | Issues-backlog items reconciled (URL structure, Lorem-ipsum placeholders, image quality, mobile alignment) across a 49-item launch checklist; 301-redirect structure mapped across 36 redirected staging URLs |
| Engagement cadence | 6 agency-raised issues · all closed by handoff (1-day active span, 2025-04-01 – 2025-04-01) |
| Review rounds | ≈4 review rounds across the 42-day calendar window |
| Launch checklist | 49 items, signed off before cutover |
The Brief
A US marketing agency delivered us access to their WP Engine staging environment pre-loaded with their branded dental template, alongside a Figma design scoped per page for Drs. Chin and Pharar Dentistry. The agency had already handled client onboarding, content gathering, and hosting provisioning. The brief was to customise the template to the Figma, migrate 145 legacy blog posts into the agency’s Blog Post template, and deliver a site ready for agency QA and client review.
The ask was explicit: match the Figma, preserve the URL structure the agency had mapped in the workbook’s Sitemap tab, and surface any deviations to the agency’s shared issue backlog rather than resolving them unilaterally.
What the agency needed to protect was the integrity of their template across all the dental practices it serves. That protection starts by keeping per-project customisations inside per-client overrides — if a style change lands in a shared component, it propagates silently to every other site on the same template. Beyond template isolation, this project had a second category of risk: a template system that has served multiple clients accumulates content artifacts — placeholder copy, development-era URLs, and in this case, content-language elements that originated in the template’s development environment and must be cleaned from every client’s deployment before handoff. Site Checker’s content-language sanitization check across all Elementor data, menus, and widgets was the gate that confirmed the staging environment was free of those artifacts before we handed back to the agency.
Risk context. A branded template that has served multiple dental practices carries two categories of risk into every new deployment: per-client customisations that drift into shared components and propagate silently to every other practice on the same base, and accumulated content artifacts — placeholder copy, development-era URLs, content-language residue — that are not always visible through a surface browser inspection. Both risks were live on this engagement, and both required explicit gate checks before handoff.
How We Did It
1. Figma-as-contract, template-as-canvas. Two inputs governed every page: the Figma, which fixed what each page should look like, and the agency’s branded template, which supplied the structure underneath it. Reconciling them was the whole task. We walked the 46 pages one at a time. The template’s default layout stayed in place wherever it already landed on the Figma; we reached into the per-client layer only where the design called for something the default could not produce. Nothing on a page changed because we decided it should; the design call was always the agency’s.
2. Blog migration at scale alongside template customisation. Carrying 145 legacy blog posts into the agency’s Blog Post template is not a mechanical copy-paste. Each post had to land with URL preservation matching the agency’s sitemap, correct meta data, and functional internal links. Running the migration in parallel with the 46-page customisation meant any URL-structure decisions on the main site had to account for how the blog archive would resolve. The workbook’s Sitemap tab tracked 198 rows — the 46 live pages and 145 blog posts, with a 301 redirect sheet of 36 mappings that showed where the staging structure needed to redirect legacy paths to their correct destinations.
3. Content-artifact cleanup as a QA gate. A dental template that has been deployed across multiple practices accumulates artifacts from prior work: generic placeholder copy, off-brand images, and occasionally development-environment content that was correct for the template’s internal build process but wrong for any specific client. On this project, the QA pass identified Lorem ipsum placeholder copy embedded in a slider component and content-language residue that had carried through from the template’s shared component layer. These were cleaned before handoff — not flagged and left for the agency — because content-language issues in Elementor widget data are not always visible through a surface browser inspection. The Site Checker QA pass scanned across pages, posts, Elementor data, menus, and widgets to confirm the staging build was clean.
4. QA cycle to the agency’s issue backlog. Post-initial-build QA went through the agency’s shared issue backlog, with the agency flagging design deltas, URL issues, image quality concerns, and mobile alignment discrepancies for our fix loop. URL trailing-slash consistency was one finding that required a systematic fix across the staging environment — the agency’s sitemap spec had no trailing slashes on internal link targets, and the initial build introduced them. Corrected and confirmed before the site moved to agency handoff.
5. Cross-device verification. No round signed off until the layout held up at desktop, tablet, and mobile widths. The service-page template carried the heaviest load. It sat behind 30 of the pages, and the Figma loaded it with per-page imagery and section variants that each had to fall into place against the template’s responsive breakpoints.
The per-page Figma diff was what carried the build. Forty-six pages across seven templates gave the agency a repeatable QA surface; the Cyrillic comments in the slider code — carried from the shared template layer — only surfaced because the review went component by component, not page-wide.
Operational Integrity at handoff
QA caught two issues before handoff: Cyrillic comments in the slider’s template code, carried from the shared layer and cleaned before review, and trailing-slash URLs applied inverse to the sitemap spec, corrected across the 46-page staging site. Everything went through Site Checker before it left our hands. How we run QA covers the categories and why we hold a build with anything still open. Once the agency had the site, they ran their own pipeline and logged findings into the shared backlog, which we worked down until the build was theirs to accept.
Anything we touched stayed inside the per-client overrides. We left the agency’s shared template components untouched.
Results
| Metric | Outcome |
|---|---|
| URLs delivered | 46 — 1 homepage · 3 about pages · 30 service pages · 10 utility pages · 1 contact · 1 blog lander |
| Blog posts migrated | 145 posts into the agency’s Blog Post template with URL preservation |
| Templates applied | 7 of 7 reusable templates built and mapped across the 46 pages |
| Launch checklist | 49 items signed off |
| QA issues resolved | URL trailing-slash structure, Lorem-ipsum placeholder copy, image quality corrections, mobile alignment — all resolved before handoff |
| 301 redirect structure | 36 redirect mappings tracked and confirmed in the workbook’s 301 tab |
| Timeline | 42 days, delivered on schedule |
| Effort | 62 hours across development, QA, and fixes — within estimate |
| Team | 5 specialists |
| Hosting handoff | Live on the agency’s WP Engine template environment |
Where that leaves things: 46 pages and 7 templates carrying the agency’s Figma onto their branded base, 145 legacy blog posts moved across in parallel, the whole run landing inside 42 calendar days and inside the hours we quoted, with no content-language residue left in the build by the time it changed hands.
Process
| Phase | Duration | Outcome |
|---|---|---|
| Brief & estimation | ~3 days | Figma reviewed, WP Engine staging access confirmed, scope agreed (50h estimate) |
| Template customisation + blog migration | ~1 week | 46 pages customised to Figma; 145 blog posts migrated into Blog Post template |
| QA iterations (concurrent) | ~2 weeks | Agency backlog issues reviewed; URL structure, placeholder copy, image quality corrected |
| Fix rounds | ~1 week | Mobile alignment, image resize corrections, late-stage content additions |
| Delivery | Mar 2025 | Site confirmed clean on staging; handed to agency for final review |
Build and review never sat in separate boxes here. As soon as the first pages were up, the iteration started, and it kept going until the agency put its name to the final sign-off. That is how this kind of template work tends to run.
Team
Delivery team
- Vladimir Kozlov — lead developer (template customisation, Figma-to-layout mapping, blog migration)
- Nikita Tumasevic — developer (build continuation after Vladimir Kozlov’s lead phase)
- Anna Polunina — QA stage and issues-backlog verification
- Natalia Bogatel — fix rounds and late-stage content additions
- Anton Hersun, xaverPRO — project lead (estimation, agency-side communication, sign-off)
Design, hosting, content strategy, and the relationship with the practice all sat on the agency’s side and stayed there. We had no contact with Drs. Chin and Pharar Dentistry at any point; requests came to us as tickets in the agency’s shared backlog, and the name on the finished site was the agency’s, not ours. A round only counted as done once the reviewer on the agency’s side had checked the fix and waved it through.
For agencies with a branded template system
A branded template system shares code and content across every client deployment, which means a customisation meant for one practice can quietly alter the look and behaviour of every other. For this practice — a single location with standard branding; for others — a multi-site DSO network that needs strict isolation. The risks are quiet ones: client-layer overrides leak into the shared base, stale content or development-stage URLs survive the handoff, and the client’s editing experience breaks when the custom fields drift out of sync.
Before you hand the template to anyone, the question worth asking is not whether they can stand up a site for a new client. It is whether they can draw the per-client boundary tightly enough that an edit made for one practice never bleeds into another.
Send us the template source or template ID and your brand spec. We will audit the customisation boundary, trace the content artifacts that have carried over from previous builds, and map the hardcoded fallbacks where your brand system could stop propagating. 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.