134-URL Dental WordPress Rebuild
A 134-URL dental WordPress rebuild: 100 blog posts migrated across 11 templates in 14 days with zero hours of overrun.
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.
Client (end user): Lotus Dental Associates — General Dentistry, Fort Mill, SC
Engagement: White-label development for a US marketing agency
Delivered: June 2025 · 14 days · 31 hours · on schedule, no overrun
The Craft of a Rebuild
34 structural pages and 100 blog posts of a dental practice rebuild to an 11-template Figma spec — 134 URLs migrated, verified, and handed off in 14 days with zero hours of overrun. The agency owned the sitemap and the redirect list; we owned per-page execution and the trailing-slash-at-every-URL discipline the spec demanded.
This case study is a record of one such rebuild, in which the agency owned the strategy and we owned the execution.
Snapshot
| Field | Value |
|---|---|
| End-client industry | Healthcare — General Dentistry |
| End-client | Lotus Dental Associates (Fort Mill, SC) |
| Engagement | White-label WordPress build for a US marketing agency specialising in local-business websites |
| Project Type | WordPress rebuild with Elementor Pro on Kinsta |
| Scope | Full site — 34 structural pages + 100 blog posts migrated |
| Timeline | 14 days (4 Jun – 18 Jun 2025), on schedule |
| Effort | 31 hours against a 31-hour estimate — no overrun |
| Team | 4 specialists (24h dev · 4h QA · 3h PM) |
| Tech Stack | WordPress · Elementor Pro · Gravity Forms · Kinsta · Yoast · Screaming Frog · Site Checker (xaverPRO QA plugin) |
| Content parity check | Original-vs-rebuild content diff cleared before handoff — no missing copy, no broken internal links, no structural drift |
| Delivered | Spec followed line-for-line — 134 URLs migrated, 11 templates, 40-item launch checklist |
| Engagement cadence | 105 agency-raised issues · all closed by handoff |
| Review rounds | ≈4 review rounds across the 14-day calendar window |
| Per-ticket effort | 6 internal Redmine tickets · median 10h / P75 31h per ticket |
| Launch checklist | 39 items, signed off before cutover |
The Brief
The agency had a retained dental client — a general dentistry practice in Fort Mill, SC — whose existing WordPress site needed a rebuild on Kinsta with a modern template system. The agency had completed the strategic work: a Google Sheets workbook mapping every current URL to its new path, every meta title and description to carry forward, a full template list, and a launch checklist covering pre- and post-migration validation.
The ask was specific. Take the spec as given; rebuild the site on Elementor Pro; hand it back ready for cutover. Remain outside the client-facing loop. Implement the SEO decisions as written. Deliver within the quoted hours.
One dimension of the spec made this rebuild more demanding than the page count suggests: the site carried a legacy blog archive of 100 posts, alongside 34 structural pages, with 86 legacy URLs marked for deletion and 16 URLs requiring path changes. Each deletion and each restructure carried its own redirect obligation. The spec covered all of it. Our job was to implement each row exactly as written.
Risk context. When a rebuild migrates a content archive of 100 blog posts alongside 30+ structural pages, the risk is not in the page build — it is in the URL continuity. A single missed redirect on a blog post that already has inbound links or social shares breaks the reader’s journey without showing an error on the new site itself. The agency’s spec covered 86 legacy deletions and 16 URL restructures; our job was to make sure every one of them landed exactly where the sheet said it should.
How We Did It
1. Template-first build. Rather than rebuilding 134 URLs one by one, we collapsed them into 11 reusable templates and fit every page into them:
- Homepage, About Us, Contact Us — the brand-defining pages
- Services Lander — powering the services directory
- Service Page — a single reusable template powering all 26 individual service pages
- Doctor Page — the principal dentist bio
- Blog Lander + Blog — the content archive and individual post template (100 posts)
- Default Template — supporting pages (accessibility statement, privacy)
- Request an Appointment — the conversion page
- Smile Gallery — the practice-specific before/after template
Eleven templates, whole site delivered. Future edits on the agency’s side live in one place per page type.
2. Spec followed line-for-line, from the agency’s sheet. The agency handed us a Google Sheets workbook: every URL to migrate with its target path, every meta title and description to port, every template assignment, every client-specific integration. We implemented each row as written. Where the sheet had a value, that value landed on the new site. Where it didn’t, we flagged it back to the agency. No “creative interpretations” shipped.
The principle behind this is simple: on a rebuild, the spec is the contract between the agency and its client. A dev team’s job is to protect that contract, not to edit it.
3. Crawl-based verification, not “looks fine to me”. Before DNS cutover, we ran Screaming Frog on the old production site and the staging rebuild side-by-side. Status codes, broken links, redirect chains, meta-tag differences — every delta reconciled against the agency’s spec. The 100-blog-post migration meant checking permalink continuity across the entire archive, not just the homepage and service pages. A second crawl after go-live confirmed every internal link resolved on the live domain.
4. 40-item launch checklist, closed before handoff. Seven categories: Design, Functionality, Content, SEO & Analytics, Responsive, client-specific integrations, and a DNS migration to Kinsta. Nothing shipped until each line was signed off. Cross-device QA on Chrome / Firefox / Safari / Edge and six viewports (1920 / 1280 / 1024 / iPad / mobile portrait / mobile landscape).
The trailing-slash rule across every internal link — «Всегда слэши на конце, если их нет, должен быть редирект» per the agency’s guidelines — was the constraint that ordered the 100-blog-post migration before any visual iteration could close. Redirect discipline on 86 deletions and 16 restructures had to clear before the build could be called clean.
Results
| Metric | Outcome |
|---|---|
| Spec fidelity — URLs migrated | 134 / 134 pages and posts migrated, as specified |
| Spec fidelity — path changes | 16 / 16 URL restructures implemented as specified |
| Spec fidelity — legacy deletions | 86 / 86 legacy URLs handled per the agency’s deletion map |
| Spec fidelity — templates | 11 / 11 templates built and applied site-wide |
| Launch checklist | 40 items signed off before cutover |
| Timeline | 14 days, delivered on schedule |
| Effort | 31h / 31h estimate — no overrun, no scope creep |
| Responsive verification | Zero layout issues across 4 browsers × 6 viewports |
| Internal QA | All agency-scoped backlog items closed before handoff |
| Handoff | Site live on Kinsta on the scheduled cutover day, no downtime |
| Site status | lotusdentalassociates.com still live, still indexed by Google |
The outcome, restated plainly: the agency’s spec was implemented as written, inside the quoted hours, on the scheduled cutover day.
Operational Integrity at handoff
Pre-handoff QA caught two categories on the staging build: a trailing-slash rule violation across internal links on the services lander — flagged as a High Bug and fixed before agency review — and a privacy-policy page copied from another practice, carrying the wrong jurisdiction (California instead of South Carolina) and a third-party email, both corrected as part of content-language sanitization. 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
| Phase | Duration | Outcome |
|---|---|---|
| Brief & estimation | 1 day | Agency spec reviewed; 31h quoted and agreed |
| Development | ~10 days | Full site rebuilt across 11 templates; 100 blog posts migrated |
| Internal QA & review | 2 days | SEO and CX backlog items addressed; all agency-scoped work closed |
| Spec verification | 1 day | Meta and redirect matches reconciled against sheet; crawl confirmed |
| Delivery & DNS cutover | 1 day | Site live on Kinsta, no downtime |
Phases overlap (QA ran alongside late development), which is why the calendar timeline is 14 days rather than the sum of individual phases.
Team
Delivery team
- Nikita Tumasevic — lead developer (full site build, template system, and blog migration)
- Pavel Sazhin — QA fixes and post-launch issue resolution
- Anna Polunina — development support on structural pages and blog archive
- Anton Hersun, xaverPRO — project lead (estimation, agency-side communication, sign-off)
The agency stayed the visible vendor; we stayed invisible to the end client throughout cutover and migration. All decisions on URL preservation and redirect strategy belonged to the agency; our role was implementation fidelity to the spec they delivered.
For agencies considering a white-label WordPress build
If your agency delivers a Google Sheets workbook — sitemap, redirect map, template assignments, and a launch checklist — send it. We will review the redirect obligations and the template-to-page assignments for execution risk, identify any rows that need a decision before build starts, and return a fixed-hours estimate within 24 hours. No cost. No obligation to proceed.
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.