The Google Play publishing checklist for a website-based app

Step 1 - Developer account

• Register at play.google.com/console. US$25, one-time, non-refundable.
• Choose personal or organisation. Organisation needs a D-U-N-S number and a verifiable website/email at your domain; personal needs government ID. Organisation accounts skip the mandatory closed-test period.
• Complete identity verification before you do anything else; it can take days, and nothing publishes until it clears.
• Personal accounts created after November 2023: plan for a closed test with 12 testers opted in for 14 continuous days before production access can be requested.

Details and decision help: developer account guide.

Step 2 - Make the app more than a browser

Do this before building, because it decides your review outcome. Google's minimum functionality policy refuses apps that only display a website. In the builder, enable:

• Push notifications (OneSignal App ID) - the clearest app-only capability.
• Offline screen - reviewers switch the network off.
• Native navigation: menu, pull to refresh, exit confirmation.
• About screen with real contact details.

And on the website side: it must be responsive at 360 px, fully HTTPS, and every link the app can reach must work. A 404 anywhere is "broken functionality". The policy guide goes into what reviewers actually test.

Step 3 - Build and sign the AAB

• Package name: reverse-domain, yours, permanent. Not editable after upload.
• Output: every build gives you the APK for your own testing and the AAB Play requires, both free. New apps cannot be uploaded as APKs.
• Target API level: the builder tracks Google's requirement (Android 15 / API 35 for 2025; raised yearly). Play refuses bundles below it.
• Signing: the builder signs with a key derived from your package name. On first upload, enrol in Play App Signing (default); your key becomes the upload key and Google signs what users download. Note the SHA-256 of both keys from Console → App signing for later.
• Install the APK on a real device and use it for ten minutes before uploading anything.

Background: APK vs AAB, signing, target API levels.

Step 4 - Create the app in Play Console

• Create app: name, default language, App (not Game, unless it is one), Free or Paid - free cannot be changed to paid later.
• Declarations: developer program policies, US export laws. Read the Families policy question carefully - answering that the app could appeal to children triggers a much stricter regime.
• Set up your app → the dashboard lists every task below with a status. Work top to bottom.

Step 5 - Store listing assets and text

Preview the whole thing before saving with the listing preview. Optimisation without policy risk: listing guide.

Step 6 - Privacy policy

• A live URL on your domain, linked in the listing and reachable from inside the app (the builder's About screen does this).
• Must name the developer, describe what the app and website collect (analytics, push tokens, account data, ad identifiers), why, who receives it (Google, OneSignal, your host), and how users can request deletion.
• Must be consistent with the Data safety answers. Reviewers compare them.

Structure and wording: privacy policy guide.

Step 7 - App content forms

• Data safety: declare everything your site and integrations collect. A website with Google Analytics collects "App activity"; OneSignal collects a device identifier; a login form collects personal info. "No data collected" for a site with analytics is a rejection and, worse, a later enforcement. Form-by-form answers.
• Ads: yes if your website shows ads or you enabled AdMob.
• Content rating: IARC questionnaire. Answer for the content on your site, including user comments if any. Walkthrough.
• Target audience and content: choose 18+ / adult age groups unless the site is genuinely for children; selecting children invokes the Families policy.
• News apps: if your app is primarily news, Google's News policy requires transparency about ownership and sourcing.
• Financial features, health, government apps: declare if applicable.
• App access: if any part needs a login, provide working test credentials here. Reviewers who can't get past a login reject the app.

Step 8 - Testing tracks

• Internal testing (up to 100 testers, live within minutes, no review): upload here first and install from Play to confirm the bundle installs and opens.
• Closed testing: required for personal accounts - 12 testers opted in, 14 continuous days. Recruit more than 12; people drop out. Use a Google Group to manage them.
• During the test: aeroplane mode → offline screen appears; back gesture → exit confirmation; rotate; tap every menu item; receive a test push.
• Pre-launch report: Google runs the app on real devices and reports crashes, accessibility and security warnings. Read it; fix anything red.
• Apply for production access (personal accounts) after the 14 days and answer the short questionnaire about your testing.

Details: closed testing guide.

Step 9 - Review: what gets checked

• Minimum functionality - is this more than a website?
• Broken functionality - every link, form and media element.
• Metadata - do title, description and screenshots describe this app truthfully, without ranking or comparative claims?
• Impersonation - does the developer match the brand? Publishing someone else's website is a fast ban.
• Payments - digital goods sold without Play Billing?
• Data safety vs reality - do the declared collections match what the app does?
• Permissions - the builder requests only what enabled features need; don't add any.
• Ads - AdMob placed where it can be tapped accidentally; AdMob stacked on top of website ads.

Review takes from hours to about a week; new accounts skew longer. Each of these, with fixes, is in the rejection reasons guide.

Step 10 - Launch and after

• Release to production with a staged rollout (e.g. 20%) if you have existing users; 100% for a first launch.
• Add the Play badge and link to your website; generate a store QR code for print.
• Content updates ship via your website with no release. Release a new AAB only for icon/colour/setting changes and for the yearly target-API requirement - set a calendar reminder for August, when Google's deadline usually falls.
• Reply to reviews; watch the Android vitals page for ANRs and crashes, which for a WebView app almost always trace back to the website.
• Keep your privacy policy URL alive forever. A dead policy link removes the app.