Mobile-First Church Websites: Most of Your Traffic Is Already on a Phone

Here is the test that decides whether a stranger visits your church, and it looks nothing like the way you review your website.

A man is standing in a parking lot on a Saturday afternoon holding a phone in one hand and a bag of groceries in the other. There is sun on the screen. He has one bar of signal. He has been meaning to find a church since he moved in April, and something reminded him just now, and he has roughly the length of the walk to his car before the thought passes.

He types three words into Google and taps the first church that looks close.

That is the review environment. One thumb, bad light, weak signal, forty seconds of attention. Nobody at your church has ever looked at your website that way. You look at it on a laptop, at a desk, on office wifi, already knowing what time the service starts.

This post is about closing that gap. Not the version of "make sure your site works on mobile" that everybody has heard and mostly believes they have already handled, but the specific, checkable, boring version. Because the data says most churches have technically handled it and practically have not, and the difference between those two things is where the visitors go.

Mobile stopped being a version of your website. It became the website.

Two dates matter here.

The first is May 2015, when Google confirmed that more searches were happening on phones than on computers in ten countries including the United States.¹ That is eleven years ago. It is older than most of the church websites currently online.

The second date is the one almost nobody in church communications knows about. On July 5, 2024, Google finished a migration it had been running since 2016 and began crawling every site on the internet with its mobile crawler.² There is no desktop version of Google's index anymore. There is no fallback. Whatever your site shows to a phone is what Google sees, judges, and ranks. If something exists only in the desktop layout, Google does not know about it.

That is the sentence worth reading twice. Your website has a phone version and a computer version, and only one of them is real to the search engine.

There is also the question of what people are searching for on those phones. By Google's own consumer research, roughly 30% of mobile searches are related to location.³ Nearly a third. People do not sit down at a desk to find a church near them. They look it up in a car, in a waiting room, at their kid's practice, standing in a parking lot with groceries.

We wrote a whole guide on showing up when someone searches "churches near me". This post is about what happens in the four seconds after they tap your name.

The thing most churches get wrong: responsive is not mobile-first

If you tell a church their website needs to work on phones, most will tell you it already does. Usually they are right, in the narrow sense.

One Eighty Digital ran an unusually thorough audit here. A five-person team spent three months in early 2024 evaluating 2,725 church websites, one denomination across an entire state. Among the churches that had a website at all, 85% were mobile-friendly, meaning the layout responded and the page was navigable on a phone.⁴

Eighty-five percent. That is a genuinely good number, and it means the standard advice, "get a responsive site," has largely worked. Churches did the thing.

And yet the same visitors keep bouncing.

The reason is that responsive and mobile-first are two different ideas that got collapsed into one phrase. Responsive means the layout does not break. The columns stack, the text reflows, nothing runs off the side of the screen. It is a technical property of the stylesheet, and it is table stakes.

Mobile-first means the phone is the version you designed, and the desktop is the adaptation. It is a decision about what the page is for, made under the assumption that the reader has one thumb and forty seconds.

A responsive site that was designed on a laptop is a laptop page folded up small. Everything is there. The hero video is there, all four rotating banners are there, the seven-item navigation menu is there, the staff directory is there, the paragraph from the pastor about the church's history is there. It all fits. It just takes eleven seconds to load, and the visitor has to scroll past two full screens of it before finding out when anything starts.

Nothing on that page is broken. It just does not answer the question.

What mobile-first actually means

Four things, in order of how much they cost you.

1. The first screen answers the three questions

On a phone, "above the fold" is roughly one paper index card of space. Not a hero image with a headline underneath. One card.

What has to survive in that space:

• Who you are. The church name, legibly, and enough of a visual cue to tell a Catholic parish from a nondenominational plant from a Lutheran congregation. People are trying to place you.
• When you gather. Service times, Mass times, whatever your tradition calls them. Actual times, in numerals. Not a link to a page about times.
• Where you are. The neighborhood or street at minimum, ideally tappable so it opens their maps app.

Everything else on your homepage is negotiable. Those three are not, and the reason is not aesthetic. Those three are what the person in the parking lot is trying to find out, and every additional tap between them and that information is a place they leave.

A useful discipline: write those three items as plain text on an index card. If your homepage's first screen on a phone does not say what is on the card, the card wins and the homepage needs to change.

2. The page has to be light

The single most common technical failure on church websites is weight, and it is almost always the same culprit: a photo somebody uploaded straight off a camera or a phone at full resolution.

