Google Play Store Listing Review Checklist: Pass First Time

Google Play reviews two things that live under the name "store listing": the text and images shoppers see, and the six declarations on the App content page that are attached to that listing. Most first-submission rejections do not come from a screenshot being the wrong shape. They come from one of those declarations being missing, stale, or inconsistent with what the app actually does. This checklist walks through every element Google checks at review, the rejection each wrong element produces, and the exact Play Console page where you fix it, so your first submission clears review instead of sitting in a rejection loop.

What Google actually checks about your listing

Google's own framing of the review scope is one sentence long: "The App content page is where you provide and manage the information we need to ensure that your app is safe for its intended users, is compliant with Google Play Developer Program Policies, and satisfies legal requirements" (Prepare your app for review, read 2026-10-17). In practice that means two review surfaces:

• The listing itself — app name, icon, developer name, short and full description, screenshots and promotional images — checked against the Metadata policy and, where identity or purpose is misrepresented, the Misrepresentation policy.
• The declarations tied to the listing — privacy policy, Data safety form, content rating, ads declaration, sign-in details, and target audience — each with its own policy and its own rejection message.

Listing element	Checked under	What a failure looks like
App name, icon, developer name	Metadata policy	Rejection naming the title or icon
Short and full description	Metadata policy, Misrepresentation policy	Rejection citing keyword repetition or a description that does not match the app
Screenshots and promo images	Metadata policy, intellectual property rules	Rejection for imagery that does not reflect the app, or artwork you cannot prove you own
Privacy policy URL	User Data policy	Rejection for a missing, dead, or inapplicable policy
Data safety form	User Data policy, Data safety requirements	Rejection for a declaration that does not match app or SDK behaviour
Content rating questionnaire	Content ratings policy	Unrated status, or removal for misrepresented content
Ads declaration	Ads policy	Wrong "Contains ads" label; misrepresentation can suspend the app
Sign-in details	App review access	Reviewer cannot open the app; functionality or access rejection
Target audience	Families policy	Additional obligations, or rejection for a children-facing app that does not meet them

App name, icon, and developer name under the Metadata policy

The Metadata policy is the short, checkable list. Google's wording: "We don't allow apps with misleading, improperly formatted, non-descriptive, irrelevant, excessive, or inappropriate metadata, including but not limited to the app's description, developer name, title, icon, screenshots, and promotional images." The concrete rules for the three most visible fields:

• Title limit: "Your app title must be 30 characters or less."
• No decorative characters: no emojis, emoticons, or repeated special characters in the title, icon, or developer name; avoid ALL CAPS unless it is part of your brand name.
• No misleading symbols: Google explicitly names a fake "new message" dot on an icon, and download or install symbols on apps unrelated to downloading content.
• No store-performance, price, or program claims: nothing in the title, icon, or developer name that indicates ranking or awards ("App of the Year", "#1"), price or promotions ("10% off"), or suggests a Google Play program ("Editor's Choice", "New").
• No anonymous testimonials: unattributed or anonymous user testimonials in the description are not allowed, and neither are word blocks, keyword lists, or one app or brand being compared against another.

There is also a pattern that is not spelled out in the policy text but shows up constantly in the Google Play Developer Community: rejections where "your current app submission's title and description are identical", flagged as a Metadata policy issue. That phrasing appears in community-posted rejection notices from 2025 onward (for example, the KeyTrak thread on Google Play Developer Community, August 2025). This is community-reported enforcement behaviour rather than documented policy, but the practical fix is simple: make the title a name and the description a description. If your app name is "KeyTrak Automotive", do not open the full description with the same phrase word for word.

Description accuracy, keyword stuffing, and the Misrepresentation policy

Two separate policies reach your description. The Metadata policy asks that it be "clear and well-written", succinct, and free of "repetitive or unrelated keywords or references". Play Console Help is blunter about the consequence: "Repetitive or irrelevant use of keywords in the app name, description, or promotional description can create an unpleasant user experience and result in an app being suspended on Google Play" (Create and set up your app, read 2026-10-17). That is a post-publication risk, not just a submission risk: an app that is already live can be suspended for a keyword-stuffed description.

