Google Play Metadata Policy Rejection: How to Fix Your Store Listing and Resubmit

What Google Play's Metadata policy actually says

Google Play's Metadata policy covers everything people see before they install: title, developer name, icon, short and full description, screenshots, feature graphic and preview video. Google doesn't allow "misleading, improperly formatted, non-descriptive, irrelevant, excessive, or inappropriate metadata" in any of them, and it explicitly bans "unattributed or anonymous user testimonials" in the description. The stricter title, icon and developer name rules were first announced on the Android Developers Blog in April 2021 and are now part of the policy text.

Title, icon and developer name have the strictest rules: no emojis, emoticons or repeated special characters, no ALL CAPS unless it's part of your brand name, and no text or images that indicate store performance or ranking, price or promotional information, or a link to a Google Play program. The whole listing also has to be suitable for a general audience, whatever your app's content rating.

Specs come from Google's preview assets help page and the store listing setup page, so recheck them there before you export. Two related policies are often cited alongside it: Impersonation (suggesting a relationship with another company or app) and Deceptive Behavior (advertising features the app doesn't have, see our deceptive behavior guide).

The triggers that actually get listings rejected

Promotional and ranking words in the title

"#1 Budget Planner – Free" breaks the rules twice. Google's store listing best practices say "Free" and "No Ads" promote deals and don't belong in titles or developer names. "Best", "Top" and "Popular" signal ranking, "New" suggests a Google Play program, and "Black Friday Sale" is promotional information.

Keyword stuffing inside 30 characters

"VPN Proxy Fast Secure Unlimited" isn't a name, it's a string of search terms. Google warns that repetitive or irrelevant keywords in the app name or description can even lead to suspension. A title that passes reads like a name: brand plus one plain descriptor, such as "Ledgerly: Budget Planner".

Formatting tricks

Emojis, emoticons and kaomojis, rows of stars, repeated punctuation ("!!!", "»»»") and ALL CAPS words used for emphasis. Capitals are only acceptable when the brand itself is written that way.

Misleading icons

The policy gives two examples: a new-message dot when there are no new messages, and download or install symbols on an app that has nothing to do with downloading. Google's icon specifications also rule out graphics that indicate ranking, promote deals or suggest a Play program, so laurel wreaths, "Editor's Choice"-style ribbons, "-50%" corners and a "FREE" banner are out too.

Screenshots and feature graphics that oversell

Award badges, "Million Downloads" banners, five-star rows, mockups of features that aren't in the build and charts against a named competitor. Google's preview asset guidelines also advise against other stores' badges and device frames, which often come from reused iOS assets.

Testimonials and word blocks in the description

"Best app ever! – Sarah" with no verifiable source is an unattributed testimonial. Lists of search terms, city names, competitor names ("alternative to …") and "Tags:" footers are word blocks and irrelevant keywords.

Content that isn't suitable for a general audience

Sexually suggestive imagery, profanity, graphic violence or depictions of illicit drug use in the icon, screenshots, video or text. This applies even if the app itself is rated for adults.

Impersonation signals

Another company's brand in your title ("Downloader for Instagram"), a lookalike logo, "Official" without the rights, or a developer name that suggests a link to Google or a well-known brand.

Rejected or stuck? Talk to an App Specialist – for free.

Book a free consultation call: we look at your rejection or setup, explain the fastest way forward and tell you honestly whether you need us. Prefer to hand it off? Book our AI-powered + human-powered service and we take care of it.

Free consultation call Book our service →

How to fix a Metadata policy rejection step by step

