What your church website tells strangers about your members (and how to check in ten minutes).

Be thou diligent to know the state of thy flocks, and look well to thy herds.Proverbs 27:23, KJV

A church website looks like one thing: your pages, your photos, your sermons, on your address. Underneath, most of them are a small crowd. The fonts come from one company. The video player comes from another. The map on the directions page, the chat bubble in the corner, the "analytics" the web designer added in 2019 and nobody has looked at since — each of those is a separate company whose computers are contacted, by your visitor's browser, every time a page opens. Not by you. By the person sitting in your pew, on her phone, at 11 p.m., looking at the prayer list.

None of this is secret and very little of it is malicious. It's just how the web is usually built, and almost nobody explains it to the church. This is the explanation, followed by a ten-minute way to check your own site. You don't need a technical person. You need a laptop, the browser already on it, and a pencil.

What actually happens when a page loads.

When someone opens yourchurch.org/prayer, their browser asks your web host for the page. The page comes back as a list of instructions, and some of those instructions say, in effect, "now go fetch this from somewhere else." A font file from a font company. A video player from a video platform. A map from a map company. A tiny invisible image from an advertising network. The browser obeys each one, and each one is a separate conversation between your member's phone and a company your church has no relationship with.

What each of those calls hands over.

This part isn't a theory about what companies do; it's how a browser request works. Every time a browser fetches anything from a server, the server receives, at minimum:

So the honest sentence is this: if your prayer page loads a piece from an outside company, that company is told that someone at this address opened your prayer page, at this time, on this phone. What they do next is up to their policy. But the church has already handed the receipt over, and no policy the church writes can get it back.

The prayer-request page is the one that matters.

On the home page, none of this is worth losing sleep over. A stranger learning that someone looked at your service times is not a harm. The pages that matter are the ones people visit when something is wrong: prayer requests, a counseling or benevolence page, a grief-support group, a page about addiction recovery, the giving page. A visit to those pages says something about the visitor that they did not choose to say to a stranger, and the referrer carries the page address with it.

The same is true for what's on the page. If your prayer list is public and it names people and their diagnoses, then every outside piece on that page loads next to that text — and if one of those pieces is a script that runs in the page (a chat widget, most analytics), it can read the page. Most don't. Some do, on purpose, to "improve the experience." The church has no way to know which, and no way to audit it.

The usual suspects.

On the church sites I've looked at, the outside calls almost always come from the same short list. None of these is exotic. That's the point: they're the defaults.

Check your own site in ten minutes.

You are going to use the built-in inspector every desktop browser has. It sounds technical; it's a panel that lists what the page fetched. You can't break anything from here — it's read-only.

1. Open a private window. In Chrome, Edge, or Firefox: Ctrl+Shift+N (or P in Firefox); on a Mac, ⌘ instead of Ctrl. Safari: File → New Private Window. This keeps your own logins and extensions out of the picture.
2. Open the page that matters. Not the home page — the prayer-request page, or the giving page.
3. Open the inspector. Press F12, or Ctrl+Shift+I (⌘+Option+I on a Mac). A panel appears. Click the tab labeled Network. In Safari, first turn on Settings → Advanced → "Show features for web developers," then the Develop menu → Show Web Inspector.
4. Reload the page with the panel open (F5 or ⌘+R). The panel fills with rows — every single thing the page fetched.
5. Find the "Domain" column (Chrome: right-click any column header and tick Domain; Firefox shows it by default). Click the header to sort by it.
6. Write down every domain that isn't yours. Ignore rows that end in your own church's domain. Everything else is an outside company. Count them. That number is the answer to "who is my member's phone talking to when she opens the prayer page?"
7. Do it again for the home page and the giving page. Different pages often carry different widgets.

If the inspector feels like too much: right-click the page, choose View Page Source, press Ctrl+F, and search for https://. Every hit that isn't your own domain is a place the page reaches out to. It's a cruder count — it misses things that scripts load later — but it's a real one, and it takes two minutes.

Reading what you found.

You'll have a short list of domains. Some names will be obvious; some will be gibberish, which usually means an advertising or measurement network. Sort them into two piles with these questions:

You don't have to fix all of it. The goal of the ten minutes is a list on paper, with a count, that the pastor can look at. Most churches have never seen theirs.

What to ask your provider.

Take the list to whoever built or hosts the site — the volunteer, the company, the platform's support line — and ask, in writing:

A good provider answers all six plainly. A provider who can't answer the first one doesn't know what their own site does. A provider who won't answer the last one has told you what you needed to know.

What you can fix this week.

Most of the list comes off without a redesign. In rough order of easy-to-hard: delete analytics nobody reads; remove social share bars and "Like" buttons; replace the embedded map with a static image and a "Get directions" link that opens the visitor's own map app; make the sermon video load only after a click (a poster image with a play button) rather than on page load; download the fonts and serve them from your own host; and move any form that handles prayer or counseling requests to something stored on your own hosting, or to plain email. Each one is a small job for whoever maintains the site. Together they take a page from a crowd of six companies down to one — yours.

A one-paragraph policy.

Once the list is short, keep it short. Put a paragraph in the church's file, next to the domain map from the last entry: "Our website loads from our own hosting only. We don't add outside scripts, widgets, or embeds without the pastor's sign-off, and we list the ones we have here. Prayer and counseling pages never load anything from outside." It takes a minute to write and it outlives the volunteer. The next person who's handed the login will know what the church decided, and why.

That's the whole thing. It isn't about fear of the internet; it's about the same care a church takes with a membership roll or a counseling note. Your members trust the building. The website should be worth the same trust.