Design and Home Pages
Church Website Design Dos and Don'ts
The habits that help a church site and the ones that hurt it: autoplay music, splash screens, walls of announcements, low contrast and slow sliders.

Church website design fails in patterns. The same habits recur on congregation after congregation: music that starts on its own, splash screens that delay the site, walls of announcements, grey text on stained glass backgrounds. This guide separates the habits that help from the habits that hurt, and names the ones that depend on context. The Web Accessibility Initiative publishes design tips that back most of the advice below, because what helps a visitor with a disability usually helps every visitor.
The older literature of church webmastering already carried these lists as dos, donts and maybes, and the categories still work: a "do" helps nearly every congregation, a "don't" hurts nearly every congregation, and a "maybe" depends on the church, its audience, and who maintains the site after the current volunteer steps down.
Do: put the visitor's first question first
The home page should answer when, where, and what a first visit feels like before it says anything else. That means service times in real text in the first screen, a plain newcomer link, and a current photo of the congregation. The home page checklist walks the full list; as a design principle it reduces to this: the page is for the visitor who has never come, not for the member who already knows the building.
Do: keep one font family and generous text size
A single readable font, sized around the equivalent of sixteen pixels or more for body text, with strong contrast against its background, outperforms every decorative choice a team can make. Members read the site on phones, in sun, without glasses. When a draft design needs a second font "for emphasis", the page usually needs a heading or a pull quote instead, not a new typeface.
Do: design for the phone first
Most first visits arrive on a phone, often from a map result or a shared link. The mobile layout deserves the first review, not the last. Menus that collapse cleanly, tap targets the size of a thumb, and photos compressed for slow connections are the working definition of good church design in the current decade. A design that only looks right on the office monitor has failed before launch.
Don't: play music or video automatically
Autoplay sound remains the single most disliked habit in church web design, and it persists because teams test on muted office computers. A visitor opening the site in a quiet waiting room closes the tab at the first note. Autoplay animations carry a second cost: visitors sensitive to motion, and members using screen readers, both lose the page. The guide for older members covers the motion side, including the browser setting a well built site respects.
Don't: use a splash screen or an entry page
A splash screen sits between the visitor and the site, usually to show a church logo animation or a "enter site" button. It delays the answer the visitor came for, and search engines index the site behind it anyway. The historical church webmaster forums mocked splash screens twenty years ago; the advice has not changed, only the technology of the delay. If the congregation wants a moment of beauty, a well chosen photograph on the home page does the work without a gate.
Don't: bury content under sliders and carousels
Rotating banners feel active but read as wallpaper: visitors scan past them, and the slide they waited for moves before they finish it. Sliders also slow the page and hide the newcomer link behind a rotation. One strong image with one sentence and one button outperforms five rotating ones. When a team insists on rotation, the test is simple: can a visitor reach slide four's content in one tap from the home page? If not, that content needs its own page.
Don't: set text over busy photographs
White text over a photo of the sanctuary, or burgundy text over a stained glass background, fails the contrast checks that the accessibility guides set out. Even when a designer forces the text to "work" by adding a shadow, the result tires the reader. Text belongs on solid backgrounds; photographs belong beside or behind areas kept clear of text.
Maybe: dark backgrounds
A dark theme suits churches with a strong evening ministry or a media heavy identity, and some congregations simply prefer it. It demands more discipline: contrast ratios still apply, links must stay distinguishable, and print stylesheets need a light version for the bulletin crowd. A team that cannot maintain that discipline should stay on light backgrounds.
Maybe: sermon media on the home page
Embedding the latest sermon on the front page serves congregations whose members return weekly for it. It costs page weight and requires the media pipeline to stay current. The compromise that works for most churches: a small block with the latest title and a link, reserving the full player for the sermons page and the livestream setup.
Maybe: member area and login
A member login for a directory, giving history, or team scheduling helps larger congregations with real content behind the wall. Smaller churches often build the login first and the content never arrives, leaving a padlock icon that promises nothing. The decision rule: no login until the content behind it exists and someone owns its freshness.
How does a team apply the list without a committee war?
Run the page against the three lists in one sitting and mark every item present or absent. Most teams find their real problems are not aesthetic but structural: no newcomer path, autoplay inherited from an old template, news from a past season. Those fixes cost an afternoon, and they should come before any conversation about colors or fonts. When the fixes run deeper than an afternoon, the page has moved from correction to makeover territory, and the staged plan in that guide takes over. Teams that want a publishing rhythm that keeps the site honest after the fixes can start with the content section, which pairs the writing habits with the small team routines that keep them running.