Topic: Church Web site users?

Has anyone seen any documented information on users of church Web sites?

I'm working on some information now, but I don't want to reinvent the wheel if there is already some good information on general church Web site audiences.


Chris: 2 Peter 1:3,

Re: Church Web site users?

Unfortunately, in my experience building church websites and in consulting ministries in building websites, I haven't found anything that could be considered  highly informative for this specific topic. Most of what you'll find is anecdotal, at best.

There is some technology-related surveys conducted by The Barna Group ( that sheds a minuscule amount of light on the topic from an objective viewpoint. Most anything else I've found on church websites are arguments for a particular methodology. For example, should the site be a community portal or an online tract.

I'd love to know if anyone has somehow found anything more deeply informative. Aside from that, here's my own anecdotal opinions:


It's hard to get somewhere when you don't know where you're going. So start by asking the question, "What do I want this website to achieve?" Basically, the site needs a vision. Whether formally written or just kept on principle, you need a goal to aim towards.

I assume from your question, you haven't built a church site yet and either work for the church or  have been commissioned to do so. (Or possibly you're writing a report/article on the subject...) The reason I mention that is, in my experience, most churches have NO CLUE what they want the site to achieve. They just want one.

That's no good. You don't start a business or church with no purpose. The same goes for a website.

Here's the one-liner: If you fail to plan, you plan to fail. (I'd credit the original author of that line, but no one seems to know with any certainty.)


Beyond demographics (age, race, income), most websites have two primary groups of people (with varying amounts of secondary and so on) who will visit the site: brand new guests and regular visitors.

It may be obvious to you and me, but most churches (from the looks of their sites) simply assume people will show up at their site and some how (osmosis perhaps?) absorb the information they need. Until the internet technology rises to telepathic levels (which may not be far off) visitors are stuck wading through the mire of a poorly-designed site with numerous methods of organization and navigation that actually seem intended to keep the information hidden from the site visitor.

That is unless the site was designed with the needs of its visitor in mind.

For example, why should a person who just wants a church's meeting times have to decipher a poor navigation menu, then click twice just to get that information? And then, why should they have to jump around somewhere else to find the address? They shouldn't.

Nor should they have to have the latest version of Flash. Nor Internet Explorer. Nor any other latest greatest anything.

My own opinion (which I've used) is that a church's meeting times and location(s) should be easily found directly on the first page a visitor opens. THE VERY FIRST PAGE. In fact, my approach was to put that information in the header of EVERY page. Why? For the audience.

One technique I've yet to try, is to really funnel the visitors by offering distinct points of entry based on their familiarity with the church. For example, the front page (NO "INTRO" PAGES!) would have the basic pertinent info (time, location, contact) with a main upcoming event or two then prominent links (images, text, whatever) that take people to two functionally separate areas/sites (i.e. "First-Time Visitors" and "Regular Attendees") that present the info relevant to that person. I do know one large church that does this, minus the initial landing page I describe.

The fundamental point is this: Attempt to make it AS EASY AS POSSIBLE for a visitor to find the information they seek. (Possibly even at the expense of aesthetics.)


It almost seems cliché, but there are very valid (unintentional geek pun. heh.) reasons to build a site using (X)HTML+CSS.

One reason? Speed. A site that does not use tables for presentation is faster. Period. There are times when tables are appropriate. For everything else, there's CSS.

Another reason is convenience. As in: do it for the person who will update the site. This is especially important if this person is you. And if it's not, the client will (or should) be duly impressed when the site maintenance individual complements your foresight and says how nice their site was built. And the client will be especially pleased that most site-wide updates take far less time, meaning less cost. If nothing else, scare yourself into it by picturing a table-based site as a Jenga tower; every revision you make being another block removed...

And the last reason I'll cite is the hardest for many clients and designers to accept: forward compatibility. Backward compatibility is cool. Forward compatibility is teh 1337 (AKA VERY cool.) Why? well, without getting into lengthy explanations of the progress towards wide spread XML usage and database-driven, uh... everything, just imagine if tomorrow you awoke and discovered that, for the price of a cheap computer, your honda civic could now hold 100 passengers, tow 4 tons, and do both faster all while getting better gas mileage and looking exactly the same.

So make it forward compatible for heaven's sake.

I hope all this blather was helpful...