Technology & Your Ministry Blog | Concordia Technology Solutions

Under the Hood: The Hidden Parts of Your Church Website

Written by Rev. Bill Johnson | Mar 18, 2025 11:00:00 AM

We’ve heard the story for years now: “Every congregation needs a website”; but the simple reality is that many congregations simply don’t have the knowledge or skills to create and support a site that will be beneficial to the church and its community. I’ll write more on overall strategy in a later post, but for today, I’d like to provide a brief introduction to the various moving parts that make up a website.

The goal here isn’t to make you into an IT genius, but simply to give you the basics so you can understand the various components that go into a site, and what the various parts of the packages website hosting companies offer to congregations actually do.

Server/Hosting Service

The first piece that’s needed to host a website is a web server that’s connected to the internet. Odds are that your congregation doesn’t have the staff to connect, maintain, and secure a server, so you’ll probably end up purchasing space on a server from your hosting company. This will likely be a server that hosts many sites, including yours, and so the performance of your site may vary depending on the activity level of the other sites on your particular hosting server. Web servers commonly run Linux and use a package called Apache for their web hosting. Apache is the old man of web servers. It’s not necessarily going to be the fastest, but it’s stable, extensible, and widely supported. It gets the job done. A slightly newer Linux option is Nginx (pronounced Engine-X). It’s younger and more agile, and it tends to perform faster than Apache, but isn’t as widely supported. Either will do in most cases, and honestly, most church websites aren’t seeing enough traffic for the difference to matter much. On a Windows server, there are options for Microsoft’s Internet Information Service, as well as ports of Apache and Nginx for Windows.

Domain Name/DNS

Now that you have your server sorted out, you need a way for people to find you on the internet. The problem here is that the internet runs on numbers, not names, much like our phone network. Some of us are still old enough to remember having to memorize phone numbers to be able to call people, but today we can just click their name/picture/contact and the technology handles the numbers. The internet works the same way. Every machine on the internet has an IPv4 address (Internet Protocol Version 4) that consists of four numbers, each between 0 and 255. (In reality, this is actually four sets of eight bits, and 28=256.) So your machine’s IP public address might be 192.168.100.2, for example. (It’s not, but we’ll deal with that another day …) You can see yours by going to whatismyip.com. There you’ll see your IPv4 address, as well as IPv6 addressing, which is a wider address space that allows many more devices to connect to the internet and is coming any day now—and has been coming any day now for the past decade or so. You can ignore IPv6 for now. The system that translates site names (like www.whatismyip.com) into number addresses is called DNS (Domain Name System).

A DNS address typically consists of three or more parts. Working backward from the end of the address, we have the Top Level Domain, or TLD for short. When the Internet first came into the public realm, ICANN (Internet Corporation for Assigned Names and Numbers) kept things pretty tightly controlled, with seven available TLDs: .edu, .net, .com, .mil, .gov, .org and .int (good information to know for trivia night). Since then, things have opened up tremendously, so you’re likely to see TLDs like .church or .website. To my knowledge, the only TLDs that remain tightly controlled are .edu (maintained by Educause), .int, and .mil.

The second piece of a DNS entry belongs to the organization that owns the domain name. You can actually look up who owns a domain name at lookup.icann.org/en, but be aware that many domain owners choose to keep their contact information confidential these days for security reasons.

Any pieces before the domain name itself are specific computer names or site names for that organization. For example, here at Concordia Theological Seminary, Fort Wayne, we use www.ctsfw.edu to point to our main web server, but we’ll use myclasses.ctsfw.edu to point to our learning management server (where students and faculty can find digital resources for classes, etc.).

Code/Content

Once you have a server and a way for people to reach it, you need the actual “meat” of your website. There are a few ways to approach this. The old-school way is to hand-code the site using a text editor or development environment. This is actually what I prefer personally, because it gives me full control over the site and how it displays, but it’s overkill for many church websites and it definitely makes updates more difficult. For most church websites, you’re going to want some kind of Content Management System, or CMS. There are a ton of options out there, including Wordpress, Drupal, and CTS’s Church360° Unite

Many hosting companies will support one or more CMS systems as a part of their hosting packages, so be sure to check which ones they offer when signing up. Once you have a base CMS up and running, you’ll want to look at the various theming and branding options that are available. Most CMSs have tons of themes, with some free and many being available only through premium licensing. Be sure to look closely at the licensing to see if the theme is a one-time payment or an annual subscription.

From there, you can begin to create content for your site. The methods vary depending on the CMS platform you’re using, but most are pretty straightforward and allow you to edit using a visual WYSIWYG (What You See Is What You Get) editor.

Database

I debated whether to even mention this piece, because, frankly, you’re not going to deal with it directly most of the time; but if you’re running a CMS, then somewhere back behind that is a database system/server. Chances are it’s on the same machine as the website, and your hosting provider will have selected and set up database modules that work with the CMS platforms they support. It’s there, and you should be aware of it, if for no other reason than ensuring that regular backups are a part of the hosting provider’s standard procedures.

Hopefully this has been a helpful overview of the things to look for and ask about when considering hosting services for a congregational website. In most cases, you’ll find these services bundled together, which is fine, but it’s helpful to know what you’re looking at when considering your options!

All of this information can be overwhelming, but with Church360° Unite’s easy-to-use WYSIWYG editor, creating your website can be a piece of cake!