Como mudar uma URL que já está em uma página da loja publicada

Mais cedo ou mais tarde você muda de endereço: um host gratuito vai encerrar, um domínio expirou, uma empresa mudou de nome ou você criou o site de verdade que sempre quis ter. Os campos são editáveis, então a mudança em si é trivial. O que pega as pessoas é todo o resto que aponta, silenciosamente, para o endereço antigo.

A ordem que não quebra nada

1. Publique a nova URL e verifique sem estar logado. Ela precisa estar no ar antes que qualquer coisa aponte para ela.
2. Faça o endereço antigo redirecionar para o novo. Não excluir — redirecionar. Este é o passo que as pessoas pulam, e é o que salva você.
3. Atualize os campos do console. Play Console → App content para as URLs da política de privacidade e de exclusão de dados; App Store Connect para a política de privacidade e a Support URL. O Google Play pede que a política “is available on an active URL” (esteja disponível em uma URL ativa) — então o campo nunca deve apontar para algo fora do ar, nem por pouco tempo.
4. Atualize os links dentro do app. A política User Data do Play exige o link da política de privacidade no Play Console e dentro do próprio app, e o link no app geralmente está fixo no código de um build que você publicou meses atrás. Usuários na versão antiga continuam acessando a URL antiga até atualizarem, e alguns nunca vão atualizar.
5. Deixe o redirecionamento no lugar. Não por uma semana — indefinidamente, se puder.

Fazer na outra ordem — mudar o campo primeiro, ou apagar o host antigo primeiro — é como você acaba com uma página da loja publicada apontando para um 404 bem durante uma revisão.

Por que o endereço antigo precisa continuar respondendo

O campo do console é o endereço que você controla. Não é o único lugar onde a URL antiga existe:

• Binários do app já distribuídos. Cada cópia instalada de cada versão anterior aponta para a URL antiga. Você não consegue atualizar essas cópias; os usuários atualizam, um dia, e alguns nunca vão atualizar.
• O cache da página da loja e os sites agregadores que copiaram a sua página da loja.
• E-mails e recibos que você já enviou.
• Registros das redes de anúncios, se o host antigo era o site do desenvolvedor declarado.

Então “a URL antiga está fora do ar, mas o campo foi atualizado” só é verdade do seu lado.

A exceção: o app-ads.txt não pode ser redirecionado

Um caso especial, e é o que custa dinheiro sem fazer barulho. As redes de anúncios buscam /app-ads.txt na raiz do site informado na página da loja, e a especificação espera que ele seja servido diretamente. Um redirecionamento na frente dele é uma causa frequente de resultado “not found” mesmo quando o arquivo está perfeitamente correto.

Então, se o host antigo era o site do desenvolvedor declarado e você o mantém como redirecionamento, o /app-ads.txt nesse host deve ser servido com 200 em vez de redirecionado enquanto o endereço antigo ainda puder ser rastreado. Todo o resto pode receber 301; esse caminho não.

O que verificar depois da mudança

Execute estes comandos sem estar logado, em uma janela anônima:

curl -i https://old-host.example/privacy        # expect 301 to the new URL
curl -i https://new-host.example/privacy        # expect 200
curl -i https://old-host.example/app-ads.txt    # expect 200 text/plain, NOT a redirect

Depois, nos consoles: cada campo de URL abre a página certa, e as respostas de Data safety / App Privacy ainda batem com o que as novas páginas dizem. Mudar uma página de lugar é um bom momento para perceber que a política ficou desatualizada dois SDKs atrás.

A mudança que não dá para desfazer facilmente

Uma URL é uma identidade, não uma configuração. Depois que ela entra em uma página da loja, passa a existir em lugares que você não controla — por isso vale a pena fazer a mudança uma vez, de propósito, para um endereço que você espera manter. A pergunta a fazer sobre qualquer host antes de colar a URL dele em um campo do console não é “é gratuito?”, e sim “esse endereço exato ainda vai responder daqui a dois anos, e eu consigo redirecioná-lo se não for o caso?”.

O que o AppFoyer faz aqui

Duas coisas foram construídas exatamente em torno desse problema.

O endereço aleatório do seu app é permanente. Todo app recebe app-xxxxxx.appfoyer.page na criação, e esse endereço nunca muda — mesmo que depois você reivindique um subdomínio personalizado em um plano pago, o original continua respondendo com o mesmo site — sem redirecionamento e sem expiração. O endereço que você colou em um campo do console há um ano não para de funcionar porque você renomeou alguma coisa.

Um subdomínio personalizado que você substitui é liberado na hora. Substitua um e o endereço antigo para de responder imediatamente — sem redirecionamento —, e qualquer pessoa pode reivindicá-lo, inclusive outra conta. Então nunca coloque um subdomínio personalizado em uma página da loja que você pode mudar depois: o endereço permanente acima é o que tem garantia de continuar funcionando.

E, como o endereço permanente serve o próprio site em vez de redirecionar, o /app-ads.txt responde com 200 ali também, além de no endereço atual — a regra acima vale sem nada para configurar.

As fontes oficiais

• Privacy policy requirements — Central de Ajuda do Google Play, para o texto “available on an active URL”.
• User Data policy — Central de Ajuda do Google Play, para a regra de console mais app.
• Set up app-ads.txt — Ajuda do AdMob, para como o arquivo é localizado.
• App Store Connect — app information — Apple, para saber onde ficam os campos.