Google AdMob Approval Guide: Requirements, Process, and Avoiding Rejections

AdMob approves most apps within 2-3 days if the submission is clean. The most common rejection reasons, in order: invalid traffic signals, ad placement violations, missing or broken privacy policy, inappropriate content, and app-ads.txt misconfiguration (mandatory since January 2025). New accounts also face a 30-day ad-serving limit while Google validates traffic quality. Run the free AdMob Approval Checker before submitting to catch the fixable issues first.

Store listing requirements

Your app needs to be live and publicly available in the Google Play Store or Apple App Store before you submit to AdMob. Apps that are still in review or unpublished as drafts are not eligible. Google's reviewers need to access the actual published listing.

Beyond live status, your store listing needs to be complete. That means an accurate description, representative screenshots, a correct content rating, and the right category. These details matter because AdMob reviewers compare the store listing to the app's actual content during review. An app listed as a productivity utility that contains gameplay, or a tools app with an "everyone" content rating that contains mature material, will flag during review.

Content rating accuracy is the most commonly underestimated listing requirement. The rating you select needs to reflect the full scope of your app's content, including any user-generated content features. Mismatched ratings are a consistent rejection trigger.

One change that went into effect in January 2025: app-ads.txt validation now runs as part of the store listing review process for new submissions. If your developer domain does not have a valid app-ads.txt file, the submission is flagged at this stage. The app-ads.txt setup is covered in the next section, but the key point here is that the two checks are linked. A clean store listing with a broken app-ads.txt will still fail.

Before you submit, walk through your listing and confirm: the app is publicly accessible, the description matches what the app actually does, the content rating is accurate for all content in the app (including in-app purchases and user-generated features if present), and the developer domain associated with your account has a valid app-ads.txt file.

If you want to audit your app's configuration before submitting, the free AdMob Approval Checker runs these checks for you.

App-ads.txt setup

App-ads.txt is the IAB Tech Lab standard that authorizes specific ad tech sellers to sell your app's inventory. Google made it mandatory for new AdMob submissions in January 2025. Missing or invalid app-ads.txt is now one of the top five rejection reasons for new app submissions.

The file lives on your developer domain, which is the domain associated with your Google Play or App Store developer account. It does not live on the app itself. If your developer domain is yourstudio.com, the file needs to be accessible at https://yourstudio.com/app-ads.txt. If you do not own a domain associated with your developer account, this is a setup requirement you need to address before submitting.

The minimum required entry for AdMob monetization is this exact line:

google.com, pub-XXXXXXXXXXXXXXXX, DIRECT, f08c47fec0942fa0

Each field in that line has a specific meaning:

google.com is the ad system domain. It is always google.com for AdMob and Google Ad Manager.
pub-XXXXXXXXXXXXXXXX is your AdMob publisher ID. Find it in your AdMob account under Account settings, labeled "Publisher ID." Replace the placeholder with your actual ID.
DIRECT is the relationship type. Use DIRECT here because AdMob is your direct monetization partner, not a reseller of your inventory.
f08c47fec0942fa0 is Google's official certification authority ID. This value is fixed and should not be changed.

If you use mediation networks alongside AdMob, those networks need their own authorized seller lines in the same file. Each mediation partner publishes their own required app-ads.txt entries in their documentation. For context on why each mediation partner needs their own line, see the mediation adapters guide. The minimum Google line above covers AdMob only.