1. Read the issue details on the app's Policy status page (left menu in Play Console), in your Play Console inbox and in the email. Note which assets and languages are named. Google says its notices may not list every violation, so treat the named items as examples.
2. List every listing surface. Under Grow users > Store presence, check the main store listing in the default language and every translation (Main store listing), all custom store listings and any running experiment (Store listings, with Listings and Experiments tabs). Menu labels change occasionally. The store listing is shared across tracks, so testing tracks show the same content.
3. Rewrite the title in the App name field. Keep it to 30 characters or fewer: brand plus one descriptor. Remove promo words, ranking words, emojis, decorative symbols and caps used for emphasis. Before: "BEST Photo Editor – FREE Filters!!!". After: "Lumora: Photo Editor".
4. Check the developer name. It is set for the whole developer account, so a change appears on all your apps. Use your company or brand name, with no keywords and nothing that suggests a relationship you don't have.
5. Re-export the icon as a full-square 512 x 512 px 32-bit PNG in sRGB. Google's icon design specifications say not to round the corners or add drop shadows yourself, because Play does that. Remove all badges, dots, ribbons, discount tags and text.
6. Rebuild screenshots and the feature graphic from the current build, as JPEG or 24-bit PNG without alpha. Keep captions short and descriptive, and drop awards, star ratings, download counts, prices, calls to action and store badges.
7. Clean up the descriptions. The short description says what the app does. In the full description, delete keyword lists, competitor names and anonymous reviews. Describe pricing in a factual sentence there, never in the title or icon.
8. Stop affected experiments whose variants still contain the flagged content.
9. Send the changes for review. Open Publishing overview, check Changes not yet sent for review and click Send for review. After a rejected update, changes are not sent automatically. Unrelated pending changes can be kept out of this review with Save for later. If managed publishing is on, publish once the changes are approved.
10. Upload a build only if Google asks. If Policy status also names an app bundle, upload a compliant bundle with a new version code and deactivate the non-compliant one on every track where it's active.

Resubmit, reply or appeal: choosing the right response

According to Google's enforcement process, a rejection doesn't affect your developer account's standing, and if an update is rejected, the version that was already published stays live. But repeated rejections or removals can lead to a suspension, and suspensions count as strikes against your account. Google also asks you not to resubmit until every violation is fixed, so don't rush a half-fix through.

When to simply fix and resubmit

In most metadata cases the finding is right, even if it seems petty. Google Play has no review chat like the one in App Store Connect, so your corrected listing, sent for review, is your answer.

When an appeal makes sense

• Your brand name really is written in capitals or includes a word or symbol the reviewer read as a claim, and you can show it's your brand, ideally with a trademark registration.
• The flagged quote is attributed to a named, verifiable source and the reviewer missed it.
• You were flagged for impersonation but you own the brand or hold a license. Attach proof, and consider Google's advance notice form before future releases that use third-party brands.

Use the appeal link in the email or on the Policy status page. Google's policy review help page allows one appeal per enforcement action, and appeal replies are only given in Chinese, English, Japanese and Korean. So make it count: say what was flagged, why it complies and what evidence you attach. If you've already removed the flagged content, resubmit instead.

Store listing experiments, translations and custom listings

Repeat rejections usually come from a listing surface the developer forgot.

Store listing experiments

Store listing experiments let you test the icon, feature graphic and screenshots, and in localized experiments the descriptions too. The app title isn't one of the testable assets. Variants are submitted for review through Publishing overview like other listing changes and are shown to real users, so each one has to meet the Metadata policy. A "Free" corner on a test icon is still a "Free" icon. Check a winning variant again before you apply it.

Translations

Google states that the Metadata policy applies to all translations of your store listing, and every localized title has the same 30-character limit. Translators and machine translation can introduce local promo words ("Gratis", "Kostenlos", "Mejor") or emojis. Review every language and remove translations you no longer maintain.

Custom store listings

You can have up to 50 custom store listings, targeted by country, pre-registration, search keywords, inactive users, a unique URL or a Google Ads campaign. They are metadata too. Listings built for paid user acquisition can easily pick up "limited offer" or discount wording.

Edge cases: brands, reused iOS assets and sales events

ALL CAPS brands and symbols

If your brand is officially written in capitals or uses a symbol, keep it exactly as you use it everywhere else, with proof ready. "ACME Notes" is defensible, "ACME NOTES PRO" is not.

Reused App Store assets

