Writing for Church Websites

People do not read church websites; they scan them for an answer, usually while standing in a parking lot. Writing for the web means accepting that and structuring pages so the scanner wins: the answer in the first sentence, short paragraphs under a honest heading, plain words over insider vocabulary, and dates no one has to decode. This guide sets the habits, page by page, from the What to Expect page to the sermon notes, and points to the government's plain language discipline as the standing reference for sentences that work the first time.

Nothing here requires talent, which is the point: web writing is a craft of habits, and a congregation that holds them writes better pages than a talented volunteer who breaks them.

Why do scanners decide everything?

A visitor arrives with a question: what time, what should I wear, is there childcare, how long does it run. The page either answers in the first screen or loses the reader to the back button. Writing for the scanner means the first sentence of every paragraph carries its point, headings describe what sits beneath them, and nothing important hides in a paragraph's last line. The test is mechanical: read only the headings and the first sentences, in order, and see whether the page still makes sense. If it does, the scanner wins, and so does the congregation.

What should a What to Expect page say?

The What to Expect page answers the nerves, not the doctrine. How long the service runs, in minutes, honestly. What children do during it, and where. What people wear, described without the word "casual" if possible, because a visitor does not know what casual means in this room. Where to park, which door to use, what happens at the door when they arrive, and whether anyone will single them out, because the fear of being asked to stand and introduce themselves keeps more visitors home than any theology. The page earns its trust by being specific: "about seventy five minutes", "the greeter in the yellow lanyard", "no one will call on you". The writing habit it teaches, answering the actual unasked question, belongs on every page the site publishes.

Which words should the page avoid?

Insider vocabulary: ministry acronyms, building names only members know, denominational shorthand, seasons assumed rather than explained. "The WMC meets in the Fellowship Hall after second service" answers nothing for a newcomer; "the Women's Ministry Council meets in the lower hall, behind the kitchen, after the eleven o'clock service" answers everything. Each expansion costs the writer six words once and saves every reader forever, the trade the plain language discipline is built on. When a term must stay, the page defines it the first time it appears.

How should dates and times be written?

In full, in text: "Sunday, March 8, at 10:30 in the morning", not "3/8" and not "10:30 a.m. Sun". Numerical date formats read differently across cultures, abbreviations assume a calendar the visitor may not share, and dates inside graphics are invisible both to search engines and to the screen readers described in the low vision guide. The full written date costs one line and ends the ambiguity. The same rule applies to the home page's service times block, where the full schedule reads more slowly but answers more completely than "Sundays 9 and 11" alone.

What makes an announcement work?

An announcement answers four things in order: what, when, where, who to ask. The youth retreat post that opens with a paragraph of enthusiasm and reaches the date in the fourth paragraph has already lost the reader the sign up needed. The working template is three sentences: the event and who it serves, the date, time and place in full, and the contact path in real text. One photo if it helps, alt text included. Then the announcement retires the week it expires, the discipline the home page checklist enforces with its dated news block.

How should sermons be published?

The sermon page serves three readers: the member who missed the week, the visitor previewing the church, and the search engine indexing the teaching. All three need the same metadata: date, preacher, title, scripture passage, in real text, above the player. A short summary, three sentences written by whoever posts the recording, gives the scanner something to read and the search engine something to index; the full transcript serves deaf members and deep readers alike, the habit the deaf and hard of hearing guide sets out and this one inherits. A sermon archive without titles and passages is a shoebox; with them, it is the church's public teaching record.

What about the newsletter?

Newsletters migrate to the web badly when they arrive as a scanned PDF, unreadable to screen readers and unsearchable by anyone. The web version publishes the same content as pages: the announcements in the announcement format, the events on the calendar page, the letter from the pastor as a page with a date. The PDF remains available for printing, never as the only home of the information, a rule the accessibility guides state and this one repeats because it breaks most often here.

Where does a team start on Monday?

Rewrite the What to Expect page first, in the visitor's own questions, in full sentences a newcomer would use. Then run the headings test across the five most visited pages, reading headings and first sentences only. Then fix the dates: every numeric date expanded, every date inside a graphic moved into text. The three fixes take an evening, and they put the site's voice where its design already points, in the scanning, plain, current writing that serves the oldest and newest members alike, the balance the older members guide describes from its side of the room.