How to Host a Privacy Policy Without a Website

The privacy policy field in Play Console and App Store Connect isn't a text box — it's a URL field: review systems visit that address automatically and check whether the page actually loads. No matter how complete your policy text is, if it doesn't live on a web page that opens directly in a browser, the field counts as invalid.

Some developers try entering a download link to a PDF or Word file in this field; technically that is also an 'address,' but it's invalid for Google Play: Play Console's own policy text specifically says the privacy policy URL must have '(no PDFs)' and requires the address to be non-editable, publicly accessible, and non-geofenced. File links also behave inconsistently across devices (some browsers trigger a download instead of opening the page), they aren't crawled like a normal web page by search engines, and automated verification from ad networks (like AdMob) expects a standard HTML page. The safest approach is publishing the policy as a page that renders directly in the browser, with no download involved.

The page also needs to require no login, avoid being a temporary preview address, and stay put once published. Whether it's the review bot or an actual user visiting the address, they should land directly on the policy text — not a 'sign in' or 'request access to this document' screen.

GitHub Pages is completely free if you already have a GitHub account, and it's technically solid: drop your policy file in a repo, enable Pages, and your address is permanent and public. The cost is the setup process — creating a repo, uploading a file, and turning on Pages settings can be a real barrier for a developer who isn't comfortable with code — and the default address (in the form username.github.io/repo-name) looks unbranded and long; connecting your own short domain requires a separate DNS setup.

Google Sites lets you publish a page in a few minutes with a drag-and-drop editor and no coding — the lowest technical barrier of the bunch, and free. But the result often doesn't look professional: it reads as a generic template, and your address ends up long and unbranded, something like sites.google.com/view/... — connecting your own short domain isn't possible on the free plan.

Sharing a Notion page or a Google Docs file with a 'public link' also produces a technical URL, and it's the fastest option — but it's risky for store review: these addresses are tied to a user account, and the page can become unreachable if workspace settings change or sharing permissions get restricted by accident. There's no permanence guarantee. Some reviewers also treat this kind of address as a shared document rather than a standard web page and may raise extra questions.

Buying your own domain and hosting a simple static page is the most professional-looking option and gives you full control — but it comes at a cost: an annual domain fee, a hosting service (or, again, a free static host like GitHub Pages), and ongoing maintenance like DNS and certificate renewal. For a single app, that investment feels disproportionate to most solo developers.

Whichever option you use, the real risk is changing the address AFTER you've already chosen it. Deleting or editing the URL in Play Console counts as a store-listing update and can send your next release into review again; the same field gets re-evaluated in App Store Connect. Switching from one hosting option to another (say, from Notion to GitHub Pages) may feel like a minor move, but on the store side it means a new submission.

So when choosing where to host, it pays to optimize for how easily you can update the content BEHIND the address, not the address itself: keep the URL fixed, and pick a setup that lets you update the policy text at that same address whenever you add a new SDK or your data-collection behavior changes.

Generating the privacy policy text on Vibeloy is free; with the premium plan, that policy is automatically published at a permanent subdomain address specific to your app (e.g. yourapp.vibeloy.dev/privacy) — no repo, no DNS setup, no picking a static host.

That address stays fixed from the moment you enter it into your store listing; when you update the policy text — after adding a new service or changing your data-collection behavior — the new content publishes at the same URL, so you never have to notify the stores of a new address.

None of the options above is 'wrong' — if you're comfortable with GitHub Pages, using it is perfectly reasonable. What Vibeloy changes is removing the hosting decision entirely, so a developer's time goes into the app instead.

1. Prepare the policy text: which SDKs your app uses (AdMob, Firebase Analytics, Crashlytics, and similar), what data types you collect, and your retention period. Picking a hosting address doesn't matter until the content itself is settled.

2. Once the content is ready, decide on a hosting option: a hosted solution makes sense if you don't want to spend time on setup, while GitHub Pages or your own domain makes sense if you want to keep control in your own hands.

3. Enter the address in both places: Play Console's Policy > App content > Privacy policy field, and App Store Connect's App Information > Privacy Policy URL field. The two systems are independent, so each needs to be filled in separately.

4. After saving the address, open it in a private/incognito browser window and confirm it loads directly with no login prompt — that's exactly what review will see.

If you'd rather not make each of these decisions one by one, Vibeloy's free privacy policy generator produces the policy text in minutes once you enter your app details and the services you use; if you want to skip the hosting step entirely, permanent subdomain hosting is included in the premium plan.