WordPress Rebuild
Replacing a heavy page-builder site with a code-first custom theme — 36 native Gutenberg blocks, a sitewide search REST endpoint, /llms.txt for AI crawlers, schema-rich markup, and an editor experience that mirrors the frontend.
The previous site sat on a generic page-builder theme — Elementor, Yoast plugin soup, and dozens of third-party assets. The home page pulled 325 network requests and transferred 5.9 MB before the visitor scrolled. Mobile navigation was broken. Schema was bolted on by plugins and frequently duplicated. The editor experience punished anyone who tried to actually write a page.
Six decisions that replace the page-builder stack
Native Gutenberg, no page builders
Every block is registered through the WordPress block API — no Elementor, no Divi, no shortcode soup. Cleaner markup, predictable updates, no vendor lock-in.
Editor mirrors the frontend
Each custom block ships PHP render + matching editor preview via ServerSideRender wrapped in <Disabled>. Writers compose pages while seeing the real layout — not an abstract form.
Schema-first markup
MedicalProcedure, FAQPage, Person, Review[], AggregateRating, VideoObject, BreadcrumbList — emitted via wpseo_schema_graph filter. Explicit deduplication so Yoast and our emitter never collide.
Server-rendered navigation
Header is PHP, not JS — ~30 hub and treatment links are visible to Bing, accessibility scanners, and LLM crawlers from the first byte.
Sitewide search as a REST endpoint
Custom /wp-json/db/v1/search returns 4 buckets (treatments, concerns, articles, topics) with synonym support. Object-cached for 5 min, auto-invalidates on save_post / edited_term.
AI-friendly out of the box
/llms.txt and /llms-full.txt expose the site index in the emerging plain-text convention for Anthropic, OpenAI, and Perplexity crawlers. Cached for an hour.
36 blocks built on the WordPress block API
Each block is styled in the editor to match how it looks on the frontend — editors see the real layout while writing. Below: the most-used blocks across the live site — each preview carries its live page count and any structured data it emits.
What the blocks actually look like
Blocks that emit structured data carry a JSON-LD badge — schema is wired in at render, not bolted on by a plugin.
Plus 25 more — section-nav helpers, hub navigators (path-router, concern-router, face-zone-explorer), cross-sell strips, CTA bands, and content scaffolds.
The theme around the blocks
Custom templates
single-treatment, single-enhancedcategory (hub), single-enhancedcategory-tag, single (blog), archive, page-home-front, page-medical-aesthetics, page-price-list — each thin, with heavy work in /parts.
New CPTs
treatment (flat-URL /{slug}/), enhancedcategory (decision hubs), review (admin-only, tagged by methods/concerns for auto-pull into reviews carousel).
Taxonomies powering auto-hubs
treatment_methods, treatment_concerns, skin_types, topics — plus admin UI for sort order and short hub intro term-meta.
Mu-plugins
Lightweight CPT registration, 301 redirects, ACF auto-sync for brand-cards, NSF schema override (WebPage → CollectionPage), tag→hub redirects.
Navigation variants
Three nav variants auto-picked from menu structure: simple link, simple dropdown, mega menu (rail + grid). Mobile: slide-in right drawer with <details> accordions and a sticky Book button.
Feedback funnel
Standalone db-feedback plugin: 5★ routes to Google reviews, lower scores capture comment + email to a custom table for follow-up.
Before / After, captured the same way both times
Desktop 1440×900, cold cache, no throttling. Old theme and post-migration (same domain) captured in Chrome after a full-page scroll — so every lazy-loaded image, tracking pixel, and downstream asset is included. Same URL, same browser, same conditions — only the theme under the hood differs.
The most-trafficked page
The new home added a Google Map, more hero images, and a full tracker stack (GA4, GTM, Cloudflare Insights, booking widget) — and still ships −41% transferred and −23% resources versus the old theme. DCL −95%, Load −87%. A caching-worker rewrite trimmed bytes and requests further.
The money page — heavy media
Treatment pages are the heaviest in the catalogue — hero photos, FAQ, schema, video. The rebuild still drops Transferred −73% and Load −84%. A WebP-on-demand pipeline (next pass) will trim Transferred another 30–50%.
The biggest reduction in the study
The hub is where the old stack’s overhead is most visible — the page-builder tooling loads its full asset payload even on a content-light orientation page. The rebuild ships only what the hub actually uses.
Lab scores, three pages, two devices
Lighthouse 13.0.2. Gauges use the official Lighthouse palette so they read instantly — green is Good, amber Needs Improvement, red Poor. This is the standard Lighthouse anyone can re-run locally in Chrome DevTools.
Home
Four 100s on the money page. The last SEO holdout — the uncrawlable-link check — closed on the follow-up pass. Best Practices climbed from 73 with the third-party trim.
Treatment · PDO Thread Lift
Four 100s on the heaviest money page in the catalogue. Performance 95 → 100, Accessibility 91 → 100 after the touch-targets and link-semantics pass, Best Practices 73 → 100 from the third-party trim. LCP 1.4 → 0.5 s.
Hub · Injections
Four 100s — clean sweep. Google Lighthouse fires its own confetti animation only when all four categories are perfect, and this page unlocks it. The page-shape we design toward for the rest of the catalogue.
Home
Four 100s on mobile Slow 4G — the last card to sweep the board. Fixing the hero image srcset closed the final Perf points. LCP 6.4 → 1.8 s (−72%), TBT 800 → 40 ms (−95%). Every page-device combination in the study now runs a clean 4×100.
Treatment · PDO Thread Lift
Four 100s on the heaviest money page in the catalogue — mobile Perf unlocked by a hero-image preload, then Accessibility (contrast + touch targets) followed. LCP 5.3 → 1.6 s (−70%, deep in Good), TBT down to 40 ms.
Hub · Injections
Four 100s on mobile — the first mobile card in the study to sweep the board. LCP 5.2 → 1.1 s (−79%), FCP and LCP effectively tied at 1.1 s, TBT down to 40 ms. The A11y contrast fix landed and unlocked this card entirely.
The whole study, in four numbers.
Across three pages and two devices, the rebuild does one thing consistently — it gets out of the way. Less code, lighter payload, cleaner schema. Every regression on the page is named and explained — every win is real.
Lab is a simulation. This is what people actually felt.
Lighthouse is lab. Cloudflare RUM is real users, on their actual devices and networks. This is what Google's CrUX database also captures — and what shapes the SEO ranking signal for Core Web Vitals. 30-day window across real visits.
p75 page load · 30-day trend
The bar under the chart is the CWV rating over time. The site sits in orange ("Needs Improvement") for the first ⅔ of the month, then flips to green ("Good") on Sun 21 Jun — the day the booking widget went lazy + GTM was cleaned up. Three days later p75 drops below 1.5 s with no spikes.
By geography & device · p75
The slow rows on the right side of the chart — Singapore, China, India, Windows — are small samples on far-from-edge networks or older hardware. That’s connectivity, not the rebuild. The numbers that actually describe your customers are US, Mexico, iOS, and Linux.
Why this is stronger than Lighthouse
Lighthouse simulates one device on one connection at one moment. RUM aggregates thousands of real sessions — old phones, slow Wi-Fi, cold caches, every combination. The numbers you see here are what your customers actually experience.
What Google does with these numbers
Chrome ships these measurements to Google’s CrUX dataset. CrUX feeds the Core Web Vitals signal in Search ranking. The greener the CWV bar, the stronger the ranking lift — visible in a 28-day rolling window.
Writing shouldn't feel like fighting the tool
URL fields autocomplete inside a chosen CPT and auto-pull image + title + excerpt from the linked post. Image fields write the attachment's alt text into the block's target field so authors set alt once, not per block. Editors compose pages while seeing the real frontend layout.
The rebuild isn't cosmetic — the content engine ships more, faster.
Fewer assets means lower latency. Cleaner markup means stronger schema and better LLM crawlability. A real editor experience means doctors and content leads can publish without a developer in the loop. Concrete impact numbers will land here once measured.
What the founder says.
I paid less than I got back — and the investment had paid itself off within a couple of months. Every metric grew. And so did our citations and brand recognition.
You scrolled this far for a reason.
You’re asking yourself the same questions every business owner asks at some point. The difference is — there are answers, and they’re simpler than you think.
Stop guessing. Find out where your site actually stands.
Drop your URL and email. We’ll come back with a first read of how fast your site loads, what Google and AI crawlers actually see, and whether a rebuild would pay for itself. Faster than you think — and cheaper than you can imagine.