Structured Data for Churches: What to Add and What It Actually Does

Structured data describes information on your church website in a machine-readable format. Choose types that match the real subject, keep the facts aligned with visible content, and validate the result. Treat markup as a precise description of your content, not a guarantee that an AI tool will recommend your church.

The first question is not “How many schema types can we add?” It is “What does this page describe?”

A congregation, a building, a sermon article, and a scheduled event are different things. Modeling those differences is more useful than adding the same bundle of markup to every page.

Distinguish the organization from the place

Schema.org defines Church under Place, through CivicStructure and PlaceOfWorship. It describes a place of worship. Organization describes an organization. [1][2]

For a congregation operating from a physical location, you can describe both and connect them. This becomes especially helpful when one organization has several campuses or meets in a building it does not own.

The organization may keep the same identity after moving. The old and new locations are different places. Your data model should be capable of expressing that distinction.

Use stable identifiers for the entities you describe. An identifier such as https://example.org/#organization can identify the organization, while a campus page fragment can identify a particular place. These are identifiers in a graph; they do not all need to be standalone pages.

Choose markup based on the page’s purpose

This table is a planning aid, not a promise that every type has a corresponding Google rich result.

Schema.org defines vocabulary. Google’s documentation defines eligibility for Google’s supported search features. Those are related but different questions. Its structured data policies also require representative, nonmisleading content and do not guarantee a special result. [3]

A small organization-and-location example

The following JSON-LD is an educational example for a fictional church. Every name, address, and URL is invented. Replace the facts with verified information before adapting it to a real church website. It is not markup for the conference website hosting this guide.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.org/#organization",
      "name": "Harbor Community Church",
      "url": "https://example.org/",
      "location": {
        "@id": "https://example.org/locations/bay-street/#place"
      }
    },
    {
      "@type": "Church",
      "@id": "https://example.org/locations/bay-street/#place",
      "name": "Harbor Community Church — Bay Street Campus",
      "url": "https://example.org/locations/bay-street/",
      "address": {
        "@type": "PostalAddress",
        "streetAddress": "123 Example Street",
        "addressLocality": "Example City",
        "addressRegion": "CA",
        "postalCode": "00000",
        "addressCountry": "US"
      }
    }
  ]
}

The example intentionally stays small. Add supported properties only when they describe verified facts and serve the implementation. Do not invent a denomination property, paste unverified geographic coordinates, or add social links that belong to another church.

The relationship here uses the organization’s location property to reference the place. Additional real campuses can be represented with distinct identifiers rather than rewriting one campus object with whichever address appears on the current page.

When implemented on a church website, JSON-LD is normally included in a script element with the application/ld+json type. When shown in this article, it should remain escaped sample code.

Keep worship times and opening hours distinct

An office being open from 9 a.m. to 5 p.m. is not a worship service. A building being accessible on Sunday morning does not identify the service’s start time.

Publish the worship schedule clearly in visible text. Use opening-hours properties only for the actual hours they describe. Do not encode every Sunday service as a broad office-hours range and assume the meaning is preserved.

For a specific event page, use event markup only when the content fits the event and platform requirements. Do not label an evergreen “Plan Your Visit” page as a single dated event just to obtain extra markup.

Mark up real events with real dates

An event page should clearly state what is happening, when, where, and how someone can attend. Google’s event documentation describes requirements including event dates and location, as well as handling event status changes. [4]

If an event is canceled or rescheduled, update both the visible page and the markup. If several distinct events share a landing page, check the platform’s current requirements before assuming that page qualifies as an individual event destination.

Do not generate imaginary future events to make a calendar appear full. Recurring activities still need an accurate implementation appropriate to the published schedule.

For the enduring description of a program, use the ministry-page framework. Keep its long-term purpose separate from a particular occurrence.

Mark up articles as articles

For a written guide, identify the actual headline, author, publication date, and substantive modification date where appropriate. Google’s Article documentation explains the properties relevant to that feature. [5]

Do not change the publication date every time the site builds. Do not attach an invented author biography or unsupported credentials to create the appearance of expertise.

If a page contains a sermon video and a short description, inspect what the page actually offers before treating it as a long-form article. Additional media markup should reflect real visible media and follow its own requirements.

For this conference’s guides, Article markup is a sensible implementation choice. Church markup belongs in the educational example, not in the conference publisher’s live identity.

What about FAQ markup?

Write useful answers because readers need them. Do not assume that adding FAQPage markup earns an expanded Google result or increases AI citations.

Search features and eligibility change. Review current platform documentation before building around any particular display treatment. Google also states that no special schema is required for its AI search features. [6]

A page can contain a useful FAQ section without carrying an unsupported promise about what happens in search.

Validate in three layers

First, validate the JSON. A missing comma or broken quote can prevent parsing. Check the generated output, not just the source template.

Second, validate vocabulary and relationships. Use the Schema.org validator to inspect the entities, properties, and value types. Confirm that identifiers refer to the intended objects.

Third, test the relevant search feature. Use Google’s Rich Results Test for supported features. A schema type that has no supported rich result may not appear there as an eligible feature. That is different from malformed JSON.

None of these checks proves that the underlying facts are true. Compare the output with the approved church fact sheet and the visible page before release.

Watch for duplicate and conflicting output

Some sites receive markup from a CMS, a plugin, a theme, and custom code at the same time. Inspect the final page for duplicate organization objects, inconsistent addresses, or unrelated author identities.

Use a consistent identifier for the same entity across pages. Preserve existing accurate markup where possible instead of stacking another disconnected copy on top.

When a shared fact changes, update the source that generates it. Manual edits scattered across dozens of pages can create the very contradictions the markup is meant to prevent.

The church information guide explains how to maintain approved facts. The crawler guide covers access and rendering if the markup or content is not retrievable.

A release checklist

• Each type matches the thing being described.
• Organization and campus identities are explicit.
• Names, addresses, URLs, and dates match the page.
• No sample values or invented ratings are present in production data.
• JSON parses and the vocabulary has been checked.
• Applicable rich-result requirements have been reviewed.
• The live rendered output contains no conflicting duplicate markup.
• Future changes have an owner and a defined source of truth.

Frequently asked questions

Should every campus be a LocalBusiness?

Do not choose that type automatically. Start with what the entity actually is and the applicable vocabulary. A physical church has a specific Church type; additional typing requires a reason grounded in the entity and implementation.

Can schema make up for a thin page?

No. Publish the information people need, then describe it accurately in markup. Hidden data should not substitute for useful visible content.

How much markup is enough?

Enough to represent the relevant entities and supported page features accurately. More properties are not inherently better if the facts are uncertain or the types do not fit.

Start with one correct implementation

Model the organization and one location, validate the output, and compare it with the visible facts. Extend the pattern only after it is working clearly.

Explore Not Another Church Marketing Conference to work through practical implementation with other church marketers.

Sources

[1] Schema.org: Church.

[2] Schema.org: Organization.

[3] Google Search Central: General structured data guidelines.

[4] Google Search Central: Event structured data.

[5] Google Search Central: Article structured data.

[6] Google Search Central: AI features and your website.

Sources reviewed September 27, 2026. The JSON example is illustrative and must be adapted and validated for a real implementation. No citation or ranking outcome is promised.