ما هو app-ads.txt، وأين يجب أن يوجد

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

إن كنت لا تعرض إعلانات في تطبيقك، فلا تحتاج إلى هذا الملف إطلاقًا. وإن كنت تعرضها، فالأمر يستغرق نحو عشر دقائق، تذهب تسع منها في ضبط الموضع، وهو الجزء الوحيد الذي يخطئ فيه الناس بانتظام.

ما المشكلة التي يحلها

المساحات الإعلانية يُعاد بيعها. بين تطبيقك والمعلِن توجد منصات تبادل ومعيدو بيع ووسطاء، وإلى أن ظهر ads.txt وشقيقه الخاص بالتطبيقات لم تكن هناك طريقة رخيصة يميّز بها المشتري بين “هذه فعلًا مساحات ذلك التطبيق” و”شخص ما يدّعي أنه يبيعها”. نجح الاحتيال لأن الادعاء لم يكن قابلًا للتحقق.

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

صيغة السطر

بائع مخوّل واحد في كل سطر، بثلاثة حقول مطلوبة وحقل اختياري واحد، تفصل بينها فواصل:

google.com, pub-0000000000000000, DIRECT, f08c47fec0942fa0

الحقل	المعنى
google.com	نطاق نظام الإعلانات: النطاق الرسمي للشبكة نفسها، لا نطاقك.
pub-0000000000000000	معرّف الناشر الخاص بك لدى تلك الشبكة. انسخه من لوحة التحكم لديها.
DIRECT أو RESELLER	DIRECT إن كان لديك عقد مباشر معها؛ وRESELLER إن كنت قد خوّلتها إعادة البيع.
f08c47fec0942fa0	معرّف اختياري لجهة الاعتماد، حين تنشره الشبكة.

كل ما يأتي بعد # تعليق. والأسطر التي تبدأ بـcontact= وsubdomain= وinventorypartnerdomain= وما شابهها متغيرات، لا سجلات بائعين، وتُترك كما هي.

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

أين يجب أن يوجد: الجزء الذي يحدد كل شيء

الزاحف لا يعرف اسم الحزمة لديك ولا يبحث عنك حسب التطبيق. إنه يقرأ رابط موقع المطوّر من بيانات المتجر، ويجلب /app-ads.txt من جذر ذلك النطاق. إن أخطأت في رابط بيانات المتجر، صار ملف صحيح تمامًا غير مرئي.

يوثّق AdMob قواعد الاستكشاف، وتستحق أن تُقرأ مرة بدلًا من التخمين:

• الدليل الجذري يعني “the directory following the top level domain” (وترجمته: «الدليل الذي يلي نطاق المستوى الأعلى»): example.com/app-ads.txt، لا example.com/some/path/app-ads.txt.
• الزواحف “probe up to one subdomain level from the developer website when constructing an app-ads.txt URL” (وترجمته: «تستكشف حتى مستوى واحد من النطاقات الفرعية انطلاقًا من موقع المطوّر عند تكوين رابط app-ads.txt»). فلبيانات متجر تشير إلى support.help.example.com/game، يُظهر مثال AdMob نفسه أنه يجرّب help.example.com/app-ads.txt وexample.com/app-ads.txt.
• www. وm. مستثنيان بوصفهما موضعين للنطاق الفرعي، فيُختزلان إلى النطاق نفسه.

وإلى جانب العنوان، يجب أن يكون التقديم صحيحًا بشكل ممل: HTTP 200، وContent-Type: text/plain، ولا إعادة توجيه أمامه، ولا تسجيل دخول، ولا JavaScript يعرضه، ولا شيء في robots.txt يحجبه. الملف الذي لا يظهر إلا بعد إعادة توجيه من http إلى https، أو من النطاق الجذري إلى www، فشل شائع وغير مرئي تمامًا.

افحصه كما يفحصه الزاحف:

curl -i https://your-domain.example/app-ads.txt

ما تريده هو 200 OK، وtext/plain، ولا ترويسة Location:، وأسطرك في المتن.

“لكن ليس لدي موقع”

هذه هي الحالة الطبيعية لدى المطوّر المستقل، ولهذا لا يملك كثير من التطبيقات أي ملف على الإطلاق.

المتطلب هو اسم مضيف تتحكم فيه ويقدّم ملفًا، وليس اشتراطًا لامتلاك موقع تسويقي أو نطاق لشركة أو صفحة هبوط. يقول AdMob ذلك مباشرة: “If you don’t have a suitable website that allows the uploading of an app-ads.txt file at the root level, you can use Firebase Hosting to host your app-ads.txt file.” (وترجمته: «إن لم يكن لديك موقع مناسب يسمح برفع ملف app-ads.txt على المستوى الجذري، يمكنك استخدام Firebase Hosting لاستضافة ملف app-ads.txt.») استضافة المنصات أمر متوقَّع، لا حيلة للالتفاف. ويستعرض دليل عدم وجود موقع الخيارات المتاحة.

أيًّا كان ما تستخدمه، يجب أن يظل أمران صحيحين لمدة أطول من أسبوع الإطلاق: أن يبقى العنوان كما هو، لأنه مطبوع في بيانات متجر لن تفكر فيها مجددًا، وأن يظل يقدّم نصًا عاديًا دون أن تتسلل إعادة توجيه أمامه في أول مرة “يحسّن” فيها أحدهم الإعداد.

حين تغيّر شيئًا، لا يحدث شيء فورًا

تعيد شبكات الإعلانات الزحف وفق جدولها الخاص. يذكر AdMob أنه “it can take up to 24 hours for AdMob to crawl and verify your app-ads.txt files” (وترجمته: «قد يستغرق الأمر ما يصل إلى 24 ساعة حتى يزحف AdMob إلى ملفات app-ads.txt لديك ويتحقق منها»)، والشبكات الأخرى أبطأ. الملف الذي رُفع قبل ساعة ولا يزال يظهر مفقودًا يكون في الغالب مبكرًا فحسب؛ راجع دليل عدم العثور على الملف قبل أن تغيّر أي شيء آخر.

ما الذي تفعله AppFoyer هنا

صفحة تطبيقك تقدّم app-ads.txt على نطاقها الفرعي الخاص: نص عادي، و200، ولا إعادة توجيه، مع الترويسات التي تطلبها المواصفة، ويتحقق المحرر من كل سطر أثناء كتابته، فتُكتشف الفاصلة الناقصة قبل أن يراها الزاحف. تضبط ذلك النطاق الفرعي موقعًا للمطوّر في بيانات المتجر، على مستوى واحد تحت appfoyer.page.

ويتحقق AdMob منه هناك: في أكتوبر 2026 أفاد بـ”app-ads.txt file found and verified” (وترجمته: «تم العثور على ملف app-ads.txt والتحقق منه») لتطبيقات موقع المطوّر فيها عنوان من AppFoyer. ولا تتوفر لدينا بعد أي نتيجة زحف خاصة بنا من شبكات إعلانات أخرى.

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

• Set up app-ads.txt — مساعدة AdMob. قواعد الزاحف ومثال النطاق الفرعي المقتبسان أعلاه مأخوذان من هذه الصفحة.
• ads.txt / app-ads.txt specification — IAB Tech Lab. المواصفة نفسها، والمرجع في قواعد صياغة السطر.