How to Get AdMob Approval for a New App

Searching for how to get AdMob approval for a new app can create the wrong expectation. AdMob does not have one permanent approval switch that guarantees full ad serving or earnings. A new publisher may face account verification, store linking, app-ads.txt app verification, app readiness review, policy checks, consent requirements, and ongoing invalid-traffic review.

Google allows publishers to add an unpublished app and prepare an integration, but unpublished or unsupported-store-only apps receive limited serving and cannot complete the normal readiness path. New apps must be linked to a supported store and reviewed before they can fully serve ads.

This guide explains the July 2026 process in the right order, including the distinction between verifying your authority to monetize and reviewing whether the app is ready. No step guarantees approval, a review time, fill, or revenue.

Understand What “AdMob Approval” Actually Includes

Several statuses are often compressed into the word approval. Treating them separately makes troubleshooting more accurate.

Google's app readiness documentation says a new app must be reviewed and approved before it can fully serve ads. It must be listed in a supported store, correctly set up in AdMob, and linked to that store.

Google's separate app verification guide explains that new apps use app-ads.txt to establish that the publisher is authorized to monetize. Once verification succeeds, the app readiness review begins. These steps are related but not interchangeable.

An app can therefore be technically integrated while serving is limited. It can also pass readiness and later face limits if content, implementation, consent, or traffic quality changes.

Prepare the App and Publisher Account

Review starts with a stable app and an account your business controls.

Complete account requirements honestly

Create the AdMob account using accurate publisher and payment information. Google may require account verification before apps can move beyond a getting-ready state. Enter legal and payment details exactly as requested, and restrict administrative access to trusted team members.

Do not create replacement accounts to avoid a prior restriction or accelerate review. Follow the account notice and appeal path if Google identifies a problem. Multiple accounts or inconsistent identity information can create additional enforcement risk.

Enable strong authentication and keep recovery methods current. A compromised monetization account can change payment details, app settings, and authorized users.

Make the app reviewable

The release should open reliably and provide meaningful user value. Review login, navigation, primary content, privacy policy, ad disclosures, and error handling. If important content requires an account, provide any review access requested through the relevant platform process.

Avoid copied, thin, deceptive, or prohibited content. A website-based app should do more than trap users in a broken page surrounded by ads. The WebView must handle navigation, offline states, permissions, and essential flows safely.

Prepare a public privacy policy that describes advertising and relevant data handling. In Google Play, declare that the app contains ads and keep Data safety responses aligned with the Google Mobile Ads SDK and any mediation SDKs shipped.

If your app is still being built, follow the AdMob integration guide with demo IDs. Production serving status is not required to test layouts and lifecycle behavior safely.

Publish and Link a Supported Store Listing

Store linking identifies the public app Google should review.

Publish before requesting full serving

AdMob lets you add an app as unpublished to create an App ID and ad units. This is useful for integration and testing. However, Google states in its app setup guide that an app must be listed in a supported store and linked in AdMob to be reviewed and approved for full serving.

If the app is exclusively in an unsupported store, it cannot complete the normal review and will receive limited serving. Google currently notes a different app-ads.txt verification treatment for apps listed only in third-party stores, but that exception does not make the app eligible for full readiness approval.

For Android publishers, Google Play is the clearest supported route. Complete production publishing with the Google Play upload guide, then confirm the listing is publicly available for download.

Link the exact app

In AdMob, open the app settings and link the store listing. The package name is case-sensitive and must match the released app. Use the same app identity rather than creating duplicate AdMob records for test and production releases.

Google says a newly published listing may take 24 to 48 hours to appear for linking and sometimes up to one week. That is a discovery delay, not a promised readiness-review duration. If search does not find the listing immediately, verify the public store URL and wait for store indexing rather than linking a similarly named app.

The developer website shown in the store listing is especially important. AdMob uses that domain to locate app-ads.txt in the next step.

Set Up and Verify app-ads.txt

App-ads.txt is an IAB standard that lets app publishers publicly declare which seller accounts are authorized to sell their inventory.

Publish the file on the listed developer domain

Add a valid developer website to the app's Google Play or Apple App Store listing. Host a plain-text file named app-ads.txt at the root of that website, such as:

https://example.com/app-ads.txt

Copy the personalized AdMob line from your account rather than guessing the publisher ID or relationship fields. If mediation partners require entries, add their exact authorized-seller records according to their documentation.

Google's app-ads.txt setup guide says the crawler follows the developer website from the store listing. The file must be formatted correctly and accessible. Google's crawl troubleshooting guide recommends an HTTP 200 response, crawl access through robots.txt, and availability through both HTTP and HTTPS paths or valid redirects.

Do not put the file under /ads/, in a private dashboard, or on a domain unrelated to the store listing. Opening the URL yourself is a useful check, but it does not prove AdMob has crawled and matched it.

Request verification in AdMob

AdMob routinely crawls the file, and Google says status updates can take up to 24 hours after a correct setup. Recent developer-website changes in a store may take longer to propagate.

Once AdMob finds the file, return to the app's verification page and use Verify app or Check for updates as shown in the current interface. New apps created from January 2025 are required to complete app-ads.txt verification, and unverified apps face limited serving.

Common failure causes include:

• no developer website in the store listing
• app-ads.txt hosted on the wrong domain or path
• incorrect publisher ID or seller line
• a 404 or other non-success response
• robots.txt blocking the crawler
• store metadata that has not propagated
• linking the wrong package name or store ID

App-ads.txt verification confirms authorization. It does not evaluate ad placement or traffic. Successful verification leads into readiness review.

Pass the App Readiness Review

After the app is verified and correctly linked, AdMob reviews whether it is ready for full ad serving.

