Healthcare keyword research: the hospital mapping grid

15 min read

Healthcare keyword research is only useful when it ends in a map: which page answers which cluster of patient searches, for which specialty, condition and location. I build that map as a three-axis grid, add intent and language, assign one URL per cluster, and refuse to create pages the hospital cannot back with real doctors and services.

Most hospital keyword lists I inherit are long spreadsheets of search terms sorted by volume, with no link to the site. The list says “knee replacement cost” is popular; nobody has decided which page should rank for it, whether that page exists, or which unit it serves. Healthcare keyword research that stops at a list is a research exercise, not a plan.

What turns it into a plan is a map: every cluster of patient searches assigned to exactly one page, with a reason. For hospitals I build that map on three axes, specialty, condition and location, and then layer intent and language on top. This piece walks through the method. It is part of the keyword and entity track of my complete playbook on local SEO for hospitals in India.

Why a three-axis grid beats a keyword list

Patient searches in healthcare combine a small number of building blocks. A specialty or service (cardiology, IVF, physiotherapy). A condition, symptom or procedure (chest pain, PCOS, angioplasty). A location (a city, a locality, “near me”, or nothing at all, which Google often treats as local anyway). Then modifiers: cost, best, doctor, reviews, insurance, language.

A grid of specialty by condition by location makes the gaps and overlaps visible. You can see that you have a strong cardiology page for one city and nothing for the second unit, or that five blog posts all compete for “kidney stone treatment”. A list hides both problems.

The grid also forces the right question for every cell: does the hospital actually offer this, at this location, with named doctors? If not, the cell stays empty, however attractive the volume looks.

Building the specialty and condition axes

Start with capability, not with a keyword tool. Get the list of services each unit actually offers from medical administration, including which procedures are done at which campus and which doctors see which conditions. That list is your specialty axis and the backbone of the condition axis.

Then translate it into patient language. Doctors say “TKR” and “PCNL”; patients search “knee replacement” and “kidney stone operation”. Patients also search in Hindi, Telugu, Tamil, Marathi and other languages, often in Latin script: “pathri ka ilaj” rather than the Devanagari form. Your call centre and WhatsApp team hear these phrases every day, which makes them one of the best sources you have.

For each condition, capture the variants patients use at different stages:

Symptom stage: what they notice (“blood in urine”, “knee pain while climbing stairs”).
Diagnosis stage: the named condition (“kidney stone”, “osteoarthritis knee”).
Treatment stage: procedures and options (“laser kidney stone removal”, “knee replacement”).
Decision stage: cost, doctor, hospital, insurance (“knee replacement cost cashless”).
After care: recovery and follow-up (“physiotherapy after knee replacement”).

Specialties behave differently. Cancer patients and families research deeply and over long periods, which I cover in why cancer patients search differently. Orthopaedic patients often delay for years before acting. The grid should reflect those patterns rather than treating every specialty as the same funnel.

The location axis in Indian cities

Location in India is layered. There is the city, the locality or micro-market, landmarks people use for directions, and the wider catchment of smaller towns that send patients to a metro or a regional hub. A unit in a large city may draw from localities that, for a patient, feel like different cities.

I map four levels: the unit itself, the city, the localities within a realistic travel time, and the feeder towns in the catchment. Then I check which of those appear in actual search behaviour and enquiry data. Many will not, and that is useful: it stops you building pages nobody searches for.

Feeder towns need separate thought. A family in a district town researching a complex procedure often searches with the metro’s name (“bypass surgery Hyderabad”) rather than their own town, because they already know they will travel. Those searches belong on the specialty page for the unit that does the procedure, with practical travel information, not on a page named after the town. Your admission records show which towns actually send patients, and that is a better guide than any keyword tool.

Remember that a large share of local intent is implicit. Someone who types “dermatologist” on a phone is usually looking for one nearby, and Google knows roughly where they are. The detailed breakdown of explicit and implicit local intent is in near me search intent in healthcare.

Healthcare keyword research sources that hold up

No single tool gives you the truth about patient search in India. I combine sources, and I trust first-party data over third-party estimates.

Google Search Console. The Performance report shows queries, pages, countries and devices for searches where your site already appeared. It is the most honest source you have, because it is your own demand.
Google Ads Keyword Planner. Useful for discovering variants and comparing relative demand. Google describes its figures as estimates, so treat them as directional, not as counts.
Your enquiry data. Call centre reasons, WhatsApp conversations, web form fields and CRM enquiry categories. These show which searches turn into patients.
Business Profile search terms. The performance view in Google Business Profile shows terms people used to find each unit, which is the best window into local demand you will get.
The results page itself. Autocomplete, “People also ask” and related searches, checked from a phone in the relevant city.
Doctors. Ask consultants what patients ask in the OPD. It takes ten minutes and often surfaces questions no tool shows.

