Google Play WebView & Affiliate Spam Policy: How to Fix a Website-Wrapper Rejection

What the Webviews and Affiliate Spam policy actually says

The clause is part of Google Play's Spam policy, next to Message Spam and Repetitive Content. Google doesn't allow apps whose "primary purpose is to drive affiliate traffic to a website or provide a webview of a website without permission" from the site's owner or administrator.

That sentence contains two separate tests:

• The permission test. Does the account that publishes the app own the website, or hold the owner's permission? Google's own example is an app called "Ted's Shopping Deals" that simply shows Google Shopping in a WebView.
• The primary purpose test. Is the app's main job to send users to a website so someone gets credit for sign-ups or purchases? Google lists these referral traffic apps as a common violation.

Two related rules often show up in the same review. Repetitive Content, in the same Spam policy, targets copied content and many near-identical apps. Limited Functionality and Content, part of the Functionality, Content, and User Experience policy, catches apps that are "static without app-specific functionalities". Many developers still call this "Minimum Functionality", its older name. A wrapper of your own site can pass the permission test and still fail here.

How this differs from Apple's Guideline 4.2

Apple's Guideline 4.2 is a quality judgment: does the app offer more than a repackaged website? Google's spam clause starts with rights and intent. Proof that you own the site can help with a Google spam rejection, but it doesn't address a 4.2 rejection at all. Google also has no back-and-forth with the reviewer like App Store Connect messages, and Google says repeated app rejections or removals can lead to a suspension, which counts as a strike against your account.

Common reasons WebView apps get flagged as spam

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 prove you own the website (or have permission)

Google doesn't publish a list of accepted documents for this clause, so give the reviewer evidence that is quick to verify.

Technical proof: Digital Asset Links

Publish an assetlinks.json file at https://yourdomain.com/.well-known/assetlinks.json. It needs a statement with the relation delegate_permission/common.handle_all_urls, the target namespace android_app, your package_name and sha256_cert_fingerprints. With Play App Signing, Google re-signs your app, so list the app signing key fingerprint, not only your upload key. Google's help currently shows it under Protected with Play > Play Store distribution > Play app signing (search for "App signing" if your console's menu differs).

Then declare App Links for the same host (an intent-filter with android:autoVerify="true", the https scheme and your domain). Check the status on the Play Console Deep links page (Grow users > Deep links), which can also generate the assetlinks.json contents for you, or on an Android 12+ device with adb shell pm get-app-links your.package.name. Android's Verify App Links guide has the file format and test commands.

Consistency proof

• The developer name in Play Console matches the site's imprint or "About" page.
• The developer contact email, store listing website and privacy policy URL use the site's domain.
• The website links to your Google Play listing.
• The site runs on your own domain, not a site-builder subdomain you can't put files on.

Third-party sites: written permission

If you don't own the site, you need written permission from its owner or administrator. A useful letter comes from the owner's domain or letterhead, names your developer account and package name, describes what the app may show and is signed and dated. Google's advance notice form is meant for written documentation of permission to use a third party's intellectual property in your app or store listing. Google doesn't name WebView permission letters there specifically, but a site owner's permission fits that description, so submitting it before your next review is a reasonable step. If you can't get permission, no code change makes that app compliant.

How to fix a WebView spam rejection step by step

1. Read the issue details on the app's Policy status page and in the email. Note which wording was used (webview without permission, affiliate traffic, repetitive content, limited functionality) and the version code.
2. Decide which test you failed. Permission problems need evidence, purpose and functionality problems need product changes. Often you need both.
3. Fix the ownership signals from the previous section.
4. Rework affiliate monetization if referral links are the core of the app (see below).
5. Add app-specific functionality to the main user journey (next section).
6. Remove web giveaways. Hide the site's header, footer and "Get our app" banners in the app (detect a custom user agent suffix), replace net::ERR_ pages with a native offline screen in WebViewClient.onReceivedError and open other domains in Custom Tabs. Don't just hide the cookie banner: if the pages still set non-essential cookies, replace it with a native consent screen.
7. Align the store listing. Describe app features, show native screens and remove third-party brands you have no rights to.
8. Upload a new release with a higher versionCode to every track that holds the rejected build, and deactivate the non-compliant bundles. Google warns that resubmission fails if they stay active.
9. Send your evidence through the advance notice form or an appeal, as described below.

Adding real app value to a WebView app on Android

Google publishes no feature quota. A reviewer should find things in your app that Chrome can't do with your website.

WebView, Trusted Web Activity or native?

A Trusted Web Activity runs your PWA full screen in the user's browser and relies on Digital Asset Links to confirm that app and site come from the same developer. If verification fails, the browser falls back to a Custom Tab with visible browser UI. That makes a verified TWA a clear ownership signal, but it adds no functionality by itself, so your PWA still needs things like offline support and notifications.

A WebView lets you bridge to native code, but Android's WebView documentation warns that addJavascriptInterface lets JavaScript control your app. Use it only if you wrote all the HTML and JavaScript shown, and keep navigation on your domain with shouldOverrideUrlLoading.

Capacitor, Flutter, React Native and no-code builders

