Church website checklist, from 203 real sites, worst item first

Every article written about church websites in the last ten years opens the same way. Put your service times on the homepage. Nobody can find when you meet. Your visitors are leaving.

We went and counted. Of 203 church websites that answered a request, 195 print a service time on the homepage. Within one click of the homepage, 202 of the 203 do. Exactly one site in the whole sample states no service time on its homepage or on a page linked from it. The single most repeated piece of church website advice in the English language is advice for a problem that, in this sample, was already solved.

What is missing is a different list, and every item on it is invisible to the person who owns the site. 187 of the 203 sites publish no structured data identifying the organization as a church, a religious organization, or even a place. 173 publish no service hours a machine can read, which means 168 congregations have put their gathering time on the page for a human being and published nothing at all for the software that answers “what time is church” on a phone. 156 show a phone number a visitor cannot tap.

This page is the checklist, ordered by how many of the 203 sites fail each item. Fix the top of the list first. The bottom of the list is where the advice industry lives.

What was crawled, and what this sample is not

Every church in the Church Posting register that carries a website URL was requested once, on 30 July 2026 UTC, which was the evening of 29 July in US Eastern time. 209 sites were attempted. 203 returned an HTML homepage and were analyzed. The other six are counted separately and never folded into a denominator: three refused the request with an HTTP 403, two disallowed this crawler in their robots.txt, and one served a certificate chain that does not verify on a clean client. A 403 from a bot-protection layer is that layer rejecting a declared crawler, and it is not a defect in a church website.

The method was one HTTP GET per URL, sequential, one request in flight, 1.5 seconds between requests or longer where a site declared a Crawl-delay, with a 15 second timeout. No browser. No JavaScript executed. No images, scripts or stylesheets fetched. robots.txt was read and obeyed per origin including redirect targets, and where it could not be read the site was left alone rather than crawled anyway. Homepage plus at most three linked pages, and the extra pages were only requested when the homepage was missing something.

The sampling frame is not random, and no figure here describes American churches generally. These are the churches editors found and researched, which selects for congregations whose websites were good enough to find in the first place. The mix is 70 Presbyterian Church in America, 40 Reformed Baptist, 21 Baptist, 21 Orthodox Presbyterian, 11 Presbyterian, 10 Lutheran Church Missouri Synod, and a tail of about twenty other affiliations. Cite it as “203 church websites from the Church Posting register, checked 30 July 2026”. Do not cite it as “US church websites”, because these sites are more likely than average to publish a service time and less likely than average to be missing altogether.

One more thing to know before any number below gets quoted. The service-time measure is a proximity test: a clock time within 80 characters of a weekday name or a service word. A day name sitting near an unrelated event time can register as a service time, so the measure overstates presence. That makes the count of sites without a time the conservative direction, and it is the direction every claim on this page is built on.

The raw aggregate is published as a CSV of every count in this chart, with the denominator, the percentage, what each field measured, and what it did not. Check the arithmetic. Every percentage on this page is a count divided by 203, and where a figure was derived rather than read the derivation is written out.

1. Nobody’s church is a Church

Missing on 187 of 203 sites. This is the largest single gap in the sample and it is the one nobody talks about.

schema.org publishes a type called Church, whose entire definition is “A church.” It sits under PlaceOfWorship, which descends from CivicStructure, Place and Thing, and it inherits openingHours and openingHoursSpecification from those parents along with address, telephone and geographic coordinates (read 29 July 2026). It is a type built precisely for this.

Five of the 203 sites use it. ReligiousOrganization appears zero times in the entire sample. What churches emit instead is generic: 53 sites type themselves LocalBusiness, and 45 emit Organization and nothing more specific. 117 of the 203 emit some JSON-LD, and not one block among them failed to parse, so this is not a competence problem.

It is a defaults problem, and the crawl can say so with numbers. Split the 203 by the platform fingerprint in their markup. All 47 Squarespace sites in the sample emit JSON-LD, all 47 emit a WebSite node, 21 emit Organization, and zero of the 47 emit a church, religious organization or place type of any kind. Wix is the same shape: 15 of 17 emit JSON-LD and none of the 17 is typed as a church. Subsplash Sites emits JSON-LD on 1 of its 15 sites. WordPress is the only platform in the sample where churches get this right, and only because a plugin can be told to: 12 of the 69 WordPress sites carry a church, religious organization or place type, which is 12 of the 16 in the whole sample. The Church Co carries one on both of the two sites it hosts here.

So the default output of the two most popular church website platforms in this sample describes the congregation as a website belonging to an organization, and stops there.

Two limits on this item, stated before the instruction.

