Rejection emails from Google Play name a policy, sometimes attach a screenshot, and rarely explain. This guide decodes the eight that account for nearly every website-app rejection we hear about, in rough order of frequency. Each has the wording to look for, the likely finding, and the fix.
1. Minimum functionality
Wording: "…does not provide the minimum functionality…", "…little to no functionality beyond a WebView…". Finding: the reviewer opened the app and saw a website with nothing added. Fix: enable push, the offline screen, native navigation and the About screen in the builder; describe those features in the listing; add a review note explaining the app's purpose and that you own the site. Full treatment in the policy guide.
2. Broken functionality
Wording: "…app crashes / doesn't load / features don't work…", often with a screenshot of an error page or a blank screen. Finding: a dead link, a page that 404s, a video that won't play, a form that errors, or — very often — the WebView's own error page in aeroplane mode. Fix: click every link in the app yourself; fix or remove dead pages on the site; enable the offline screen; if the start URL requires login, provide credentials (see #8). If the screenshot shows a specific page, that page is the problem.
3. Metadata policy
Wording: "…title/description/screenshots violate the Metadata policy…". Finding: one of: "free", "best", "#1" or emoji in the title; a keyword list or repeated words in the description; a competitor's name; a testimonial; screenshots showing a browser bar or content not in the app; a feature graphic with a "Download now" call to action. Fix: rewrite with the listing text tool's rules; recapture screenshots from the installed app; remove claims. Metadata fixes don't need a new bundle — edit the listing and resubmit.
4. Impersonation / intellectual property
Wording: "…impersonates another entity…", "…uses another party's intellectual property…". Finding: the developer name doesn't match the website's brand; a well-known brand name or logo appears in the icon or title; or the app wraps a site the reviewer believes you don't own. Fix: make the developer name, listing contact email (at your domain) and website consistent; remove third-party logos; in review notes, point to the site's About or contact page showing the same entity. If you are an agency publishing for a client, publish from the client's account or provide a signed authorisation in the notes.
5. User Data — Data safety mismatch
Wording: "…Data safety section is inaccurate…", "…app collects data not disclosed…". Finding: Google observed analytics, advertising or identifier traffic that the form said didn't exist; or the privacy policy contradicts the form. Fix: complete the form per the Data safety guide — Google Analytics, OneSignal, AdSense/AdMob, forms, accounts — and align the privacy policy. Form changes publish without a new bundle.
6. Missing or inadequate privacy policy
Wording: "…privacy policy link is missing/invalid…", "…does not comprehensively disclose…". Finding: the URL field is empty, 404s, redirects to the homepage, or the policy doesn't mention the app or the data the app handles. Fix: host a real policy at a stable URL, link it in the listing and confirm the builder's About screen shows it; structure from the privacy policy guide.
7. Payments
Wording: "…must use Google Play's billing system…". Finding: the reviewer found a digital product or subscription sold through your web checkout inside the app. Fix: hide digital goods from the app, or restructure per the payments guide. Physical goods are not the issue; if you only sell physical goods and got this, the reviewer likely mis-classified something — reply through the appeal with the product page and the delivery method.
8. App access / login required
Wording: "…unable to access all parts of the app…", "…login credentials required…". Finding: the app or the site behind it opened on a login screen and no test account was provided. Fix: in App content → App access, choose "All or some functionality is restricted" and supply a working username/password (and any 2FA workaround). Keep the account alive; reviewers re-check on later updates.
Less common but worth knowing
- Ads policy — AdMob banner overlapping content or placed where navigation taps land; AdMob stacked on top of website ads. Fix placement or pick one network.
- Permissions — the app requests SMS, call log or "query all packages" without justification. The builder's template requests none of these; if you see it, you modified the manifest or used another tool.
- Deceptive behaviour — a "download" that does nothing, fake system dialogs, or a listing that promises features absent from the app.
- Families — you selected a child audience without meeting the stricter requirements. Change the target audience if the app isn't for children.
- Target API level — the upload was refused, not rejected in review. Rebuild.
Resubmit or appeal?
Resubmit when the finding is right and you have fixed it: new version code if the app changed, edited listing if only metadata, and a clear review note stating what changed. Appeal (via the policy status page) only when you believe the reviewer was mistaken — for example a physical-goods shop flagged for payments — and attach evidence. Appeals take longer than resubmissions and a weak appeal delays you further.
Writing the review note
Two or three sentences, factual: what the app is, that you own the site (link to About), what app-specific features it has, test credentials if any, and what you changed since the last review. Reviewers read notes; they don't read your email to support.