Why the template-and-swap approach fails
A set of branch pages usually fails because it is one page repeated. The same six hundred words, the same three service bullets, the same stock photograph, with the city name substituted in eight places and the phone number changed. Search engines have detected that pattern reliably for well over a decade, and the outcome is not so much a penalty as indifference. The pages get crawled, none of them is ever chosen as the best answer to anything, and the group's traffic stays stuck on the homepage.
The fix is not more words. It is more facts that only that branch can supply. A branch page stating the actual bed count, the departments genuinely running at that address, the consultants who sit there and on which days, the diagnostic equipment installed, the overnight emergency capability, the schemes and insurers accepted at that site, and the parking and public transport situation is a page nobody else on the internet can write. Ten of those are ten distinct documents rather than one document published ten times.
There is a real cost, and it explains why most hospitals do not do it. Genuinely unique branch content has to come from the branch, and branch managers already have a job. Budget for the collection effort rather than the writing effort, because the writing is straightforward once somebody has walked each site with a checklist and a camera. Hospitals that skip the collection step and simply brief an agency to produce ten branch pages receive ten paraphrases of the homepage, on schedule and to budget.
What a branch page must carry that no other page can
Start with the facts a patient actually decides on and that genuinely vary by site. Which departments run an OPD at this address and on which days. Whether the emergency department is open around the clock and whether an intensivist is physically present overnight. Which imaging modalities are installed, named by modality and configuration rather than by adjective. Whether the pharmacy and the sample collection counter operate outside OPD hours. Whether the site does day-care procedures or admits. These answers differ between branches, which is the whole point.
Then the practical logistics no aggregator carries. How to reach the branch by road, which gate to use after ten at night, where to park and what it costs, which floor registration sits on, whether attendant accommodation exists, and the direct number that reaches a desk at that building. This is the content patients read most and hospitals write least. It is also what earns links and shares from local community groups and resident associations, which no quantity of service copy will ever do.
Finally the fields that change: the current consultant roster with days and sessions, the current package rates, the current scheme empanelment. These are the highest-value items on the page and the most likely to go stale, which is the argument for generating them from a system rather than typing them into a content management system once. A hand-maintained branch page will be wrong within two quarters, and a wrong roster generates phone calls that irritate the patient, the desk and the consultant equally.
Branch-specific facts worth collecting on a site walk
- Departments holding an OPD at this address, and their operating days
- Emergency and ICU capability actually available overnight, not on paper
- Installed diagnostic equipment, named by modality and configuration
- Access, entrances, parking, floor layout and attendant facilities
- Schemes, TPAs and insurers empanelled at this specific site
One department page, or one per department per branch?
The architecture question is whether you publish one cardiology page for the group or one cardiology page for every branch. The answer depends entirely on whether the branches differ in substance. If cardiology at three sites means the same OPD consultation and nothing more, one strong group page with a where-to-find-us block serves better. If one site has a catheterisation laboratory and the others do not, those are different services and deserve different pages, because a patient searching for angioplasty needs to arrive at the site that performs it.
Where hospitals go wrong is generating the full matrix by default. Eight branches multiplied by eighteen departments produces 144 pages, of which perhaps twenty describe something distinctive. The other 124 are the near-duplicates that drag down the whole site and consume the crawl attention that should be going to pages capable of ranking. Generate an intersection page only where the intersection has a fact of its own to state, and keep a written note of why each one exists so nobody regenerates the rest later.
The pattern that works in practice is a group department page acting as the authority, carrying the clinical depth, the conditions treated, the procedures offered and the patient guidance, with a short availability block linking to each branch where the department runs. The branch page then carries the logistics and the roster. Each page has a distinct job, neither repeats the other, and a patient entering from either direction reaches what they need in a single click rather than looping.
Internal linking that holds the structure together
The link structure should mirror the decision the patient is making rather than the organisation chart. Somebody on a condition page is deciding whether to seek care and needs the department. Somebody on a department page is deciding where and needs the branch. Somebody on a branch page is deciding when and needs the appointment route. Each page should therefore carry a clear link forward along that chain, with anchor text that describes the destination in the words a patient would use.
Two structural mistakes recur across hospital sites. The first is a mega-footer linking to all 144 pages from every page, which flattens the hierarchy and communicates that nothing is more important than anything else. The second is orphaned pages: a department page built for a campaign and linked from nowhere except the advertisement that has since stopped running. Crawl the site quarterly and list every page more than three clicks from the homepage or carrying no internal links at all.
Contextual links from editorial content carry the most weight and are the least maintained. When a new branch opens, nothing in the existing content points at it, and it starts life invisible. Keep a short standing list of the pages you want strengthened, and whenever new editorial content is published place one relevant contextual link deliberately rather than hoping the writer happens to think of it. Two links a month, placed on purpose, beat a bulk internal linking exercise done once and never repeated.
Internal link checks worth running each quarter
- Every branch page reachable within three clicks of the homepage
- Every department page linked from the relevant condition content
- No orphan pages left behind by campaigns or microsites
- Anchor text written in patient language, not internal department names
- Redirects in place for renamed departments and closed branches
Schema markup for hospitals and departments
Schema.org maps onto this structure closely. Hospital is a subtype of MedicalOrganization and of LocalBusiness, so a branch page can carry address, geo coordinates, opening hours, telephone and department relationships in a single block. The department property points at the units genuinely operating at that address, availableService points at the procedures and tests offered, and Physician is the type for a consultant, referenced from the hospital rather than duplicated inside it. The vocabulary is more expressive than most hospital sites use.
The rule that keeps structured data useful is that it must describe what is visibly on the page. Marking up opening hours the page does not display, or services the branch does not actually offer, is a direct route to losing eligibility for enhanced presentation, and it misleads a patient in the meantime. Use stable identifiers for each entity so that a consultant referenced from three pages resolves to one person rather than three, which is the same identity discipline you would apply to any master record.
Be realistic about what this buys you. Structured data helps machines understand entity relationships and supports certain presentation features. It is not a ranking shortcut and it will not rescue a thin page. Hospitals that spend a quarter on schema and no time on content generally see nothing change, and conclude that schema does not work. Do it after the page is worth reading, at which point it is cheap because the facts already exist in a structured form somewhere.
Structured data fields to get right on a branch page
- Name, address and telephone matching the map listing exactly
- Separate opening hours specifications for emergency and OPD
- Department entities only for departments genuinely at that address
- Stable identifiers so a consultant resolves to one entity site-wide
- No marked-up fact that is absent from the visible page
Diagnosing the thin-page trap before it costs you
The symptoms are recognisable. Pages indexed but drawing no impressions at all. Branch pages ranking below aggregator directories for your own brand name plus the locality. A large block of pages reported as crawled but not indexed. Rankings that improve for a fortnight after publication and then decay. None of these individually proves thinness, but together they describe a site producing volume without producing anything distinguishable, which is exactly the pattern search systems are built to filter out.
Measure it rather than debating it. Run a text similarity comparison across your own page set, which any crawler can do, and look at any pair sharing most of their body text. Then count unique verifiable facts per page: numbers, names, dates, equipment models, timings that appear nowhere else on the site. A page with fewer than a dozen unique facts is unlikely to earn a position against a competitor page that has thirty, regardless of how well written it is.
Fix in the right order. Consolidate first, by merging near-duplicates into the strongest version and redirecting the rest. Then enrich what remains with the branch facts you collected. Only then consider expanding into new pages. Most hospitals do this backwards, adding pages to fix a problem caused by having too many pages, which is why the second attempt usually performs worse than the first. Deletion is a legitimate optimisation and is frequently the highest-yield one available.
“We deleted forty department pages and rewrote nine of them properly. Total organic traffic went up the following quarter. The pages we removed had never been read by anyone except a crawler.”
Maintenance is what decides whether any of this works
Assign every page an owner by name, not by department. The branch manager owns the branch page facts, the department head owns the clinical content, and someone in marketing owns the publication mechanics. Set a review cadence tied to how fast the content decays: rosters and rates monthly, equipment and capability quarterly, clinical content annually. An unowned page is a page that will be accurate on the day it launches and progressively wrong every day after.
Know what breaks these pages, because it is always the same short list. A consultant leaves and their name stays for a year. Rates are revised and the page still shows last year's package. A department relocates to another floor and the directions no longer work. A branch closes and nothing redirects, so the page keeps ranking and keeps sending patients to an empty building. Each of these is an operational event that somebody already knows about; the failure is that nobody told the website.
The structural answer is to generate the volatile blocks from the systems that already hold the truth. HealUDoc doctor and schedule records can feed the roster block so a branch page reflects the live rota rather than a snapshot taken at launch. Accept, finally, that this is a slow channel. Structural work on branch and department pages typically takes two or three quarters to show clearly, and judging it after six weeks will lead you to abandon something that was working.
