Church websites run by volunteers
A practical guide to church websites kept by volunteers: what belongs on a home page, accessibility for every visitor, and how the platform and content get
A church website kept by volunteers works when the home page answers four questions in the first screen: where the building is, when services happen, what a first visit is like, and how to get in touch. Everything else, including live streams, podcasts and online giving, belongs one click deeper. The platform matters less than the content behind it, and accessibility is not a separate project: it is the same work as writing clear pages.
The Church Web Review, a practical magazine for the volunteers and communication teams who maintain congregational sites, covers these three areas in depth at church website design and content, and its structure is a useful map for anyone starting a rebuild.
What belongs on a church home page?
A home page carries the information a stranger needs before deciding to walk in. In practice that means the street address written as text, not baked into an image, plus a map link; the regular service times with the day of the week spelled out; a short paragraph describing the building, the entrance and the parking; and a phone number or email that a person actually monitors.
Beyond those four items, a home page benefits from a single clear action, such as a link to a page titled What to Expect. That page answers the questions visitors are too polite to ask: what people wear, how long the service runs, whether children stay in the room, whether there is coffee afterwards, and which door to use. Writing it once saves the greeters from repeating the same answers every Sunday.
Classic design errors are worth naming because they recur. Full screen splash animations delay the moment a visitor sees the address. Autoplaying audio startles anyone browsing in a quiet room. Carousels rotate the one piece of information a visitor came for, the service time, out of view. A home page that loads in under three seconds on a phone and states the address in plain text outperforms a more elaborate one on every measure that matters.
A rebuild does not have to cost the search ranking the site already has. Keeping the existing URLs, or redirecting each old address to its new equivalent with a 301 response, preserves the links and the local search position that took years to accumulate. Deleting pages without redirects is the most common way a congregation loses the visitors it had.
How do you make a church site accessible to every visitor?
Accessibility is the practice of making the site usable by people who are blind or have low vision, people who are deaf or hard of hearing, people with colour vision deficiency, and older members of the congregation. Most of the work is concrete and cheap.
Text contrast is the first item. Body text should reach a contrast ratio of at least 4.5 to 1 against its background, which rules out light grey type on white and pale yellow on cream. Colour should never be the only signal: a red link in a paragraph is invisible to a reader with deuteranopia, so links need underlines as well.
Images need alternative text, which is a short description of what the image shows, not a repetition of the caption. A photograph of the choir can be described as the choir in the sanctuary on Easter morning. Decorative images take an empty alt attribute so screen readers skip them.
Video needs captions, and any audio needs a transcript. A live stream without captions excludes deaf members, and a recording published without a transcript is not searchable. Autoplay should be off by default, with controls visible and keyboard reachable.
Text size should be set in relative units so a reader who enlarges the page to 200 percent still sees the layout intact. Navigation should work with the Tab key alone, in a visible order, because some visitors cannot use a mouse. Forms, including giving forms, need labels attached to their fields rather than placeholder text that disappears on typing.
Older members are often the largest group affected. Larger default type, generous line spacing and short paragraphs help them more than any dedicated accessibility menu.
Which platform and tools should a volunteer team choose?
The honest answer is that the platform should match the skills of the people who will maintain it, not the ambitions of the person who builds it. A volunteer team of two who post once a week are usually better served by a hosted service built for congregations than by a general content management system that requires plugin updates and security patching.
A dedicated church platform typically bundles events, sermon archives, giving and a member directory. A general CMS offers more freedom and more maintenance. The deciding questions are who will apply updates when the maintainer moves away, and whether the congregation can export its own content if it decides to leave.
Hosting cost is usually quoted monthly but should be compared annually, including the domain name, any email service, and the fees taken by the online giving processor. A processor that keeps a percentage of each gift can cost more over a year than a higher monthly hosting bill.
Live streaming and podcast distribution are separate decisions from the website. A stream can be embedded from a video platform, which shifts the bandwidth cost to that platform, while a podcast needs an audio file and a feed that podcast apps can read. Both should be linked from a page that also states the regular schedule, so a visitor knows when to return.
How is the content behind the site written and found?
Content is the part volunteers underestimate. A page titled What to Expect, a page listing service times, a page for each regular group, and a page with the address and contact details cover most of what visitors search for. Each page should have one subject and a heading that names it.
Local search depends on consistent details. The congregation's name, address and phone number should appear in the same form on the site, on the map listing and on social profiles. Search engines compare these records, and mismatches weaken the result. A page that names the neighbourhood or town in its text helps more than a list of keywords.
Sermon archives benefit from a date, a title and a one sentence summary, which makes them findable months later. Event pages should be removed or archived once the date passes, because a calendar full of past events tells a visitor the site is abandoned.
Writing for the web means short sentences and front loaded paragraphs. The first sentence of each section should carry its point, since many readers scan headings and first lines only. Plain language serves everyone, including readers using translation tools and readers with cognitive disabilities.
Who should maintain the site, and how is that decided?
A site survives when one named person is responsible for it and at least one other person knows how to reach the hosting account. The named person does not have to write the content; they publish what others write. This split between writing and publishing keeps the site current without overloading a single volunteer.
A short handover document, stored where the congregation can find it, should list the hosting provider, the domain registrar, the login recovery email, the giving processor and the person to contact for each. Without it, a change of volunteer can leave a site unreachable for weeks.
Reviewing the site once a quarter is enough for most congregations. The review checks that service times are correct, that the contact form still delivers, that no page shows a past event as upcoming, and that the site still loads quickly on a phone. These four checks catch most of what goes wrong between rebuilds.
The same discipline applies to a folio: an edit is an argument, and the order of works carries it. A portfolio entry states its own terms, how the sequence was chosen, how each piece is captioned, and which technical checks the files pass before anyone opens them. the folio edit described here treats those decisions as the subject rather than the decoration, which is the point of practice shared with this entry: nothing is shown until the reason for showing it is settled.
The same question of shared access runs through the history of computing outside the studio. Before home connections were common, terminals in libraries and community centres served as the public's entry point to networked machines, and the organisations behind them kept their own records of who used them and how. That history is set out in the reference's note on free-nets and community computer networks, which covers what a free-net was, how people used one, which community network opened to the public first, and what public internet access looks like today.