Stay organized with collections Save and categorize content based on your preferences.

Google takes security very seriously to ensure our users are protected. Please review Google's security requirements at All projects must adhere to these requirements. These should be called out and committed to in your SOW with Google.

You should also familiarize yourself with the Security Review Process. All projects will be subject to security review, and the more you know and are prepared, the easier the process will be.

If user data is being stored, non-Googlers should not have access to it. Particularly if the information reveals the real names, addresses, or other personal information about our users, especially when it can be tied to their email address. If Personally Identifiable Information (PII) must be collected for your project, please talk to your Google partners about using internal Google systems such as FormBox to do so.

Any data should only be kept for as long as required, for the use for which it was collected, and deleted promptly when no longer useful. If there is a way for the user to request deletion of their data, this request should be honored as quickly as possible. This includes any copies of the data that have been downloaded from and stored independently from the original application, which may be on a, doc, spreadsheet, or even a workstation. As with any other Google data, this information should be treated as HIGHLY CONFIDENTIAL.

Special Considerations for Non-Sensitive Domain Projects

It is required that HTTPS is set up as default for all non-sensitive domain projects. You will need to double check the following items:

  • Confirm HTTPS is default by using "secure: always" flag on app.yaml
  • Request SSL set up for custom domains early on (this can take 3+ weeks)

Test the site with Google Cloud Security Scanner for App Engine projects prior to submitting code for Security review:

In addition, ensure that public access to the site is restricted until the site has been approved to go live.

Coding Requirements

Any code you write for Google should follow our style guides. In some cases your code will need to go through a stylistic code review and if it does not follow our style guides, it will not be allowed to launch. Make sure you are familiar with these style guides before starting to code.

If you need more information on other Google coding style guides, you can find out more here

You should also familiarize yourself with the Code Review Process and be sure that any code you write for Google is committed to a Google provided repository (typically on

App Engine Projects

  • App Engine applications must be written in Python, Java, or Go. We have a strong preference towards Python. PHP is strictly banned at Google, NO EXCEPTIONS.
  • Python projects must use either the Python Secure Scaffold, the Djangae Scaffold or if building a purely static site you can follow the "Building A Secure Static Site" guide. If you feel your project won't work with either of these scaffolds please discuss it with your ATL before proceeding.
  • Use DataStore and not Cloud SQL.
  • Scan your site with Cloud Security Scanner early and often to ensure you're not introducing vulnerabilities.
  • Code is not reviewed against the Google style guides.

G6 Projects

  • Use standard CSS or SASS.
  • Code must be written using Google Closure or AngularJS. No JQuery!
  • Make use of Google's JavaScript UI library Glue.
  • Code is strictly reviewed against the Google style guides.

Domains Requirements

The Google PMM is responsible for obtaining URL/domain approvals and for working with internal teams to acquire new domain(s) if needed. All new domains must be acquired through Google. Do not ever purchase domains on Google's behalf.

All vendor projects must be hosted on Google infrastructure without and source code must be shared with Google regardless of domain (see below for details).

The routing of traffic from Google-owned domains to third party servers or hosting of Google projects on third party infrastructure is strictly forbidden.

Sensitive Domains vs Non-Sensitive Domains

Sensitive domain projects (also commonly referred to as "on-domain") are those that live on high-sensitivity domains such as or They have URLs such as:


If your project will live on a URL similar to the examples above, it will be considered a sensitive domain project.

Sensitive domain projects are typically built using Goro or G6. You can find more information about both in the tools and resources section. These projects require more thorough code and security reviews, so keep that in mind as you are planning your project.

Non-sensitive domain projects (also commonly referred to as "off-domain") are those that live on low-sensitivity domains. These are domains such as:


If your project will live on a domain similar to the examples above, it will be considered a non-sensitive domain project. These projects are hosted on Google App Engine.

Hosting Requirements

All sites built for Google must be hosted on either SCS (Static Content Service) or App Engine. We have a strong preference for agencies to build on App Engine. However, sensitive domain projects will always be hosted on SCS without exception.

If you're building on App Engine please do not create your own Cloud Project. Your ATL will create the project for you so that it is associated with the Google org and tied to our internal billing account.

The use of App Engine Flexible Environment or Google Compute Engine is not approved for use. If your project requires one of these non-standard environments please discuss with your ATL before proceeding.

Hosting Environment Comparison

Non-sensitive domain
[x] or custom domain
Sensitive domain,,
Content type allowed Static or Dynamic Static only
Platform Google App Engine only (internally created Cloud Project) using Python.
Java or Go are allowed upon ATL's approval. PHP is strictly banned without exception.
Bracket or G6 only.
Code repository Internal Git repository.
ATL will create and send an invite to the Git repository.
Your ATL will configure what is needed for the project.
Vendor Security Review Required: 2 weeks minimum for first-time vendors Required: 2 weeks minimum for first-time vendors
Project security review Depending on the nature of the site: 2 weeks min for light review. 3 weeks min for heavy review. Can potentially be bypassed if following Fast Track Required: 2 weeks minimum.
Code review Not required Required: 2 weeks minimum but is dependent on amount of code to review.

Browser Requirements

Make sure the site works in every user agent used by more than 5% of the site's target audience (which may be different than the general consumer audience).

We understand that not all browsers work the same, so here are some guidelines to follow:

  • Site should afford an optimal user experience in the latest two versions of all browsers that meet the 5% requirement.
  • For browsers older than the latest two versions that meet the 5% requirement, minor layout and functionality differences are allowed.

Accessibility and Performance Requirements

New websites, or updates to existing websites, are required to reach an accessibility score of 100 and a performance score of 90+ on a Lighthouse test for both desktop and mobile. Google requires your site to meet the WCAG 2.1 AA standard for accessibility. Marketing's specific guidelines can be located in MWS.

How to run a Lighthouse report

  • In Chrome, navigate to the staging URL of the site and open Dev Tools (Option + Command + J).
  • Open the Lighthouse tab and click the “Generate report” button. The report includes scores for Accessibility, Performance, Best Practices, and SEO (as well as PWA support), and provides useful data and recommendations for any issues that are identified.
  • If the Accessibility score is less than 100 or the Performance score is less than 90, Lighthouse should provide a reasoning and insight into how to improve the scores (example: minifying images).
  • Save the JSON file and share with your PMM who will submit it for approval.

The PMM can then link the doc to the Accessibility & Performance review in Launch, then ask the ATL to give the approval.


The Google PMM or ATL will send you an internally issued Google Analytics account number to use on the site. Only Google-internally issued accounts can be used and agencies are not allowed direct access to the actual Analytics account or data. Your PMM can however share generalized findings. You may not include any other Analytics tracking without prior consent from Google Privacy & Security teams nor can you double tag a site with our internal account number and one of your own.

Documentation Requirements

There are a few documents you may be required to complete as a part of your project. Make sure you check with your PMM or ATL to see if you need to complete these. Failure to complete this documentation when it is required could result in a delayed launch.

Technical Design Document

A Technical Design Document, TDD, is required for every project. It is referred to as the blueprint for how your plan to build and implement your solution. It should be drafted in the concepting phase and kept up to date during the entire lifecycle of the project.

When it is ready for review, tag your project's ATL and they will review it for any initial flags prior to it being filed with the Security team.

Ultimately Google should own the TDD, you can transfer ownership of the document under the "sharing" settings of the document to your project's PMM.

Privacy Design Document

Google takes the protection of user data very seriously. The Google PMM will need to fill out an internal Privacy Design Doc, and while access to this document by agency partners is forbidden, they may need some information from you regarding the data types you may be collecting (data type, description and field name are preferred).