Real fixes from seven live sites. No pitch.Log in / My reports
Idea to Traffic Pressure Test

Why AdSense rejects sites, and how to get approved

AdSense most often rejects new sites for low value content: pages that are mostly tools or links with little original explanation, a privacy policy that does not match the site, broken technical files, and too little history. Fix the pages, not the word count, and reapply only after the changes are live and indexed.

Measuring a rejected site instead of guessing

We measured a utility site after a low value content rejection instead of eyeballing it. Seventeen pages. 4,067 words of prose across all of them, an average of 239 words per page. Four of those pages were letter-specific word lists at 128 words each, whose surrounding text was 99 to 100 percent identical, differing only in the letter named. One page looked like it ran past a thousand words until we separated the generated output from the prose: 972 word chips and 212 words a reader would actually experience.

None of that was a judgement about writing quality. It was arithmetic, and it was the same arithmetic a reviewer or a classifier performs. Four pages that differ by one letter are functionally one page published four times.

Disclosure. The measurements in this guide come from a low value content rejection on one of the other sites in the Edgewater Media network, a word-game utility site, not from this site. We publish them because they are the only figures we have that were measured rather than guessed, and because the arithmetic transfers.

Most AdSense rejection advice online is generic: "add quality content," "be patient." That's not wrong, but it's not specific enough to actually act on. Here's what actually determines approval.

1. Your privacy policy has to be accurate, not just present

A privacy policy that describes tracking you don't actually have, or omits tracking you do have, is worse than not having detailed language at all. Before writing it, check exactly what's actually installed on your site: which analytics tool, whether it uses cookies, what ad network you're applying for. Write the policy to match reality, and update it when that reality changes.

