Thay đổi một URL đã có trong trang thông tin đang phát hành trên cửa hàng

Sớm hay muộn bạn cũng sẽ chuyển: một host miễn phí đóng cửa, một tên miền hết hạn, một công ty đổi tên, hoặc bạn đã xây trang web thật mà bạn luôn định làm. Các trường đều sửa được, nên bản thân thay đổi là chuyện nhỏ. Điều khiến người ta vấp là mọi thứ khác vẫn âm thầm trỏ tới địa chỉ cũ.

Thứ tự không làm hỏng gì

1. Công bố URL mới và kiểm tra khi chưa đăng nhập. Nó phải hoạt động trước khi có thứ gì trỏ tới nó.
2. Cho địa chỉ cũ chuyển hướng sang địa chỉ mới. Không xóa — chuyển hướng. Đây là bước người ta hay bỏ qua, và là bước cứu bạn.
3. Cập nhật các trường trong console. Play Console → App content cho URL chính sách quyền riêng tư và URL xóa dữ liệu; App Store Connect cho chính sách quyền riêng tư và Support URL. Google Play yêu cầu chính sách “is available on an active URL” (có sẵn tại một URL đang hoạt động) — vì vậy trường này không bao giờ được trỏ tới thứ đã chết, dù chỉ trong chốc lát.
4. Cập nhật các liên kết bên trong ứng dụng. Chính sách User Data của Play yêu cầu liên kết chính sách quyền riêng tư trong Play Console và bên trong chính ứng dụng, và liên kết trong ứng dụng thường được viết cứng trong một bản build bạn đã phát hành từ nhiều tháng trước. Người dùng phiên bản cũ vẫn truy cập URL cũ cho tới khi họ cập nhật, và một số người sẽ không bao giờ cập nhật.
5. Giữ nguyên chuyển hướng. Không phải một tuần — mà vô thời hạn, nếu bạn có thể.

Làm theo thứ tự ngược lại — đổi trường trước, hoặc xóa host cũ trước — là cách bạn kết thúc với một trang thông tin đang phát hành trỏ tới trang 404 trong lúc đang có một lượt duyệt.

Vì sao địa chỉ cũ phải tiếp tục phản hồi

Trường trong console là địa chỉ bạn kiểm soát. Nó không phải nơi duy nhất URL cũ tồn tại:

• Các bản ứng dụng đã phát hành. Mọi bản cài đặt của mọi phiên bản trước đều liên kết tới URL cũ. Bạn không thể cập nhật chúng; người dùng thì có, dần dần, và một số người sẽ không bao giờ cập nhật.
• Bộ nhớ đệm của trang thông tin trên cửa hàng và các trang tổng hợp đã thu thập trang thông tin của bạn.
• Email và biên nhận bạn đã gửi.
• Hồ sơ của mạng quảng cáo, nếu host cũ là trang web nhà phát triển bạn đã khai báo.

Vì vậy “URL cũ đã chết nhưng trường đã được cập nhật” chỉ đúng từ phía bạn.

Ngoại lệ: app-ads.txt không được chuyển hướng

Có một trường hợp đặc biệt, và đó là trường hợp âm thầm làm bạn mất tiền. Các mạng quảng cáo tải /app-ads.txt ở thư mục gốc của trang web trong trang thông tin trên cửa hàng, và đặc tả yêu cầu tệp được phục vụ trực tiếp. Một chuyển hướng phía trước tệp là nguyên nhân thường gặp của kết quả “not found” ngay cả khi tệp hoàn toàn đúng.

Vì thế nếu host cũ là trang web nhà phát triển bạn đã khai báo, và bạn giữ nó lại làm chuyển hướng, /app-ads.txt trên host đó nên được phục vụ với mã 200 thay vì bị chuyển hướng chừng nào địa chỉ cũ còn có thể được thu thập. Mọi thứ khác có thể 301; riêng đường dẫn đó thì không.

Cần kiểm tra gì sau khi chuyển

Chạy các lệnh này khi chưa đăng nhập, trong cửa sổ riêng tư:

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

Sau đó trong các console: mọi trường URL đều mở đúng trang, và các câu trả lời Data safety / App Privacy vẫn khớp với nội dung các trang mới. Chuyển trang là thời điểm tốt để nhận ra chính sách đã lỗi thời từ hai SDK trước.

Thay đổi bạn không dễ hoàn tác

URL là một danh tính, không phải một thiết lập. Một khi nó đã nằm trong trang thông tin trên cửa hàng, nó tồn tại ở những nơi bạn không kiểm soát, vì vậy việc chuyển đáng làm một lần, có chủ đích, sang một địa chỉ bạn định giữ lâu dài. Câu hỏi cần đặt ra về bất kỳ host nào trước khi dán URL của nó vào một trường trong console không phải là “có miễn phí không” mà là “chính xác địa chỉ này hai năm nữa còn phản hồi không, và nếu không thì tôi có chuyển hướng được không”.

AppFoyer làm gì ở đây

Có hai điều được xây dựng xoay quanh đúng vấn đề này.

Địa chỉ ngẫu nhiên của ứng dụng là vĩnh viễn. Mỗi ứng dụng nhận app-xxxxxx.appfoyer.page khi tạo và địa chỉ đó không bao giờ thay đổi — kể cả khi sau này bạn nhận một tên miền phụ tùy chỉnh ở gói trả phí, địa chỉ gốc vẫn phản hồi với cùng trang web — không chuyển hướng, và không hết hạn. Địa chỉ bạn đã dán vào một trường trong console một năm trước không ngừng hoạt động chỉ vì bạn đổi tên thứ gì đó.

Tên miền phụ tùy chỉnh mà bạn thay thế sẽ được giải phóng ngay lập tức. Thay một tên và địa chỉ cũ ngừng phản hồi ngay — không chuyển hướng — và bất kỳ ai cũng có thể nhận nó, kể cả một tài khoản khác. Vì vậy đừng bao giờ đặt tên miền phụ tùy chỉnh vào một trang thông tin mà sau này bạn có thể thay đổi: địa chỉ vĩnh viễn ở trên mới là địa chỉ được đảm bảo tiếp tục hoạt động.

Và vì địa chỉ vĩnh viễn phục vụ chính trang web thay vì chuyển hướng, /app-ads.txt phản hồi với mã 200 ở đó cũng như trên địa chỉ hiện tại — quy tắc ở trên được đáp ứng mà không cần thiết lập gì.

Nguồn chính thức

• Privacy policy requirements — Trợ giúp Google Play, cho cách diễn đạt “available on an active URL”.
• User Data policy — Trợ giúp Google Play, cho quy tắc console cộng với trong ứng dụng.
• Set up app-ads.txt — Trợ giúp AdMob, về cách tìm tệp.
• App Store Connect — app information — Apple, về vị trí của các trường.