The Misrepresentation policy asks a different question: does the listing honestly represent what the app is? It prohibits apps that "impersonate any person or organization, or that misrepresent or conceal their ownership or primary purpose". Two listing consequences follow. First, the description must describe the app's real functionality — a launcher that is really a wallpaper app, or a "free VPN" that quietly routes traffic through a paid tier, fails here regardless of how the metadata rules are satisfied. Second, screenshots and promotional images must reflect the app's actual experience; the Key Considerations on the policy page put it as "Provide screenshots and videos that reflect your app's actual experience", paired with "Don't use a celebrity's name or a brand's logo without permission".

Privacy policy URL: the requirement most often missed

Google's condition for the listing link is specific: for apps that request access to sensitive permissions or data, "You must link to a privacy policy on your app's store listing page and within your app. Make sure your privacy policy is available on an active URL, applies to your app, and specifically covers user privacy." For apps that target children, the same requirement applies regardless of whether the app touches sensitive data. Three failure modes account for most privacy policy rejections:

• Dead or redirecting URL. A policy hosted on a personal site that 404s, or behind a login, does not satisfy "an active URL". Reviewers and Google's crawlers both have to be able to open it.
• Listing-only policy. The User Data policy requires a valid privacy policy "in both the app's store listing and within the app itself". A settings screen or an "About" page linking the same URL is enough, but a policy that exists only on the Play page is not.
• Generic boilerplate. A policy "applies to your app" — a template that names a different product, or that promises no data collection while the app has an analytics SDK, is the kind of mismatch Google treats as a User Data policy issue.

The User Data policy also separates the policy from in-app consent: data collection disclosures "cannot only be placed in a privacy policy or terms of service", and apps must not "request device permissions before users have provided their consent". In other words, the policy URL on the listing is necessary and not sufficient — the in-app disclosure flow has to match it.

Data safety form: required even when you collect nothing

The Data safety form is the most misunderstood declaration on the App content page, and the one that most often sits directly behind a first-submission rejection. Google's requirements, in order of how badly they are missed:

• Everyone completes it. "All developers that have an app published on Google Play must complete the Data safety form, including apps on closed, open, or production testing tracks." A closed test does not exempt you, and apps that collect no user data still "must complete this form and provide a link to their privacy policy".
• Third-party code counts. "This includes data collected and handled through any third-party libraries or SDKs used in their apps." An ad SDK that reads the advertising ID, a crash reporter that uploads device details, or a Firebase configuration that enables analytics all create declarations you owe.
• Accuracy is on you, and enforcement is the consequence. "When Google becomes aware of a discrepancy between your app behavior and your declaration, we may take appropriate action, including enforcement action." Google also states plainly that its "review process is not designed to verify the accuracy and completeness of your data safety declarations" — you cannot hide behind the review, and you cannot assume a wrong declaration was checked and approved.
• It must match the privacy policy. The User Data policy requires the Data safety section to be consistent with the disclosures in your privacy policy, kept up to date as behaviour changes.

Based on our own review of more than 1,500 closed-testing campaigns, the three listing-side problems that come up most often are an undeclared ad or analytics SDK in the Data safety form, a privacy policy URL that resolves to a dead page, and sign-in details that do not let a reviewer past the login screen. These are observations from campaigns we have handled, not Google-published statistics.

Content rating questionnaire and the "Unrated" risk

Content ratings come from independent rating authorities (IARC and the regional bodies Google works with) and are assigned from your questionnaire answers. Google's requirement: fill out the rating questionnaire for every new app, and again on "all app updates where there has been a change to your content or features that would affect the responses to the questionnaire". Two consequences are easy to underestimate. First, an app without a rating is visible to nobody: "'Unrated' apps may be removed from Google Play" — the wording used in Google's own review-preparation page. Second, the answers have to be true: "Misrepresentation of your app's content may result in its removal or suspension", per the content rating requirements page.