A privacy policy needs, at minimum: disclosure of ad-network cookie use with opt-out links (Google's Ads Settings, aboutads.info), an accurate description of any analytics tool actually installed, a children's-privacy line, and it needs to be linked from every page's footer, not just the homepage.

2. ads.txt: the file that can hurt you if you get it wrong

Don't create ads.txt until you have your real publisher ID. A malformed or placeholder entry in this file is read by Google's crawler as authoritative, meaning a fake ID can actively work against you, not just sit there harmlessly. Once you have a real ID, the file is one line:

google.com, pub-XXXXXXXXXXXXXXXX, DIRECT, f08c47fec0942fa0

3. The bug that fails silently and tanks approval without you ever seeing an error

This is the one almost nobody talks about, and it's become more common as more sites get built with AI tools and deployed to modern static hosts. A file, often your stylesheet, can return a successful 200 OK status while actually serving the wrong content entirely. The page looks "up" to any automated check, but a real visitor (or a real reviewer) sees a completely unstyled, broken-looking page.

This happens because many hosting platforms have a fallback behavior: if a specific file wasn't actually included in your deployment, instead of a clean 404 error, they silently serve your homepage's HTML in its place, with the wrong file type. Status code checks don't catch this, so open the site in a real browser and look at it.

How to check: for any file your site depends on (your CSS file is the most common victim), fetch it directly and check the response header. If a .css file's Content-Type comes back as text/html instead of text/css, that file was never actually deployed, even though visiting it returns "200 OK."

4. Site age and traffic aren't hard requirements, but they're not nothing either

AdSense doesn't have a published minimum traffic threshold, but a brand-new site with a handful of daily visitors and no external validation is a harder approval case than one with some organic search presence already. If you can, let a site accumulate a few weeks of real content and at least some organic traffic before applying. It's not required, but it measurably helps.

The realistic timeline

Google's own guidance says review "usually takes a few days, but in some cases it can take 2-4 weeks." Don't read silence as rejection before that window has actually passed.

← Back to the full checklist to see where this fits alongside deployment, analytics, and traffic.

"Low value content" is the rejection you will probably get, and it is measurable

The policy centre wording is vague on purpose, which is why people read it as a judgement about quality and respond by rewording their homepage. It is more concrete than that, and it can be measured before you submit.

Here is what one of the utility sites in our network looked like after a low value content rejection, measured rather than eyeballed. It was a word-game site we run. Seventeen pages. 4,067 words of prose across all of them, an average of 239 words per page. Four of those pages were letter-specific word lists whose surrounding text was 99 to 100 percent identical to each other, 128 words each, differing only in the letter named. One page appeared to run over a thousand words, but 972 of them were generated word chips and only 212 were actual prose.

None of that is a quality judgement. It is arithmetic, and it is the arithmetic a reviewer or a classifier is doing. A page that is mostly generated output with a caption on top has almost nothing on it that a person could not get from the tool itself, and four pages that differ by one letter are, functionally, one page published four times.

Measure your own site before you argue with the decision

Do this before rewriting anything, because the result usually decides what to rewrite.

Count prose words per page, excluding navigation, footer, and anything your tool generates. A crude version of this is a few lines of Python using an HTML parser to strip tags and skip any element carrying your generated-content class. What you want is the number a reader would experience, not the number in the file.

Then compare your pages against each other. If you have a family of similar pages, run a text similarity check across them. Anything above roughly 80 percent similar is a duplicate wearing different headings, and it counts against you rather than adding to your page count.

A rough target that has worked: 1,000 words or more of genuine prose per content page, with cross-page similarity in the single digits. That is not a published threshold and nobody at Google will confirm a number. It is well clear of the range where a site gets flagged.

Write from something, not about something

The trap when adding a thousand words to a page is producing a thousand words of nothing, which reads worse than the 200 words you started with and does not help.

The material that works is specific to the page and could not be copy-pasted onto its neighbour. On a word list page, that means facts derived from the actual list: how many entries start with each letter, which positions a rare letter occupies, which subsets are worth memorizing and why. On a calculator, it means what the numbers mean in a real situation, which inputs people get wrong, what the output does not account for.

The test is simple. Take a paragraph from one page and put it on a sibling page. If it still makes sense there, it was filler. Every paragraph should be false or nonsensical on any other page of your site.

Derive your specifics from the data rather than asserting them. It takes a few minutes to compute the real distribution of something and it means every claim on the page is true. It also means the page contains information that genuinely does not exist elsewhere, which is the actual bar.

The network problem: seven sites that say the same thing

If you are building more than one site, there is a failure mode that does not exist for a single site.

The efficient way to build a second word-game site is to reuse the first one's copy with the nouns changed. That produces two sites that are, to a classifier, one site. It is worse than having one site, because now both are flagged.

The fix is to give each site a genuinely different pillar even when the underlying tool is similar. Two sites that both solve letter puzzles can be written around completely different subject matter: one around board game scoring, tile values, and rack management, the other around puzzle grids, cluster shapes, and level clearing. Same tool, different knowledge, no overlap.

Resubmitting repeatedly does not help

Once a site is rejected, the instinct is to make a small change and resubmit, then repeat. That burns weeks, because each review cycle takes days and a small change does not move a site that was flagged on a structural problem.

Fix the whole thing, then resubmit once. If the rejection was low value content, that means every content page, not the three you thought were weakest. Reviewers look at the site, not at the pages you would prefer they look at.

And check the thing everyone forgets: whether your fix is actually deployed and visible to a crawler. A rewritten page sitting in version control is worth nothing, and a page behind a stale cache is worth less than nothing, because it looks fixed to you and unchanged to them.

What approval will not do for you

Word counts and similarity scores address only the content side of the decision. They do nothing about a stylesheet returning 200 OK while serving your homepage HTML with the wrong Content-Type, a rewritten page still sitting in version control, or a stale cache that makes a fixed page look unchanged to a crawler. They do not create the ads.txt line you can only write once you have a real publisher ID, they do not produce the organic search presence that makes a brand new site an easier case, and they do not shorten a review that Google says can take 2 to 4 weeks.

Questions about AdSense approval

What does "low value content" actually mean in an AdSense rejection?

It is more concrete than a judgement about quality and can be measured before you submit: prose words per page excluding navigation, footer and anything your tool generates, plus how similar your pages are to each other. A page that is mostly generated output with a caption on top has almost nothing on it a person could not get from the tool itself.

How many words should each page have to pass AdSense review?

A rough target that has worked is 1,000 words or more of genuine prose per content page, with cross-page similarity in the single digits. That is not a published threshold and nobody at Google will confirm a number, it is simply well clear of the range where a site gets flagged.

Is a calculator or tool on its own enough content for approval?

Usually not. Add real explanatory content around the tool: how it works, why it matters, and questions answered with actual specifics rather than generic filler.

How do I know if my pages count as duplicates?

Run a text similarity check across any family of similar pages. Anything above roughly 80 percent similar is a duplicate wearing different headings, and it counts against you rather than adding to your page count.

Should I resubmit to AdSense after making a small change?

No. Each review cycle takes days and a small change does not move a site flagged on a structural problem, so fix every content page, verify it on the live site rather than in your repository, and resubmit once.

Why did my site look broken to the reviewer when every status check passed?

Many hosting platforms serve your homepage HTML in place of a file that was never deployed, so the request still returns 200 OK. Check the response header instead: a .css file coming back as text/html rather than text/css was never deployed.