Classify intent before you assign pages

Keywords with the same words can need different pages. “Knee replacement” might want an explainer; “knee replacement surgeon in Pune” wants a doctor or specialty-at-location page; “knee replacement cost” wants a transparent pricing or package page. I tag every cluster with one intent class.

Learn: symptoms, conditions, treatment options. Answered by condition and treatment pages, clinically reviewed.
Find a doctor: specialty plus location, or a doctor’s name. Answered by specialty-at-unit pages and doctor profiles.
Find a place: hospital, clinic, test or scan near a location. Answered by unit pages and Business Profiles.
Decide: cost, insurance, cashless, reviews, comparisons. Answered by pricing, package and insurance pages.
Act: book, call, directions, reports. Answered by the booking flow and unit contact details.
Navigate: your brand plus a unit or department. Answered by the right unit or department page, not the home page.

Look at what Google already shows for each cluster. If the results are dominated by map listings, the fight is largely in Business Profiles. If they are explainers from health publishers, a thin service page will not compete.

One page per cluster: the mapping sheet

The rule that makes the map work is simple: one primary URL per cluster, and every other page that touches the topic links to it. When two pages target the same cluster, they split signals and confuse both Google and patients.

These are the columns I use. The specialty keyword and entity mapping sheet has them set up with examples.

Cluster name and the main query plus close variants, including regional-language forms.
Specialty, condition and location values, so you can filter the grid.
Intent class from the list above.
What the results page shows: map pack, explainers, directories, video, AI Overview.
Assigned URL, and whether it exists, needs rewriting or needs creating.
Capability check: service offered at this unit, named doctors, confirmed by medical administration.
Clinical reviewer for learn and decide pages.
Owner and review date.
Measures: impressions and clicks from Search Console, enquiries from the CRM.

The entity columns matter as much as the keywords: the doctors, procedures and units each page is about. That side of the work is covered in entity SEO for doctors and hospitals.

A worked example: one service line, two units

Take a fictional Example Hospital with two units in one city, one in the west and one in the east, and a urology service. The west unit does stone surgery and prostate procedures; the east unit has urology OPD only. This is an illustration of the method, not real data.

Capability list. Medical administration confirms which procedures each unit performs and which urologists consult where, including a senior consultant who sees patients at both.
Clusters. The team groups searches into kidney stone symptoms, kidney stone treatment, prostate enlargement, urologist by location, stone surgery cost, and the consultant’s name with variants.
Intent and results check. Symptom clusters show health publishers and “People also ask”. Urologist-by-location clusters show map listings. Cost clusters show a mix of hospital and aggregator pages.
Assignment. One condition page for kidney stones, clinically reviewed. One urology page per unit, each saying honestly what that unit offers. One cost and insurance page for stone surgery that names the west unit. One profile for the consultant, listing both units. No locality pages at this stage.
Gaps. Search Console shows impressions for Hinglish stone queries that no page answers well. That becomes a brief for a regional-language section on the condition page, written and reviewed properly.

The result is a handful of well-scoped pages instead of the dozens a raw keyword list would suggest, each one defensible to a clinician and to a patient.

When not to create a page

The grid can generate thousands of combinations. Most of them should never become pages. Multiplying every condition by every locality produces near-duplicate pages that Google’s spam policies describe as doorway abuse: pages targeted at specific regions or cities that funnel users to one place, or substantially similar pages closer to search results than a browsable hierarchy.

My rules for leaving a cell empty:

The unit does not offer the service, or no doctor there treats the condition.
There is no evidence of search or enquiry demand, however logical the combination looks.
The page would say nothing that the parent specialty or unit page does not already say.
No clinician is willing to review it.

For localities with genuine demand, the way to build pages that earn their place is in building location pages without thin content. Usually the right answer is a strong unit page plus strong specialty pages, not a page per locality.

Keeping the map alive

A keyword map decays as fast as a doctor roster. Doctors join and leave, units add services, packages change, and patients start searching for new procedures. I review the map on a fixed cycle and on events: a new unit, a new service line, a senior doctor joining or leaving.

Each review asks three things. Which clusters gained or lost impressions in Search Console? Which pages are ranking for clusters they were not assigned, a sign of cannibalisation or a gap? And which enquiries in the CRM do not map to any cluster yet? The last question is where new pages usually come from.