Google's research on this is old but has never stopped being true. In a 2016 study of mobile browsing behavior, 53% of mobile site visits were abandoned when a page took longer than three seconds to load.⁵ Over half. And a church homepage with an uncompressed hero image on a weak cellular connection routinely takes eight to fifteen seconds.

Your building's wifi is lying to you about this. So is your office internet. Test on cellular, with wifi turned off, ideally somewhere with mediocre signal.

3. Everything has to be operable with a thumb

This is where responsive sites quietly fail, because a stylesheet can stack columns correctly and still produce a page that is miserable to actually use.

The specific failures, in rough order of frequency:

• Tap targets too small or too close together. Google's own tooling flags anything under about 48 by 48 pixels, and Apple's interface guidelines have said 44 points for years.⁶ Footer social icons and stacked navigation links are the usual offenders.
• Form fields that zoom. If an input's font size is under 16 pixels, Safari on iPhone zooms the whole page in when someone taps it, and it does not zoom back out. The visitor is now stranded at 150% magnification trying to fill in a prayer request. This one is a one-line CSS fix and it is broken on an astonishing number of sites.
• PDFs. The bulletin, the calendar, the ministry brochure. A PDF on a phone is a wall of unreadable text that requires pinching. If information matters to a first-time visitor, it belongs on a web page, not in a PDF.
• Sticky headers that eat the screen. A fixed navigation bar plus a fixed announcement banner plus a cookie notice can consume 40% of a phone screen before any content appears.
• Anything that needs hover. A dropdown menu that opens on hover has no equivalent on a touchscreen. It either does nothing or it fires on the first tap and navigates on the second, which most people never discover.

4. What is on the phone version has to be everything

Since the mobile-first indexing change, content that exists only in your desktop layout is content Google cannot index and visitors cannot read.

To be precise, because this gets overstated: content collapsed inside an accordion or a tab is fine, as long as it is in the page's HTML when the page loads. Google indexes it normally. The problem is content that is genuinely absent from the mobile version, or that only loads after a user interaction the crawler never performs.

The most common church-specific version of this: a homepage with a detailed service schedule in a sidebar on desktop that gets hidden on mobile because it did not fit. The information is on your site. It is not on your website.

The five-minute test

Do this now, before you forward this post to anyone. It takes five minutes and you need your own phone.

Minute 0. Set up honestly. Turn wifi off. Open a private or incognito browser window so you are not getting your own cached version. If you have a second phone in the house on a different carrier, better.

Minute 1. Find yourself the way a stranger would. Do not type your church's URL. Search the way the man in the parking lot would: your denomination or "church" plus your town. Then search your church's actual name. Note whether you appear, and note what the result looks like before anyone taps anything.

Minute 2. Time the load. Tap through and count out loud. One thousand one, one thousand two. If you are still looking at a blank screen or a spinner at three, that is your first repair job and it is probably one oversized image.

Minute 3. The index card test. Do not scroll. Look only at what is on the screen when the page finishes loading. Can you find the church name, the service times, and the location? If you have to scroll to get any of the three, write down which one is missing.

Minute 4. Use it one-handed. Hold the phone in one hand the way you actually hold it. Open the menu. Tap "Plan a Visit" or whatever your equivalent is. Tap the address and see whether it opens maps. Tap the phone number and see whether it offers to call. Tap into a form field and see whether the page zooms. Try to reach the top-right corner with your thumb without shifting your grip.

Minute 5. Ask the only question that counts. Out loud: if I had never heard of this church, would I know what to do next?

Then hand the phone to someone who does not attend your church. A neighbor, your dentist, your kid's friend's mom. Give them one instruction: "pretend you are thinking about coming Sunday, show me what you would tap." Say nothing else. Watch their thumb. The three seconds where they pause and squint is the whole report.

That last step is worth more than every tool in the next section combined, and every church skips it.

The tools, including the one that no longer exists

If you search for church website mobile testing, most of what you find will tell you to use Google's Mobile-Friendly Test. Do not bother looking for it. Google retired the Mobile-Friendly Test, its API, and the Mobile Usability report in Search Console on December 1, 2023.⁷ The advice is everywhere and it is dead.

Here is what to use instead.

PageSpeed Insights (pagespeed.web.dev). Free, no account. Paste your homepage URL and read the Mobile tab, not Desktop. It gives you a score, but ignore the score and read the three Core Web Vitals underneath it. Those are the numbers Google actually uses.