One ordering detail matters in the Console itself. Before you can complete the "Target audience and content" section, Google requires that you have already declared whether the app contains ads, provided sign-in instructions for reviewers, and added a privacy policy. A developer who tries to do the content rating first will find the flow blocked until those three are done. Declaring a children-facing target audience pulls in the Families policy, including its advertising rules, so answer the age question honestly rather than defensively.

Ads declaration and the "Contains ads" label

You must declare whether the app contains ads, including ads delivered through third-party SDKs, native ads, and house ads promoting your own apps. A correct "yes" puts a "Contains ads" label on the public listing. Google monitors this: "While you're responsible for accurately declaring ad presence in your apps, Google may verify this at any time and display the 'Contains ads' label if appropriate." And the failure mode is severe: "If you misrepresent the presence of ads in your app(s), it's considered a violation of the Google Play policies and may result in your app(s) being suspended."

The narrow exception worth knowing: a simple "More apps" menu that links your other apps, does not interfere with gameplay, and is not embedded in the core experience does not count as ads for the label. A banner, interstitial, native ad, ad wall, or a "More apps" screen that interrupts the experience does.

Sign-in details so a reviewer can open the app

If any part of the app sits behind a login, membership, location check, or other authentication, Google requires you to "provide all required details to enable access to your app" through the Sign-in details section of the App content page. You can store up to five sets of instructions, and Google asks you to use the free-text field for anything unusual: one-time codes, multi-factor flows, or logins with more than two fields.

This is a quiet failure point because the rejection message does not always say "reviewer could not log in". The fix is mechanical: save working test credentials, disable or bypass forced MFA for the test path where policy allows, and describe the flow in the instructions. Automated checks run before a human reviewer ever sees the app, so a build that crashes on launch also gets caught early — our walkthrough of the Pre-Launch Report explains where to read those results before you submit.

When review fails: rejection, enforcement, and how to resubmit

Two different processes can stop a listing, and telling them apart saves days.

Situation	What it means	Documented route out
Submission rejected ("App status: Rejected", with an "Issue found" line)	The app or a declaration does not comply; nothing is published. For updates, the previous version stays live.	Fix the named issue, save, then submit again — no support ticket required.
App removed or suspended after publication	An enforcement action under the Developer Program Policies.	Follow the instructions in the enforcement email, or use Google's appeal troubleshooter (Managing policy violations and appeals, read 2026-10-17).
Production access application refused	A separate process with its own questionnaire and criteria.	See our analysis of production access failure patterns.

For a plain rejection, Google's documented resubmission flow for declaration fixes is deliberately simple: update the affected section on the App content page, open Publishing overview, find your change under "Changes ready to send for review", and select Send for review. Google states that "you can complete these steps without contacting or waiting for a reply from the policy support team" — so do not open a ticket and wait when the Console gives you a direct path.

A worked example, drawn as a composite from cases in our own campaign records with identifying details removed: an app is rejected with an issue found in the Data safety area. The developer had shipped an ad SDK in a later build and never reopened the form. The fix took four steps: open App content, then Data safety, then Manage; set data collection to Yes and declare device or other identifiers with the advertising purpose; confirm the privacy policy URL still resolves and covers ad personalisation; save, then Send for review from Publishing overview. The point is not the specific case — it is that the rejection email names an area, and each area maps to exactly one page in the Console.

How often rejections clear on appeal is a separate question with published data behind it: our Google Play rejection rate analysis for 2026 works through the numbers Google itself prints in its transparency report. Account-level enforcement — a terminated developer account — is a different and heavier process, covered in our guide to appealing a terminated Play developer account. If you are still at the stage of shipping your first app, our first-app roadmap puts this checklist in order with everything else you owe the Console.

Pre-submission self-audit

Run this list before you press the submit button, and the odds of a first-pass review improve substantially — this is our recommendation from campaigns we have handled, not a Google-published checklist:

