انتقل إلى المحتوى
AppFoyer
ابدأ

الأدلة بعد الإطلاق

تغيير عنوان URL موجود بالفعل في صفحة متجر منشورة

نقل سياسة الخصوصية أو صفحة الحذف بعد نشر التطبيق، بالترتيب الذي لا يترك رابطًا معطّلًا أبدًا، ولماذا يجب أن يظل العنوان القديم يستجيب.

يمكنك تعديل حقول عناوين URL في Play Console وApp Store Connect متى شئت. الخطر ليس في التعديل — بل في الفجوة التي يكون فيها العنوان القديم معطّلًا بالفعل بينما لا تزال صفحة المتجر تشير إليه. انشر العنوان الجديد أولًا، ثم حدّث صفحة المتجر، وأبقِ العنوان القديم يعيد التوجيه.

1:11
فيديو مدته 1:11 · يُفتح على YouTube

أنجز هذا في دقائق بدلًا من ذلك

تستضيف AppFoyer الصفحات التي يتناولها هذا الدليل — سياسة الخصوصية والشروط والدعم وحذف الحساب وapp-ads.txt — على نطاق فرعي خاص بها، دون نطاق أو خادم خاص بك. تطبيق واحد مجاني، ولا شيء يشترطه المتجر يكون خلف جدار دفع أبدًا.

تمت المراجعة في 19 سبتمبر 2026. تتغير سياسات المتاجر، أحيانًا دون إشعار. كل ما يلي يربط بالتوثيق الرسمي، وتلك الصفحة — لا هذه — هي المرجع. إذا تعارضتا، فالمتجر هو المحق. هذا الدليل مترجم من الإنجليزية؛ والاقتباسات من توثيق المتاجر محفوظة بالإنجليزية الأصلية.

عاجلًا أو آجلًا ستنتقل: مضيف مجاني يُغلق، أو نطاق انتهت صلاحيته، أو شركة غيّرت اسمها، أو بنيت الموقع الحقيقي الذي طالما نويت بناءه. الحقول قابلة للتعديل، لذا فالتغيير نفسه أمر بسيط. ما يوقع الناس هو كل ما عدا ذلك مما يشير بصمت إلى العنوان القديم.

الترتيب الذي لا يكسر شيئًا

  1. انشر العنوان الجديد وتحقّق منه دون تسجيل دخول. يجب أن يكون منشورًا قبل أن يشير إليه أي شيء.
  2. اجعل العنوان القديم يعيد التوجيه إلى الجديد. لا تحذفه — بل أعد التوجيه. هذه هي الخطوة التي يتخطاها الناس، وهي التي تنقذك.
  3. حدّث حقول وحدة التحكم. Play Console → App content لعنواني سياسة الخصوصية وحذف البيانات؛ وApp Store Connect لسياسة الخصوصية وSupport URL. يطلب Google Play أن تكون السياسة «is available on an active URL» (متاحة على عنوان URL نشط) — لذا يجب ألا يشير الحقل أبدًا إلى شيء معطّل، ولو لفترة وجيزة.
  4. حدّث الروابط داخل تطبيقك. تشترط سياسة User Data في Play وجود رابط سياسة الخصوصية في Play Console وداخل التطبيق نفسه، والرابط داخل التطبيق عادةً ما يكون مكتوبًا مباشرة في بنية أصدرتها قبل أشهر. يواصل مستخدمو الإصدار القديم الوصول إلى العنوان القديم إلى أن يحدّثوا، وبعضهم لن يفعل أبدًا.
  5. أبقِ إعادة التوجيه في مكانها. ليس لأسبوع — بل إلى أجل غير مسمى، إن استطعت.

فعل ذلك بالترتيب المعاكس — تغيير الحقل أولًا، أو حذف المضيف القديم أولًا — هو ما ينتهي بك إلى صفحة متجر منشورة تشير إلى 404 أثناء سير مراجعة.

لماذا يجب أن يظل العنوان القديم يستجيب

