How to Get Your Nonprofit Website Approved for the Google Ad Grant

By Zoya Syal

Google's eligibility guidelines for US nonprofits never mention your website. Not the domain, not HTTPS, not one line about page content. The website test arrives later, at activation, after your organization has already been told it qualifies.

Google's Ad Grants website policy requires a nonprofit to own the domain its ads point to, meaning administrative control over the site's content, structure, and technical settings. The entire site must load over HTTPS, state the mission clearly, describe programs in real page content, and carry no broken links or broken donation buttons.

Applications clear the organizational checks and stall on a site nobody thought to look at. For the program itself, read how the Google Ad Grant works end to end, and if that part is unsettled, whether your nonprofit clears Google's eligibility rules. What follows is that gate, in the order a reviewer meets it.

Own the domain and secure the whole site before you apply

Confirm the organization controls the domain, not a former volunteer

Google's Ad Grants website policy puts that control test on you, and two questions settle it. Can someone at your organization sign into the registrar today and change a DNS record? Can that person edit a page and publish it without asking anyone outside? A no on either means the domain sits with a web designer, a parent organization, or the volunteer who built the site in 2019 and stopped answering email. Moving it is a transfer of accounts, not an afternoon of editing.

The extension does not decide it. Google says a .org is not a strict requirement.

Serve every page over HTTPS, not just the donation form

The failures Google lists are the ones a homepage padlock hides: no SSL certificate, an expired one, or mixed content, where the page loads over HTTPS but an image or script on it still loads over HTTP.

Google's instruction is to redirect all HTTP traffic to HTTPS automatically. Its published rejection reason reads "Website does not use HTTPS across all pages, or has mixed content warnings."

Show a reviewer what your organization actually does

Give your main pages real content, not a carousel

The pitfalls Google names are common on a site built over a weekend. Very little text. Content copied from elsewhere with nothing original added. Pages that are mostly links or embedded video. Pages still marked under construction.

Google's guidance tells you to develop the key pages it names, with detailed, unique text: Homepage, About Us, Mission, Programs and Services, and Contact. It also tells you to feature the mission prominently and to include your registration number, meaning your EIN or tax ID, or an annual report. Those last two are guidance, not requirements. Do them anyway.

Move core information out of PDFs and onto real pages

Google lists relying heavily on PDFs instead of HTML pages for core information as a pitfall. The annual report is a PDF, and so are the program descriptions.

Open your Programs page and count what is on it. A heading and three download links reads as an almost empty page, to a reviewer and to a crawler. Move that information into the page and keep the PDF underneath.

Fix the links and the donation path before a reviewer finds them

Users must be able to find information easily, and Google's wording is that all links should work correctly. Google's pitfall list runs past broken links into structure: a confusing menu, disorganized pages, links to empty pages, and broken donation buttons.

Google's instruction is to run a broken link checker over the site. It catches the external links that died since you published, like the partner that rebranded while your resources page still points at their old URL.

Walk the donation path to the confirmation screen

Donation buttons get named twice, in Google's pitfalls and again in its published rejection reasons, where the wording is "broken/insecure donation links." Its commercial-activity line adds that donation links must go to a secure page dedicated to donations.

Do the click yourself, on the live site, not the staging copy. Homepage button, giving page, a test transaction if your processor allows one, all the way to the confirmation screen, watching the address bar. A flow that hands the visitor to a processor on an unsecured page fails the requirement that donation links go to a secure page, and it is named in Google's rejection reasons as a broken or insecure donation link.

Make the site fast enough and usable on a phone

Google publishes no number here. No load-time threshold, no minimum score, nothing to hold up to a board. It says pages should load quickly across devices and connection speeds, and that the site must display and function correctly on smartphones and tablets. Its published rejection reason is poor performance in tools like PageSpeed Insights, particularly on mobile.

Run your homepage and one interior page through PageSpeed Insights and read the Mobile score, which Google tells you to watch specifically. The causes it lists are ones you can fix without a developer: large unoptimized images, a heavy theme, excessive plugins and widgets, large custom scripts, and inadequate hosting. Compress the images first.