The most common app-ads.txt mistakes are: the file placed on the wrong domain (the app's marketing site instead of the developer domain), the publisher ID containing a typo or using a test ID, RESELLER instead of DIRECT, the file served behind authentication, and the domain on file in AdMob not matching the actual domain where the file is hosted.

The AdMob Approval Checker fetches your developer domain's app-ads.txt, validates the syntax, checks the publisher ID format, and confirms the required seller entries are present. Run it before submitting.

Privacy policy requirements

AdMob requires a publicly accessible privacy policy URL to be submitted with your app. This is not optional and a placeholder or "coming soon" page will not pass review.

The policy URL must be live at review time. It cannot be password-protected, behind a login, or returning an HTTP error. Reviewers access the URL directly, so test it in an incognito browser before submitting.

The content of the policy matters as much as its existence. The most common rejection pattern in this category is a vague generic template that does not mention advertising data. For an AdMob-monetized app, your privacy policy needs to cover four things at minimum:

What personal data the app collects. This includes device identifiers, IP address, and location data if your app requests it.
Use of advertising SDKs. The policy should state that the app uses third-party advertising SDKs and that those SDKs may collect and use data for interest-based advertising.
User opt-out. How users can opt out of interest-based advertising. For EU users, this means GDPR consent. For US users, CCPA disclosure and opt-out rights.
Contact information for privacy inquiries.

If your app targets children under 13, or is rated "everyone" which includes children, you must disclose child-directed data practices in the policy and configure the app as child-directed in AdMob settings. This is the primary COPPA compliance trigger. Running standard interest-based advertising to an app in a children's content category is a direct policy violation.

The privacy policy URL you submit to AdMob must match the URL in your app store listing. A mismatch between the two is a common source of manual review flags that slows down the review cycle.

Before submitting, validate that the policy URL loads in an incognito browser, that it contains advertising-specific language, and that the URL matches your store listing submission exactly.

Account verification

AdMob account verification is a separate process from app approval and runs on a different timeline. Understanding the two tracks prevents confusion about why ads are not serving or why payments are not releasing after an app is approved.

For new AdMob accounts, there are two verification steps:

Identity and payment verification is Google's process for confirming your identity and setting up your payment profile. You submit identification documents through your AdMob account. Review time for this step is typically 24 hours but can take up to 2 weeks depending on your country and the current document review queue. Verification does not block ad serving during the initial period, but it does block payment release.

PIN verification is a secondary step that happens after your account reaches the first payment threshold ($10 in most countries for new accounts). Google mails a PIN to your registered payment address, and you must enter it in your account settings to release payments. This step only applies once earnings accumulate, but it is worth knowing in advance so it does not come as a surprise.

The most common account verification errors:

Address on AdMob does not match the address on the payment instrument
Name does not match the government ID submitted exactly
Selecting the wrong account type (individual vs. business). This selection is permanent. You cannot change it without creating a new account, which means starting the approval process for your apps over from scratch.
Business name does not match registered business documentation

Start account verification as soon as you create your AdMob account, before you submit your first app. The identity review can take up to 2 weeks and runs in parallel with the app review, so there is no reason to wait.

Ad placement policies

Ad placement violations are the second most common cause of AdMob rejections and the most common cause of post-approval ad serving suspensions. Getting approved with bad placements and then being suspended later is worse than getting it right before submission.

The core placement rules:

No ads near interactive elements. Ads placed within close proximity of buttons, navigation elements, or other tappable UI cause accidental clicks. Google's policy describes this as "close to interactive content." The practical threshold reviewers use is roughly 150 pixels, but the real test is whether a user trying to interact with the app's UI would be likely to tap the ad instead. Review each placement with that test in mind.

Ads must be fully visible at display time. Do not overlay other content on top of an ad unit after it loads. Do not position ads partially off-screen. The ad must be fully visible and unobstructed when it is served.

No custom refresh logic. Banner refresh rates must use AdMob's SDK settings. Implementing your own JavaScript or native refresh logic outside the AdMob SDK is a violation, even if the cadence matches AdMob's recommended rate.

Interstitials require natural transition points. Interstitials cannot fire during loading screens, at app launch, or during active gameplay in a way that interrupts the core mechanic. AdMob's interstitial policy requires that the ad appears at a natural break in user flow. Between game levels is acceptable. During a loading spinner is not.

Rewarded video must be user-initiated. The user must choose to watch a rewarded ad. Do not block progression in a way that leaves watching an ad as the only option. The rewarded format requires a genuine opt-in. Blocking the app's primary function without an alternative is a policy violation.

No incentivized ad clicks. Offering users in-game currency, items, or any other reward for clicking on (not watching) ads is a direct policy violation. Incentivizing views for rewarded video is the approved pattern. Incentivizing clicks on any ad format is not.

The most reliable self-check method is to screen-record your app's full user flow with ads loaded. Watch the recording specifically looking at: how close ad placements are to buttons, whether anything obscures ads after they load, what triggers each interstitial, and whether any in-app reward prompt could be interpreted as incentivizing a click.

If you want to check your AdMob account configuration, the free AdMob Approval Checker covers the account-side setup. Ad placement review requires this manual inspection of your app's UX.

Content policies

AdMob has a list of content categories that are ineligible for monetization, and a separate list of restricted categories that require specific configuration. Technical setup quality does not override content policy. A perfectly configured AdMob account with a prohibited-category app will be rejected.

Categories that are ineligible for AdMob:

Adult content and sexually explicit material
Content that facilitates illegal activity (cheat tools, piracy applications, hacking utilities)
Hate speech or content targeting protected groups
Gratuitous violence or gore (incidental violence in a game is treated differently than content where violence is the primary subject)
Counterfeit goods or trademark infringement apps
Gambling content without a valid license and Google's prior written approval

Restricted categories (eligible with proper setup):

Alcohol-related content requires age-gating and geographic content restrictions
Healthcare and pharmaceutical content is subject to restricted ad categories in ad delivery
Financial services apps require disclosure language
Dating apps are eligible but restricted ad categories apply to what ads can be shown
Children's content is eligible but requires child-directed treatment in AdMob settings and full COPPA compliance, including disabling personalized advertising for child-directed apps

One common mistake: assuming that passing App Store or Google Play review means AdMob will also approve the content. App store review and AdMob content policy are separate processes. An app can pass app store review and still be ineligible for AdMob if its content falls into a restricted or prohibited AdMob category.

Before submitting, check AdMob's content policies documentation at support.google.com/admob/answer/10448709 against your specific app category. If your app has content in any restricted category, configure the relevant AdMob content settings before submitting. Submitting without the correct configuration is a common cause of rejections that look like content violations but are actually missing-configuration issues.

Common rejection reasons

These are the rejection reasons developers encounter most frequently, in order of how often they appear.

1. Invalid traffic or click fraud

This is the most common rejection reason. Google's systems flag unusual click or request patterns before or during the approval review. The most common cause for new apps is using live ad unit IDs during development or testing. If you tested your app with production ad units rather than AdMob's test ad unit IDs, the resulting click patterns can look fraudulent to Google's detection systems.

Developer community testing is another common trigger. If you shared a build containing live ad units in a Slack, Discord, or Reddit community for feedback, and those testers tapped on ads, the click pattern will register as suspicious.

Self-check and fix: Confirm you used only AdMob's official test ad unit IDs for all non-production builds. Check your AdMob dashboard for any unusual click-through rate spikes in the 30 days before submission. Do not share builds with live ad units for community testing.

2. Ad placement violations

The second most common reason. Close proximity to interactive elements, interstitials firing at the wrong moment, or rewarded video that is not genuinely opt-in. See the #ad-placement-policies section above.

Self-check and fix: Screen-record your full user flow with ads loaded and review each placement manually against the rules in the placement section.

3. Privacy policy issues

Missing policy URL, broken link, policy does not cover advertising data, or the URL does not match the app store listing. COPPA non-compliance for children's apps falls into this category.

Self-check and fix: Load the privacy policy URL in an incognito browser. Confirm the policy covers advertising data collection and SDK usage. Confirm the URL matches the store listing exactly. If your app is rated for children or targets children, confirm child-directed treatment is enabled in AdMob settings.

4. Inappropriate content

The app's content falls into a prohibited category, or a restricted category was not configured correctly in AdMob settings.

Self-check and fix: Review AdMob's content policies page for your category. Configure restricted category settings in AdMob before resubmitting.

5. App-ads.txt misconfiguration

Since January 2025, this is a standard rejection trigger. The most common issue is the file being hosted on the wrong domain, followed by an incorrect publisher ID or RESELLER instead of DIRECT.

Self-check and fix: See the #app-ads-txt-setup section. The AdMob Approval Checker validates your app-ads.txt against all known common errors.

6. Content quality or minimum standards

Apps with very thin functionality, where the app is clearly built primarily to display ads rather than serve a user need, are rejected for not meeting AdMob's content quality standards. This is a judgment call in review, but the pattern is consistent.

Self-check and fix: Ensure your app has meaningful user-facing functionality that stands on its own without advertising. If the core user experience is thin, address it before resubmitting.

7. Insufficient user base

Less frequent but real. Very new apps with near-zero installs submitted within 24-48 hours of going live can be flagged when the ad request volume does not match the install count. AdMob does not publish a minimum install threshold, but the pattern is documented in community reports.

Self-check and fix: Allow the app to accumulate organic installs for at least a week before submitting. This is not an official requirement but aligns with observed approval patterns.

8. Account-level issues

Prior policy violations, payment verification holds, or a history of invalid traffic on other apps in the same account can cause a new app submission to fail even when the app itself is clean. Account-level flags carry across submissions.

Self-check and fix: Review your AdMob account status before submitting a new app. Resolve any existing policy holds or verification issues first. The AdMob Approval Checker covers account configuration checks.

Timeline and process

Most clean AdMob submissions are reviewed within 2-3 days. Apps in restricted content categories, or submissions that require additional manual review, can take up to 7 days. There is no way to expedite the review.

New account identity verification runs on a parallel track. If you submit your first app before completing identity verification, the app review may complete before verification does. Your ads will not serve until both are done. Identity review typically takes 24 hours but can take up to 2 weeks depending on your country and the current review queue.

Here is the realistic sequence for a new account and first app submission:

Day 0: Create AdMob account, submit identity verification documents, submit app for review
Day 1-3: App review completes for a clean submission
Day 1-14: Account identity verification completes (this timeline varies)
Day 3 (if approved and verified): Ads begin serving, but under a 30-day ad serving limit
Day 30: Ad serving limit lifts for accounts with clean traffic patterns
Day 60-90: Revenue approaches steady-state as Google's demand systems calibrate to your app's traffic profile

The 30-day ad serving limit is the part most developers do not expect. After approval, Google applies a limited ad serving restriction to new publishers for approximately the first 30 days. This means a reduced percentage of ad requests are filled during that window. The restriction is automatic and lifts once Google's systems have validated your traffic quality. It is not a penalty and it is not specific to your app. Every new AdMob publisher goes through this window. Revenue during this period will be materially lower than your eventual steady state. Plan accordingly.

Rejection and resubmission: After a rejection notice, fix the issues cited in the notice, then resubmit through AdMob's app management interface. Each resubmission goes through a full review cycle. Plan for another 2-3 days per round. Google does not provide expedited review for resubmissions or appeals.

After approval: eCPMs in the first 30-60 days will likely be below the benchmarks you see in forums and case studies. Google's demand systems and the AXON-based bidding infrastructure need time to learn your app's traffic profile. The 30-day serving limit and the calibration period often overlap. The steady-state revenue picture becomes visible between day 60 and day 90.

If you want to run through the full checklist before submitting, the AdMob Approval Checker covers the configuration-side requirements so you go into review with the fixable issues already resolved.

Once you are approved and past the 30-day window, the next question most developers face is whether AdMob alone is the right setup or whether adding a second network through mediation makes sense. The decision framework for that is in AdMob vs AppLovin MAX. If you are evaluating mediation platforms more broadly, AppLovin MAX vs Unity LevelPlay covers that decision.

If you are past the checker and the rejection persists after addressing all the items above, the free 30-minute call is the right next step. Persistent rejections usually have a root cause that is not visible in the rejection notice itself, often in account-level history or traffic patterns from pre-launch testing. Book a call here.

Frequently asked questions

How long does AdMob approval take?

Most clean submissions are reviewed within 2-3 days. Apps in restricted content categories, or submissions where identity verification is pending, can take up to 2 weeks total. The 30-day ad serving limit for new publishers begins after approval is granted, not during the review period.

Is app-ads.txt required for AdMob?

Yes, since January 2025. New app submissions without a valid app-ads.txt file on the developer domain are flagged during the approval process. The minimum required entry is the Google DIRECT line with your AdMob publisher ID. If you use mediation networks, those networks need their own authorized seller lines in the same file.

Why did AdMob reject my app for invalid traffic?

The most common cause for new apps is using live ad unit IDs during development or community testing. If any build containing production ad units was shared externally before submission, the resulting click patterns can be flagged by Google's invalid traffic systems. Use AdMob's official test ad unit IDs for all non-production builds. Avoid sharing builds with live ad units for community feedback.

What content is not allowed on AdMob?

Prohibited categories include adult content, content that facilitates illegal activity, hate speech, gratuitous violence, counterfeit goods, and gambling without Google's prior approval. Restricted categories (alcohol, healthcare, dating, children's content) are eligible but require specific configuration in AdMob settings. Passing app store review does not guarantee AdMob content eligibility. The two review processes are independent.

What is the 30-day ad serving limit on new AdMob accounts?

After first approval, Google applies a limited ad serving restriction to new publisher accounts for approximately 30 days. Fewer ad requests are filled during this window while Google validates traffic quality. The restriction lifts automatically. It is not a penalty and applies to every new AdMob publisher. Revenue during this period will be lower than steady-state benchmarks. Plan your revenue projections around the 60-90 day window, not the approval date.

Can I resubmit after an AdMob rejection?

Yes. Fix the issues cited in the rejection notice, then resubmit through AdMob's app management interface. Each resubmission goes through a new 2-3 day review cycle. Google does not expedite re-reviews or appeals. If the rejection reason persists after addressing the cited issues, the root cause is often in account-level flags or traffic patterns not disclosed in the rejection message. That is the situation where a second set of eyes on the setup is worth it.