Cambiare un URL che è già in una scheda dello store pubblicata

Prima o poi ti sposti: un hosting gratuito chiude, un dominio è scaduto, un’azienda ha cambiato nome, oppure hai costruito il sito vero che avevi sempre in mente. I campi sono modificabili, quindi il cambio in sé è banale. Quello che sorprende le persone è tutto il resto che, in silenzio, punta ancora al vecchio indirizzo.

L’ordine che non rompe nulla

1. Pubblica il nuovo URL e controllalo senza aver effettuato l’accesso. Deve essere online prima che qualsiasi cosa punti lì.
2. Fai in modo che il vecchio indirizzo reindirizzi al nuovo. Non eliminarlo: reindirizzalo. È il passaggio che le persone saltano, ed è quello che ti salva.
3. Aggiorna i campi della console. Play Console → App content per gli URL della privacy policy e dell’eliminazione dei dati; App Store Connect per la privacy policy e la Support URL. Google Play chiede che la policy “is available on an active URL” (sia disponibile a un URL attivo): quindi il campo non deve mai puntare a qualcosa di morto, nemmeno per poco.
4. Aggiorna i link dentro la tua app. La norma User Data di Play richiede il link alla privacy policy in Play Console e dentro l’app stessa, e quello nell’app di solito è scritto nel codice di una build che hai rilasciato mesi fa. Gli utenti con la vecchia versione continuano a finire sul vecchio URL finché non aggiornano, e alcuni non lo faranno mai.
5. Lascia il redirect al suo posto. Non per una settimana: a tempo indeterminato, se puoi.

Farlo nell’ordine inverso (cambiare prima il campo, o eliminare prima il vecchio hosting) è il modo in cui ti ritrovi con una scheda pubblicata che punta a un 404 mentre è in corso una revisione.

Perché il vecchio indirizzo deve continuare a rispondere

Il campo della console è l’indirizzo che controlli. Non è l’unico posto in cui esiste il vecchio URL:

• I binari dell’app già distribuiti. Ogni copia installata di ogni versione precedente collega il vecchio URL. Non puoi aggiornarli tu; lo fanno gli utenti, prima o poi, e alcuni non lo faranno mai.
• La cache della scheda dello store e i siti aggregatori che hanno copiato la tua scheda.
• Le email e le ricevute che hai già inviato.
• I registri delle reti pubblicitarie, se il vecchio host era il sito web dello sviluppatore che avevi dichiarato.

Quindi “il vecchio URL è morto ma il campo è aggiornato” è vero solo dal tuo lato.

L’eccezione: app-ads.txt non deve essere reindirizzato

Un caso speciale, ed è quello che fa perdere soldi in silenzio. Le reti pubblicitarie recuperano /app-ads.txt alla radice del sito web indicato nella scheda dello store, e la specifica prevede che sia servito direttamente. Un redirect davanti al file è una causa frequente di un risultato “not found” anche quando il file è perfettamente corretto.

Quindi, se il vecchio host era il sito web dello sviluppatore dichiarato e lo mantieni come redirect, /app-ads.txt su quell’host dovrebbe essere servito con un 200 invece di essere reindirizzato finché il vecchio indirizzo potrebbe ancora essere scansionato. Tutto il resto può fare 301; quel percorso no.

Cosa controllare dopo lo spostamento

Esegui questi comandi senza aver effettuato l’accesso, in una finestra privata:

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

Poi nelle console: ogni campo URL apre la pagina giusta, e le risposte di Data safety / App Privacy corrispondono ancora a ciò che dicono le nuove pagine. Spostare una pagina è un buon momento per accorgersi che la policy è diventata obsoleta due SDK fa.

Il cambiamento che non puoi annullare facilmente

Un URL è un’identità, non un’impostazione. Una volta finito in una scheda dello store esiste in posti che non controlli, ed è per questo che lo spostamento conviene farlo una volta sola, con cognizione, verso un indirizzo che prevedi di mantenere. La domanda da porsi su qualsiasi hosting prima di incollarne l’URL in un campo della console non è “è gratuito?” ma “questo indirizzo esatto risponderà ancora tra due anni, e se no, posso reindirizzarlo?”.

Cosa fa AppFoyer

Due cose sono costruite proprio attorno a questo problema.

L’indirizzo casuale della tua app è permanente. Ogni app riceve app-xxxxxx.appfoyer.page al momento della creazione e quell’indirizzo non cambia mai: anche se in seguito richiedi un sottodominio personalizzato con un piano a pagamento, l’originale continua a rispondere con lo stesso sito, senza redirect e senza scadenza. L’indirizzo che hai incollato in un campo della console un anno fa non smette di funzionare perché hai rinominato qualcosa.

Un sottodominio personalizzato che sostituisci viene rilasciato subito. Se ne sostituisci uno, il vecchio indirizzo smette immediatamente di rispondere, senza redirect, e chiunque può richiederlo, anche un altro account. Quindi non mettere mai un sottodominio personalizzato in una scheda che potresti cambiare in seguito: l’indirizzo permanente qui sopra è quello che ha la garanzia di continuare a funzionare.

E poiché l’indirizzo permanente serve il sito stesso invece di reindirizzare, /app-ads.txt risponde con un 200 lì come sull’indirizzo attuale: la regola qui sopra è rispettata senza nulla da configurare.

Le fonti ufficiali

• Privacy policy requirements — Guida di Google Play, per la formulazione “available on an active URL”.
• User Data policy — Guida di Google Play, per la regola console più app.
• Set up app-ads.txt — Guida di AdMob, per come viene individuato il file.
• App Store Connect — app information — Apple, per sapere dove si trovano i campi.