"Privacy policy link invalid" on Google Play means Google could not validate the privacy policy URL you provided, so your update or app is rejected. The usual causes are a broken URL that returns a 404, a link that points to your homepage instead of an actual privacy policy, a page that is not publicly accessible because it needs a login or is geo-blocked, a PDF or editable document, or a policy that does not reference your app. The fix is to host a real, publicly accessible privacy policy that names your app, set it in Play Console, and link it in the app too.
Short answer
The rejection means your privacy policy URL did not meet Google's requirements. Per Google's guidance on preparing your app for review, the URL must be active and publicly accessible, apply specifically to your app, and clearly be a privacy policy, not a homepage or a PDF. Common failures include a 404 or a page that does not load, a link to your store listing, an editable document, or a policy that does not name your app or entity. Fix it by hosting a real policy on a stable HTTPS page, setting it under App content in Play Console, and linking it inside the app. Every app needs one, even those that collect no data.
What "privacy policy link invalid" means
The message means Google visited the URL you entered as your privacy policy and could not accept it as a valid one. It is not a vague complaint: Google actually opens the link during review, and if the page does not load, is not a privacy policy, or does not meet the specific requirements, the submission is rejected with this notice. It is a metadata issue tied to that one field.
Because it is about the link and the page behind it, the fix lives outside your app's code. You are not changing the binary; you are making the URL point to a compliant privacy policy that Google can open and validate. That also means a rejection here can usually be resolved without uploading a new build, once the URL and page are correct.
Why your privacy policy URL was rejected
Matching the exact reason to a fix is the fastest path. The most common cause is a broken URL that returns a server error, followed by a link that points to your homepage or store listing rather than an actual privacy policy. Other frequent causes are a page that requires a login or is blocked in some regions, a PDF or an editable document, and a generic policy that never mentions your app. The table below maps these to their fixes.
| Cause | Typical sign | Fix |
|---|---|---|
| Broken URL (404) | A server error or page not found | Host it on a live, stable URL |
| Points to your homepage | "Not a valid privacy policy" | Link the actual policy page |
| Not publicly accessible | Requires a login or is geo-blocked | Make it public from any region |
| PDF or editable document | Google cannot validate it | Use a non-editable HTML page |
| Does not reference your app | The policy is generic | Name your app and entity in it |
Reading the cause first avoids a common loop, where a developer resubmits the same URL without changing anything and is rejected again. The URL has to actually change, or the page behind it does, before the rejection clears.
What a valid privacy policy URL requires
Google is specific about what makes a privacy policy URL valid, and meeting all of it is what clears the rejection. The page must be on an active, publicly accessible URL, not a PDF, and it must be non-editable, so an editable document shared from a drive does not qualify. It must refer to your app and specifically cover user privacy, and it should be clearly labeled as a privacy policy in the title or URL and in the body of the page.
It also has to match your identity. The policy should reference the same developer or company name used in your Google Play listing, or the exact name of the app, so it is clearly yours. Finally, Google expects the policy to be linked both on your store listing and within the app itself. A page that meets every one of these points is what Google accepts.
Where to set it in Play Console
You enter the privacy policy URL in Play Console under Policy and App content, in the privacy policy section. This is the field Google reads during review, so it must contain the exact, working URL of your compliant policy page. Save it there, and make sure it is the same URL you also link from inside the app.
Keep it current over time. If you later move domains, change your support host, or restructure your site, update this field so it does not end up pointing at a dead page. A privacy policy URL that was valid at launch but returns an error months later is a rejection or a policy warning waiting to happen on your next update.
Keep it consistent with your Data safety form
A subtle cause of trouble is a mismatch between your privacy policy and your Data safety declaration. Google Play asks you to declare what data your app collects and shares in the Data safety form, and your privacy policy should describe the same handling. If your policy says one thing and your Data safety section says another, that inconsistency can draw a rejection or a policy notice.
Treat the two as one story about your data. Whatever your app actually collects, uses, and shares should be reflected accurately in both the Data safety form and the privacy policy. Getting them to agree not only avoids rejections but is also what the policy is for: telling users, truthfully, what happens to their data.
Fix checklist
Work the fix in order rather than resubmitting and hoping. The checklist below takes you from hosting the page to clearing the rejection.
| Step | Action | What it confirms |
|---|---|---|
| 1 | Host the policy on a live HTTPS page | It loads for anyone, anywhere |
| 2 | Make sure it names your app and entity | It clearly applies to your app |
| 3 | Label the page as a privacy policy | Google recognizes what it is |
| 4 | Set the URL under App content in Play Console | The field is correct |
| 5 | Link the same policy inside the app | Meets the in-app requirement |
| 6 | Resubmit or reply after correcting it | Clears the rejection |
The steps that people skip are usually the second and fifth: a policy that never names the app, and a policy that is on the listing but not linked in the app. Both are explicit requirements, so covering them is often what turns a repeated rejection into an approval.
Common mistakes
A few mistakes cause most of these rejections. Using an editable document, such as one shared from a drive, fails because the policy must be non-editable. Pointing the field at your homepage or app landing page fails because it is not a privacy policy. Hosting the page somewhere that blocks Google or requires a login fails because the reviewer cannot open it. And using a generic template that never mentions your app or company fails the requirement to apply specifically to your app.
Avoiding these is mostly about putting yourself in the reviewer's position. Open your privacy policy URL in a private browser window, from a normal connection, with no login, and check that it loads, that it is clearly a privacy policy, and that it names your app or company. If you can see all of that, so can Google.
Does every app need a privacy policy?
Yes. Google requires a privacy policy for every app, even one that does not access any personal or sensitive user data. This surprises developers of simple apps, who assume a policy is only needed when the app collects data, but the requirement is universal. There is no category of app that is exempt from having a valid privacy policy URL.
So even a small utility with no accounts and no data collection must provide a compliant policy that states, honestly, that it does not collect user data, hosted on a valid URL and linked in both the listing and the app. Skipping it because "my app collects nothing" is itself a common cause of this rejection.
Match your policy to what your app actually does
A privacy policy is only truthful if it matches what your app really does with data, and that is harder to know than it sounds when permissions and network calls pile up. If your app requests permissions or sends data you have forgotten about, your policy and your Data safety form can end up understating what actually happens, which is both a policy risk and a trust problem.
A scanner like PTKD.com analyzes your .apk and returns findings ordered by severity and mapped to OWASP MASVS, including the permissions your app requests and its network behavior, which helps you describe your data handling accurately. To be clear about the boundary: PTKD does not host your privacy policy, fix the URL, or write the document, and it cannot clear a privacy policy rejection on its own. It shows you what your app actually does, so your policy and Data safety declaration can tell the truth.
What to take away
- "Privacy policy link invalid" means Google could not validate your privacy policy URL, so the submission is rejected.
- The page must be a live, publicly accessible, non-editable HTML privacy policy that names your app and entity, not a homepage or PDF.
- Set the URL under App content in Play Console, and link the same policy inside the app.
- Every app needs a privacy policy, even one that collects no data, and it should match your Data safety form.
- Use PTKD.com to see what data your app actually handles, so your policy and Data safety declaration are accurate.
