Why this signal matters for Google
A privacy policy is a written promise about technical facts. It says what your site does with a visitor's data: what it collects, through which tools, why, for how long, and who else receives it. That is what makes it different from your other legal pages: anyone can check it in thirty seconds. Open the browser Network tab (press F12) and compare the outside domains being called with the list you published. A page that never mentions your analytics tool, your advertising pixel or your newsletter form is not incomplete. It is wrong, and a suspicious visitor notices before you do.
Google sends its evaluators looking for this page. Human evaluators rate the quality of websites using a public manual, the Quality Rater Guidelines (QRG for short). Section 2.5.3 points them to the About, contact and customer service pages, to work out who is responsible for the site and how to reach them. The privacy policy belongs to that set, and the more you ask of the visitor, the more is expected of it. Section 3.2 puts trust at the centre of the rating: collecting personal data without saying what happens to it runs straight into that criterion. This page works as a pair with your legal pages: those say who you are, this one says what you do with the data of the people who trust you.
On a sensitive topic, the bar goes higher. Google calls those topics YMYL, for Your Money or Your Life: anything touching health, money or the law. Section 3.4.1 expects real trustworthiness there, and section 5.1 rates as Low quality a page that is not as transparent as its purpose demands. A health advice site whose form asks for symptoms, or a loan comparison tool that captures income, handles data nobody hands over lightly. The law says the same thing: privacy rules such as the GDPR require you to tell the person, at the moment you collect, in plain language, what you do with the data, on what legal basis, how long you keep it, and how to access, correct or delete it. The good news is that you write the page once and satisfy both at the same time.
For AI tools, this page is worth what it lets them cross-check. When ChatGPT, Perplexity or Google's AI summaries weigh whether a source is credible, they lean on details they can find elsewhere: a company name, a named person in charge, a contact address identical to the one on your other pages, an update date. A policy published as an image or a PDF matches nothing. Neither does a policy naming a company that appears nowhere on your About page. The most common failure looks like this: the page exists, but it cites a legal name, an analytics tool and an email address found nowhere else on the site.
The NeuroEEAT scoring grid (0-10)
Score the page on what a reader can verify, not on how long it is. Four thousand words copied from a template are worth less than thirty accurate, dated lines.
| Score | Description | Concrete indicators |
|---|---|---|
| 0-2 | Missing | No privacy policy at all, or a footer link that leads to an error, on a site that sets cookies and runs forms. The visitor has no way to know what they are handing over. |
| 3-4 | Generic | A generator page with blanks left unfilled or another company's name in the text. No tool named, no retention period, no date. |
| 5-6 | Half accurate | Broad data categories and rights are described correctly, but the real vendors, the retention periods and the transfers are missing. The page matches only half the scripts the site actually loads. |
| 7-8 | Verifiable | The company in charge is named, purposes and legal bases are stated, tools and retention periods are listed, rights come with instructions, and the page is dated. A reader can match the page against how the site behaves. |
| 9-10 | Kept true over time | Accurate, dated, consistent with the cookie banner, the legal pages and the contact details. Access and deletion requests get a real answer within the deadline, and the page is reviewed whenever a new tool goes in. |
How to audit it on your site
Five checks to find out whether your policy describes your site or the template it came from. Budget an hour, no tools to buy.
- 01
Compare the page with what your site really loads
Open the site in a private window, press F12, open the Network tab and list the outside domains called on arrival (Google Analytics, Facebook, YouTube, a web font...). Match that list against your policy. Every domain missing from the text is an undeclared use of data, and it is the most common gap in the whole audit.
- 02
Check who is named as responsible
Does the page name the company that decides all this, with an address and a way to reach it? Section 2.5.2 of the QRG asks who is responsible for the site. An anonymous "we" is responsible for nothing.
- 03
Test your cookie banner
Reload the page, reject everything, then look at what gets set anyway. A banner that offers a choice while trackers fire before the click turns your policy into a public contradiction: the text says one thing, the code does another.
- 04
Look for retention periods and recipients
For each type of data, how long do you keep it, and who else can see it? This is what generic templates almost always skip. It is also what proves the page was written for your site.
- 05
Run the access request test
From a personal email address, write to the address you published and ask for your data. Time the reply: privacy rules such as the GDPR give you one month. A dead address cancels everything above it, because a right only exists if somebody answers.
How to activate or improve it
Three levels, from a page that finally exists to a policy that matches what your site really does.
Write an accurate page
- List every place the site collects something: contact form, newsletter, comments, cart, analytics, advertising.
- For each one, write what you collect and what it is used for, in short sentences and no jargon.
- Name the company responsible, its address, and an email address somebody actually reads.
- Put a plain link in the footer of every page, with "Privacy policy" as the wording.
- Date the page, and delete any template sentence you could not defend in front of a customer.
Make the policy verifiable
- Name every vendor and its role: host, analytics tool, ad network, email platform, payment processor.
- For each type of data, say what it is for, on what legal basis you keep it and for how long · server logs included.
- Explain how to exercise a right: who to write to, what to include, and how long the reply takes.
- Align the cookie banner with the text in both directions: nothing non-essential before consent, and withdrawal as easy as agreement.
- Connect the policy to your <a href="/en/trust/legal-notice/guide">legal pages</a> and contact page so they read as one block.
Keep the page true over time
- Keep an internal table of everything you do with data and make it the reference: the published page becomes its readable version.
- Review the policy whenever a new tool goes in, as a release step, rather than once a year.
- Repeat the essentials where you collect, under each form, with a link to the matching section.
- If your tools are hosted abroad, say so and explain what covers those transfers.
- Publish a short history at the top of the page: what changed, on what date, and why.
5 common mistakes to avoid
Sector specifics
Practitioner and health advice site
A booking form that asks for a reason for the visit collects health data, a category that HIPAA in the US and the GDPR in Europe both treat separately from ordinary data. Section 3.4.1 expects real trustworthiness here: say who can open the record, where it is hosted, how long it is kept and how to have it deleted. A generic small-business template does not cover that level of risk.
Online store
The customer hands over an address, a purchase history and a payment method. Name your payment processor, say clearly what you do not store (card numbers, for example), and keep two periods apart: invoices, which accounting rules dictate, and marketing data, which consent governs. This page is read alongside the technical <a href="/en/trust/security">security</a> of the site.
Ad-funded publisher
Targeted advertising and analytics are the most intrusive uses of data, and the least often declared. List your advertising partners, explain what consent actually switches on, and connect the page to your <a href="/en/trust/conflict-of-interest/guide">conflict of interest</a> disclosure: readers judge what you earn and what you collect together.
Local shop or service
A brochure site with a form and a booking tool follows the same rules on a simpler scale. Name the two or three vendors you use, give the business email rather than your agency's address, and check that the company name matches the one on your business listing and legal pages.
Signals to activate in parallel
A privacy policy proves nothing on its own. It holds up through the signals that identify the publisher and protect the data:
FAQ
How to write a privacy policy for a simple brochure site?
Start from what you actually collect, not from a template. List your forms, your cookies and your vendors, then write, for each one, what you collect, why, for how long and who to email to have it deleted. Thirty accurate lines beat ten generic pages.
Can you use a privacy policy generator?
As a starting point, yes: it stops you forgetting a section. As the finished text, no. A generator knows none of your tools, your retention periods or your vendors. The real work starts afterwards: replace every generic clause with what your site does, and delete the paragraphs describing things you never do.
Does a privacy policy help SEO?
Not directly, it is not a ranking factor. It affects trust, which section 3.2 of the QRG places at the centre of the rating, and what an evaluator finds when looking for who is behind the site. On a site that collects data, its absence does far more harm than its presence does good.
Do you have to name vendors one by one?
Yes, and that is what separates a verifiable page from a decorative one. "We may share your data with partners" informs nobody. Naming your host, your analytics tool and your email platform lets the reader match your list against what their own browser loads.
How often should the page be updated?
Whenever a tool changes, not on a fixed date. Adding live chat, an ad network or a new form creates a use of data that has to appear in the text. A yearly review is a safety net, but it will not recover six months of drift between what the site does and what the page claims.
Anonymized case study
Before · a generator page
After · a policy that matches the site
Illustrative figures meant to show the typical progression of the signal. They do not come from a real client case and must be replaced with your own measurements before any external communication.