Privacy policy checker
Checks your privacy policy exists and contains real GDPR and CCPA substance.
What TMOD checks
- Locates your privacy policy by URL patterns, internal link text, and an AI classifier that recognises the page in any language.
- Reads the page and tests it against GDPR vocabulary, legal basis, data subject rights, processors, retention, rather than only confirming a page exists.
- Tests separately for CCPA concepts, including the right to opt out of sale and the disclosure of categories collected.
- Checks for general privacy vocabulary as a baseline, so a policy that is neither GDPR- nor CCPA-shaped is still assessed rather than failed outright.

Why it matters
A privacy policy is an explicit AdSense requirement, not a nice-to-have. Serving ads means third-party cookies and data collection you are obliged to disclose, and its absence is one of the more common straightforward rejections.
It is also a legal requirement in most jurisdictions the moment you collect any personal data, and analytics counts. The exposure there is considerably larger than a rejected ad application, with regulators rather than a review queue on the other end.
The reason this check reads the content rather than confirming a URL exists is that almost every site has a page at /privacy, and a large share of them say nothing. A page reading 'we value your privacy and do not share your data' is not a privacy policy in any sense that matters to either a regulator or a reviewer.
How to fix it
01Describe your actual data flows
Name every service that receives visitor data: analytics, ad networks, embedded video, fonts loaded from a CDN, comment systems, hosting. This list is what a policy is for, and it is the part templates cannot fill in for you.
02Cover the required elements
What data is collected, why, on what legal basis, who it is shared with, how long it is kept, and how someone exercises their rights including access and deletion. If EU visitors are in scope, GDPR expects all of them stated.
03Disclose advertising cookies explicitly
AdSense requires you to disclose the use of third-party ad cookies and, where applicable, point to Google's own advertising policies. This is a specific, checkable requirement and a common omission.
04Link it from every page and keep it current
A footer link on every page is the convention and the expectation, alongside the other pages a reviewer looks for. Revisit it whenever you add a service, a policy that has not been touched in three years is unlikely to still describe your site.
What the major regimes actually ask for
GDPR wants a policy someone can act on. What personal data you collect, why, the lawful basis for each purpose, who else receives it, whether it leaves the region, how long you keep it, and how a visitor exercises access, correction, deletion, portability and objection. Plus a real way to contact whoever is responsible. Analytics and advertising both count as processing, which is what brings an ordinary blog into scope.
California's rules approach the same ground from the other side. They centre on categories: what categories of personal information you collect, where they came from, what you do with them, who you disclose them to, and a clear route to opt out of sale or sharing, which for a site running behavioural advertising is not a hypothetical.
Cookies sit under separate rules again, which is why a policy and a consent mechanism are two different obligations rather than one. None of this is legal advice, and the check here is not a legal review: it reads the page for the substance these regimes expect and tells you what is missing. Whether your specific processing is adequately covered is a question for someone who can be professionally wrong about it.

Keeping the policy true after you add a tool
A privacy policy is a snapshot of a system that keeps changing. Every embedded video, hosted font, heatmap trial, chat widget, comment system and ad partner added after the policy was written is a processor the policy does not mention. Nobody removes one, and nobody updates the page, so the document drifts from the site by a service or two a year.
The practical fix is to derive it from something you already have. The list of third-party requests your pages make is the same list the performance audit produces when it asks why the site is slow, and it is the closest thing to ground truth about who receives visitor data. Walking that list once or twice a year and reconciling it with the policy takes an hour.
Then date the review on the page, and delete the services you have dropped rather than leaving them listed in case they come back. Both directions matter: an omission is a gap, and a policy naming processors you do not use tells a reader, a reviewer or a regulator that the document was never about this site in the first place.
An inventory pass on one ordinary blog
A recipe blog whose owner would tell you, sincerely, that it collects nothing. Open one article with the browser's network panel and read the third-party domains: an analytics tag, AdSense, an embedded YouTube video, fonts loaded from Google's CDN, a Pinterest save button, and Gravatar fetching commenter avatars. Six services receiving visitor data, on a site with no accounts and no shop, and the privacy policy names none of them. That gap between what the owner believes and what the network panel shows is the single most common finding this check produces.
Each service dictates its own paragraph. Analytics: usage data and device information, and whether IP addresses are truncated. The ad network: cookies, personalisation, and a pointer to Google's own disclosure and opt-out pages, which AdSense contractually requires you to provide. The video embed: sets cookies once played, worth a sentence and the privacy-enhanced embed mode. The hosted fonts are the one people are most surprised by: loading them remotely transmits the visitor's IP address to the font CDN, and a German court found in 2022 that doing so without a lawful basis violated GDPR. Comments: what is stored with each one, name, email, IP, and for how long.
Written that way, the policy is six short paragraphs of fact plus a rights section with a working contact address, and it reads like it was written about this site because it was. It is also now falsifiable, which is the property that matters: a reader, a reviewer or a regulator can check any sentence against the site's actual behaviour and find them agreeing. It is also shorter than the template it replaces, which is the counterintuitive part: a policy that describes one real site needs a fraction of the words of one drafted to cover every site that might ever use it.
The inventory also hands you the maintenance schedule for free. The list of third-party requests is the same list the performance check complains about, so any time a new widget appears in one, it belongs in the other. And where a listed service sets cookies for EU visitors, the policy needs its companion: a consent mechanism that actually gates those requests, which the policy audit tests as a pair with this page.
Questions
I have a privacy policy but it is flagged. Why?
The check reads the content and looks for the substance a real policy contains, what is collected, the legal basis, third-party processors, retention, and how rights are exercised. A short page asserting that you respect privacy without describing any actual processing will be flagged, and that is the correct result.
Does GDPR apply if I am not in the EU?
It applies based on whose data you process, not where you are. If EU residents visit your site and you collect their data, which analytics does, you are generally in scope. Most site owners find it simpler to write one policy that satisfies the strictest regime they plausibly touch than to attempt geographic segmentation.
Can I use a generated privacy policy?
As a starting point, provided you then edit it to match your site. Generators produce reasonable structure and standard clauses. What they cannot know is which services you actually use, and a policy naming products you do not use while omitting your ad network is a compliance problem rather than a solution.
Is a privacy policy enough on its own?
No. For EU visitors you also need a working consent mechanism that gates tracking before it fires, which is checked separately. A policy describing consent you do not actually collect is arguably worse than no policy, because it documents the gap.
Should the privacy policy be its own page, or can it share one with the terms?
Give it its own page at its own URL. Nothing prohibits a combined legal page, but separation wins on every practical axis: the footer link can say what it is, a visitor looking for the privacy section does not scroll through liability clauses to find it, and automated detection, ours, Google's, or a consent platform's page scanner, finds the document it expects at an address that names it. The terms deserve the same treatment for the same reasons.
Read more
Screaming Frog, Ahrefs and Sitebulb for AdSense readiness
The big SEO crawlers are better at technical auditing than any AdSense tool. They are also scoped to a different question. Here is where the line falls.
The robots.txt lines that quietly block ad crawlers
Blocking Mediapartners-Google costs you ad revenue while the site keeps ranking normally, so nothing looks wrong. Here is how to read the file.
What AdSense means by "low value content"
The rejection reason gives you nothing to act on. Here is what reviewers are actually looking at, and the order to fix it in.