Capacitor and Ionic apps are on firmer ground when they use native plugins for push, camera and storage in the main journey. In Flutter (webview_flutter) or React Native (react-native-webview), put native tabs around clearly scoped web screens. No-code website-to-app builders tend to produce the thin, repeatable template this policy targets, so add native modules or move the core journey to native code.

Affiliate and deal apps: what Google allows

Affiliate links aren't banned. An app whose primary purpose is to drive affiliate traffic is. Ask yourself: if you removed every referral ID, would the app still be worth installing?

• Build original value first: price history and alerts, your own reviews and comparisons, barcode lookup, wish lists.
• Make outbound links a secondary step, not the only action on every screen.
• Don't frame the merchant's site in your WebView. Open it in Custom Tabs or the browser.
• Label affiliate links clearly so users know when you earn a commission.
• Check your affiliate program's terms. Programs can have their own rules for links inside mobile apps, so read them before you ship.

Responding: resubmit, send evidence or appeal

Fix and resubmit when you changed the app. For a rejected update, the previous version stays live while you work.

Appeal when the app already complies and the reviewer couldn't see your ownership or permission. Use the link in the enforcement email or the Policy status page. Before you write, know the limits:

• Google allows one appeal per removal, suspension or other enforcement action. Send all evidence at once.
• As of October 2026, Google says it can respond to appeals only in Chinese, English, Japanese and Korean.
• Name the package, version code and domain, list your proof and say where each native feature lives. Link a short screen recording and keep reviewer sign-in details current under App content > App access.

Suspensions count as strikes, and you forfeit the suspended app's users, statistics and ratings. Google says that if your developer account is still in good standing and the app allows for it, you can publish a new compliant version. Follow the instructions in the email exactly.

Never show reviewers a native version and switch back to a plain website via remote config later. Google's Deceptive Behavior policy requires apps to behave the same for reviewers and regular users, and such violations can put your developer account at risk.

How to avoid WebView spam rejections next time

Add these checks to your release pipeline:

• Asset links check: a CI step fetches /.well-known/assetlinks.json and fails the build if your package name or the app signing SHA-256 is missing.
• Domain allowlist: a lint or unit test that fails when loadUrl targets a host outside your own domains.
• Affiliate scan: flag outbound URLs with referral parameters such as tag=, ref= or aff_id=.
• Listing consistency: developer name, contact email and website share one domain.
• Data safety: if your app controls the code or behavior of the pages in its WebView, the data they collect belongs in the Data safety form. Google exempts only WebViews in which users navigate the open web.
• Pre-launch report review: ship to internal testing first and check the screenshots for website headers and browser error pages. Our broken functionality guide covers the rest of that report.

AI-assisted checks help here, for example by flagging app screens identical to your mobile site. A human still decides what to build and how to argue the case. appsubmitter.io combines both in its CI/CD and submission service. Start with a free consultation call to review your WebView app before you upload it.

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.

Subject: Appeal – [App name] ([package name]), version code [version code] – Spam policy (Webviews and Affiliate Spam)

Hello Google Play team,

We are appealing the [rejection / removal] of [App name] ([package name]) under the Spam policy, notified on [date]. We believe the app complies, and we are providing the evidence below.

1. Website ownership
[https://yourdomain.com] is owned by [legal entity], the same entity that holds our developer account "[developer account name]". Evidence:
- https://[yourdomain.com]/.well-known/assetlinks.json lists [package name] and our Play app signing SHA-256 fingerprint
- Our developer contact email and store listing website use the same domain
- The website links to our Google Play listing: [URL]
- [If applicable: written permission from the website owner, signed by [name, role] on [date], attached / sent via the advance notice form on [date]]

2. App-specific functionality in version code [version code]
- [Feature 1, e.g. order tracking with push notifications]
- [Feature 2, e.g. offline access to saved items]
- [Feature 3, e.g. barcode scanning]
Screen recording: [link]

3. Affiliate links
[The app contains no affiliate links. / Affiliate links appear only on [screen], after [user action], and are clearly labeled.]

[If you uploaded a new release: Version code [new version code] is live on [tracks], and the non-compliant bundles are deactivated on all tracks.]

Thank you for your review.
[Your name], [Company]
[Developer account ID]

Checklist before you resubmit

• You own the website shown in the app, or hold written permission from its owner naming your developer account and package name.
• assetlinks.json on your domain lists your package name and the Play app signing SHA-256 fingerprint, and App Links show as verified.
• Developer name, contact email, store listing website and privacy policy URL match the displayed website.
• The core user journey includes features the mobile website cannot offer, such as relevant notifications, offline access or scanning.
• Website header, footer and app install banners are hidden inside the app, and any cookie consent still works (natively if needed).
• Going offline shows a native screen, and third-party domains open in Custom Tabs, not your WebView.
• Affiliate links are secondary, clearly labeled and allowed in apps by your affiliate program.
• Title, icon and screenshots show app features and no third-party brands without permission.
• The new release has a higher versionCode on every affected track, and all non-compliant bundles are deactivated.
• Your appeal contains all evidence at once, written in English (or Chinese, Japanese or Korean).

Frequently asked questions

Official source: Google Play Policy Center – Spam (Webviews and Affiliate Spam). Store policies change regularly – always check the current version. This guide is independent advice and not affiliated with Apple or Google.