Case study Healthcare, Australia and New Zealand
Clinic location pages rebuilt around search intent
Clinic location pages sat on a mix of legacy templates and often missed what patients were searching for. Local enquiries could drift to clearer pages elsewhere, and updates had to be made one page at a time.
- Client
- A multi-clinic healthcare group
- My role
- Owned the location-page architecture, from search-intent audit to rollout
- Disciplines
- Information architecture, Technical SEO, Content architecture, Landing pages
Client anonymised. Details are generalised and contain no confidential figures.
Context
Each of the group's clinics in Australia and New Zealand has its own location page on its market's website. For a patient looking for care nearby, that page is often the first one they land on and the place they decide whether to get in touch. The pages had been created over time on whichever template was current, then edited one at a time as details changed.
Constraints
- Clinics offer different services, so modules had to cope with missing content cleanly.
- Clinic details had to come from one source rather than being retyped on each page.
- Existing location URLs had to keep working so pages with search history weren't lost.
- Healthcare copy could make no claim a clinic couldn't back.
- An AU clinic's page could never show NZ details, or the reverse.
Diagnosis
I audited the location pages side by side, recording what each one contained and which template it used. Then I grouped the searches that lead people to a clinic page by what the person is trying to do. Laying one over the other showed where pages and intent had drifted apart.
- No shared structure. Pages sat on a mix of legacy templates. Contact details and opening hours appeared in a different place on each, and on some they were missing or out of date.
- Intent buried. Someone searching for a clinic in their area wants to confirm a few practical things fast: that it’s close, that it treats their problem, when it’s open and how to book. Pages often opened with general copy about the group and left those answers further down.
- Near-duplicate copy. Much of the body text had been copied between locations with only the suburb changed. That gives search engines little reason to rank a page for its own area, and patients little reason to trust it.
- Dead ends. Location pages rarely linked to the doctors who practise there or the treatments offered there, and those pages rarely linked back.
Enquiries were what this put at risk. A patient who can’t confirm the basics quickly goes back to the search results, and the next result may well be a competitor. Upkeep was slow as well: changing a phone number or adding a service meant finding and editing every affected page by hand.
Approach
I designed the page from the patient’s questions, not from any existing template. In the order patients tend to ask them:
- Is this clinic near me, and how do I get there?
- Does it treat what I need?
- Who would I see?
- When is it open, and how do I book?
Those questions set the module order. The call and booking actions also sit at the top, so a patient who has already decided doesn’t scroll for them.
Modules, not pages
Each question became a module with one job. Modules take structured clinic data instead of free text, so a page is assembled rather than written. A few rules kept them honest:
- A module with nothing to show hides itself rather than leaving a gap.
- The order is fixed, so each detail sits in the same place on every location.
- One module holds genuinely local information, such as parking or access notes, so pages differ where it helps the patient, not in boilerplate.
- Treatment descriptions live on treatment pages. Location pages summarise and link instead of carrying their own copy.
Pages that connect
Each location page works as a hub. It links to the doctors who practise there and the treatments offered there, and those pages link back to the locations that offer them. A locations index for each market sits above them all. Patients always have a next step, and search engines can follow the relationships rather than guess.
Implementation
A record for each clinic
I set up one record per clinic holding the facts the modules need: name, market, address, contact details, opening hours, services offered and the doctors who practise there. Modules read from that record and nothing else. The same record feeds the clinic’s structured data, so the markup and the visible page can’t disagree.
The module library
I built the modules as reusable template partials in plain HTML/CSS/JS, keeping script to a minimum. Each partial takes the clinic record and the market as inputs, so a shared module can’t show one country’s details on the other’s site. Layouts started at phone width and worked up from there.
Moving locations across
I built one reference page first and checked it in both markets, then moved the remaining locations across in batches. For each one I mapped the old content into the clinic record, kept anything genuinely local, dropped the copied boilerplate and kept the existing URL, redirecting it only where it had to change.
Before each batch went live I checked that:
- no module rendered empty or half filled
- every detail on the page matched the clinic record
- old URLs resolved to the right new page
- call and booking clicks fired the same GA4 events on every location, so locations can be compared like for like
Content editors got a short guide on adding a clinic and keeping its record current.
Outcome
Structural outcome: what changed in how the site works
Every location page is now assembled from the same set of modules, ordered by search intent and filled from a single source of clinic details. Changing a clinic's details or adding a new location is a content edit rather than a page build, and a fix to one module reaches every location at once. Location pages in both markets now answer the same questions in the same place.