Walk through the parish websites in almost any diocese and you will see the same thing. One parish has a clean, modern site a volunteer built two years ago. The next one is a Facebook page and nothing else. A third pays a vendor $200 a month for a template they cannot edit. A fourth has Mass times that are eight months out of date because the person who knew the password moved away.
Each parish is an island. Each one solves the same problem from scratch, badly, at a different price. And when something needs to change across all of them, a new safe-environment policy link, a corrected diocesan phone number, an accessibility fix, there is no way to push it. Someone emails forty parish secretaries and hopes.
There is a better shape for this, and it is not new. It is the shape large organizations already use when they have hundreds of local outposts that all need to look and behave the same. The idea is simple. Central infrastructure, local content.
The problem is that every parish is treated as a separate project
When a parish needs a website, the usual path is to find a volunteer or a vendor and start from zero. That means every parish independently decides on a platform, a design, a hosting bill, and an email setup. Forty parishes means forty of everything.
This is expensive in money and worse in maintenance. The accessibility of the site depends entirely on whoever built it. The structured data that helps Google and AI assistants answer "what time is Mass at St. Whoever this Sunday" is present on a few sites and absent on most. Security and email reputation are handled forty different ways, which means they are handled badly in at least thirty of them.
And the quality gap is permanent. The good sites stay good, the bad sites stay bad, and nobody can lift the floor because there is no shared floor to lift.
The fix: generate every parish from one template
The alternative is to build the parish site once, as a template, and generate every parish from it. In our toolkit we call this a monoclone. One codebase, one design, one set of accessibility and schema decisions, cloned out to as many parishes as you have.
Each generated site is identical in structure. What differs is the content, and the content lives in a plain data file: the parish name, the address, the Mass and confession times, the pastor, the photo, the bulletin link. A parish secretary opens that file, changes Saturday Vigil from 5:00 to 4:30, saves, and the site updates. No web designer, no ticket, no waiting.
The payoff is in the other direction too. When you fix the template, you fix every parish at once. Add a "report a concern" link required by the diocese, improve the contrast on a button so it passes accessibility checks, add the structured data that makes Mass times show up cleanly in search and in AI answers. You do it one time, regenerate, and all hundred parishes have it that afternoon. I wrote about the underlying mechanics of this approach in the monoclone generator post if you want the technical version.
This is exactly the pattern the Latter-day Saints use, and use well. Their meetinghouses run on one consistent template with a single meetinghouse locator that works the same everywhere. Apply that here and you get a parish directory and a Mass-times locator that behaves identically across the whole diocese, because it is the same code everywhere.
Get the structured data right once, for everyone
A parish site has one job that matters more than design: answer the practical questions. Where is it. When is Mass. When is confession. Is there a vigil. Who do I call.
Search engines and AI assistants can only answer those questions reliably if the answers are marked up in a machine-readable way. That is what structured data does. A diocese with a hundred independently built sites will have a hundred different levels of correctness here, and most of them will be wrong in the predictable ways: one block of structured data covering all locations, missing geo coordinates, the same identifier reused across parishes so the search engine thinks they are the same place. We see this constantly outside the Church too, in any business with more than one address. The full breakdown is in the multi-location schema audit post.
With one template, you solve this once. Each parish gets its own correct location data, its own coordinates, its own hours, all tied up to the diocese as the parent organization. Done in the template, true for every parish, forever.
Host them all free, on one account
Here is the part that surprises people. A static parish site, which is what a template-generated site is, can be hosted for free. One Cloudflare Pages account can hold all of your parish sites at no hosting cost. Not one free site and the rest paid. All of them.
That replaces the most common recurring line item in the whole diocese: the per-parish hosting bill. Forty parishes paying anywhere from a few dollars to a few hundred dollars a month collapses into a single free account that the diocese controls. If a parish goes quiet for a year, nothing breaks and no invoice arrives. The site just stays up.
Because everything runs from one account, you also get one place to see all of it, one place to roll out a change, and one place to lock things down. If you are deciding how to handle AI crawlers across the whole diocese, you set that policy once. The Cloudflare AI crawler allow-list post covers what that decision looks like.
Run the audits and the writing in batch
A hundred parishes is a lot of pages to check and a lot of "About our parish" paragraphs to write. Doing it one parish at a time is what makes this feel impossible.
It is not one at a time. You run the accessibility checks, the structured-data checks, and the content generation across all parishes in a single batch. The AI batch APIs, the ones built for processing a large set of jobs at once rather than answering in real time, run at roughly half the cost of asking the same questions live, one by one. So the big initial lift, generating a first draft of every parish's page and auditing every site, is both faster and cheaper than the piecemeal version.
After the first pass, ongoing work is small. A parish edits its own data file. The diocese re-runs the batch audit when it wants a fresh report on the whole portfolio. The new website discoverability stack post lays out which checks are worth running on a new site, and they apply cleanly here because every parish site is built the same way.
Consolidate the bills into one subscription per layer
This is where the real money is. Right now a diocese is probably paying for the same thing many times over, once per parish, because each parish bought its own version.
Flip it. Pay once per layer, for the whole diocese:
- One Google Workspace for Nonprofits tenant. Most parishes qualify for the nonprofit tier at no cost. One tenant means one place to manage every parish email account, and one email security policy applied across all of the parish domains at once. No more thirty different mail setups with thirty different spam problems. If you want to understand why a shared, properly configured mail policy matters so much, the email infrastructure for small organizations post explains it without the jargon.
- One hosting account. The free Cloudflare Pages account already covers it. Zero recurring hosting cost across every parish.
- One enterprise AI agreement. Instead of individual parishes each fumbling toward their own AI tools, the diocese signs one agreement and the batch generation and audits run under it.
- One negotiated giving rate. If parishes accept online donations, a single diocese-wide processing rate almost always beats whatever rate a single parish could negotiate alone. The volume is the leverage.
Each of these is a place where "everyone does their own" quietly costs more than "the diocese does it once." Consolidating does not take anything away from the parish. The parish still owns its content, its identity, its voice. It just stops paying separately for the plumbing.
Central infrastructure, local content
That phrase is the whole model. The diocese owns the parts that should be uniform: the template, the accessibility floor, the structured data, the hosting, the email security, the contracts. The parish owns the parts that should be local: the words, the photos, the times, the people, the heart of the place.
The parish secretary should never have to think about hosting, schema, or DNS. She should think about whether the Tuesday morning Mass time is right. The template handles everything else, the same way for every parish, so the worst parish site in the diocese is as accessible, as findable, and as correct as the best one.
And none of this is unique to dioceses. Any organization with many local outposts that all need to look and behave the same has this exact problem. School districts. Franchise networks. Chapters of a nonprofit. Clinics under one health system. If you have read this and thought "this is also my company," you read it right. The wider playbook for running a whole portfolio of sites this way is the subject of my book The $100 Network, if you want the full version.
Fact-check notes and sources
- Static sites generated from a template can be hosted at no cost on Cloudflare Pages within its free plan; verify current free-plan limits on the Cloudflare Pages pricing page before committing a large portfolio.
- Google offers a no-cost nonprofit tier of Google Workspace to eligible organizations through Google for Nonprofits; eligibility and current terms are on the Google for Nonprofits site.
- Anthropic and OpenAI both document a batch processing mode for large, non-time-sensitive jobs at a reduced price versus standard real-time calls. See the Anthropic Message Batches documentation and the OpenAI Batch API documentation for current pricing and limits.
- Structured-data requirements for places and organizations are defined by schema.org and by Google Search Central's local business guidance.
- The Church of Jesus Christ of Latter-day Saints publishes a public meetinghouse locator built on a consistent template; this is referenced as a working example of the central-infrastructure pattern, not as an endorsement or affiliation.
- This post describes a general architecture pattern. It does not name or audit any specific parish or diocese; "St. Whoever" and "the parish secretary" are stand-ins.
Related reading
- Why the monoclone generator exists — the one-template-many-sites mechanics in detail.
- The multi-location schema audit — how multi-address organizations get structured data wrong, and how to fix it once.
- The new-website discoverability stack — the checks worth running on every generated site.
- The Cloudflare AI crawler allow-list — set one crawler policy for the whole portfolio.
- Email infrastructure for small organizations — why one shared, well-configured mail policy beats forty improvised ones.
This post is informational and not a substitute for professional consulting. Mentions of Cloudflare, Google, Anthropic, OpenAI, schema.org, and The Church of Jesus Christ of Latter-day Saints are nominative fair use. No affiliation is implied.
