Tools, Hosting and Giving
Choosing a Church Website CMS
How a church team should choose its CMS: who edits, what it must publish, sermon media, giving links, costs, and the exit question nobody asks.
Every church website runs on something: a general purpose content management system, a platform built for churches, or a page builder a volunteer once assembled and nobody since dares touch. The choice decides who can edit the site, what it costs each year and how easily the congregation can leave with its content when it must. This guide walks the decision axes in order, without ranking vendors, because the right answer depends on the people, not the product.
The standing example throughout is WordPress, the open source CMS that runs a large share of the web, including many church sites, published and documented at wordpress.org. It illustrates the general purpose path: rich, flexible, free in license, and demanding of the team that runs it.
Who actually edits the site?
The first question is not technical. It is: name the people who will publish on a Tuesday night when the pastor sends the announcement. If the answer is one volunteer with web experience, a general CMS works and grows with that person. If the answer is a rotating cast of office staff and ministry leaders who will each touch the site twice a year, a church platform with a constrained editing screen and phone support serves better than a flexible system that intimidates. The graveyard of church websites is full of flexible systems that only one person could operate, who then moved away.
What must the site publish?
A CMS for a church publishes a predictable set: pages, news or announcements, events with dates, sermon media, staff listings and a contact path. The general CMS handles all of it with plugins and configuration. The church platform handles all of it out of the box, including the pieces unique to congregations: a sermon library with series and scripture fields, a members directory, registration for Vacation Bible School. The gap shows at the edges: the church that wants an unusual thing, a lecture archive, a private prayer wall, finds plugins abundant in the general ecosystem and absent in the constrained one.
How do sermon media and giving fit in?
Sermon media deserves its own look, because it drives both storage and workflow. The platform that embeds a sermon player, an audio podcast feed and archive pages natively saves the volunteer the plumbing described in the streaming guide. Giving integration follows the same pattern: a church platform bundles a giving provider, convenient and coupled, while the general path means choosing a payment processor and building the page, with the trust details covered in the giving guide. Neither path is wrong; the church should know which it is choosing, and what it costs to reverse.
What does each path really cost?
The general CMS costs a license of nothing, hosting that scales from a few dollars a month to whatever traffic demands, and time: updates, backups, security and the occasional plugin conflict, laid out in the hosting guide. The church platform costs a subscription, typically tens of dollars a month at entry level, that bundles hosting, support, updates and often giving fees on top. The free looking option, a volunteer's spare server or a donated plan, costs nothing until it costs the site. Teams comparing quotes should write both columns, money and hours, and be honest about which the congregation has.
What is the exit question?
Nobody asks it at signing: how does the congregation leave? The general CMS, built on open source software and exportable content, lets a church pack its pages, media and database and move to another host in an afternoon. Church platforms vary: some export everything cleanly, some export content but not the design, some hold the sermon archive hostage to the subscription. Before signing, the team should ask for the export in writing: what formats, what media, what happens to the member and giving records. The question sounds paranoid at the kickoff meeting and prescient at the departure one.
How do addresses survive the move?
A CMS change rewrites the site's URLs unless someone plans otherwise, and the addresses carry the congregation's search visibility: the sermons page a seminary links to, the what to expect page that ranks for the town's searches. The move belongs to the makeover guide's redirect stage, and the CMS choice should be tested against it: does the platform allow arbitrary permanent redirects from old addresses to new pages? The church platform that answers "no" has quietly priced the congregation's search history into its subscription.
What about accessibility and editing discipline?
Whatever the system, the editing screen decides whether captions, alt text and honest headings happen. The general CMS offers fields for image descriptions and heading structure and leaves them to the editor's habits; the good church platforms prompt for them. Either way, the discipline lives in the accessibility section, and the CMS choice only removes or adds friction. Teams should test the editor with their least technical volunteer before committing: hand over a sample announcement and watch, silently, what happens.
Where does a team start on Monday?
Write the two lists before looking at any product: the people who will edit, by name, and the things the site must publish, by page. Then take the three candidates the team already knows of, and score each against the six axes above: editors, content, media and giving, cost in money and hours, exit, and redirect support. The short list usually collapses to one on the editor question alone. Whatever survives, run it against the publishing habits in the content section: a CMS the team can operate, publishing words people read, is the whole of the prize.