Eine URL ändern, die bereits in einem veröffentlichten Store-Eintrag steht

Früher oder später ziehen Sie um: Ein kostenloser Host wird eingestellt, eine Domain ist ausgelaufen, eine Firma wurde umbenannt, oder Sie haben endlich die richtige Website gebaut, die Sie immer bauen wollten. Die Felder sind bearbeitbar, die Änderung selbst ist also trivial. Was Leute erwischt, ist alles andere, was still und leise auf die alte Adresse zeigt.

Die Reihenfolge, die nichts kaputt macht

1. Veröffentlichen Sie die neue URL und prüfen Sie sie abgemeldet. Sie muss live sein, bevor irgendetwas auf sie zeigt.
2. Lassen Sie die alte Adresse auf die neue weiterleiten. Nicht löschen – weiterleiten. Diesen Schritt überspringen viele, und genau er rettet Sie.
3. Aktualisieren Sie die Felder in der Konsole. Play Console → App content für die URLs der Datenschutzerklärung und der Datenlöschung; App Store Connect für die Datenschutzerklärung und die Support URL. Google Play verlangt, dass die Richtlinie „is available on an active URL“ (unter einer aktiven URL verfügbar ist) – das Feld darf also nie auf etwas Totes zeigen, auch nicht kurz.
4. Aktualisieren Sie die Links in Ihrer App. Die User-Data-Richtlinie von Play verlangt den Link zur Datenschutzerklärung in der Play Console und in der App selbst, und der Link in der App ist meist fest in einem Build verdrahtet, den Sie vor Monaten ausgeliefert haben. Nutzer der alten Version landen auf der alten URL, bis sie aktualisieren, und manche tun das nie.
5. Lassen Sie die Weiterleitung bestehen. Nicht eine Woche – unbegrenzt, wenn Sie können.

Es in der umgekehrten Reihenfolge zu machen – zuerst das Feld ändern oder zuerst den alten Host löschen – ist der Weg zu einem veröffentlichten Store-Eintrag, der auf einen 404 zeigt, während gerade eine Prüfung läuft.

Warum die alte Adresse weiter antworten muss

Das Feld in der Konsole ist die Adresse, die Sie kontrollieren. Es ist nicht der einzige Ort, an dem die alte URL existiert:

• Ausgelieferte App-Binärdateien. Jede installierte Kopie jeder früheren Version verlinkt die alte URL. Diese können Sie nicht aktualisieren; die Nutzer tun es irgendwann, und manche nie.
• Der Cache des Store-Eintrags und Aggregator-Websites, die Ihren Store-Eintrag ausgelesen haben.
• E-Mails und Belege, die Sie bereits verschickt haben.
• Einträge bei Werbenetzwerken, wenn der alte Host Ihre angegebene Entwickler-Website war.

„Die alte URL ist tot, aber das Feld ist aktualisiert“ stimmt also nur aus Ihrer Sicht.

Die Ausnahme: app-ads.txt darf nicht weitergeleitet werden

Ein Sonderfall, und zwar der, der unbemerkt Geld kostet. Werbenetzwerke rufen /app-ads.txt im Root der Website aus Ihrem Store-Eintrag ab, und die Spezifikation erwartet, dass die Datei direkt ausgeliefert wird. Eine Weiterleitung davor ist eine häufige Ursache für „nicht gefunden“, selbst wenn die Datei völlig korrekt ist.

Wenn der alte Host also Ihre angegebene Entwickler-Website war und Sie ihn als Weiterleitung behalten, sollte /app-ads.txt auf diesem Host mit 200 ausgeliefert statt weitergeleitet werden, solange die alte Adresse noch gecrawlt werden könnte. Alles andere darf mit 301 weiterleiten; dieser eine Pfad nicht.

Was Sie nach dem Umzug prüfen

Führen Sie diese Befehle abgemeldet in einem privaten Fenster aus:

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

Dann in den Konsolen: Jedes URL-Feld öffnet die richtige Seite, und die Angaben unter Data safety / App Privacy passen noch zu dem, was die neuen Seiten sagen. Der Umzug einer Seite ist ein guter Moment, um zu bemerken, dass die Datenschutzerklärung schon seit zwei SDKs veraltet ist.

Die Änderung, die sich nicht leicht rückgängig machen lässt

Eine URL ist eine Identität, keine Einstellung. Sobald sie in einem Store-Eintrag stand, existiert sie an Orten, die Sie nicht kontrollieren – deshalb lohnt es sich, den Umzug einmal und bewusst zu machen, auf eine Adresse, die Sie behalten wollen. Die Frage, die Sie zu jedem Host stellen sollten, bevor Sie seine URL in ein Konsolenfeld einfügen, ist nicht „ist er kostenlos“, sondern „wird genau diese Adresse in zwei Jahren noch antworten, und kann ich sie weiterleiten, falls nicht“.

Was AppFoyer hier tut

Zwei Dinge sind genau um dieses Problem herum gebaut.

Die zufällige Adresse Ihrer App ist dauerhaft. Jede App bekommt bei der Erstellung app-xxxxxx.appfoyer.page, und diese Adresse ändert sich nie – selbst wenn Sie später in einem kostenpflichtigen Tarif eine eigene Subdomain beanspruchen, antwortet die ursprüngliche weiter mit derselben Website – ohne Weiterleitung und ohne Ablaufdatum. Die Adresse, die Sie vor einem Jahr in ein Konsolenfeld eingefügt haben, hört nicht auf zu funktionieren, weil Sie etwas umbenannt haben.

Eine eigene Subdomain, die Sie ersetzen, wird sofort freigegeben. Ersetzen Sie eine, antwortet die alte Adresse sofort nicht mehr – ohne Weiterleitung –, und jeder kann sie beanspruchen, auch ein anderes Konto. Setzen Sie also nie eine eigene Subdomain in einen Store-Eintrag, den Sie später vielleicht ändern: Die oben beschriebene dauerhafte Adresse ist die, die garantiert weiter funktioniert.

Und weil die dauerhafte Adresse die Website selbst ausliefert, statt weiterzuleiten, antwortet /app-ads.txt dort ebenso mit 200 wie unter der aktuellen Adresse – die Regel oben gilt, ohne dass Sie etwas einrichten müssen.

Die maßgeblichen Quellen

• Privacy policy requirements – Google-Play-Hilfe, für den Wortlaut „available on an active URL“.
• User Data policy – Google-Play-Hilfe, für die Regel „Konsole plus App“.
• Set up app-ads.txt – AdMob-Hilfe, dazu, wie die Datei gefunden wird.
• App Store Connect — app information – Apple, dazu, wo die Felder stehen.