We did not test which typing Google honors for a congregation. Google’s local business structured data documentation asks for “the most specific LocalBusiness sub-type possible”, requires address and name, and lists openingHoursSpecification, telephone and url among its recommended properties (read 29 July 2026). That page names Restaurant, DaySpa and HealthClub as examples. It does not name Church, and Church is not a LocalBusiness subtype: it descends from Place. So a church has a real decision to make between the accurate type and the type Google documents, and the honest answer is to emit both in an array and test it. No site in this sample was submitted to a testing tool and no ranking effect was measured here.

Structured data has to match the page. Google’s general structured data guidelines state it flatly: “Don’t mark up content that is not visible to readers of the page” (read 29 July 2026). A block claiming a 9:30 service on a homepage that says nothing about Sunday is worse than no block at all.

The block to paste is at the bottom of the downloadable checklist, with every value marked as a placeholder to replace.

2. The service time is on the page and not in the markup

Missing on 173 of 203. Only 30 sites publish service hours in a form a machine can read, and 29 of those 30 use the plain openingHours string rather than the OpeningHoursSpecification object. The object form appears exactly once in 203 sites.

Cross the two measures and the finding gets sharper. 195 sites print a service time in the homepage text. 30 publish hours in JSON-LD. 168 sites publish the time to a person and nothing to a machine. That number is 195 minus the 27 sites that do both, counted from the per-site records rather than subtracted from the two totals, because three of the 30 sites publishing hours in JSON-LD did not register a service time in the page text.

What that costs is a fair question and it deserves a careful answer rather than a scary one. Nothing was tested here about what any search engine or assistant does with a missing openingHours. What is certain is narrower and still worth acting on: a structured field is the one place a machine can read a service time without inferring it, Google’s local business documentation lists openingHoursSpecification among its recommended properties, and a congregation whose time exists only inside a sentence in a hero caption has left every tool that reads the site to guess.

Two systems, not one. The JSON-LD hours live on the website. The hours a map result shows live on the Google Business Profile, which is a separate product and does not read the site. Google’s help page for business hours tells an owner to “Provide your regular customer-facing hours of operation” and to set special hours for “holidays or special events”, which for a church is Christmas Eve, Good Friday and every fifth-Sunday change (read 29 July 2026). Set both, and set them on the same afternoon so they agree.

3. The phone number that has to be retyped

Missing on 156 of 203. 47 sites carry a tel: link.

144 sites show a phone number somewhere in the visible homepage text. 47 make it tappable. So 97 of the 144 churches that publish a number make a phone user select it, copy it, and paste it into a dialer. That is 144 minus 47, and it is the cheapest fix on this entire page.

MDN’s documentation for the anchor element records what a tel: href actually does: “Cellular devices autodial the number”, and desktop machines hand it to whatever program can place a call. The scheme is defined in RFC 3966 (read 29 July 2026). One attribute. Every platform in this sample supports it, because it is plain HTML.

The visible digits stay formatted the way a human reads them. Only the href changes.

4. Sixty homepages carry no h1, and one carries eighteen

Missing on 127 of 203, counting sites that carry none and sites that carry more than one. 60 sites emit no h1 at all. 76 emit exactly one. 67 emit more than one, and the highest count on a single site is eighteen.

136 of the 203 carry at least one h1 holding text rather than only a logo image, so seven sites have an h1 whose entire content is a picture. That is an empty heading with a decoration in it.

Two separate reasons this matters, and they are not the same reason.

Google’s title link documentation lists the sources it uses to generate the blue line in a search result, and heading elements are on that list alongside the title element, the main visual title, and og:title. When the title element is unhelpful, “Google Search looks at information in header elements or other large and prominent text on the page to produce a title link” (read 29 July 2026). Sixty sites in this sample have handed that job to a paragraph.

The second reason has nothing to do with search. W3C’s WAI guidance on headings states that “Headings communicate the organization of the content on the page. Web browsers, plug-ins, and assistive technologies can use them to provide in-page navigation”, and asks that ranks be nested rather than skipped (read 29 July 2026). A homepage with eighteen h1 elements has no organization to communicate.

The fix is a markup fix and not a design fix. The text that looks like the biggest thing on the page is usually already there. It is wrapped in a div.

5. Half the title tags do not name the town

Missing on 105 of 203. 98 name the town, 77 name the state. Every one of the 203 sites has a title element, so nothing here is broken. Somebody decided what those words would be, or left the platform to decide.

Titles in the sample run from 4 characters to 122, median 41. 31 run over 60 characters and 55 run under 30. Google’s guidance is to “Write descriptive and concise text for your <title> elements” and to “Avoid vague descriptors like ‘Home’ for your home page”, and asks for “distinct text that describes the content of the page in the <title> element for each page on your site” (read 29 July 2026).

A four-character title exists in this sample. So does a 122-character one. Both are the same mistake, which is that nobody wrote it.