حقل وحدة التحكم هو العنوان الذي تتحكم فيه. لكنه ليس المكان الوحيد الذي يوجد فيه العنوان القديم:

  • ملفات التطبيق المنشورة. كل نسخة مثبّتة من كل إصدار سابق ترتبط بالعنوان القديم. لا يمكنك تحديثها؛ المستخدمون يفعلون ذلك في النهاية، وبعضهم لن يفعل أبدًا.
  • ذاكرة التخزين المؤقت لصفحة المتجر ومواقع التجميع التي نسخت صفحة متجرك.
  • رسائل البريد الإلكتروني والإيصالات التي أرسلتها بالفعل.
  • سجلات الشبكات الإعلانية، إن كان المضيف القديم هو موقع المطوّر الذي أعلنته.

لذا فإن عبارة «العنوان القديم معطّل لكن الحقل محدَّث» صحيحة من جهتك فقط.

الاستثناء: يجب ألا يُعاد توجيه app-ads.txt

حالة خاصة واحدة، وهي التي تكلّف مالًا بصمت. تجلب الشبكات الإعلانية /app-ads.txt من جذر الموقع المذكور في صفحة متجرك، ويتوقع المعيار أن يُقدَّم مباشرة. وإعادة التوجيه قبله سبب متكرر لنتيجة «غير موجود» حتى عندما يكون الملف صحيحًا تمامًا.

لذا إذا كان المضيف القديم هو موقع المطوّر الذي أعلنته، وكنت تُبقيه كإعادة توجيه، فيجب أن يُقدَّم /app-ads.txt على ذلك المضيف بالحالة 200 بدلًا من إعادة توجيهه ما دام العنوان القديم قد يظل يُزحف إليه. كل ما عداه يمكن أن يُعيد التوجيه بـ 301؛ أما هذا المسار وحده فلا.

ما الذي يجب التحقق منه بعد النقل

شغّل هذه الأوامر دون تسجيل دخول، في نافذة خاصة:

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

ثم في وحدات التحكم: كل حقل URL يفتح الصفحة الصحيحة، وإجابات Data safety / App Privacy ما زالت تطابق ما تقوله الصفحات الجديدة. نقل الصفحة لحظة جيدة لتلاحظ أن السياسة تقادمت منذ آخر حزمتَي SDK أضفتهما.

التغيير الذي لا يمكنك التراجع عنه بسهولة

عنوان URL هوية، لا إعداد. فبمجرد أن يظهر في صفحة متجر يصبح موجودًا في أماكن لا تتحكم فيها، ولهذا يستحق النقل أن يتم مرة واحدة، عن قصد، إلى عنوان تتوقع الاحتفاظ به. والسؤال الذي يجب طرحه عن أي مضيف قبل لصق عنوانه في حقل وحدة التحكم ليس «هل هو مجاني» بل «هل سيظل هذا العنوان بالضبط يستجيب بعد عامين، وهل يمكنني إعادة توجيهه إن لم يفعل».

ما الذي يقدمه AppFoyer هنا

شيئان مبنيّان حول هذه المشكلة تحديدًا.

العنوان العشوائي لتطبيقك دائم. يحصل كل تطبيق على app-xxxxxx.appfoyer.page عند إنشائه، ولا يتغير هذا العنوان أبدًا — حتى لو حجزت لاحقًا نطاقًا فرعيًا مخصصًا في خطة مدفوعة، يظل العنوان الأصلي يستجيب بالموقع نفسه — دون إعادة توجيه، ودون انتهاء صلاحية. العنوان الذي لصقته في حقل وحدة التحكم قبل عام لا يتوقف عن العمل لأنك غيّرت اسم شيء ما.

النطاق الفرعي المخصص الذي تستبدله يُحرَّر فورًا. استبدل واحدًا فيتوقف العنوان القديم عن الاستجابة في الحال — دون إعادة توجيه — ويمكن لأي أحد حجزه، بما في ذلك حساب آخر. لذا لا تضع أبدًا نطاقًا فرعيًا مخصصًا في صفحة متجر قد تغيّرها لاحقًا: العنوان الدائم المذكور أعلاه هو المضمون أن يظل يعمل.

ولأن العنوان الدائم يقدّم الموقع نفسه بدلًا من إعادة التوجيه، يستجيب /app-ads.txt بالحالة 200 هناك كما على العنوان الحالي — فالقاعدة أعلاه تتحقق دون أي إعداد.

المصادر الرسمية