How we run the clinic sites

Who changes what, how a change reaches a live site, and the guardrails that stop a small edit becoming a big problem.

Three kinds of change

ChangeWhere it happensWho
Wording on one clinic's page
opening hours, an offer, a paragraph		That clinic's repository, in its content filesMarketing team, or an agent on request
Design or layout
a new section, a fix to how pages look		The template, once. It then reaches every clinic as a pull requestAmy, or an agent
Text-level SEO requests
titles, headings, keywords		Raised as a request, applied in the clinic's content filesSEO provider requests, we apply
The one rule that matters. Never edit a template file inside a clinic's repository. The next sync overwrites it and the change silently disappears. If something in the design needs changing, change it in the template so all eleven clinics get it.

How a change reaches a live site

The change made on a branch Pull request what changed, and why Checks + review it builds, nothing else broke Merge to main Live rebuilds itself in about a minute
Nothing goes straight onto a live site. Merging is the moment of publication.

A pull request is simply a proposed change with a description, which someone reads before it goes live. It also gives us a record of why every change was made, and a one-click way back if a change turns out wrong.

When the template changes

A design change is made once and offered to every clinic. It never arrives unannounced.

  1. The change is made in the template and reviewed there.
  2. A sync job opens a pull request in each clinic's repository listing exactly which files change.
  3. We try it on one clinic first, check the site still looks right, then let the rest follow.
  4. The sync can only touch template files. It is blocked from a clinic's own content, photos and redirect map, so a sync can never overwrite a clinic's words.
Worth knowing. When we fixed the logo shrinking in the menu bar, the fix was made once in the template and both live clinic sites picked it up on their next sync.

Checks that run before anything ships

The site builds

If a page is broken, the build fails and nothing ships.

Every old address still works

Fails until every address from the old site is either rebuilt or redirected.

No duplicated wording

Fails if a page is still another clinic's copy with the names swapped.

House rules

No superlatives, no invented numbers, no other clinic's details left behind.

This board

The review board on this site is where page-by-page feedback happens, instead of a Word document going back and forth. Sign in with your name and the shared team password, set a page's status as you review it, and leave notes on the page itself. Everyone sees the same list, and the notes stay attached to the page they belong to.

Ongoing SEO

Each site's rankings are tracked daily, from the clinic's own suburb, because local results depend on where the searcher is. We keep a baseline of where the old site ranked before the move, so the effect of the migration can be measured rather than guessed.

After launch we watch for four to eight weeks with the old site still available as a fallback. A dip in the first fortnight is normal; what matters is the trend and whether any page that used to rank has dropped out.

Before a site goes live