Country targeting is the switch that decides which Google Play accounts can install your app — and it is measured by where the account is registered, not where the phone happens to be standing. That distinction is why a market can look open in your analytics while a whole group of testers never sees the build. In 2026 the controls are split across three places: the Production page, the country tab on each testing track, and the Country availability option inside a staged rollout. This guide walks all three, plus the publishing rules that decide when a country change actually goes live.


App availability vs. country targeting

Play Console uses two related but separate switches, and mixing them up is the most common cause of "the app is not visible in that country":

Underneath both switches sits one rule: country targeting follows the user's Play country, i.e. where their Google account is registered, not their current location. A traveller carrying a foreign account is still counted as a user of that foreign country, and a visitor using a local account counts as local.


Step 1 — Set app availability on the Production page

  1. Open Play Console and select the app.
  2. Go to the Production page.
  3. Select the Countries/regions tab.
  4. Click Add countries/regions or Remove countries/regions and select the countries you want to change.
  5. Confirm your selection.

Two commercial side effects arrive with the change:

Availability is a distribution decision, not a relevance decision. Because targeting follows the registered account country, a city-specific or region-specific service still needs wider availability if visitors must be able to install it before they arrive. Scope it too tightly and the store page returns "not available in your country" to exactly the people who need it.


Step 2 — Customize country targeting for testing releases

Prerequisite: you can customize testing-track availability only if your app has no app bundle uploaded to production, or it has one and at least one country is available in the production track.

  1. Open the track you want to change. For Open testing, go to Testing > Open testing and select the Countries/regions tab. For Closed testing, go to Testing > Closed testing, click Manage track next to the track, then select Countries/regions.
  2. Note that the track is synced with production by default: changes to production availability, or to pre-registration, also land on your testing release.
  3. To diverge, click Unsync countries/regions. The sync option stays available only while your track has no release rolled out, your production track targets at least one country, or pre-registration targets at least one country that is not "Rest of World".
  4. Once a track is unsynced, click Edit countries and select the countries to add or remove.
  5. Confirm your selection.

If the country controls are greyed out, it is usually permissions rather than a Play Console bug — an account without the testing-track permissions cannot change them, and the control is disabled by design.


Step 3 — Restrict a staged rollout to specific countries

  1. Open the track page: Production for a production update, or the open / closed testing page. If the Production page is not visible, you are missing the permission to manage production releases.
  2. Select the Releases tab.
  3. On the release you want to change, click Edit. If nothing else changes, you can click Review release and skip straight to the review section.
  4. Scroll to the Staged rollout section and enter a rollout percentage.
  5. Under Country availability, choose Select specific countries/regions and tick the countries this rollout should reach. This control is offered only when you are updating a production release.
  6. Click Start rollout to production.

Three constraints decide how you plan the rollout:


Four patterns country targeting is actually used for


Review and publishing timing for country changes

Country changes are not invisible plumbing. The Publishing overview page lists them next to store listing edits and app content changes, including:

Changes wait in Changes not yet sent for review until you click Send for review — or Save for later to hold one change back while you submit another. They publish as soon as Google approves them unless managed publishing is on, in which case approved changes sit in Ready to publish until you release them yourself. Processing can take a few hours or up to seven days, and longer in exceptional cases, so a one-week buffer between submitting and a planned go-live is the safe assumption. Managed publishing cannot be used when publishing an app for the first time.

Not everything waits for managed publishing. These go through regardless: increasing an existing staged rollout to 100%, release notes updates, price changes, changes to device exclusion rules, unpublishing the app, stopping store listing experiments, and changes to in-app products.


Checklist before you submit a country change

  1. Is this app availability (production, and inherited by all future releases) or testing-track targeting (per track)?
  2. Are prices set — paid app or subscription — for every country you are adding?
  3. If a staged rollout starts soon, is the country list final? It cannot shrink after the rollout begins.
  4. Are your test tracks still synced to production, or deliberately unsynced?
  5. Does the change need to be held for a fixed launch moment through managed publishing?
  6. Is the store listing still accurate for the markets you are removing from?

The one-line model: app availability sets where the app exists for production and every future release; testing tracks inherit it until you unsync them; internal testing ignores it; a staged rollout can narrow it per release but never wider once started. Every targeting change is a reviewed publishing event, so build the review window into the plan.


Sources