AdSense approval

AdSense Approval Tips: 14 Things That Tip a Borderline Review

14 numbered tips for a site that could go either way, each marked as Google's statement or our view, plus a table of 10 checks you can run in 10 minutes each.

A notebook with handwritten plans next to a laptop and a coffee
Photo: https://kaboompics.com/ on Pexels

What tips a borderline review can be mundane: a script in the wrong place, a robots.txt line left over from staging, a homepage that never says what the site is. Google’s pages on refusals and self-review name several of these causes, and the others appear when you read your own site the way a stranger would.

We ranked the 14 tips by damage: a site that cannot be reached cannot be judged at all, while an unconvincing About page only weakens the case. We cannot rank them by how often each causes a refusal, because Google does not publish that. Each tip is labelled Google says or Our view. They assume you have worked through the basic checklist in the requirements guide, and where a tip repeats a point from it, the tip adds the way to test it.

1 to 4: fix what blocks the review first

  1. Put the ad code in the head of the site you applied with, then read the live page. Google says. Missing or incomplete code is the first reason on Google’s list, and its fix is to confirm the snippet sits in the <head> of the right site, or to verify ownership through Search Console. Check the page the server actually sends rather than your template, because in our experience a caching layer can keep serving an older copy.
  2. Take down password protection and maintenance pages. Google says. The help page tells you to remove password protection temporarily, and the policy on valuable inventory excludes pages under construction. If staging and production share a template, make sure no maintenance flag travelled with it.
  3. Serve a valid certificate and redirect http to https. Google says. Both are on the access checklist. Test the plain http:// address too: we recommend a single permanent redirect to the https page rather than a chain, and a certificate with weeks left rather than days. The HTTPS guide has the server snippets.
  4. Let the AdSense crawler through robots.txt. Google says. The help page states that robots.txt must not block the AdSense crawler, which identifies as Mediapartners-Google. A Disallow: / copied from staging is a common cause in our experience, and the robots.txt tester shows the verdict for that crawler next to Googlebot. The traps are collected in our robots.txt guide.

5 to 9: fix what the review reads

  1. Read your homepage as an examiner would. Our view, built on Google’s self-review advice, which names 3 areas: unique content, navigation people can use, and an experience that makes them want to read. Open the homepage in a private window on a phone. Within a few seconds a stranger should know what the site is for, who writes it and where to start reading. Rewrite the page until that is true: it is usually the address you registered with Google.
  2. Remove everything that says “coming soon”. Google says. Google’s policy names pages under construction and screens with no content or low-value content as places it will not serve ads. Empty category and tag archives and lorem ipsum belong to the same family in our reading. Finish them or delete them, and remove the links to what you delete.
  3. Merge thin pages instead of deleting them. Our view. Imagine 2 pages of 200 words that answer the same question. Fold the useful parts into the stronger URL, send the other to it with a 301 (Google treats that as a strong signal) and update your internal links so nothing points at a redirect. Plain deletion turns every inbound link into a 404. Our guide on low value content shows how to find the candidates.
  4. Check real indexing in Search Console. Our view. Google sets no number of indexed pages, so we use the check to catch accidents. Inspect the homepage, 2 articles and the privacy page, then compare the count in the page indexing report with the number of URLs in your sitemap. A large gap points at a noindex, a robots.txt rule, or pages Google chose to skip.
  5. Link every page from another page. Google says. Google follows <a href> links and says every important page should receive at least 1 link from another page. A page that appears only in the sitemap, or one reachable only through a menu built by JavaScript on click, is an orphan. Descriptive anchors beat “read more”, and the internal linking guide gives a method.

10 to 14: show who is behind the site

  1. Publish the pages that show a person, and let them be indexed. Google states the privacy part; the rest is our view. Privacy policy with the advertising wording, contact, about, terms, all in the footer and none of them noindex. What each page must say has a weak and a strong About page side by side.
  2. Check your niche against the content policies before you write. Google says. The categories include enabling dishonest behavior, which covers promoting hacking and giving instructions or software for unauthorized access to devices, servers or sites, plus misleading claims and harmful health claims. Context and intent count, so a defensive security tutorial is not the target by itself. If you write on security, health or finance, read AdSense and sensitive niches.
  3. Use only images and embeds you have the right to use. Google says. The self-review advice excludes stolen or protected content, and the policies cover intellectual property infringement. Keep a note of the source and licence of every photograph. Our own are credited on the credits page.
  4. Review every AI-assisted draft, and say that you use AI. Google says. Auto-generated content with no review or curation is listed among the problems, and Google’s helpful content guidance asks for transparency about how content is produced, AI included. Our view on the review itself: it must add something only you have, such as a measurement, an example or a correction. More in E-E-A-T for small publishers.
  5. Keep publishing at your normal pace, and do not redesign, while you wait. Our view. Google says the process usually takes a few days and in some cases 2 to 4 weeks, so a review can overlap with whatever you change. A redesign or a migration in the middle risks showing an unfinished site. What to do during the wait covers the rest.

Before you apply: 10 checks of 10 minutes

Run them on the live site, in this order. None takes more than 10 minutes. Replace example.com with your domain; the commands are below the table.

#CheckWherePassing looks like
1Ad code is liveCommand 1Your publisher ID prints, and it matches your account
2http redirects to httpsCommand 21 permanent redirect to the https address, then a 200
3Certificate is validCommand 3The notAfter date is well in the future
4robots.txt lets the crawlers inCommand 4, then the robots.txt testerNo Disallow: /, and the AdSense crawler is allowed
5No stray noindexCommands 5 and 6No output, or a tag that says index
6Indexing matches the sitemapSearch Console, page indexing reportHomepage and key pages indexed, the count close to your sitemap
7Homepage reads well to a strangerPrivate window on a phonePurpose, author and starting point clear in seconds
8No dead endsClick every menu, footer and category linkNo 404, no “coming soon”, no empty archive
9The 4 trust pages openFooter linksPrivacy, contact, about and terms each return a 200
10A second opinionThe AdSense eligibility checkerRed items fixed first, then the manual checklist at the end read line by line
# 1. ad code
curl -s https://example.com/ | grep -o 'adsbygoogle.js?client=ca-pub-[0-9]*'
# 2. http to https
curl -sIL http://example.com/ | grep -iE '^(HTTP|location)'
# 3. certificate dates
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates
# 4. robots.txt
curl -s https://example.com/robots.txt
# 5. stray noindex, in the headers
curl -sI https://example.com/ | grep -i x-robots-tag
# 6. stray noindex, in the HTML
curl -s https://example.com/ | grep -io '<meta[^>]*robots[^>]*>'

Sources

Who stands behind this

GreenlightMySite is run by Stéphane Cardon, a network and cybersecurity engineer. We write from running real sites through real reviews, and every technical claim here is either linked to a primary source or measured with our own tools.

About · Editorial policy · LinkedIn