Website Templates & the Footer Standard

1. Which template, when

The decision rule is one question: does the charity already have a website design it wants to keep?

• No website yet (most pre-501(c)(3)s, plus mature charities that never had one) → FFC-IN-FFC_Single_Page_Template. A volunteer builds a complete single-page site from the charity's content, so every required section — mission, programs, team, donate, contact, legal pages, footer — exists from day one. How-to: Build a Charity Site from the Template.
• Already has a designed website → FFC-IN-Footer_Only_Template. The charity keeps its design and adopts the compliance layer — footer, seven policy pages, consent, analytics, team section, SEO — on top of it. How-to: Adopting the FFC Footer on an Existing Website.
• Live on WordPress (or other legacy hosting) → the site is first converted to a static build (see the WordPress to Next.js Conversion Guide), then brought to the footer standard like any other already-designed site.

When in doubt, choose the Single Page template — it is the fastest path to a validated site. Both paths converge on the same gate: the site validated live on its free GitHub Pages address, which unlocks the free .org domain, which unlocks email.

2. What both templates ship

Beyond their different starting points, the templates deliver the same infrastructure, driven by one shared site.config.ts shape (a config written for one template transcribes directly into the other):

• The FFC footer on every page — the full anatomy in section 3.
• Seven legal/policy pages — privacy policy, cookie policy, terms of service, the charity's donation policy, the FFC donation policy, vulnerability disclosure, and security acknowledgements.
• Consent banner — Accept All / Decline All / Customize, four cookie categories, analytics and marketing gated until opt-in, and cookie deletion on withdrawal.
• Analytics — Google Tag Manager with a consent-aware data layer (the charity swaps in its own container id during customization).
• Team section — data-driven, initials monograms so no charity has to source portrait photos; self-hides when no members are configured.
• SEO + accessibility + security plumbing — sitemap, robots, per-page metadata and canonicals, skip links, WCAG AA targets, CSP, and RFC 9116 security.txt.
• Static export for GitHub Pages — free hosting, with assetPath() handling project-page base paths.

The Single Page template additionally ships the eleven home-page sections, schema.org JSON-LD, and integrations (Zeffy, Idealist, events widgets); the Footer-Only template deliberately ships none of that — it is the “backend formality” layer only.

3. The footer, item by item

The footer is the only element guaranteed to appear on every page — which makes it the one place a donor, grant maker, or regulator always finds what they need, wherever a search engine dropped them. That is why Gate-3 validation checks it on every page. Every item, and why it is there:

Candid (GuideStar) seal, profile link, and EIN

Grant makers and serious donors verify a charity on Candid before funding it, so the footer puts a working profile link and the EIN one click away on every page — a verifiable 501(c)(3) claim, and a ready-to-cite link for the charity’s own grant applications. Level 2 only: it renders exclusively once the charity actually holds IRS recognition and a public profile (see section 4).

Donate quick link

Every page ends with a giving pathway. Sites from the Single Page template ship a Zeffy donation form (zero-fee processing); post-deploy smoke monitoring treats lost donation capability as a failure class, not a cosmetic defect.

Two donation policies

The charity’s own Donation Policy (deductibility, receipts, refunds) plus the Free For Charity Donation Policy. The FFC entry keeps FFC’s name after any rebrand — deliberately, because that page documents FFC’s own gift-acceptance policy — and the drift checker exempts exactly that label.

Privacy policy, cookie policy, and the consent banner

The consent layer is built to the strictest common bar visitors browse under: analytics and marketing scripts stay off until opt-in (the posture UK/EU rules expect), withdrawal actually deletes tracking cookies, and the privacy policy carries data-rights language plus a no-selling-data statement (the posture California expects). A two-person charity inherits it all by default.

Terms of service

A stated legal basis for the visitor relationship — eligibility, acceptable use, governing law — so no charity launches without one.

Vulnerability disclosure policy + security acknowledgements

Coordinated disclosure with safe-harbor language, wired into RFC 9116 security.txt so researchers’ tools find it. Charities hold donor data; this is how a finder reports a problem safely.

Contact block: email, phone, physical addresses

The legitimacy signals grant applications, nonprofit tech programs, and payment processors check — and a human-reachable path for donors, journalists, and partners. Address links open in Google Maps with the visible text kept in the accessible name (WCAG 2.5.3).

“Supported by Free For Charity” + Supported Charity Login

The permanent attribution (siteConfig.supportedBy) and the hub login link. This is the one element that is never a rebrand target: it records the provenance of the free stack, gives every charity a path into the FFC hub from its own site, and is how the next charity discovers FFC. check:drift and check:rebrand deliberately exempt it.

Copyright + tax-status line

The year is computed at build time — never hand-typed, never stale. The “a US 501c3 Non Profit” clause renders only when it is true; on a pre-501(c)(3) site it would be a false legal claim, which is what the two passing levels exist to prevent.

4. The two passing levels

The standard is level-aware so the footer never claims more than the charity can prove:

• Level 1 (pre-501(c)(3)) — the full footer minus the two items that assert IRS recognition: strip the “a US 501c3 Non Profit” status line (a false legal claim on a pre-501(c)(3) site, flagged by the fleet audit as a violation) and skip the Candid/GuideStar item (no public profile exists yet).
• Level 2 (full 501(c)(3)) — everything in Level 1 plus the Candid/GuideStar profile link and the status line. When a charity's determination letter arrives, a small follow-up PR adds the two Level-2 items.

Operational details live in the repo doc footer-standard-adoption-checklist.md, which also sequences the retrofit of live sites that predate the standard.

5. Generated, not hand-typed

Footer data comes from the charity's validated application record, not from anyone's memory. The generator script builds the site-config partial from the application data; if it exits listing gaps, those are onboarding gaps — the application goes back for completion in WHMCS rather than anyone guessing values. This is what makes the footer trustworthy: every EIN, address, and profile link on a supported site traces to reviewed application data.

6. How the standard is enforced

The standard is machine-enforced at every stage of a site's life:

• In the templates — unit tests pin the footer's required content, and check:drift / check:rebrand stop a customized fork from shipping FFC's identity while explicitly protecting the permanent supportedBy attribution and the FFC donation-policy label.
• At Gate 3 — auto-validation live-verifies the footer markers (brand text, freeforcharity.org link, EIN) on the deployed GitHub Pages site before any domain money is spent.
• After deploy — post-deploy smoke checks every live site for its footer, required policy links, and donation capability.
• Monitoring the monitors — a dedicated canary site is deliberately broken one failure class at a time (footer element removed, policy link missing, dead donation link, lost consent banner, unrebranded defaults) to prove the smoke engine catches each one with the expected message.
• Across the fleet — the fleet audit classifies every live supported site against Level 1 / Level 2 and drives the retrofit backlog.