Doctor names deserve their own treatment, because searches for named consultants are among the highest-intent queries a hospital receives. How to structure and rank those pages is in doctor profile pages that rank and convert. For the content side of answering patient questions well, see healthcare content marketing.

What to report from healthcare keyword research

Leadership does not need the spreadsheet. They need to know coverage and results by service line. I report the share of priority clusters that have an assigned, live and reviewed page; the Search Console trend for those clusters by unit; and enquiries attributed to organic search for the same service lines.

The coverage number is the one teams can move directly, which makes it the right internal target. Rankings and enquiries follow, with a lag, and they depend on everything else in the playbook: technical health, reviews, Business Profiles and authority.

Questions people ask

What is healthcare keyword research, and how is it different from ordinary SEO research?

Healthcare keyword research finds the words patients and families use to search for symptoms, conditions, treatments, doctors and hospitals, then maps them to pages. It differs because every page must be backed by real clinical capability, most content needs clinical review, and much demand is local and in regional languages. The output should be a page map, not just a list of terms.

Which tools do we actually need?

Google Search Console and Google Business Profile performance data are essential and free. Keyword Planner helps with variants and relative demand, though its figures are estimates. Paid SEO suites add competitor views and convenience. Your CRM, call centre and WhatsApp logs are equally important, because they show which searches become patients. A spreadsheet is enough to hold the map.

How many pages should a hospital have for a single specialty?

There is no fixed number. Start with one strong specialty page per unit, then add condition and procedure pages only where there is distinct search demand, a named clinical team and something substantive to say. Merge pages that compete for the same cluster. Fewer, deeper, reviewed pages outperform many thin ones, and they are easier to keep accurate.

How long does it take to build a keyword map for a hospital group?

A first version for priority service lines can be done in a few weeks if medical administration provides the capability list quickly and the call centre shares enquiry data. The slow part is usually confirming which doctors and services exist at which unit. Build it by service line, publish the first map, then extend rather than waiting for completeness.

Should we target regional-language keywords?

Yes, where your patients use them. Many patients search in Hindi or other Indian languages, often typed in Latin script. Start by listening to call recordings and WhatsApp chats for phrasing, then check Search Console for existing impressions. Build regional-language pages only when you can write and clinically review them properly, not by machine translation alone.

What is keyword cannibalisation and how do we spot it?

It happens when two or more of your pages compete for the same cluster, so neither ranks as well as one strong page would. In Search Console, filter by a query and see how many of your URLs receive impressions. If several do, pick one primary page, merge or rewrite the others, and link them to the primary page.

How do we decide between a blog post and a service page?

Look at intent and at what Google already shows. Symptom and learning queries often reward explainer content, while queries with a location, a doctor or a cost modifier reward service, doctor or pricing pages. If a blog post and a service page chase the same cluster, one of them is wrong. Assign each cluster once.

Can we create a page for every locality in the city?

Only where there is real demand and real substance. Pages that differ only by locality name risk being treated as doorway pages under Google’s spam policies. A strong unit page, strong specialty pages and a well-managed Business Profile usually cover locality searches. Build a locality page only when it gives patients information they cannot get elsewhere on the site.

Who needs to be involved from the hospital side?

Medical administration to confirm services and doctors per unit, clinicians to review learn and decide pages, the call centre and CRM team for enquiry data, unit marketing for local knowledge, and the web team to implement changes. The SEO lead or agency owns the method and the map, but cannot confirm capability on their own.

What does building and maintaining the map cost?

Mainly time. The research and first map take analyst or agency effort; maintenance needs a few hours each cycle plus event updates when doctors or services change. Tools range from free Google products to paid suites. The expensive mistake is creating dozens of unneeded pages, which then need writing, review and upkeep for years.

How do we measure whether the keyword map is working?

Track coverage first: the share of priority clusters with a live, assigned and reviewed page. Then track Search Console impressions and clicks for those clusters, and organic enquiries in the CRM by service line. Compare service lines where the map is implemented with those still pending, which gives a fair internal benchmark without invented targets.

How should the map handle doctor-name searches?

Treat each doctor as a cluster with one canonical profile page, named consistently everywhere. Map misspellings and variants such as initials or titles to that page. If a doctor consults at several units, keep one profile that lists all locations rather than duplicates. When a doctor leaves, redirect thoughtfully and update the map the same week.

How does this fit with paid search planning?

The same map serves both. Clusters with strong decision or action intent are candidates for paid campaigns, and the assigned page is often the right landing page. Search terms reports from paid campaigns also reveal new organic clusters. Share one taxonomy of service lines and locations across SEO and paid media so reports can be compared.

Read my takes first in Google Search