Adopting the FFC Footer on an Existing Website
The compliance layer that gets an already-designed site through FFC validation
Charities that already have a designed website don't rebuild it — they adopt the FreeForCharity/FFC-IN-Footer_Only_Templatelayer on top of their existing design. Passing FFC validation on the site's GitHub Pages address is what unlocks the domain step — FFC registers a new .org, or transfers the domain you already own, in Cloudflare and points it at your validated site.
On this page
1. Who this path is for
FFC's gated onboarding journey has two website paths, and both converge on the same validation gate:
- No website yet?An FFC volunteer builds a complete single-page site from the charity's content — see Build a Charity Site from the Template.
- Already have a designed website? This guide. The charity keeps its design and adopts the FFC footer and compliance layer from FFC-IN-Footer_Only_Template, which is what makes the site pass FFC validation.
In both cases the site goes live on its free GitHub Pages address first (no custom domain). Only after it passes validation there does FFC register the charity's new .org — or transfer the domain it already owns — in Cloudflare. The full sequence is on the charity onboarding journey page.
2. What the charity adopts
The Footer-Only Template contributes exactly the pieces an already-designed site is usually missing — the legal, compliance, and infrastructure formality of the FFC standard:
- FFC footer — contact info, social links, policy links, GuideStar badge, and branding.
- 7 legal/policy pages — privacy policy, cookie policy, terms of service, donation policies, vulnerability disclosure, and security acknowledgements.
- GDPR cookie consent — banner with granular opt-in/opt-out controls.
- Analytics — Google Tag Manager with a consent-aware data layer.
- Team section — data-driven team member display.
- SEO infrastructure — sitemap, robots.txt, Open Graph and Twitter Card metadata.
3. Add the layer to the existing site
The charity's site lives in a FreeForCharity repository and deploys to GitHub Pages, with the existing design preserved. Point your AI agent at the template and let it graft the compliance layer in.
“Read FreeForCharity/FFC-IN-Footer_Only_Template and its README. Then, on a new branch in <charity-repo>, adopt the FFC footer, the 7 policy pages, the cookie consent banner, the GTM integration, and the team section — without changing the site's existing design or content. Fill in <Charity Name>'s contact details and team data, and show me what changed before opening anything.”
Run the repo's formatting, lint, build, and test checks as documented in its own conventions, then open a pull request and let CI validate it. Once it merges, GitHub Pages publishes the updated site on its *.github.io address.
4. Pass FFC validation
FFC validates the live site on its GitHub Pages address. An already-designed site that has adopted the footer layer passes when:
- The site is live on its GitHub Pages URL with a green CI build — no custom domain yet.
- The FFC footer renders on every page with the required policy links, contact info, and branding.
- All 7 policy pages resolveand contain the charity's information rather than placeholder text.
- The cookie consent banner appears and gates analytics until consent is given.
- GTM analytics fires (consent-aware) and the team section shows real people.
- SEO basics are in place — sitemap, robots.txt, and page metadata.
5. What passing unlocks
Validation is the gate. Once the site passes on its GitHub Pages address, FFC registers a new .org — or transfers the domain the charity already owns — in Cloudflare and points it at the validated site (Cloudflare DNS → GitHub Pages, a Global Admin task — see the Domains & DNS module). The domain in turn unlocks charity email setup.