Search Console (search.google.com/search-console). If your church does not have this set up, that is a separate forty-five minute job worth doing. The Core Web Vitals report shows how real visitors on real phones experienced your site over the last month, which is more honest than any single test.

Your own phone. Still the best instrument in the list. See above.

The numbers to hand your web person

If you are the person who forwards things rather than fixes them, this is the section to forward. These are Google's published thresholds, measured at the 75th percentile of real visits, meaning three out of four people should experience at least this.⁸

Metric	What it means in English	Target
LCP (Largest Contentful Paint)	How long until the main thing on screen appears	Under 2.5 seconds
INP (Interaction to Next Paint)	How long after a tap before something happens	Under 200 milliseconds
CLS (Cumulative Layout Shift)	How much the page jumps around while loading	Under 0.1

And four fixes that are not metrics but cause most of the failures:

• Homepage hero image compressed to well under 500KB, sized for a phone screen, not a print exhibit
• All form inputs at 16 pixels or larger so iPhones stop zooming
• Tap targets at least 44 to 48 pixels with real spacing between them
• No visitor-critical information locked inside a PDF

That is a short enough list to paste into an email. Most competent web people will work through it in an afternoon, and if your site is on Squarespace, Wix, or a church platform like Subsplash or Tithe.ly Sites, several of these are settings rather than code.

If you cannot rebuild the site this year

Most churches cannot. The site was built by a volunteer who has since moved, or by a company on a contract that renews in March, or by the pastor's nephew in 2019. A full rebuild is a budget conversation and a committee and probably a year.

You can still fix most of this without touching the architecture.

Compress the images. Free, one afternoon, biggest single speed win available to you.

Rewrite the first screen. Not a redesign. Just change what words and buttons occupy the top of the homepage so the index card survives. On most platforms this is editing one content block.

Cut the carousel. Rotating banners are slow, they push everything down, and on a phone people almost never see slides two through five. Pick the one that matters and delete the rest.

Make the address and phone number tappable. Two links. Ten minutes.

Move anything a first-time visitor needs out of PDFs and onto a page.

That is a real, meaningful mobile improvement for zero dollars and about four hours of one person's time. It is not the same as a mobile-first rebuild. It closes most of the gap.

Worth naming the organizational problem underneath, because it is the actual reason these things sit broken for years: on most church staffs, the website is an orphan. It belongs to everyone and therefore no one. The fix is to give one specific person, paid or volunteer, forty-five minutes a quarter and permission to change things. That is the whole intervention. We made the same argument in the 7-second rule and it has not gotten less true.

The question your homepage cannot answer

Here is the honest limit of everything above.

Suppose you do all of it. The page loads in 1.8 seconds, the first screen has the name and the times and the address, every button is thumb-sized, and Search Console is green across the board. You have a genuinely excellent mobile church website.

The man in the parking lot still has a question you did not anticipate.

His is about whether the 9:30 has childcare for a two-year-old who does not separate well. Somebody else's is whether the parish office is open on Fridays. Somebody else's is whether they need to be a member to have a child baptized, or whether the Wednesday study is still meeting in August, or where to park if the lot is full, or what people wear, or whether anyone will make them stand up and introduce themselves.

These are the questions every visitor actually asks, and there is no version of a homepage that answers all of them, because there are hundreds and they are specific and half of them are asked at 10 p.m. on a Saturday when nobody is in the office.

On a phone, the cost of asking is even higher than usual. Typing a paragraph into a contact form with one thumb, addressed to nobody in particular, with no idea whether anyone reads it, is a lot to ask of someone who is still deciding whether to come at all. So most people do not ask. They just leave, and the question goes unanswered forever, and nobody at the church ever learns it was asked.

That gap is the entire reason Greetyr exists. A digital greeter sits on your site, answers the specific question from your own content, in a chat window that was designed for a thumb, and then does the thing a greeter is supposed to do: point the person toward a human being on Sunday. It is not a replacement for a good mobile site. A greeter on a broken page is a doorman in front of a locked door.

Fix the page first. Then staff it.

Frequently asked questions

What does mobile-first mean for a church website?

Mobile-first means the phone version is the primary version, designed first, with the desktop layout adapted from it. That is different from responsive design, which only means the layout does not break on a small screen. Practically, mobile-first means the first screen on a phone answers who you are, when you gather, and where you are, without scrolling, and the page loads fast enough on cellular data that nobody gives up waiting.

Does Google penalize church websites that are not mobile-friendly?