For a congregation, the useful title names the church and the town, because the search that finds a church is almost always a place search. That is one line of a settings page on every platform in this sample. It is not a redesign, and the small church website options that do not need a redesign covers what changing platforms actually costs if somebody proposes it.

6. A hundred and four sites have no copyright line, and eighteen are stuck before 2025

Missing on 104 of 203. 99 sites carry a copyright line. 70 of those read 2026, 11 read 2025, and 18 read a year before 2025, going back to 2018.

A current year in a footer proves nothing, because every mainstream platform prints it from the server clock. The 18 stale years mean something different: somebody typed a year into a template once and never came back, which is worth reading as a symptom rather than fixing as a defect. Fix the year with one line of template code, then go and read the staff page, the events page and the ministries page and delete what finished.

7. Two things the template should have given you free

An email address on the homepage. Missing on 90 of 203. 113 sites show one, 87 of those as a mailto: link. A contact form was not counted as an email address, because a form is not an address: a visitor who wants to write from their own mail client, keep a copy, or forward a thread to a spouse cannot use one.

A meta description. Missing on 72 of 203. 131 sites have one, with a median length of 137 characters and a range from 13 to 664. 33 run over 160 characters. A further 13 sites carry an og:description and no meta description, which is worth separating carefully: Google’s snippet documentation says Google “sometimes uses the meta description HTML element if it might give users a more accurate description of the page”, and that page does not name og:description at all (read 29 July 2026). We did not test whether Google ever falls back to og:description. What is certain is that the documented field is the one 72 sites do not have.

The same page asks for unique descriptions, because “Identical or similar descriptions on every page of a site aren’t helpful when individual pages appear in search results”. A church with a template description repeated across forty pages has one description, not forty.

8. What to actually put on a church website homepage

This is the question underneath the checklist, and the crawl answers it better than an opinion can.

Four facts were measured on every homepage: a service time, a street or city-state-ZIP address, a phone number, and an email address. 90 of the 203 sites have all four on the homepage. 113 do not. One site has none of the four.

Fact on the homepage	Sites with it	Sites without
A service time	195	8
An address in the text	191	12
A phone number	144	59
An email address	113	90
All four at once	90	113

Read the shape rather than the rows. Presence falls off in exactly the order a church stops thinking about a stranger and starts thinking about itself. The time and the address are for the visitor. The phone number and the email address are for the person with a question the website did not answer, and that person is the one about to decide whether this congregation is reachable by a human being.

Address in text matters as its own item because 12 sites publish an address only inside a map embed or an image. A map is not text. Print the street, the town, the state and the ZIP in words next to the service times, and keep the map as well.

Everything else that gets recommended as church website content sits below those four. A staff page with real names. A sermon archive. A page that says what the church believes without requiring a glossary. A giving page. What comes next after somebody arrives is a different problem entirely, and it is the one a guest follow-up system exists to solve, because a website that gets a stranger through the door and hands them to nobody has wasted the whole exercise.

9. A giving link, and the harder question about it

Missing on 43 of 203. 160 sites have a link whose text or href says give, giving, donate, tithe, offering or generosity, or carry a known giving platform in the markup. 68 name a platform: Planning Center Church Center on 38 sites, then Tithe.ly on 6, PayPal on 5, Pushpay on 5, Realm on 5, Breeze on 4, and a tail of e-giving, Donorbox, EasyTithe and Givelify. 50 sites send the visitor off the host domain to complete a gift.

No giving link was followed and no payment was attempted. Presence is all this crawl measured. So nothing in this sample proves that any of those 160 links resolve, that the page behind them loads on a phone, or that a gift completes. That test needs a human with a card and one dollar, and it is the test worth running this week. Count the taps. What each platform charges to process that dollar is a separate question with published answers, and it is in what giving platforms actually cost.

10. Thirty sites stop a visitor zooming

Fails on 30 of 203, which carry user-scalable=no or a maximum-scale at or below 1 in the viewport tag. 201 of the 203 carry a viewport tag at all.

MDN’s viewport meta tag documentation carries an explicit warning: “Disabling zooming capabilities by setting user-scalable to a value of no prevents people experiencing low vision conditions from being able to read and understand page content. Additionally, WCAG requires a minimum of 2× scaling; however, the best practice is to enable a 5× zoom” (read 29 July 2026). The requirement it points at is WCAG Success Criterion 1.4.4, Resize Text, at Level AA: “Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality” (read 29 July 2026).

MDN also notes that browser settings can ignore the rule and that iOS has ignored it by default since iOS 10, so on a lot of phones this does nothing at all. It still ships on 30 church websites, aimed at the congregation members most likely to need to make the text bigger.

The fix is a deletion. The correct tag is width=device-width, initial-scale=1 and nothing else.

