WordPress and medical practice
A surgery site on WordPress, and the page the widget must not be on
Two things about a practice website change this install and neither has anything to do with medicine. The first is that the practice usually does not control it: the site was built by a website supplier who kept the plugin rights, so the person who can add a footer hook does not work at the surgery. The second is that somewhere on the site there is a form that collects symptoms, and the launcher must not be next to it.
Why this pairing is its own job
The WordPress install guide covers the tag, and the medical practice guide covers what the assistant has to know. What follows is the part that belongs to neither.
- Practice sites are frequently built and hosted by a website supplier, and the surgery's own login is an editor account. There is no plugin screen, no snippet tool and no route to the footer hook, so the install becomes a request to the supplier rather than a job somebody does on a Tuesday afternoon.
- Almost every surgery site now carries an online consultation or symptom submission route, usually a form served from the supplier's own address. That is a triage channel with a clinical process behind it. A chat launcher floating over it invites a patient to describe symptoms in the wrong box, which is exactly the failure the whole design of a health assistant exists to prevent.
- The material that answers the most calls is a leaflet library: registration forms, travel questionnaires, fee lists for private letters, practice policies. On a WordPress site those are files sitting in the media library, linked from one page, sometimes from none.
- A practice with branch surgeries often has a page per branch and occasionally a separate site per branch, with different opening hours and different services. Each site is its own origin and its own set of hours, and mixing them produces an answer that sends somebody to the wrong building.
What changes about the install here
<script src="https://cdn.askably.xyz/w.js" data-key="pk_live_YOUR_KEY" defer></script>The tag is the same one on the WordPress guide. Everything below is about where it goes on a medical practice site specifically.
Find out who can actually add the tag
Before anything else, log in and look for the plugins screen. If it is not there, the surgery has an editor account and the install is a ticket to the website supplier, not a task for the practice manager. That changes the timeline and it changes who has to be told when the key or the exclusions change later.
Ask the supplier for the tag to be added on the footer hook rather than in the theme, and ask them to record it somewhere you can see. A supplier who pastes it into a template will have to do it again after the next theme change, and you will find out by noticing the launcher missing rather than by being told.
If the supplier will not add third party markup at all, that is a real answer and worth getting in writing early, because the alternative routes on a hosted arrangement you do not control are all worse.
Exclude the consultation route explicitly
Whatever page holds the online consultation link or form, name it in the snippet and return before the tag prints. Do this at install time and not as a refinement, because the version of this that goes wrong is the one where the exclusion was on the list for next week.
If the consultation form is served from the supplier's address rather than yours, the tag was never printed there in the first place. Confirm that rather than assume it: some suppliers embed the form into a page on your own domain, which is the case where the exclusion is needed and the one people expect least.
List every branch address the practice answers on
Branch surgeries collect domains over time: an old practice name that still resolves, a site built for one branch before a merger, the apex and the www of each. Every one of those that a patient can reach is an origin, and an origin that is not listed shows nothing at all.
Where a branch has genuinely different hours or services, it needs its own material rather than its own entry on a shared list. A patient asking about Saturday opening does not say which branch they mean, and a shared index gives them whichever page matched best.
Where the answerable material lives
| The media library, read as a document store | Registration packs, travel questionnaires, private fee lists, practice leaflets and policies. On a practice site these are uploaded files linked from one page, which means a crawl following navigation reaches almost none of them. They answer more calls than the pages do. |
|---|---|
| Registration information, per branch if it differs | Who can register, what proof is needed, how long it takes and whether the list is open. The single most repeated call at any practice with a moving population nearby. |
| The repeat prescription process as it works here | How to request, how long it takes, which pharmacy it goes to, and what happens when a medicine is due a review. Ordering is administrative even though the medicine is not, so the process is safe material and the medicine is not. |
| Access and interpreter information | Step free routes, which entrance, interpreter arrangements and alternative formats. Practice sites tend to bury this on a page nobody links to, and it is exactly the sort of question a chat panel gets asked instead of a receptionist. |
The first thing to get right
Name the online consultation page in the snippet and confirm the launcher is gone from it, before you tell anyone at the practice that the assistant exists.
Every other decision here can be corrected later. A patient who typed their symptoms into a chat panel because it was the nearest open box has already done it, and the practice cannot take that back or treat it as having been triaged.
The failure that belongs to this combination
The supplier update that takes the tag with it, months later
On a site the practice does not control, this failure has a long fuse. The supplier adds the tag, everything works, and a year later they roll out a template change across every practice on their platform. The tag was in the template rather than on the hook, so it goes.
What makes this specific to a surgery rather than to WordPress in general is that nobody at the practice is watching the front page. Staff work in the appointment system all day and reach the website through a bookmark to the staff page. The absence is discovered when somebody asks why the assistant stopped taking enquiries, and the enquiry inbox has been quiet for weeks without anyone noticing that quiet was the symptom.
Two habits fix it. Ask the supplier for the footer hook rather than the template, and put one recurring check in the practice manager's diary that is nothing more than opening the front page in a private window and looking for the launcher.
Before you go live
- The origin the page is served from has to be on the allowlist for that assistant, or nothing renders and the browser console says which origin was refused. An apex domain and its www are two different origins to a browser, so list both, along with any staging or preview host you want it to work on.
- Open the site as a visitor would, on the pages a medical practice visitor actually lands on, and ask it something only your own material could answer. A widget that renders is not the same as a widget that has read anything.
Questions
- Our website supplier controls the site. Can we still do this?
- Usually yes, but as a request rather than a job. Ask for the tag on the footer hook rather than in a template, and ask where they recorded it. If they decline third party markup entirely, that is worth knowing in writing before you plan anything around it.
- Should the widget appear on the online consultation page?
- No. That route has a clinical process behind it, and a chat panel next to it invites somebody to describe symptoms in the box that has no process behind it. Exclude that page in the same snippet that prints the tag, and check it in a private window afterwards.
- Can it tell a patient whether their prescription is ready?
- No. It has no access to the clinical system and cannot look anybody up. What it can do is state the usual turnaround and the process, which is what most of those calls actually need, and take a name and message for anything else.
Keep reading
- Installing on WordPressHook the tag into wp_footer with a snippet plugin, keep it out of the theme, and stop optimisation plugins from deferring it away.
- Everything for a medical practiceAdministrative questions a practice can safely automate, the symptom questions it must never touch, and how to word the refusal.
- One launcher across a property that books in three different placesRooms, the restaurant and the spa each book somewhere else with their own notice period. One footer hook covers all three and the terms are on none.
- A WordPress site for a law firm, and the pages a crawl comes back empty fromFee tables hidden in page builder accordions, a client area the widget must stay out of, and costs documents published as files rather than pages.
- Practice sites on Drupal, and the install that may not be availableBlocks strip the tag and a supplier managed install may leave no route at all. What a practice can answer, and where the tag must not go.
Try it on your own material
Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.