Lesson 12.5. Website Requirements for Developers
Every other lesson here is written for the person running the organization. This one is written for whoever builds the website, and it exists so you can send it to them instead of explaining it.
The reason it needs to exist: a nonprofit site is not judged only by the people who visit it. Google Ad Grants pays for search advertising up to $329 a day, approval depends on the website, and so does keeping it afterwards. An account can be suspended because the site changed, months after it was approved. A developer who has never built for this programme has no way to know that, and nothing in an ordinary brief tells them.
So this is a specification rather than a wish list. Part one is what Google requires, and a site missing one line of it does not get the grant. The rest is what we ask for on top, and the last part is what to check before calling the work done.
Every requirement is marked BUILD ONCE or KEEP TRUE. The second kind is what costs organizations their grant: satisfied on launch day, quietly untrue eight months later.
What Google requires
These are the website requirements of the Ad Grants programme, published by Google at support.google.com/nonprofits/answer/1657899. Read them there as well. They are the ones that decide the application, and they change without anybody being told.
BUILD ONCE
The organization owns the domain the ads point to. Ownership means administrative control of the content, the structure and the technical settings. A site on somebody else's domain, on a builder's subdomain, or as a page inside another organization's site does not qualify. A .org ending is not required: .com, .ngo and .foundation are all acceptable.
The entire site is served over HTTPS. Every page, not the donation form alone. An expired certificate fails, and so does mixed content, where a page loads over HTTPS and pulls an image or a script over HTTP. All HTTP traffic redirects to HTTPS.
The mission and the activities are stated clearly. A visitor and a reviewer both have to find, without searching, what the organization does and who it does it for. Registration details and annual reports belong on the site as well.
The site works on a phone. Displays and functions correctly on phones and tablets, which means a responsive layout rather than a desktop page scaled down. Forms and donation flows have to be usable with a thumb.
KEEP TRUE
Substantial original content, about this organization's mission. Thin pages, text copied from elsewhere, placeholder text and anything marked "under construction" all fail. This is the requirement most often failed months after approval, because a site launched with real content grows pages nobody finished.
Navigation is clear and every link works. A broken link is a policy failure, not an inconvenience, and links rot on their own as other people move their pages. Check them on a schedule rather than once.
The site loads quickly. Measured with PageSpeed Insights, and the mobile score is the one that matters, because most of the traffic an ad account sends is mobile. Large unoptimized images and unnecessary plugins are the usual cause.
No third-party advertising and no affiliate business. No AdSense, no ad blocks sold to anybody, and the site must not exist mainly to send traffic elsewhere through affiliate links. Limited commercial activity can be acceptable, but it cannot be what the site is for.
Below is that list as something to tick off, with what to actually check rather than what to believe.
The pages the site needs
This part is our specification, not Google's, and it exists for one reason: every page carries a single subject and its own address, because that is what lets one advertising campaign lead to one page.
A single page listing five services can carry one vague campaign. Five pages carry five precise ones. This is the difference between using a fraction of the daily budget and using most of it, and it is decided by the site structure long before anybody writes an ad.
The organization's legal name and its state of registration belong in the footer, on every page.
Why the articles section decides the budget
Our recommendation, the part most often skipped, and the part that determines how much of the daily budget the organization can actually use.
A search advertising account works on relevance. Somebody types a question, an ad answers it, and the page they land on has to be about that question and nothing else. A campaign that leads to the home page is answering every question with the same page, and it performs accordingly: the click costs more, fewer people stay, and the account drifts towards the thresholds the programme measures.
An article is a landing page. That is what it is for here. Each one is a page about a single subject, which means each one can be the destination of a campaign about that subject. Two to four articles at the start are enough to run several campaigns instead of one. As the number of articles grows, so does the number of campaigns, and so does their quality, because each is narrower than the one before.
Without the section, the account has one or two places to send people, and most of the budget goes unused. That is why this is a requirement of ours rather than a nice addition.
What an article has to be, structurally:
1. Its own address, readable, one article per page. Not an accordion on a single news page, not a modal, not a PDF. 2. One heading at the top that says what the article is about, and only one. 3. A title and a short description that can differ from the heading, because they are what a search result shows. 4. Written for somebody who has never heard of the organization, since that is who arrives from an advertisement. 5. One clear next step at the end: apply, donate, contact, subscribe. 6. A date, and a listing page that puts the newest first. 7. Original text. Copied text fails Google's content requirement and takes the whole site down with it.
Length matters less than being genuinely about one thing. An article that answers one question completely is worth more than three that mention five topics each.
Email, which is part of the job
The organization needs email on its own domain. This is a requirement of the verification the grant depends on, not a preference: an organization writing from a free mailbox cannot prove it controls the domain it is asking to advertise.
BUILD ONCE. At least one role address read by a person, info@ or contact@ at the domain, rather than a personal name, so that somebody leaving does not take the correspondence with them.
BUILD ONCE. SPF, DKIM and DMARC, all three. Without them the organization's mail lands in spam folders or does not arrive at all, and the failure is invisible from the sending side: nothing bounces, the letters are simply never read. SPF lists who may send for the domain, DKIM signs each letter, DMARC states what a receiving server should do when a letter fails the first two. Publish DMARC in reporting mode first, read the reports for a week, then tighten it.
BUILD ONCE. The forms on the site send from the domain, not from a personal account. A contact form mailing from a random address gets filtered and the enquiry is lost with no trace. If a third-party service sends on the domain's behalf, authorize it in SPF and have it sign with DKIM.
KEEP TRUE. Somebody reads the mailbox. Advertising sends people who write, and a mailbox nobody opens turns paid traffic into nothing. This is the cheapest failure on the list and the most common.
What to hand over
The site is finished when these exist and have been checked, not when it looks done. Every item is something the organization can verify without the developer present, which is the point of the list.
What the developer does not do
So that nobody builds the wrong thing twice. The advertising account itself is not a website task: the campaigns, the keywords, the geographic targeting, the conversion tracking, the account structure, and the programme thresholds that have to be held month after month. A developer cannot control any of that, and nothing in this document asks them to.
What the account needs from the site is exactly what is above: pages that carry one subject each, an articles section that can grow, and email that arrives. Build those and there is something to advertise with.
The reverse is worth saying too, because it is where the money is lost. A site can be built perfectly and still lose the grant, if six months later three pages say "coming soon", the mailbox nobody reads is full, and half the outbound links point at pages that have moved. That is why half of this document is marked KEEP TRUE, and why the handover list ends with a report rather than a launch.
What to file in your Binder
The handover checklist with every item confirmed, the PageSpeed results, and the broken link report, all dated. Then the KEEP TRUE items go into the compliance calendar from your compliance calendar, because they are recurring obligations rather than launch tasks: a link check, a PageSpeed run, and a look at whether anything on the site has quietly become untrue.
Frequently asked questions
Can we use a website builder?
Yes, provided the site runs on the organization's own domain with administrative control of content, structure and technical settings. A builder's own subdomain does not qualify.
Does the domain have to end in .org?
No. Google accepts .com, .ngo, .foundation and others. What matters is who controls it.
How many articles are enough to start?
Two to four is enough to run several campaigns instead of one. The number is not a threshold to pass, it is what decides how much of the daily budget can be used at all, so it keeps mattering after launch.
Who writes the articles, the developer or the organization?
Usually the organization, because they have to be original and about this organization's work. What the developer owes is the structure: one article per page, its own readable address, a title and description separate from the heading, a date, and a listing that puts the newest first.
The site is already built. Does all of this apply?
The BUILD ONCE items apply as an audit, and most existing sites fail two or three of them, usually mixed content, a domain held in somebody else's account, or an articles section that is one page with expanding blocks rather than pages with addresses.
What actually causes a suspension after approval?
Almost always a KEEP TRUE item: unfinished pages, broken links, or content that stopped being original. Not the design, and not the technology chosen.
Closing
Hand this to whoever builds the site, and keep the handover list for yourself. The parts marked BUILD ONCE end when the work does. The parts marked KEEP TRUE are the ones that decide whether the grant is still there next year, and they belong to the organization from the day the site goes live.
Would rather have this done than learn to do it?What we do, and where to start
We put a mission into words, file the registration, claim the grant and benefit programs that open once the determination letter arrives, worth up to $329 a day of Google advertising alone, and get an operating nonprofit found by donors, sponsors and volunteers.
Which of that applies depends on where you are. Tell us, and we will say what is open to you and in what order.
Either route reaches a person who reads it and answers, usually the same day. There is no charge for working out what fits you. We are not attorneys and not CPAs, and nothing here is legal or tax advice.