Cambiar una URL que ya está en una ficha publicada

Tarde o temprano te mudas: un hosting gratuito cierra, un dominio caduca, una empresa cambia de nombre o construyes por fin el sitio de verdad que siempre quisiste. Los campos se pueden editar, así que el cambio en sí es trivial. Lo que pilla a la gente es todo lo demás que, sin hacer ruido, apunta a la dirección antigua.

El orden que no rompe nada

1. Publica la URL nueva y compruébala sin sesión iniciada. Tiene que estar activa antes de que nada apunte a ella.
2. Haz que la dirección antigua redirija a la nueva. No la borres: redirígela. Este es el paso que la gente se salta, y es el que te salva.
3. Actualiza los campos de la consola. Play Console → App content para la política de privacidad y las URL de eliminación de datos; App Store Connect para la política de privacidad y la Support URL. Google Play pide que la política “is available on an active URL” (esté disponible en una URL activa), así que el campo nunca debe apuntar a algo caído, ni siquiera un momento.
4. Actualiza los enlaces dentro de tu app. La política User Data de Play exige el enlace a la política de privacidad en Play Console y dentro de la propia app, y el de la app suele estar fijo en el código de una build que publicaste hace meses. Los usuarios con la versión antigua siguen llegando a la URL antigua hasta que actualizan, y algunos nunca lo harán.
5. Deja la redirección. No una semana: indefinidamente, si puedes.

Hacerlo en el otro orden (cambiar primero el campo, o borrar primero el hosting antiguo) es como acabas con una ficha publicada apuntando a un 404 mientras hay una revisión en curso.

Por qué la dirección antigua tiene que seguir respondiendo

El campo de la consola es la dirección que controlas. No es el único lugar donde existe la URL antigua:

• Los binarios de la app ya publicados. Cada copia instalada de cada versión anterior enlaza la URL antigua. No puedes actualizarlos; los usuarios lo hacen, con el tiempo, y algunos nunca lo harán.
• La caché de la ficha de la tienda y los sitios agregadores que copiaron tu ficha.
• Los correos y recibos que ya enviaste.
• Los registros de las redes publicitarias, si el hosting antiguo era tu sitio web de desarrollador declarado.

Así que «la URL antigua está caída pero el campo está actualizado» solo es cierto desde tu lado.

La excepción: app-ads.txt no debe redirigirse

Un caso especial, y es el que cuesta dinero sin que te enteres. Las redes publicitarias descargan /app-ads.txt en la raíz del sitio web de tu ficha de la tienda, y la especificación espera que se sirva directamente. Una redirección delante es una causa frecuente de un resultado «not found» incluso cuando el archivo es perfectamente correcto.

Así que, si el hosting antiguo era tu sitio web de desarrollador declarado y lo mantienes como redirección, /app-ads.txt en ese host debe servirse con un 200 en lugar de redirigirse mientras la dirección antigua pueda seguir rastreándose. Todo lo demás puede ir con 301; esa ruta, no.

Qué comprobar después de la mudanza

Ejecuta esto sin sesión iniciada, en una ventana privada:

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

Luego, en las consolas: cada campo de URL abre la página correcta, y las respuestas de Data safety / App Privacy siguen coincidiendo con lo que dicen las páginas nuevas. Mover una página es un buen momento para darte cuenta de que la política quedó desactualizada hace dos SDK.

El cambio que no se deshace fácilmente

Una URL es una identidad, no un ajuste. Una vez que ha estado en una ficha de la tienda, existe en lugares que no controlas, y por eso vale la pena mudarse una sola vez, a propósito, a una dirección que esperas conservar. La pregunta que debes hacerte sobre cualquier hosting antes de pegar su URL en un campo de la consola no es «¿es gratis?», sino «¿seguirá respondiendo esta dirección exacta dentro de dos años, y podré redirigirla si no?».

Qué hace AppFoyer aquí

Hay dos cosas construidas exactamente en torno a este problema.

La dirección aleatoria de tu app es permanente. Cada app recibe app-xxxxxx.appfoyer.page al crearse y esa dirección nunca cambia: aunque más adelante reclames un subdominio personalizado en un plan de pago, la original sigue respondiendo con el mismo sitio, sin redirección y sin caducidad. La dirección que pegaste en un campo de la consola hace un año no deja de funcionar porque hayas renombrado algo.

Un subdominio personalizado que sustituyes se libera de inmediato. Si sustituyes uno, la dirección antigua deja de responder al instante (sin redirección) y cualquiera puede reclamarla, incluida otra cuenta. Así que nunca pongas un subdominio personalizado en una ficha que quizá cambies más adelante: la dirección permanente de arriba es la que tiene garantizado seguir funcionando.

Y como la dirección permanente sirve el propio sitio en lugar de redirigir, /app-ads.txt responde con un 200 tanto ahí como en la dirección actual: la regla de arriba se cumple sin configurar nada.

Las fuentes oficiales

• Privacy policy requirements — Ayuda de Google Play, para la redacción “available on an active URL”.
• User Data policy — Ayuda de Google Play, para la regla de consola más app.
• Set up app-ads.txt — Ayuda de AdMob, para cómo se localiza el archivo.
• App Store Connect — app information — Apple, para saber dónde están los campos.