KIME Performance Physical Therapy

The site for a sports physical therapy group across Northern California and Nevada, serving patients looking for a clinic and clinicians looking for training.

What they came with

Most KIME clinics do not have their own front door. A site sits inside a host facility — a university athletics building, an orthopaedic practice, a strength gym — so every location carries two names at once: the town a patient searches for, and the venue they actually walk into. The same practice also runs continuing education on a separate platform and takes clinical interns, so one navigation has to answer a patient looking for a clinic and a clinician looking for a placement. A front office maintains all of it, and it changes whenever a therapist moves site or a new host facility opens.

What the build had to do

Two records for one address

A venue record carries the host facility and the partnership behind it; a separate city page carries the clinical offer, the opening hours and the direct phone line. Both point at the same street address, and a venue can either stand as its own Gym Details page or resolve to the city page it belongs to.

Clinicians tagged to a site

Every therapist is a content record holding a portrait, a credential line, a biography and a site assignment. Those records build the full directory on the about page and the shorter roster on each city page, so moving someone between clinics is one edit rather than a hunt through templates.

One FAQ set, two audiences

The same FAQ record type answers billing, insurance and first-appointment questions on the patient page, and holds the graduate and undergraduate entries that drive the internship page. The template decides which subset a given page draws, which keeps two unrelated conversations in one editorial place.

A location page as a fixed sequence

Every city page runs the same order: hero with address, hours and phone, then services, approach, clinician roster, the host facility write-up, testimonials, price and booking. Opening a new site means filling a sequence and attaching the right people rather than designing a page.

Two booking paths on every page

A location page offers an enquiry form that reaches the front office and a direct link into the practice management system's own booking wizard. Both sit on the same page, and the form carries its own list of bookable locations so a request can be routed before any record exists.

Angled geometry as a system

A chevron cut runs through the navigation bar, the location cards, the clinician name plates and the call-to-action panels. It had to hold its proportion at card width and at full-bleed hero width, across photography that ranges from dark gym interiors to daylight track shots.

Technical detail

Custom theme beneath a page builder

The theme compiles Tailwind to one purged stylesheet and ships its display faces as font files from the theme directory. Elementor Pro sits above it for layout and theme-builder templates, set to write each page's CSS to a file under uploads instead of inlining it, and it loads its own Google Fonts with font-display: swap — the document stays small, at the cost of a regeneration step whenever a shared template changes.

Content types rather than duplicated pages

Locations, team members and FAQs are registered custom post types with Pods installed as the modelling layer, and each type gets its own set in the core sitemap index. The site assignment lives as a field on the person rather than as a second listing, so one record feeds the global directory, the per-city roster and the sitemap together.

Integration boundary at the record system

Scheduling and the patient portal run on Raintree under two of its own hostnames, messaging arrives as an iframed Weave widget, and the clinician education arm sits on a Kajabi subdomain. WordPress holds the marketing content and the first-contact enquiry; anything that reads or writes a patient record happens on the far side of that boundary.

Two cache layers, two lifetimes

The origin page cache returns HTML with a ten-minute max-age and must-revalidate, and Cloudflare passes the document through rather than holding it, while theme and builder assets carry a one-year max-age and are served from the edge. Hours, phone numbers and roster edits surface within one cache window without an explicit purge; the trade is that the origin is asked for the document far more often than a long-TTL setup would allow.