iOS screenshot sets often carry an "Available on the App Store" badge, an iPhone frame or an award laurel. Google's preview asset guidelines say to avoid other stores' badges and device imagery, and award or ranking claims break the Metadata policy itself. Recreate the set from an Android build. If you ship on both stores, see our guides to Apple's Guideline 2.3 and Guideline 2.3.3 screenshots.

Sales, launches and "New" versions

Price and promotional information doesn't belong in the icon or title, even for a weekend sale. Put update news in the release notes ("What's new"). For time-limited events, Play Console's promotional content tool is available for all games and for apps that meet Google's eligibility criteria.

How to prevent Metadata policy rejections in your pipeline

Metadata problems are easy to catch automatically once your listing lives in version control.

• Keep metadata as code. With fastlane supply, titles and descriptions live in fastlane/metadata/android/<locale>/title.txt, short_description.txt and full_description.txt, and graphics in images/. Every change goes through a pull request.
• Lint text in CI. Fail the build if a title is over 30 characters or a short description is over 80. Also fail it on emoji code points, repeated punctuation, words in all caps that aren't on your brand allowlist, and a list of risky words in every locale ("free", "no ads", "best", "top", "#1", "new", "sale", "% off", "download now").
• Check image specs automatically: icon size, format and file size, feature graphic dimensions, screenshot side lengths and aspect ratio, and no alpha channel in screenshots or the feature graphic.
• Add AI-assisted visual review. OCR and vision models flag text, badges, star rows and notification dots in images that text linting can't see. A human still judges context, such as whether a symbol is part of a trademark.
• Review experiments and translations like releases, with the same checklist for every variant and locale.

If you'd rather hand this off, appsubmitter.io combines AI-powered listing checks with human review as part of CI/CD setup and store submission. You can talk through a current rejection in a free consultation call or book the Google Play service.

Template: how to reply to the Google Play review team

Adapt this template to your situation. Keep it factual, short and specific – and only claim what you have actually changed.

Hello Google Play team,

We are appealing the rejection of the store listing for [App name] ([package name]) under the Metadata policy, notified on [date].

Flagged element: [e.g. app title "[title]" in [language] / app icon / screenshot [number]]

Why we believe it complies:
- [e.g. "[BRAND]" is our brand name and is always written in capitals (trademark registration no. [number], [office]). It is not used for emphasis or to make a promotional claim.]
- [e.g. The quote in our full description is attributed to [publication], [date], [URL].]
- [e.g. We are the rights holder / licensee of [brand]. Proof attached: [document].]

We have also checked all translations, custom store listings and experiments against the Metadata policy: [short summary].

Attachments: [trademark certificate / license / screenshot of the current listing]

Thank you for reviewing our appeal.

[Your name]
[Company], developer account "[developer account name]"
[Contact email]

Checklist before you resubmit

• Every app title in every language is 30 characters or fewer: brand plus one descriptor.
• No title, developer name or icon contains "Free", "No Ads", "#1", "Best", "Top", "Popular", "New", "Sale", discounts or award wording.
• No emojis, repeated punctuation or ALL CAPS words (except your brand name) in title, developer name or short description.
• The icon is a full-square 512 x 512 px 32-bit PNG under 1024 KB, without badges, notification dots, download arrows, ribbons or text.
• Screenshots and feature graphic are JPEG or 24-bit PNG without alpha and show real UI from the current build, with no store badges, star ratings, download counts, prices or testimonials.
• The full description has no keyword blocks, competitor comparisons or unattributed reviews, and other brands appear only if you hold the rights.
• Icon, screenshots, video and text are suitable for a general audience, regardless of the app's content rating.
• All translations, custom store listings and running store listing experiment variants have been checked against the same rules.
• Changes were sent for review on Publishing overview (and published afterwards if managed publishing is on).
• If Policy status also names an app bundle, a compliant build with a new version code is uploaded and the non-compliant bundle is deactivated on every track.

Frequently asked questions

Official source: Play Console Help – Metadata policy. Store policies change regularly – always check the current version. This guide is independent advice and not affiliated with Apple or Google.