This is the only accessibility item in this checklist, and it is here because it was the only one a request-and-parse crawl can honestly measure. Contrast, focus order, alt text coverage, form labels and screen reader behavior were not tested on any of the 203 sites, and no claim about them appears anywhere on this page.

11. Twenty-one homepages are nearly empty in the HTML

Fails on 21 of 203, which ship under 1,000 characters of visible text in the served HTML. Four ship under 500, and the lowest in the sample is 98 characters. Median across the sample is 1,959.

Those pages deliver their content with client-side JavaScript. This crawl ran no JavaScript, so what it recorded is that the words were not in the document. That is also the honest explanation for several of the eight sites recorded as publishing no service time, and it is recorded that way in the data rather than as a church hiding its times.

Do not overstate the consequence. Google renders JavaScript. Its JavaScript SEO documentation describes three phases, crawling, rendering and indexing, and states that a page “may stay on this queue for a few seconds, but it can take longer than that” before a headless Chromium runs the scripts (read 29 July 2026). The page will very likely be indexed. It will not answer a question for any tool that reads raw HTML and stops there.

The fix is narrow. Get the service time, the address and the phone number into the served HTML, in a footer if nowhere else, and leave the rest of the page alone.

12. The four items every article leads with

These are the bottom of the chart. In this sample, they are close to done.

An address in the homepage text. Missing on 12 of 203. 184 carry a street address, 175 carry a City, ST ZIP pattern, and 202 have one within a click.

A service time on the homepage. Missing on 8 of 203. Missing on the homepage or a linked page on exactly one site.

Served over HTTPS. Fails on 4 of 203. 199 answer over HTTPS and 110 send an HSTS header. web.dev’s why HTTPS matters puts the case in one sentence: “Always protect all your websites with HTTPS, even if they don’t handle sensitive communications”, and notes that modern browser features require it (read 29 July 2026). Four sites is four too many and it is also a settings toggle on every platform in this sample. One further site was excluded from the analysis because its certificate chain does not verify on a clean client, which is a missing intermediate certificate and a five-minute fix for whoever holds the hosting login.

A giving link. Missing on 43 of 203, covered above.

Anybody publishing a church website checklist that leads with these four is describing 2014.

What this crawl did not measure

Every item below was considered for this checklist and cut, because the method cannot support it.

Speed is not a finding here. Median time to last byte of the HTML document was 160 milliseconds and exactly one site of 203 took over three seconds. That measurement is one request from one machine on one connection. It is not Largest Contentful Paint, not Interaction to Next Paint, not Cumulative Layout Shift, and not a Lighthouse score. A checklist item counting church websites that load in over three seconds was planned for this page and cut, because the only answer this method can give is one, and one is not a finding.

Nothing was opened in a browser. No screenshots, no rendering, no visual review of any of the 203 sites. Every finding is a property of the served HTML.

No giving link was followed, no form was submitted, no email was sent, and no phone call was placed. Presence, in every case, is all that was measured.

No service time was checked for accuracy. The crawl found the pattern. It did not attend a service, and a wrong time in the markup looks exactly like a right one to a parser.

No accessibility audit was performed beyond the viewport tag, as stated above.

Nothing was tested against Google. No URL was submitted to the Rich Results Test or to URL Inspection, no ranking was measured, and no before-and-after was run. Every claim about what Google does comes from Google’s own published documentation, linked at the sentence that uses it, with the date it was read.

Six sites were never analyzed and they are named in the data with their causes. Their absence is why the denominator on this page is 203 and not 209, and why no percentage here is quietly computed against the bigger number.

The decision this page asks for

Open the church homepage. View the source. Search it for ld+json. That single search sorts every church into one of two piles, and 86 of the 203 sites in this sample land in the pile with nothing.

Then do these three things, in this order, and stop.

One. Add the Church block with the address, the telephone and the openingHoursSpecification, and make every fact in it appear in words on the page. Test that it parses before you publish. That closes the two largest gaps in the sample at once, and it takes one afternoon.

Two. Wrap the phone number in a tel: link and open the page on a phone to tap it. Five minutes.

Three. Put the town in the title tag and give the homepage exactly one h1 holding real words. Twenty minutes on any platform in this sample.

That is the whole intervention. It does not touch the design, the photography, the copy, or the platform. Anybody proposing a rebuild before those three are done is selling a rebuild.

What it will not do is bring anyone through the door. A church website makes a congregation findable and legible, and that is the entire job. The work that decides whether a stranger walks in happens half a mile from the building, and the work that decides whether they come back happens in the seven days after they leave. Whatever the website collects about them the moment they do, from a connect card to a mailing list, is member data with rules attached, and those rules are the same whether the site is beautiful or not.

Take the checklist and the aggregate CSV. Work down the list in the order the counts put them in. Write today’s date at the top, because the next person to open the site will want to know whether anybody has already been through it.