1. App name is 30 characters or less, with no emoji, no ALL CAPS, and no award, price, or "new" claims.
2. Title and full description share no long identical phrase, and the description contains no keyword blocks.
3. Description matches what the app actually does on first launch.
4. Screenshots come from the current build and show real screens, with no third-party logos or celebrity imagery you cannot document rights for.
5. Privacy policy URL loads without login, applies to this app, and the same URL is reachable from inside the app.
6. Data safety form is completed, including SDK-collected data, and consistent with the privacy policy.
7. Content rating questionnaire is complete, and its answers still match the app's current content.
8. Ads declaration matches reality; the "Contains ads" label expectation is deliberate either way.
9. Sign-in details exist for every gated area, with working test credentials and notes on OTP or MFA.
10. Target audience is declared, and if children are included, Families policy obligations are actually met.
11. Any high-risk permission has a completed permissions declaration form on the same App content page.
12. Pre-Launch Report has been read for crashes and device compatibility failures before submission.

Frequently Asked Questions

Can Google reject my app because of the store listing alone?

Yes. Listing text and images are governed by the Metadata policy, and Google rejects submissions for metadata that is misleading, excessive, or inappropriate — including title, icon, screenshots, and promotional images. Rejections for an identical title and description, emoji in the title, or award and price claims in the icon have all been reported by developers in Google's own community forums. Separately, an incorrect declaration attached to the listing (Data safety, content rating, ads) produces its own rejection.

Is the Data safety form required if my app collects no data and I am only running a closed test?

Yes. Google requires every developer with an app published on Play to complete the Data safety form, explicitly including apps on closed, open, and production testing tracks. Apps that collect nothing still complete the form and provide a privacy policy link, declaring that no user data is collected or shared. Remember that SDKs inside the app can create real collection obligations even when your own code does not.

Do I need a privacy policy even if my app has no login and collects nothing?

For children-targeting apps, yes — a privacy policy is required on the listing and in the app regardless of data access. For other apps, the Data safety form requires a policy link in every case, so in practice every Play listing needs one. An active URL that applies to your app is the standard Google applies; a dead link or boilerplate for a different product fails.

My rejection says "Issue found" under the Metadata policy. What do I change?

Read which field the rejection names and fix that field: the title, the description, or the graphic assets. Common corrections are shortening the title to 30 characters, removing emoji or repeated special characters, cutting keyword repetition, and replacing screenshots that do not match the current build. When the issue is that the title and description are near-identical, rewrite the description so it explains the app rather than repeating its name.

How do I resubmit after fixing a listing or declaration issue?

Save your fix on the relevant App content or Main store listing page, open Publishing overview, find the change under "Changes ready to send for review", and select Send for review. Google documents this flow for rejected updates and removals and states that you can do it without contacting or waiting for a reply from the policy support team. Reserve the appeal route for enforcement actions, following the instructions in the enforcement email.

Can a wrong content rating answer get my app removed?

Google states that misrepresentation of an app's content in the rating questionnaire "may result in its removal or suspension", and that unrated apps may be removed from Google Play. Answering accurately, and re-running the questionnaire whenever content or features change in a way that affects the answers, keeps the rating defensible.

Sources

• Prepare your app for review — Play Console Help (privacy policy, ads, sign-in details, target audience, content ratings; read 2026-10-17)
• Metadata policy — Play Console Help, Developer Program Policies (read 2026-10-17)
• Misrepresentation policy — Play Console Help, Developer Program Policies (read 2026-10-17)
• User Data policy — Play Console Help, Developer Program Policies (read 2026-10-17)
• Provide information for Google Play's Data safety section — Play Console Help (read 2026-10-17)
• Content rating requirements for apps, games, and the ads served on both — Play Console Help (read 2026-10-17)
• Create and set up your app — Play Console Help (store listing fields, keyword-stuffing suspension warning; read 2026-10-17)
• Managing policy violations and appeals — Play Console Help (read 2026-10-17)
• Google Play Developer Program Policies — Policy Center (read 2026-10-17)
• Metadata policy: identical title and description — Google Play Developer Community thread, August 2025 (community-reported rejection notice)