One correction. Google's policy page still points readers to its Mobile-Friendly Test tool, and that URL now redirects to Lighthouse documentation. Use PageSpeed Insights instead, and build on the responsive design Google's action step asks for.

Take the commercial signals off a nonprofit site

Your site has to comply with Ad Grants policies on commercial activity, advertising, and prohibited content, and stay focused on the mission. Google says an online store selling mission-related items may be acceptable as long as selling is not the primary focus, and that financial information must be clearly presented.

Two lines about third-party ads on the same Google page do not match. The requirement is that a site cannot host excessive third-party ads, with AdSense named as the example, and cannot function primarily to send traffic to other websites through affiliate links. The action step is flatter: do not display AdSense ads on your website. Take the second as the safe reading. Ad revenue on a nonprofit site is rarely worth what it risks.

Get a second domain approved before you point ads at it

More than one domain can be approved, and Google publishes the route: a section of the website policy headed "Requesting an additional domain." Each one clears the same check.

Google's wording is that before submitting a new domain you must ensure it meets all of the website policy qualifications, and only then request approval through the additional website domain request form. A campaign microsite or an event domain is a fresh review each time.

The policy page says requests submitted through the form are reviewed within 3 to 5 business days. The request form itself says 7 business days. Both are Google's own. Build your calendar against the 7.

Run the review yourself before you submit

Google's instruction is to treat the requirements on its website policy page as a checklist and address all potential issues before reapplying or requesting a review. Work it in the order above, on the live site, on a phone as well as a laptop.

Google says only that once a decision is made, you will receive an email containing further instructions. It does not publish whether that email names the item that failed, which is the argument for auditing the whole list yourself rather than waiting to be told.

Two notes from Google's Ad Grants activation steps. Step 1 is to verify the site is secure with HTTPS and meets the website policy standards, before you enter your website in step 2, and Google says the review that follows "may take several business days." Do not create a Google Ads account during activation. One is provided for you, and building your own first leaves you with an ordinary paid account the grant will not attach to.

After a rejection, Google's troubleshooter names the case plainly: you submitted a website that can't be approved in its current state. The site keeps mattering after approval. Google states that any account found in violation of program policies is subject to automatic suspension without notification. How a live account slips out of policy after approval covers that stage, and what Ad Grant setup and monthly management involve sets out the ongoing work.

Google Ad Grant website questions nonprofits ask

What are the website requirements for the Google Ad Grant?

Own the domain, meaning administrative control over its content, structure, and technical settings. Serve the whole site over HTTPS. State the mission and describe programs in original page content. Keep links and donation buttons working, pages fast on mobile, and excessive third-party advertising off the site.

Does the Google Ad Grant require HTTPS on the whole website?

Yes, the whole site, not the donation page alone. A missing or expired SSL certificate fails it, and so does mixed content, where an HTTPS page loads an image or script over HTTP.

Can you run AdSense or other third-party ads on an Ad Grant website?

The stated requirement is no excessive third-party ads, with AdSense named as the example. Google's action step is flatter: do not display AdSense ads on your website.

Why would Google reject a nonprofit website for the Ad Grant?

Google's published rejection reasons include no HTTPS across all pages, broken links and donation buttons, insufficient unique content, slow load speed, poor mobile experience, and disallowed commercial activity. Fix them on the live site, then request a review.

Can Ad Grant ads point to more than one website domain?

Yes. Google publishes a process for requesting an additional domain, so more than one can be approved. Each new one meets the website policy first, then goes through Google's additional website domain request form. The policy page says 3 to 5 business days, the form says 7.

Find out what your site would fail on

Most of this you can do yourself with a free tool and an afternoon. The hard part is knowing which item a reviewer will stop on, and whether the fix is a setting or a rebuild.

We will go through your site against Google's website policy point by point and tell you what stands between it and activation, in the order to fix it. If the site needs rebuilding before an application is worth filing, we will say so. Have us run your site against Google's website policy.

Zoya Syal is Content and Production Manager at Nonprofits Engine, where she runs the content and testimonial program for a team that gets small nonprofits formed, funded, and found online.