Google Play Policy hub
Policy guide

Google Play Repetitive Content Policy: Avoiding Rejection for Duplicate or Spammy Listings

Nobody sets out to build spam. Repetitive content usually happens by accident: a template that worked once, a series of small apps that each seemed reasonable, a description tuned for search a little too hard.

The core idea in Google's Spam policy is simple: an app should offer something other apps on the store don't already offer — including your own other apps.

Scope note: SubmitSafe checks your store listing metadata only — title, descriptions, screenshots and listing notes. It does not analyze APK code, SDK behavior or malware. Examples on this page are hypothetical composites, not real apps. Google Play makes all final decisions.

The test most developers get wrong

Developers tend to ask "is my app different from everyone else's?" The more dangerous question is "is my app different from my other apps?" Google calls out creating multiple apps with highly similar functionality, content and experience, and suggests combining small apps into one.

A new skin, a new colour theme or a new city name usually isn't a new product. Different content can be — if the listing makes the difference obvious.

Three patterns that look like spam

Example 1 — the city series

"Bus Times Leeds", "Bus Times York", "Bus Times Hull" — eight apps, identical code, identical description with the city name swapped. Each one is thin; together they look like a store-flooding strategy. One app with a city picker is the version reviewers expect.

Example 2 — the reskinned template

A flashlight or wallpaper app built from a purchased template, uploaded with the template's stock description and screenshots. Dozens of other developers bought the same template. Nothing in the listing explains what this version adds.

Example 3 — the keyword wall

Title: "PDF Reader – PDF Viewer, PDF Editor, PDF Scanner". The full description ends with a paragraph of comma-separated search terms. Search terms repeated for the algorithm, not sentences for a human — that's exactly the spammy-keyword pattern the Metadata policy prohibits.

How it typically gets noticed

  • Several apps from the same developer share most of their description text word for word.
  • Screenshots are interchangeable between apps — same layout, same sample data.
  • The title is a list of keywords rather than a name ("Editor, Maker, Creator, Free").
  • A description that could describe any competitor because it never mentions anything specific.

For the closely related title and description rules, see 5 metadata mistakes that get listings rejected.

Rewriting a listing that reads as templated

Avoid

"Best photo editor app. Edit photos, photo filters, photo effects, collage maker, selfie editor, beauty camera."

Better

"Fix lighting in old scanned family photos. Batch-correct faded colour and save the originals alongside."

The better version is shorter, uses fewer keywords and is far more likely to be read as a distinct product. Specific beats broad, every time.

Practical next step

Paste your title and descriptions into the free listing checker — it flags keyword stuffing, superlatives and vague template phrasing. It can't compare your app's code to other apps; that's a judgement only you (and the reviewer) can make.

Run your listing past a second pair of eyes

The free checker flags the listing-text patterns described above before a reviewer sees them.

Check your listing before Google does

Paste your listing text and get a policy risk breakdown in 60 seconds.

Check for free