Monitor the real status

The All apps and App settings pages show statuses and actionable feedback. “Requires review,” “Getting ready,” “Needs attention,” and “Ready” represent different states. Read the status details rather than repeatedly changing IDs or creating another app record.

If the account itself is not verified, the app can remain in Getting ready. If the store listing is not linked, it may require review but cannot proceed normally. If app verification failed, correct app-ads.txt or identity details. If policy issues are reported, fix the app or placement and follow the review workflow presented in AdMob.

Google publishes typical durations for some account checks, but exceptional cases take longer. Do not state a guaranteed approval time. Release planning should assume that full serving may not be available on launch day.

Make every placement policy-safe

Review AdMob policies before submitting. Keep banners away from app controls and WebView links. Do not place interstitials before content, at every navigation, during login or checkout, or where users can mistake them for system messages.

Rewarded ads must be optional and disclose the benefit before the user chooses to watch. Native ads need required attribution and AdChoices elements. App open ads need careful foreground and loading behavior.

Essential navigation must work when there is no fill, slow network, consent denial, or ad-load failure. A user should never need to click an ad to close a screen or continue a core task.

Passing readiness does not authorize every future placement. Review policy again whenever the app adds a format, mediation source, audience category, or substantial content area.

Implement Consent and Safe Testing

An app can be store-linked and still be unready for responsible production serving.

Use test ads during development

Google's test ads guide provides demo units for each format. Android emulators are automatically treated as test devices for Google ads, while physical devices need demo units or test-device registration when using your own IDs.

Confirm the Test Ad label before interacting. Separate debug and release configuration so live IDs cannot appear in developer builds. Never click your own live ads, ask another person to click them, or use a production rollout as a test harness.

Test no fill, slow network, rotation, app backgrounding, dismissal, repeated navigation, and process recreation. The product must continue if an ad is unavailable.

Request consent before eligible ads

Use Google's User Messaging Platform and the current Android privacy guide. Request an updated consent status at app launch, show a required form, and check canRequestAds() before requesting ads. Provide a privacy-options entry when the SDK indicates that users need one.

Consent requirements depend on region, audience, app configuration, and applicable law. UMP assists with Google's configured message flow, but it does not replace the publisher's privacy policy or legal obligations.

Mediation adds more SDKs and partners to disclose. Keep consent configuration, privacy policy, app-ads.txt, and Play Data safety answers synchronized with the build users actually receive.

Protect Approval With Valid Traffic

Readiness is not the end of review. Google continues to assess app behavior and traffic.

Prevent invalid activity

Google's invalid traffic guidance states that publishers are responsible for traffic to their ads. Never click live ads, encourage supportive clicks, buy unexplained traffic, or position ads where accidental taps are likely.

Monitor click-through rate, requests, impressions, geography, traffic source, app version, and ad unit. A sudden earnings or click spike is a reason to investigate, not celebrate automatically. Pause the affected placement or acquisition campaign while checking layout and traffic.

Do not obscure ads, auto-click, manipulate WebViews, refresh outside allowed behavior, or show ads to bots and background processes. Estimated earnings can be adjusted when activity is determined invalid.

A realistic new-app example

Arun publishes a free habit-tracking Android app. Before release, he creates an unpublished AdMob record, integrates Google's demo rewarded unit, and tests an optional reward that unlocks one additional theme preview. No production ad is required for app testing.

After the Play listing is public, Arun links the exact package in AdMob. His Play developer website points to his own domain, where /app-ads.txt returns the personalized AdMob line with HTTP 200. He waits for store metadata and crawler updates, then requests app verification.

Once authorization is verified, the readiness review begins. Arun monitors the status rather than creating duplicate records. He has already declared ads, published a privacy policy, implemented UMP, and excluded onboarding, settings, and account deletion from ad triggers.

The app reaches Ready status, but Arun does not call that a revenue guarantee. He stages production IDs to a small release group, watches traffic quality and user behavior, and keeps test IDs in debug builds. If review had returned a policy issue, he would have corrected the named problem and resubmitted through the provided workflow.

Conclusion: Treat AdMob Approval as a Readiness Process

To get AdMob approval for a new app, prepare a useful and policy-compliant release, complete account requirements, publish in a supported store, link the exact listing, and verify monetization authorization through app-ads.txt. App readiness review begins after the required verification and linking conditions are met.

Then maintain safe placements, consent, test-ad discipline, accurate disclosures, and valid traffic. Use the AdMob integration guide for implementation and the Play publishing guide for store release. Approval is conditional and ongoing, and neither full serving nor earnings are guaranteed.

FAQ

Can AdMob approve an unpublished app?

You can add an unpublished app, create IDs, and test with demo ads. However, Google says an app must be listed in and linked to a supported store to complete app readiness review for full serving. Unpublished apps receive limited serving.

Is app-ads.txt required for a new AdMob app?

Yes for new apps covered by Google's current verification requirement. Host the personalized seller line at the root of the developer website listed in the store, let AdMob crawl it, then request app verification. Apps that remain unverified face limited serving.

How long does AdMob approval take?

There is no duration you should treat as guaranteed. Store discovery, app-ads.txt crawling, account checks, and app readiness are separate processes. Follow the status details in AdMob and allow additional time when store or website metadata recently changed.

Why is my AdMob app still getting ready?

Possible causes include incomplete account verification, missing or incorrect store linking, failed app-ads.txt verification, review still in progress, or policy feedback. Open the app's status details and fix the stated condition instead of creating another app record.

Can AdMob limit ads after an app becomes Ready?

Yes. Ready status is not permanent immunity from review. Policy violations, invalid traffic, consent failures, deceptive placements, or major app changes can affect serving later.