Solutions · Medical clinics
In a clinic, the raw material for search already exists and is called the nomenclature: each item has a code, name, unit of measurement and price. We turn it into proper addresses, in two languages, with structured data that makes them machine-readable — and we write from the start what we cannot promise.
Already builtThe work can be verified from outside today. The source nomenclature of a medical centre we built has 446 items in 9 categories, each with code, name, unit of measure and price, plus a separate file with 77 physiotherapy items in Romanian and Russian. In code, 521 page files, of which 481 under the services section; the production sitemap lists 890 addresses, counted by me on 06.09.2026. The second implementation is the audit method, applied on our own site: 249 addresses traversed with direct requests, 23 columns per address, the result in a tabular file versioned alongside the code. What we cannot support and will not write: positions obtained, growth percentages or number of visits. We do not have access to the client’s search console and we do not have publicable measurements for that.
A medical clinic almost always comes with the same site structure: a “Services” page, a “Prices” page with an attached document, and a “Contact” page. And behind the scenes, in accounting, there is already the thing that should be the site: the tariff nomenclature. Hundreds of items, each with a code, exact name, unit of measurement and price. Nobody searches for “laboratory services”; people search for the procedure name, exactly as it is written in the doctor’s referral, plus the word “price”.
So the work does not start with keywords, but with structure. In a medical centre we built, the nomenclature has 446 items in nine categories: treatment packages, periodic medical examinations, consultative services, diagnostics, physiotherapy, alternative medicine, gynaecology, ozone therapy, dentistry. From them came 481 service routes in code, and the production site map lists 890 addresses — because each page exists in both Romanian and Russian. In the Republic of Moldova this is not an image option: it is half of the audience that searches.
On top of the structure comes the technical part, which is the same for any site but has a bigger stake here: one official address declared once for the whole site, a site map generated from data and not written by hand, a verdict for each old address during any restructuring, and structured data that describe what is on the page. Our verification method is not an impression: we request each address, put the result in a table with 23 columns and fix what can be verified in the table.
And now the part others omit. For a clinic there is a documented Google restriction: the FAQ rich result is shown only for well-known and authoritative government and health sites — a restriction announced in September 2023. That means two things at once: a clinic is in one of the few categories that can still benefit from it, but “well-known and authoritative” is not a box we tick ourselves. So we set the structured data correctly and validate it with the engine tool, but we do not sell the rich snippet as a deliverable.
What it covers
The first stage is the inventory of tariff items, in the form the clinic keeps them: code, name, unit of measurement, price. From it follows how many pages can be made honestly — that is, for how many items there is their own content, not a recycled paragraph. An item with nothing to say does not get a page; it gets a row in a list.
In the cited work: 481 service routes in code and 890 addresses in the production site map, because each page has its Russian pair. The address structure follows the real sections — physiotherapy, consultative services, periodic examinations, diagnostics — not a taxonomy invented by us to look richer.
“Per session”, “per investigation”, “per treated case” completely change the meaning of a price. In the nomenclature they exist; on most clinic websites they get lost when copied. We keep them in the page structure, because the person comparing two clinics is in fact comparing two different units of measure without knowing it.
Direct requests to each known address, without following redirects, with no more than six requests at once so as not to disturb the server, and 23 columns per address: response code, canonical address, title, description, language variants, visible text volume. We deliver the table, not a list of general recommendations.
The canonical address is declared relatively, in one place only, and resolved for each route; the sitemap is generated from content sources, with final deduplication, and checked after publication. On our own website, the same figure — 147 addresses — appears in the code and in the file served in production. A clinic website with hundreds of pages cannot be kept correct with a hand-written sitemap.
The machine-readable block is generated from the data from which the page is built, not written a second time by hand — otherwise the two versions of the truth diverge at the first change. Each page type goes through the search engine’s validation tool, which says what it read and which field is missing; we deliver that check’s screenshot, not our opinion.
The search crawler that sends people back, the agent triggered by a person who requested the page, and the training crawler are three different things, with independent rules. We check what they actually receive: on our own website, ten model agent identifiers on the same address all receive 200 and exactly the same number of bytes as a browser. For a clinic, the decision about which of them is allowed is made in writing, not implicitly.
We do not promise positions in results, growth percentages or a number of visits. We do not promise the FAQ rich snippet, because the search engine documentation restricts it to well-known and authoritative health and government websites, and “well-known” is not a setting. And we do not promise citations in generated answers: there is no position to buy there.
Statements about the result of a treatment, cure percentages, comparisons with other clinics, scores and reviews that cannot be proven with a public source. Not out of legal caution: a rating declared in structured data without a public source is exactly what triggers a sanction, and a promise of result on a medical website is a bigger problem than an unhelpful page.
Traseul
We structure the nomenclature and go through the current website, address by address, with 23 columns per address. We deliver two tables: which tariff items exist and what state each address published today has. From here it is visible, before any work, how many pages can be made honestly.
Each existing address receives a verdict: stays, is permanently redirected, or disappears. We deliver the redirect list and the new structure, in both languages, with the canonical address resolved in one place and the sitemap generated from data.
The text of a medical service page is written with the doctor who provides that service and is published after they confirm it. We deliver the structure of each page and the questions it must answer; we do not deliver medical text written by us, nor automatically generated text across hundreds of pages.
The machine-readable block is generated from the same source as the text, passes through the engine validation tool and is checked after publication with a script that fails if anything is missing. We deliver the validation screenshots and the verification script, so you can repeat the check without us.
The data
The rules differ from one industry to another. These are the ones that apply in medical clinics.
A case
The situation
A medical centre with hundreds of tariff positions had the information in a nomenclature file and, on the website, a prices page. Anyone searching for the exact name of a procedure — as it is written on the doctor's referral — had nowhere to go.
What we built
We structured the nomenclature — 446 positions in nine categories, each with code, name, unit of measure and price, plus a separate file with 77 physiotherapy positions in Romanian and Russian — and turned each position that had its own content into a route with its own page, in both languages. The site is bilingual by configuration, and the site map is generated from data.
What came out
The code contains 521 page files, of which 481 are under the services section; the production site map lists 890 addresses, approximately double the number of services, because each has its Russian pair. Each page carries the unit of measure of the position, not just the price.
What the case does not say
“890 addresses in the sitemap” does not mean 890 indexed pages. We do not have access to the client’s Search Console, so we cannot state anything about rankings, traffic or indexing — nor about the commercial effect of the work.
Questions
As many as there are items in the nomenclature with something of their own to say. In the work we cite, 481 service routes resulted from a nomenclature of 446 items, in two languages — 890 addresses in the sitemap. But the correct figure for your clinic comes from inventory, not from a promise. Hundreds of pages with the same recycled paragraph are worse than ten good pages.
No, and no one can. We do not have publicly reportable measurements on positions, and we do not sell what does not depend on us. What we deliver is verifiable in another way: the list of addresses with the status of each, the repairs made, the validation of structured data with the engine tool, and the post-publication check.
Because a significant part of the audience searches in Russian, and a clinic cannot choose not to respond to a medical referral written in the other language. In the cited work, bilingualism is declared in code, and the sitemap contains the Russian pair of each page — that is why the number of addresses is double the number of services.
The translation of the page into data that a machine reads without guessing: what kind of page it is, what service it describes, who the organisation is, where it is located. It is generated from the same source as the visible text and validated with the engine tool. What we do not sell under that name is the enriched snippet with frequently asked questions — Google’s documentation has restricted it, since September 2023, to well-known and authoritative health and government sites.
The part that depends on you can be worked on: the page should be server-rendered, so that an agent that does not execute JavaScript receives the full text; claims should have their source next to them; organisation data should be consistent across everything public. What cannot be done: promise that you will be cited, or how many times. There is no position to buy in a generated answer.
No, if you do not give it to us. And if we do not have it, we do not write anything about positions, traffic or indexed pages — not even “visibility increased”. The number of addresses in the sitemap is not the number of indexed pages, and this confusion is the most common way a SEO report looks good and says nothing.
Technically, yes — the structure is generated from the nomenclature. The text is not. On a medical site, a generated and unsupervised paragraph becomes a health statement made in the name of the clinic. We generate the structure, price, unit and navigation; the description is written or confirmed by a specialist.
Each one receives a written verdict: stays, is permanently redirected, or disappears. On our own site, a restructuring produced 43 permanent redirects in the configuration. Addresses that were sent to patients by message or printed on a leaflet must not end up in 404.
The technical side is what we can guarantee is done correctly and can be checked in a table. The content — that is, whether each page truly answers a real question — determines whether the work has any effect. That is why the first deliverable is the inventory: it shows whether you have material for hundreds of pages or for a few dozen.
Tell us about your process. Together we decide what is worth building, what we can connect, and how we check the result.