Writing for the Web

Most people don't read a web page top to bottom. They scan it: headings, the first couple of words of a line, bold text, links and lists, looking for the one thing they came for. Usability studies have shown this since the 1990s, and eyetracking research maps the scanning patterns people fall into. Write for scanning and everyone benefits, including the few who read every word.

These are general habits for any website, not just this one.

Write for the reader

• Center the reader, not the organization. Every page should answer "what can I do here, and why does it matter to me?" "You can book an appointment in a few minutes" beats "Our scheduling system offers convenient online options." (About pages are the fair exception: that's where people come to read about the organization.)
• One page, one job. If you can't say what a page is for in a sentence, it's doing too much. A page that tries to do three things leaves visitors unsure which to do, so they often do none.

Write for skimming

• Front-load the point. Put the conclusion first, then the supporting detail. A reader who stops after the first sentence should still come away with the main idea. Journalists call this the inverted pyramid.

• One idea per paragraph. Keep paragraphs to one to three sentences. Walls of text get skipped no matter how good they are.
• Use descriptive headings. Someone should understand the whole page from the headings alone. "Insurance we accept" beats "Coverage." Clear beats clever.
• Break series into lists. Any run of three or more items reads faster as a list than buried in a sentence.
• Bold the key phrase, not the sentence. A little bold guides the eye. Bold everything and it guides nothing.
• Keep it short. Short words, short sentences, short sections.

Content length by section

Rough guides, not hard rules, to keep pages from running long:

Write plainly

Plain language isn't dumbing down; it's respect for the reader's time. The plain-language guidelines are a good free reference for the techniques.

• Prefer the short word. "Use," not "utilize." "Help," not "facilitate." "About," not "regarding."
• Write in the active voice. "The doctor reviews your results," not "Your results are reviewed."
• Talk to the reader. Use "you." It's warmer and clearer than "patients should" or "one may."
• Numbers beat adjectives. Specifics build credibility. "Open until 7pm on weekdays" sticks; "extended evening hours" doesn't.
• Avoid internal language. Words like "intake," "referral process" or "client services" make sense inside an organization and sound clinical to everyone else. Read it aloud; if it sounds like a form letter, rewrite it.
• Define jargon and acronyms on first use. Spell it out, then abbreviate: "National Provider Identifier (NPI)."
• Cut filler. "In order to" becomes "to." "Due to the fact that" becomes "because."

Headings and hierarchy

Headings do double duty: they let skimmers jump to the right place, and they're how screen-reader users navigate a page.

• One H1 per page (the page title). Everything else is H2, then H3 inside it.
• Don't skip levels to get a bigger or smaller font. The hierarchy is meaning, not size; styling is the theme's job.
• Keep them parallel. If one heading is a noun phrase ("Office hours"), its siblings should be too ("Parking and directions").

Heading structure is a W3C accessibility guideline, not a style choice: assistive technology and search engines both rely on it.

Links and calls to action

Links are part of how people skim, so the words you link carry weight.

• Make link text describe the destination. Link the meaningful words, not "click here" or "read more." People tend to read only the first couple of words of a link, and descriptive text is a WCAG requirement because screen readers often list links out of context. "Read Dr. Smith's bio" beats "read more."
• One primary action per page. Secondary actions are fine, but don't let them compete. If everything is emphasized, nothing is.
• Use verbs that match what the visitor will do: "Book an appointment," "Find a provider," not "Submit" or "Go."
• Cross-link related content. Link related pages to each other so readers can follow a thread and search engines can see how the content connects.
• Don't break existing links. If a URL has to change, set up a redirect so old links and bookmarks still work. See Managing Redirects.

Writing FAQs

A well-built page shouldn't need an FAQ. If the page explains things clearly, nobody should have to hunt for the answer in a separate list. When you find yourself writing one, first ask why the main page isn't answering it.

FAQs do earn their place in a few cases:

• Objection handling. Trust questions people won't ask aloud ("Is there really no cost?").
• Search traffic. People google questions verbatim, so a direct answer that links to the action is genuinely useful.
• Cutting repeat calls. If the office keeps fielding the same question, answer it on the site, but treat that as a cue to strengthen the source page first.

When you do write one: phrase the question the way a person would actually ask it, keep the answer to a few sentences, and link back to the page where they can act.

Make it visually scannable

The layout should reward a skimming eye:

• Short paragraphs with white space between them.
• Lists for steps and series.
• Tables for anything you'd otherwise describe as "A is X while B is Y."
• Callouts for a warning, a tip, or a "read this first."
• Meaningful images with real alt text, and a caption when the image needs context.

Good for readers is good for search

Writing that's scannable, plainly worded and well cross-linked is also what search engines reward. You don't write for readers and for search separately; doing the first well covers most of the second. For the search side, see SEO Strategy → Search intent.

Before you publish

• Does the first sentence give away the main point?
• Can you understand the page from the headings alone?
• Is there one obvious primary action?
• Are paragraphs short, and long series broken into lists?
• Is every link's text descriptive on its own?
• Did you spell out acronyms and cut the filler words?
• Would it read clearly to someone outside your field? (A readability checker like Hemingway flags long sentences and dense copy.)

For day-to-day editing mechanics (pasting cleanly, previewing, what not to touch), see Editing Basics.