Website options for a small church, ranked by who maintains it

The most common church website failure is a service time eighteen months out of date, because the volunteer who built the site moved to Georgia and nobody has the login.

Pick the option whose maintenance burden matches the person who will actually be maintaining it. That single decision outranks templates, platforms, and design.

The five pages that do the work

A first-time visitor arrives with four questions and leaves as soon as they are answered or as soon as they give up. Answer them above the fold, in text, on the page they land on.

Home. Church name, denomination or tradition in plain words, street address, service time, and one sentence a stranger can repeat. Not a hero video. Not a rotating slider. A visitor on a phone in a parking lot needs the address at 9:52am.

Visit. Where to park, which door to use, what people wear, how long the service runs, what happens with children, and whether anyone will single you out. Write the paragraph about children’s check-in in detail, because it is the single largest source of visitor anxiety.

Beliefs. What you actually confess. Link the full confession or statement of faith rather than summarizing it into mush. People who care read it, and people who do not care skip it in three seconds.

Sermons. The last several, playable, with the passage in the title. A church with no sermon archive is asking a stranger to trust a room they cannot hear.

Contact and giving. A real email address that someone reads, a phone number, and the giving link. Do not put giving in the top navigation ahead of Visit.

Everything else, staff bios, ministry pages, the history of the building, is optional and can wait a year.

Four paths, by who maintains it

Path one: a hosted site builder, when a staff member maintains it. Squarespace and Wix both let a non-technical person edit text without breaking the layout, which is the whole value. Prices change and promotional rates are common, so check the vendor’s current pricing page rather than any figure a blog post gives you. This path is right when a paid administrator will spend twenty minutes a month on it. It is wrong when the maintainer is a volunteer who checks in twice a year, because the subscription lapses and the site vanishes.

Path two: a church-specific builder bundled with your other software. Tithely lists a standalone church website at $19 per month as of 28 July 2026, and includes websites in its All-Access bundle at $119 per month. Subsplash includes websites in its quote-only Subsplash One plan. The argument for these is that sermons, events, and giving flow from the same system you already run, so the calendar on the site is the calendar the office maintains. The argument against is lock-in: leaving takes your site with it.

Path three: WordPress on shared hosting. Still the most common church site in America and still a real option, with one condition. WordPress requires someone to apply updates. An unattended WordPress site with six abandoned plugins becomes a spam host within a couple of years, and the church finds out when its email starts landing in junk folders. Choose this only if a named person owns updates in writing.

Path four: a static site on free hosting. A site built as plain HTML or with a static generator, deployed to Cloudflare Pages or a similar host. Cloudflare’s free plan serves static assets with unlimited requests, so a church site costs nothing but the domain. This is nearly unbreakable, extremely fast, and impossible for a non-technical volunteer to edit. Correct when a developer in the congregation has committed to a term, and correct for a church plant that needs five pages that will not change for a year. Wrong for everyone else.

There is no path where a church gets a site that is free, beautiful, and editable by anyone. Pick which two you need.

Own the domain and the email, and prove it

This is the part churches get wrong in a way that costs money later.

1. Register the domain in an account owned by the church, with billing on a church card and the login in the church password vault. Not the youth pastor’s personal Namecheap account.
2. Two people have access. The administrator and one elder. A domain that expires because the only account holder left the church is recoverable sometimes, expensively, and sometimes not at all.
3. Turn on auto-renew and set the expiration date as a calendar reminder anyway.
4. Church email lives on the domain, not on a personal Gmail address. pastor@yourchurch.org survives the pastor. Google and Microsoft both run nonprofit programs that many churches qualify for. Apply through their nonprofit portals and confirm your own eligibility rather than trusting a summary.
5. Write down where everything lives. Registrar, host, DNS, email, analytics, who pays, and the renewal dates. One page, in the office, on paper. This document is worth more than the website.

Launch order for one weekend

Friday evening through Sunday afternoon is enough time if you stop trying to design.

1. Write the words first, in a plain document. All five pages. This takes the longest and has nothing to do with software. Read the Visit page out loud to someone who has never attended.
2. Take photographs of your actual building, your actual doors, and your actual people, with permission. Stock photography of a stone church that is not your stone church tells a visitor the site is fiction. A phone camera in good morning light is fine.
3. Register the domain and set up email. Do this before the site, because DNS changes take hours to propagate.
4. Build the five pages. Resist adding a sixth.
5. Test on a phone, on cellular data, with the screen brightness low. That is the actual reading condition. If the service time is not visible without scrolling, fix that before anything else.
6. Check the address against Google Maps and your Google Business Profile. Matching hours, matching address, matching phone. Mismatches push you down in local search results.
7. Publish. Then set one recurring calendar event for the person who owns it: fifteen minutes on the first Monday of each month to check service times, upcoming events, and staff names.

Five things to cut before launch

• The auto-playing video header. It costs a second of load time and hides the address.
• A slider with five rotating messages. Visitors read the first one, maybe.
• A chat bubble. Nobody is staffing it.
• A countdown to the next service. It says nothing a service time does not.
• The pastor’s blog with two posts from 2021. An abandoned section signals an abandoned church. Delete it or commit to it.

When to pay a designer

Pay for design when your church has a genuine visual identity to carry, when you have real photography, and when the words are already finished. A designer handed unfinished copy will fill the layout with placeholder language that becomes permanent.

Do not pay a monthly retainer for a five-page site that changes twice a year. Pay once for the build, get the files and the accounts in the church’s name, and hold a written agreement that says the church owns the design and the domain outright.

If the words on the site still feel thin after all this, the problem is upstream. Fix the announcements and the invitation language first, using church announcement examples, and give a visitor somewhere to land with a guest follow-up system one volunteer can run.