01
Executive thesis
Patients do not search for departments. They search for a symptom they cannot explain, a diagnosis they were given yesterday, a procedure a friend mentioned, a doctor whose name they half remember or a clinic near a specific district. Those are five different intents arriving at five different moments in a decision, and each one requires a page with a different job.
Healthcare website architecture SEO is the discipline of assigning those jobs deliberately. The Six-Layer Healthcare Search Architecture is a page-type model for doing that, along with the entity relationships and governance rules that keep it from decaying into duplication.
The scale problem is specific to healthcare. The General Authority for Statistics reported that in 2024 Saudi Arabia had 516 hospitals, 5,779 primary healthcare centres and medical complexes, and 129,772 physicians. A single mid-sized specialist group operating across three cities is managing an entity set of conditions, procedures, practitioners and locations that multiplies rather than adds. Without an architecture, that multiplication produces pages faster than anyone can govern them.
02
Why healthcare websites become structurally confusing
Three forces push healthcare sites toward disorder, and all three feel reasonable at the time.
The first is the organizational chart. Internal department names are the most available vocabulary, so they become the navigation. The problem is that patients rarely share that vocabulary. A patient with numbness in the hand does not know whether that belongs to orthopedics, neurology or rheumatology, and asking them to choose is asking them to make a triage decision they are not qualified to make.
The second is the marketing campaign. Each campaign needs a landing page, each landing page targets a phrase and over three years the site accumulates six pages that all address the same intent with slightly different words. Search engines are then asked to choose between them, and the choice is made unpredictably.
The third is the multi-location expansion. Each new branch appears to need its own copy of every service page. Three locations and eight services generate twenty-four pages, most of them differing only in the name of the district. The service content is duplicated, the local content is thin and no page is strong.
The common failure underneath all three is the same. No one has written down what each page type is for. The Six-Layer model exists to make that explicit before the page count grows past the point where it can be corrected cheaply.
03
The six layers
Each layer answers a different patient question at a different stage. Each has a defined job, a defined intent and a defined route onward.
Layer 1. Symptom and question. The patient's question is "what is happening to me". These pages address the presenting complaint in the patient's own language, describe when the symptom warrants clinical attention and route to the conditions that may explain it. They are the widest entry point and the least commercial. Their job is not to convert. Their job is to be found and to route correctly.
Layer 2. Condition. The question is "what do I have, and what does it mean". These pages address a named diagnosis, its typical course, how it is assessed and what treatment options exist. Patients arrive here both before diagnosis, from Layer 1, and after diagnosis, directly from search. They must link to the procedures the organization actually provides.
Layer 3. Procedure and treatment. The question is "what will be done to me". These pages describe an intervention, what it involves, recovery, risks in general terms and what the patient should expect operationally. This is the layer where high-consideration decisions are made, and it is the layer most often reduced to a single line inside a service page.
Layer 4. Service and specialty. The question is "what do you offer". These pages describe the organization's clinical offer, the team, the technology and the scope. This is the layer most healthcare sites build first and most patients reach last. It is genuinely useful for orientation and for organizational credibility, and it is not a substitute for the three layers above it.
Layer 5. Practitioner. The question is "who will treat me, and are they the right person". These pages carry the individual clinician, their scope in patient-comprehensible terms, their credentials, their languages and the conditions and procedures they handle. Practitioner discovery is a primary search behaviour in Saudi Arabia and this layer is routinely built as a staff directory instead of a decision page. The signals that make clinical expertise legible are covered in the clinical authority signal map.
Layer 6. Location and access. The question is "can I actually get this, and where". These pages carry the physical facility, directions, parking, hours including evenings, accepted insurers, referral requirements, languages spoken on site and the booking path. This layer is operational fact rather than marketing copy, and its accuracy determines whether the other five layers convert. The measurement discipline for this layer is set out in local visibility share rather than a single ranking.
04
Defining the job of each page type
An architecture is only enforceable if each layer has written constraints. The table below is the minimum specification.
| Layer | Primary intent | Must contain | Must not do | Routes to |
|---|---|---|---|---|
| 1 Symptom | Informational, early | Patient-language description, warning signs, when to seek care | Diagnose, or claim outcomes | Layers 2 and 6 |
| 2 Condition | Informational, evaluative | Named diagnosis, assessment path, treatment options available here | List treatments the organization does not provide | Layers 3 and 5 |
| 3 Procedure | Evaluative, high consideration | What happens, preparation, recovery, general risks, who performs it | Promise results or compare to named competitors | Layers 5 and 6 |
| 4 Service | Orientational, organizational | Scope, team, technology, subspecialties | Absorb the condition and procedure layers into itself | Layers 2, 3 and 5 |
| 5 Practitioner | Trust, selection | Scope in plain language, credentials, languages, conditions and procedures handled | Read as an internal CV | Layers 3 and 6 |
| 6 Location | Access, transactional | Address, hours, insurers, referral rules, languages, booking path | Duplicate service copy across branches | Booking |
Two rules apply across every layer.
Use the patient's vocabulary in the visible label and the organization's vocabulary in the supporting text, not the reverse. Navigation that reads "Musculoskeletal Sciences" serves the internal reporting line. Navigation that reads "Bones, Joints and Muscles" serves the person trying to find help.
Build Arabic and English as parallel structures rather than as a translation layer bolted onto an English tree. Arabic search intent diverges from English intent at the symptom and condition layers in particular, where colloquial and Modern Standard terms differ from clinical terminology. This is an adaptation problem rather than a translation problem, as set out in Arabic healthcare content is not translation.
05
Entity relationships and internal linking rules
A layer model without relationship rules produces six isolated silos. The value is in the edges, not the nodes.
Five rules govern the edges.
Every relationship must be clinically and operationally valid. A condition page links only to procedures the organization actually performs, and a procedure page links only to practitioners who actually perform it. An internal link that implies a service the organization cannot deliver is a booking failure waiting to happen and, depending on how it is worded, a claims problem.
Every page must have a route to care. A symptom or condition page with no path to a bookable endpoint is an information asset with no operational value. This does not require an aggressive call to action. It requires that the next step exists.
Practitioner pages must be relational in both directions. A doctor page that links to conditions and procedures, and condition and procedure pages that link back to the doctors who handle them, is how a site expresses clinical scope in a form both patients and search engines can follow. A doctor page reachable only from a staff index is orphaned in practice even when it is technically linked.
Location pages carry access facts, not service descriptions. The service is described once at Layer 3 or 4. The location page states where it is available, when and under what eligibility conditions.
Anchor text should describe the destination and vary naturally. Repeating an identical exact-match anchor across a hundred pages is a pattern, and it is not a useful one.
On structured data, Google's Article documentation states that Article markup can help Google understand a page and details such as its title, images and dates, and its breadcrumb documentation notes that Google uses breadcrumb markup in the page body to categorize the page in search results, which matters precisely because users reach the same page from very different query types. Two constraints are worth stating plainly. Structured data does not guarantee a rich result, and Google's list of supported structured data types is not healthcare-specific, so schema types such as MedicalWebPage or Physician may be reasonable for general semantic clarity but should not be presented internally as a route to a rich result. Breadcrumb markup should mirror the visible hierarchy. If the two disagree, fix the hierarchy.
For bilingual sites, Google's localized versions documentation states that each language version must list itself as well as all other versions, and that Google does not use hreflang or the HTML lang attribute to determine the language of a page, since language is determined algorithmically. The practical consequence is that hreflang manages the relationship between versions and does not rescue a page whose Arabic content is machine-generated or partially untranslated.
06
Avoiding cannibalization and duplicate location content
Cannibalization in healthcare is usually structural rather than accidental. It comes from the multiplication of location by service.
Consider a group with three branches and eight services. The permutation approach produces twenty-four service pages, each substantially identical apart from the district name. The architecture approach produces eight service pages and three location pages, eleven pages total, with each location page stating which of the eight services it provides.
| Approach | Pages, English | Pages, bilingual | Unique content required |
|---|---|---|---|
| Location by service permutation | 24 | 48 | 24 service descriptions, mostly duplicated |
| Six-layer architecture | 11 | 22 | 8 service descriptions, 3 sets of access facts |
The permutation approach costs more than twice as much to write, more than twice as much to maintain and produces internal competition for the same queries. It is defensible in one case only, which is where the service genuinely differs by site, for example where one branch has an imaging modality or a subspecialty team the others do not have. In that case the difference is the content, and the page earns its existence.
The test to apply before creating any page is a single question. Can this page answer a question no existing page answers. If the honest answer is no, the correct action is to strengthen the existing page and add a section, not to create a new URL.
07
A specialty architecture worked example
The following is an illustrative planning model for a private orthopedic group in Saudi Arabia with three locations and twelve physicians. The counts are planning assumptions, not measurements.
| Layer | Entity count | Pages, English | Pages, bilingual |
|---|---|---|---|
| 1 Symptom | 10 presenting complaints | 10 | 20 |
| 2 Condition | 18 conditions | 18 | 36 |
| 3 Procedure | 22 procedures | 22 | 44 |
| 4 Service | 6 subspecialty areas | 6 | 12 |
| 5 Practitioner | 12 physicians | 12 | 24 |
| 6 Location | 3 sites | 3 | 6 |
| Total | 71 | 142 |
The decision number is not the page count. It is the governance load that page count creates.
Annual review hours = total pages × reviews per year × hours per review
At 142 bilingual pages, one review per year and half an hour per review, the load is 71 hours annually. That is a manageable commitment for one part-time content owner. Apply the permutation approach to the same organization and the location by service expansion pushes the page count past 250, and the annual load past 125 hours, for no additional intent coverage. The architecture decision is therefore also a staffing decision, and it should be made before the pages exist rather than discovered afterwards.
An architecture audit scores six things.
| Metric | Definition | Review threshold |
|---|---|---|
| Intent coverage | Share of priority conditions with all of Layers 2, 3 and 5 present | Below 80% |
| Orphan rate | Share of pages with fewer than two internal inbound links from a valid relationship | Above 10% |
| Query overlap | Share of tracked queries where more than one URL receives impressions | Above 15% |
| Route to care | Share of Layer 1 and 2 pages linking to a bookable endpoint | Below 95% |
| Bilingual parity | Share of English pages with a genuine Arabic equivalent and correct hreflang | Below 90% |
| Practitioner depth | Average conditions and procedures linked per practitioner page | Below 4 |
Query overlap is the cannibalization indicator and it is measurable directly in Search Console by grouping impressions by query and counting distinct URLs. Orphan rate requires a crawl. The other four are page audits.
08
Governance rules for adding new content
Fix now, within thirty days. Assign every existing page to one of the six layers, and list the pages that fit no layer or two layers. Those are the cannibalization candidates. Identify the top twenty queries where more than one URL receives impressions and consolidate each to a single page with redirects. Add a route to care to every condition page that lacks one.
Build next, within one to two quarters. Fill the highest-value gaps in Layers 2 and 3 for priority conditions rather than adding more Layer 4 service pages. Rebuild practitioner pages as relational decision pages. Establish the Arabic structure as a parallel tree with its own keyword research rather than a mirror of the English tree.
Measure continuously. Run the six-metric audit quarterly. Require a written layer assignment and a duplication check before any new page is published, which is the operational point where architecture either holds or erodes. Retire pages that no longer answer a distinct question rather than leaving them to compete.
One governance rule matters more than the rest. A new page requires an owner and a named intent before it requires a writer. Every site that has become structurally confusing got there by reversing that order.
The relationship between this architecture and the wider discovery strategy is set out in why healthcare SEO is a market-access system, and a specialty-level application of the symptom to specialist path is developed in orthopedic digital demand. The conversion requirements that sit underneath these page types are covered in what a medical website must do before it looks good.
09
Audit method, limitations and compliance boundary
This article presents a framework and an illustrative planning model. It does not present original DEMA research findings.
The page counts, entity counts and governance hours in the worked example are planning assumptions for a hypothetical three-site orthopedic group. They are not measurements, benchmarks or client results. The six audit thresholds are editorial judgements intended as starting points for review, not validated benchmarks, and they should be calibrated against an organization's own baseline before being used as targets.
External evidence is limited to two categories. Saudi facility and workforce counts are from the General Authority for Statistics Healthcare Establishments and Workforce Statistics publication for 2024, covering the Kingdom across public and private sectors. Platform guidance is from Google Search Central documentation on Article structured data, breadcrumb structured data, supported structured data types and localized versions, all current at the date of review. Platform guidance changes without notice and should be re-verified before implementation.
Structured data does not guarantee rankings, rich results or inclusion in AI-generated search features, and no recommendation in this article should be read as promising any of those outcomes.
Symptom and condition content carries clinical risk. Every page at Layers 1, 2 and 3 requires qualified clinical review before publication, and none of it should present individualized medical advice. Claims about treatment outcomes, comparative superiority and practitioner credentials require substantiation and should be checked against Saudi health advertising rules before publication.
Last reviewed August 2026. Review cycle annual.
Request an Information Architecture Audit. DEMA maps existing page types against the six layers, measures orphan rate, query overlap and bilingual parity, and returns a consolidation and build sequence.