Publishing a WordPress or WooCommerce site on Google Play
WordPress sites make good Play apps — they change often, they have readers who come back, and WooCommerce checkout works inside a WebView. The things that trip publishers up are policy, not technology: what you sell, what your plugins collect, and whether the app does anything a browser can't.
Payments: the question WooCommerce owners must answer first
Google Play's payments policy requires Play Billing for digital goods and services consumed within the app, and permits your own checkout for physical goods and services consumed outside the app. For a WooCommerce store that means:
| You sell | Inside a Play-listed app |
|---|---|
| Physical products shipped to the customer | WooCommerce checkout is allowed as is — cards, PayPal, Stripe, whatever you use. |
| Services delivered in person (classes, bookings, repairs) | Your checkout is allowed. |
| Digital downloads, e-books, courses consumed in the app, memberships to app content | Play Billing required. A WebView app cannot use WooCommerce checkout for these. Either integrate Play Billing natively (not something a wrapper does), remove those products from the app, or don't list on Play. |
| Donations to a registered charity | Exempt; own checkout allowed. |
| Mixed catalogue | Physical via WooCommerce; digital items must be hidden or purchased through Play Billing. |
Reviewers look at your product catalogue. A store selling PDFs through Stripe inside a Play app is rejected under "Payments", and repeated violations affect the account. The payments guide covers subscriptions, memberships and the grey areas.
Data safety: what WordPress plugins collect on your behalf
The Data safety form must reflect what the website inside the app collects, and WordPress sites collect more than their owners realise:
- Jetpack / Site Kit / Google Analytics / MonsterInsights → App activity (page views), device identifiers.
- WooCommerce → Name, email, address, phone, purchase history; payment info handled by the gateway (declare "financial info" collected, processed by a third party).
- Comments → Name, email, IP address.
- Contact forms (WPForms, Contact Form 7) → Name, email, message contents.
- OneSignal push (if enabled) → Device identifier.
- AdSense on the pages → Advertising identifiers, collected by Google.
Each maps to a Data safety category with a purpose and a "shared with third parties" answer. Declaring "no data collected" for a site running Jetpack is the fastest route to a rejection followed by an enforcement notice.
Clearing minimum functionality
A WordPress blog wrapped with no additions is the archetype of what the minimum-functionality policy refuses. In the builder, enable:
- Push notifications via OneSignal — and set up OneSignal's WordPress plugin or RSS automation so each new post sends one. This is the strongest app-only capability a publication can offer.
- Offline screen — reviewers test in aeroplane mode.
- Native menu and pull-to-refresh — link the menu to your main categories.
- About screen with real contact details and the privacy policy link.
Ads: AdSense on the page vs AdMob in the app
If your WordPress site runs AdSense, those ads display inside the app because the app renders the live pages. Do not also enable AdMob banners in the builder on those screens: Google prohibits stacking two ad networks on the same content, and AdSense's own policy restricts display inside apps you don't explicitly allow. Two clean options: keep AdSense on the pages and leave AdMob off; or hide AdSense units when the user agent is your app (the builder adds an identifiable string) and run AdMob in the app shell. Declare "contains ads" in the console either way.
WordPress-specific behaviour inside a WebView
- wp-admin: exclude it from the app's navigation; set external links to open in the browser so an editor tapping "Edit" leaves the app.
- Login state is separate from the phone's browser; users sign in once in the app.
- Cookie consent plugins appear on first launch, as they must. Ensure the banner is dismissible on a 360 px screen.
- Downloads (PDFs, media): enable downloads in the builder so they go to the system download manager.
- Performance: page builders that load megabytes of scripts feel slow in an app because there is no browser tab to hide behind. Cache plugins help; a 3 MB hero image does not.
WordPress.com plans
Everything above applies to any plan, including Free — the app displays whatever is at your URL. Free-plan sites carry WordPress.com's own ads, which count as "contains ads" and are a third ad network you can't control; note that in your declarations.
Screenshots
Take them from the installed app: a post, a category, the menu open, a notification arriving. No browser bar. The screenshot tool exports at Play's ratios.
Frequently asked questions
Can I sell WooCommerce products in a Play app?
Physical products and in-person services, yes, through your normal WooCommerce checkout. Digital goods consumed in the app must use Play Billing, which a WebView wrapper does not provide — hide those products from the app or don't list on Play.
Do I need a separate privacy policy for the app?
One policy can cover site and app if it names both and describes push and analytics. It must be reachable from the listing and from inside the app; the builder's About screen links it.
Will WordPress.com's ads cause a problem?
They count as advertising you must declare. Because you cannot control their placement, avoid adding AdMob on top; keep the app to the page ads only.
How do new posts trigger notifications?
Enable OneSignal in the builder, then use OneSignal's WordPress plugin (self-hosted) or its RSS-to-push automation (any plan) to send on publish.