A church website has five jobs, and they are all for someone who has never been through the door: say when and where the services are, say what to expect on a first visit, make giving possible in two taps, put the latest sermon one click from the homepage, and give a way to get in touch. Everything else, the history, the ministries, the staff page, matters to people who already attend and belongs one level down. Get the five right on a phone screen and the site is doing its work, whichever platform it is on.
The pages that rank for this term are galleries of beautiful examples, and the examples are genuinely useful for seeing what good looks like. What they leave out is the decision a church actually has to make: who builds it, on what, who updates it on Wednesday when the service time changes, and what it costs to keep online for the next five years. This post is that decision, with the examples’ lessons folded into the first section.
Table of contents
- The five jobs of the homepage
- Who updates it on Wednesday
- The platform decision
- Giving, safely
- Being found locally
- What it costs to keep online
- How this fits the rest of the stack
- FAQ
The five jobs of the homepage
Look at the church sites people hold up as examples and the same pattern repeats. The homepage is built for a visitor, on a phone, in the car park, ten minutes before a service. It answers their questions in this order.
- When and where. Service times and the address, above the fold, with a map link. Not in the footer, not on an About page.
- What to expect. A short plain-language paragraph or a Plan Your Visit page: parking, how long it lasts, what happens with children, what to wear. This is the page first-time visitors read most and churches build least.
- Give. A giving button in the header and on the homepage, leading to a form that works on a phone. If giving is three taps away it is one tap too far.
- Watch. The latest sermon or a livestream link, one click from the homepage, and the archive one click behind that.
- Connect. A contact form, a phone number, and the next steps someone might take: a newcomers’ event, a small group, a volunteer signup.
The example galleries also agree on the aesthetics, and they are right: photographs of people rather than the building, a small number of colours used consistently, short text, and a navigation that fits on a phone. The restaurant SEO post makes the same argument for a different kind of local organisation: the site is for the person who has not visited yet.
Who updates it on Wednesday
Before choosing a platform, answer this. Church websites fail not at launch but eighteen months later, when the person who built it has moved on and the Christmas service times are wrong. Whoever will update the site next year, usually an office administrator or a volunteer, should be able to change a time, add an event and post a sermon without calling anyone. That constraint eliminates most of the clever options.
The realistic answers are: a hosted website builder with a simple editor, a WordPress site with a theme the volunteer can operate, or a static site that a technical member of the congregation maintains from a repository. Each is a fine answer for a different church, and the next section is the comparison.
The platform decision
- Church-specific builders. Templates that already have sermons, events and giving built in, on a monthly subscription. The fastest route to a competent site, easy to update, and the least control over design, data and cost, which rises with the congregation and the features.
- General website builders. Cheaper and more flexible than the church-specific ones, with giving and sermons added through integrations rather than built in. Fine for a small church whose site is mostly information.
- WordPress. The most common choice for churches that want ownership of the site and the data. Sermon and event plugins are mature, giving integrates through any of several providers, and any freelancer can work on it. The trade is maintenance: updates, backups and hosting are someone’s job, and the managed WordPress post explains what it means to make them the host’s job rather than the volunteer’s.
- A static site. For churches with a developer in the congregation. Fastest, cheapest to host, nearly impossible to break or hack, and updates go through a repository, which is the constraint from the previous section in a different form. Works well when a simple content editor is put in front of it.
The honest summary: a builder if nobody technical is around and the budget is monthly; WordPress if the church wants to own the site and can pay someone, host or freelancer, to maintain it; static if a developer is willing and the editing workflow is agreed in advance.
Giving, safely
Online giving is the feature with the highest stakes, and the rule is simple: never handle card details yourself. Use a giving provider, embed its form or link to its hosted page, and let it carry the compliance. The website’s job is to make the button obvious and the page fast. Recurring gifts, a mobile-friendly form and a receipt by email are the features that matter; a custom checkout is not.
Two things the site does need to do well. It must be served over HTTPS with a valid certificate, because a giving page with a browser warning loses the gift. And the giving page must load quickly on a phone, because that is where most gifts are made. Both are hosting properties, and both are reasons to prefer a host that issues certificates automatically over one that leaves it to the volunteer.
Being found locally
Most first-time visitors search for a church near them, by denomination or by neighbourhood, and the results are dominated by the map listing. Claim it, keep the hours and address correct, and add photographs. On the site itself, put the town and neighbourhood in the page title and the first paragraph, mark up the organisation and its events with structured data, and make sure the site loads fast on a phone, since speed is a ranking factor and the site will be found on a phone. The submitting a website to search engines post covers the mechanics of getting a new site indexed at all.
A blog is optional and usually neglected. A sermon archive that is actually updated is a better use of the same effort, and it produces a page a week without anyone writing an article.
What it costs to keep online
Build cost is a one-off and varies enormously, from a volunteer’s weekend to a small agency’s invoice. Running cost is the number that matters over five years, and it has three parts: the domain, the hosting, and the subscriptions for giving, email and any builder.
The hosting part depends on the platform. A builder bundles it into the subscription. A static site is close to free to host: on RunxBuild a static site build from a repository includes a custom domain, an automatically issued certificate and 120GB of monthly bandwidth, which a church site will never approach. A WordPress site on managed hosting starts at $3 a month on the Starter plan and $5 on Mini, with automatic certificates, backups, a file manager and a database browser in the dashboard, so the volunteer who needs to fix a plugin can do it without SFTP. The deploy WordPress guide walks through the first setup.
Whichever option, write the running cost down with the domain renewal date and the login details, and keep it with the church’s other records. The website outlives the person who built it, and the next person needs to know where it lives.
How this fits the rest of the stack
A church website is a small site with a clear job, and the platform matters less than whether someone can update it next year and whether it stays online without attention. The RunxBuild hosting calculator shows what static hosting or a managed WordPress plan costs beside the domain and the bandwidth, so the five-year figure is a real number to put in front of the finance committee. Build for the visitor in the car park, keep the giving page fast, and write down where the site lives.
Useful related references:
- Freelancer Portfolio Websites: Getting One Online, Not Just Designing It
- Restaurant SEO: The Technical Half Local Guides Leave Out
- Squarespace vs WordPress: The Question Behind the Question
- Managed WordPress on RunxBuild
FAQ
What should be on a church website homepage?
Service times and the address above the fold, a plan-your-visit section for first-time visitors, a giving button that works on a phone, the latest sermon or livestream one click away, and a contact form. Everything for existing members, such as ministries and staff pages, belongs one level down.
What platform should a church use to build its website?
A church-specific or general website builder if nobody technical is available and a monthly subscription is acceptable; WordPress if the church wants to own the site and can pay a host or freelancer to maintain it; a static site if a developer in the congregation will maintain it and an editing workflow is agreed. The deciding question is who will update it next year.
How much does a church website cost?
Build cost ranges from a volunteer’s time to an agency invoice. Running cost is the domain, the hosting and any subscriptions. Static hosting can be close to free; managed WordPress hosting starts at a few dollars a month, from $3 on RunxBuild; builder subscriptions are higher and rise with features. Write the five-year figure down, not the launch figure.
How should a church take donations online?
Through a giving provider, never by handling card details on the site. Embed the provider’s form or link to its hosted page, make the button obvious in the header and on the homepage, and make sure the site is served over HTTPS with a valid certificate and loads fast on a phone.
Does a church need a mobile app as well as a website?
Usually not. Most of what an app offers, sermons, events, giving and notifications, a mobile-friendly website with a giving provider and an email list does as well, without a second thing to maintain. An app makes sense for a large congregation with a dedicated communications team.