It is not a penalty so much as an omission. Since July 5, 2024, Google crawls and indexes every site using its mobile crawler only. There is no desktop index to fall back on. Content that is missing or inaccessible on your phone version is content Google effectively does not have, which means it cannot rank for it. Page experience signals like Core Web Vitals also factor into ranking, so a slow phone experience costs you twice.

How do I test whether my church website works on mobile?

Google retired its Mobile-Friendly Test tool on December 1, 2023, so ignore any guide that recommends it. Use PageSpeed Insights (pagespeed.web.dev) and read the Mobile tab, check the Core Web Vitals report in Google Search Console for real-visitor data, and most importantly open the site on your own phone with wifi turned off. Then hand the phone to somebody who does not attend your church and watch what they tap.

How fast should a church website load on a phone?

Aim for the main content to appear in under 2.5 seconds, which is Google's threshold for a good Largest Contentful Paint score. Google's research found that 53% of mobile visits are abandoned when a page takes longer than three seconds. On most church sites the difference between eleven seconds and two seconds is a single uncompressed photo on the homepage.

Our website is responsive. Is that enough?

Usually not, and the data suggests this is the most common blind spot. In an audit of 2,725 church websites, 85% qualified as mobile-friendly, and churches still lose visitors on phones at high rates. Responsive means the layout survives a small screen. It says nothing about whether the page is fast, whether the important information is near the top, whether the buttons are thumb-sized, or whether a stranger can figure out what to do next.

What is the single highest-impact mobile fix for a church website?

Compressing the homepage images, followed immediately by rewriting the first screen so service times are visible without scrolling. Those two changes cost nothing, take an afternoon, and address the two failures that lose the most visitors: pages that are too slow to wait for and pages that make people hunt for the one fact they came for.

---

Greetyr is a digital greeter for church websites. It answers a visitor's real question from your existing content, on whatever device they happen to be holding, and points them toward the people in your building who can take it from there.

Footnotes

1. Google confirmed in May 2015 that more searches were taking place on mobile devices than on computers in ten countries including the United States and Japan, announced by Jerry Dischler at Google's annual advertising conference. Google grouped tablets with desktops in this comparison. See: searchengineland.com. ↩

2. Google Search Central Blog, "Mobile-indexing-vLast-final-final.doc" (June 3, 2024). Sites still being crawled with desktop Googlebot were switched to the smartphone crawler after July 5, 2024, completing a migration that began in 2016. See: developers.google.com/search/blog. ↩

3. The figure that roughly 30% of mobile searches are related to location comes from Google's own consumer-search research published through Think with Google in the mid-2010s, and is the source behind the same statistic as aggregated for church audiences by CommunicateJesus in "12 Essential Statistics to Shape Your Church's Website." More recent industry estimates of local intent across all devices run higher, around 46%, but those come from third-party aggregators rather than Google directly. Treat 30% as a conservative floor. ↩

4. One Eighty Digital, "State of Church Websites: Insights from 2,725 Churches" (published February 2025, fieldwork conducted January 2024). A five-person team spent over 100 hours evaluating every church in one denomination across a single state. 46.3% had no website at all; among those that did, 85% were assessed as mobile-friendly and 14% as non-responsive. The mobile-friendliness criterion was a qualitative assessment of responsive design and navigability, not a technical performance measurement, which is precisely the distinction this post is about. Single-denomination, single-state sample, so read it as directional. See: oneeighty.digital. ↩

5. Google / DoubleClick, "The Need for Mobile Speed" (September 2016). 53% of mobile site visits were abandoned if a page took longer than three seconds to load. The same research found average mobile load times of 19 seconds on 3G. Our earlier post the 7-second rule cites the companion 2017 Google/SOASTA finding on how bounce probability climbs with load time. ↩

6. Google's Lighthouse audit flags tap targets smaller than roughly 48 by 48 pixels or without adequate spacing. Apple's Human Interface Guidelines have long recommended a minimum tappable area of 44 by 44 points. The two numbers describe the same underlying constraint, which is the width of an adult thumb. ↩

7. Google retired the Mobile Usability report in Search Console, the Mobile-Friendly Test tool, and the Mobile-Friendly Test API on December 1, 2023, pointing site owners to Lighthouse and other page-experience tooling instead. Mobile usability remains part of Google's page experience guidance; only the standalone tools went away. See: searchengineland.com. ↩

8. Core Web Vitals thresholds published by Google on web.dev: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1, each measured at the 75th percentile of page loads segmented across mobile and desktop. INP replaced First Input Delay as a Core Web Vital in March 2024. See: web.dev. ↩