Your ER Needs Condition Pages, Not a Services List

Open almost any freestanding ER website and you will find a services page. It lists imaging, laboratory, pediatric care, orthopedics, cardiac care. It is accurate, it is organized the way the facility is organized, and it brings in close to no search traffic.

The reason is simple. Nobody searches for "imaging services." They search "chest pain," "how do I know if my arm is broken," "stomach pain that will not go away." Your site is organized by department. Their search is organized by symptom.

What a Condition Page Is

A condition page is a full page about one thing a patient might be experiencing. Not a paragraph on a services page. A page, with its own URL, its own title, and its own place in the sitemap.

"Chest Pain" is a condition page. "Cardiac Services" is a department. The first matches a search. The second matches an org chart.

On a new ER site we launched, the pages that started drawing search impressions in the first month were exactly this kind, along with the FAQ and the financial support page. The services page was not among them, and it never is.

How to Structure One

The order matters more than the length, because of who is reading. Someone at two in the morning with chest pain does not scroll. They scan the first screen and decide.

So the answer goes first. Not background, not a definition of what the heart is, not a paragraph about your commitment to excellence. The answer.

• Open with the decision. When should this person come in, and when should they call 911 instead? Say it in the first two sentences.
• Then the detail. What the symptom usually means, what makes it more concerning, what you will do when they arrive.
• Then the practical. What to bring, what the wait is like, what happens to the bill.
• Then the reassurance. Your capability, your team, your equipment.

Most ER sites run that order exactly backwards, opening with the facility and arriving at the patient's question somewhere near the bottom.

Tell People When Not to Come

This is the part that makes operators nervous, and it is the single strongest trust signal an ER page can carry.

A chest pain page that says "if you have chest pain with shortness of breath, call 911 now rather than driving" is telling a patient not to come to you. It is also the most credible thing on the page, and it is what a person remembers about your facility afterward.

The same applies to cost. A page that says plainly when an urgent care would serve someone better and cost them less is counter-intuitive, and it converts. Patients are extremely good at detecting when they are being sold to, and extremely responsive to being told the truth.

Use Question Headings

Structure each condition page around the questions people actually type. "When Should You Go to the ER for Chest Pain?" is a better heading than "Chest Pain Overview," for three reasons: it matches search phrasing, it makes the page skimmable, and it gives Google and AI search tools a clean question and answer pair to lift.

AI Overviews now appear on a large share of health searches. They are built by extracting direct answers. A page structured as questions with immediate answers is far more likely to be the source than a page structured as prose.

How Many Pages, and Which First

Start with eight to twelve, chosen by volume rather than by clinical interest. For a typical freestanding ER that usually means chest pain, abdominal pain, fractures and sprains, head injury, fever in children, breathing difficulty, cuts and lacerations, and dehydration.

Then expand. On one build we published thirty-two service and condition pages inside a thirty-day contract, which is aggressive but achievable when the content is planned properly rather than written page by page as an afterthought.

What About Accuracy?

Clinical content carries obligations. Our rules on every ER site are firm: no diagnostic advice, no medication names, no promised outcomes, and every clinical claim traced back to CDC, NIH, MedlinePlus, ACEP, or the equipment manufacturer.

Each clinical page carries a named physician reviewer, with structured data behind it rather than the words "medically reviewed by" sitting in plain text. That distinction is invisible to patients and very visible to Google.

How to Choose Which Pages to Build First

Do not start with the conditions your clinicians find most interesting. Start with the ones people search most and arrive with most often, which is a different list.

Three inputs give you the priority order:

• Your own arrival data. What actually walks through the door, by volume. Your EMR knows this and nobody ever asks it.
• Search volume for the symptom phrasing in your metro area, which tells you where the demand sits.
• Competitor gaps. Conditions where the established facilities nearby have thin content or none. Those are the pages you can win first on a new domain.

Overlay the three and the first ten pages choose themselves. Build those, publish them, then use the search data they generate to choose the next ten.

The Comparison Table Nobody Includes

Every condition page should carry one comparison table, and almost no ER site has any. It is the single most snippet-friendly element you can put on a page, and Google lifts tables into results readily.

For a condition page, the natural table compares severity: which symptoms mean go to the ER now, which mean call 911 instead of driving, and which mean an urgent care or your primary care physician would serve you better.

That last column is the one facilities resist and the one that earns trust. Telling a person their symptom does not need an emergency room is the most credible thing on the page, and it is remembered.

We benchmarked a client site against an established competitor in the same market with 91 URLs. The competitor had comparison tables on zero pages. We put one on every service page. That is not a small edge, and it cost nothing but the decision to do it.

Writing for Someone Who Is Frightened

The reader of a chest pain page at two in the morning is not in a normal state. They are scanning, not reading, and their tolerance for anything that is not the answer is close to zero.

That has concrete implications for the writing:

• Short sentences. Long ones lose people who are already struggling to concentrate.
• Plain words. "Trouble breathing" rather than "dyspnea." Write for a person, not a chart.
• No throat-clearing. Never open with "chest pain is a common symptom that affects millions." They know. Get to the decision.
• The answer first, every section. Not building to a conclusion. Leading with it.

Read the page aloud when it is done. If it sounds like a brochure, rewrite it. If it sounds like a calm person explaining something to a worried friend, it is right.

How Depth Compares to the Market

On the benchmark mentioned above, our client's service pages averaged 2,397 words against the competitor's 1,043, with 16 question-format headings per page against their 7, and physician-review schema on 32 pages against their zero.

Depth is not automatically better, and a padded 2,400-word page loses to a tight 1,000-word one. But depth that comes from genuinely answering more of what a patient needs to know is a durable advantage, because the competitor would have to rewrite their whole site to match it.

Common Questions

Is this not just more pages for the sake of it?

Only if the pages are thin. A condition page that genuinely answers what a worried person needs to know is not filler, it is the most useful thing on your site. A condition page written to hit a word count is filler, and Google is good at telling the difference.

How long should each page be?

Long enough to answer the question properly. In practice that lands somewhere between 1,200 and 2,600 words for a substantive condition, but length is an output rather than a target.

Who writes them, us or you?

Usually us, with clinical review from your side. We write to a documented standard on sourcing and claims, and we would rather have a physician on your team read it before publication.

Will this cannibalize our existing pages?

Not if the site is structured hub and spoke, with a department page linking down to its condition pages and each condition page targeting a distinct search. Cannibalization comes from two pages chasing the same phrase, which is a planning problem rather than a volume problem.