خدمة ملفات التحقق عند edge: ads.txt وsecurity.txt وAASA وassetlinks.json
بعض الملفات يجب أن تكون في root أو تحت /.well-known/. وإذا كانت CMS أو المنصة تجعل ذلك صعبًا، يمكن لـ edge response أن يقدمها مباشرة بالـ status وContent-Type الصحيحين.
أصعب ما في ملفات التحقق ليس المحتوى، بل المسار.
تحتاج ad ops إلى ads.txt في root. وتحتاج security إلى security.txt تحت /.well-known/. أما mobile فيحتاج apple-app-site-association. وAndroid يحتاج assetlinks.json. قد تكون CMS أو storefront ممتازة للصفحات العادية، لكنها تتعثر في هذه الـ URLs بالذات.
وهكذا قد يمنع ملف صغير إطلاق حملة أو تحقق تطبيق أو migration كامل.
إذا كنت تعمل أيضًا على Universal Links أو Android App Links، احتفظ بمقال كيفية إعداد Universal Links وApp Links بعد Firebase. هذا المقال يركز على تقديم الملفات نفسها.
مشكلة root و.well-known
هذه الملفات صغيرة، لكن الأنظمة التي تتحقق منها دقيقة جدًا.
أخطاء شائعة:
- CMS لا يسمح بملف في root
/.well-known/يلتقطه router التطبيق- يظهر redirect قبل الملف
- Content-Type غير صحيح
- لا أحد يملك الملف بعد الإطلاق
تفيد edge لأن بإمكانها الرد مباشرة على المسار المطلوب من دون تحويل الموقع كله إلى مشروع بنية تحتية.
لكل ملف وظيفة مختلفة
ads.txt وapp-ads.txt
هذه الملفات مخصصة للشفافية الإعلانية والتحكم في inventory. يجب أن تكون سهلة القراءة:
- مسار مباشر
200response- text plain
- owner واضح
إذا كانت خلف login أو redirect أو fallback من CMS، فقد يفشل التحقق.
security.txt
security.txt يوضح كيف يمكن الإبلاغ عن الثغرات. في كثير من الفرق تتوزع المسؤولية بين web وsecurity وlegal وplatform.
edge response يجعل path وbody وContent-Type وowner واضحة.
apple-app-site-association
Universal Links من Apple تعتمد على AASA file في المكان الصحيح. إذا فشل هذا الملف، قد يتجه الفريق إلى debug التطبيق بينما المشكلة في delivery الملف.
assetlinks.json
Android App Links يحتاج assetlinks.json صالحًا. إذا كان الملف مفقودًا أو قديمًا أو أعاد site builder كتابته، تصبح domain verification غير مستقرة.
ما الذي يجب أن تفعله edge response بشكل صحيح
لا تحتاج أن تكون ذكية. تحتاج أن تكون دقيقة.
| الملف | المسار المعتاد | المطلوب | الخطأ الشائع |
|---|---|---|---|
ads.txt | /ads.txt | 200، نص، محتوى ثابت | وضعه خلف redirect أو login |
app-ads.txt | /app-ads.txt | 200، نص، app inventory | نسيان أن التطبيق لديه inventory خاص به |
security.txt | /.well-known/security.txt أو /security.txt | 200، نص، جهة اتصال حديثة | root بلا owner |
apple-app-site-association | /.well-known/apple-app-site-association أو /apple-app-site-association | 200، JSON، body مطابق | Content-Type أو المسار خطأ |
assetlinks.json | /.well-known/assetlinks.json | 200، JSON، body مطابق | إعادة كتابة المسار بواسطة CMS |
إذا طلبت منصة ما مسارًا مختلفًا، فاتبع وثائقها. المهم أن يبقى contract قابلًا للتحقق.
لا تُخفِ هذه الملفات خلف redirects
بالنسبة لملفات التحقق، direct response يكون أفضل غالبًا.
أي hop إضافي يعني نقطة فشل إضافية. ويجعل debugging أصعب عندما ينجح التحقق أمس ويفشل اليوم.
استخدم redirect فقط إذا كانت الجهة المستهلكة تسمح به صراحةً. وإلا فالأفضل تقديم الملف مباشرة.
حدّد ownership
هذه الملفات تتعطل لأن أحدًا لا يشعر بأنه صاحبها بعد الإطلاق.
نموذج عملي:
- ad ops تملك
ads.txtوapp-ads.txt - mobile engineering تملك AASA و
assetlinks.json - security أو platform تملك
security.txt - web/platform تملك path وstatus وContent-Type
عند تغيير CMS أو إعادة إطلاق العلامة أو تحديث التطبيق، توفر هذه ownership كثيرًا من الوقت.
عملية تشغيل بسيطة
- حدّد exact path لكل ملف
- عرّف body وContent-Type
- قدّم الملف مباشرة من edge
- وثّق owner وreview date
- اختبره مع consumer الحقيقي، لا في المتصفح فقط
هذا مفيد عندما لا تريد إنشاء deploy منفصل لبضعة ملفات root.
أين يناسب UrlEdge
يمكن لـ Custom Response Tool من UrlEdge أن يقدم responses قصيرة من نوع text أو JSON مباشرة من edge.
مفيد عندما:
- لا تتعامل origin جيدًا مع root أو
.well-known - تحتاج إلى
200مباشر - يجب التحكم في Content-Type وbody
- يكون النطاق يستخدم UrlEdge أصلًا للـ redirects أو routing
هذا لا يستبدل stack الخاص بالـ deep links بالكامل. لكنه يزيل friction الخاص باستضافة الملفات.
FAQ
هل يجب أن تكون هذه الملفات على origin؟
لا. يجب أن تكون متاحة في المسار المتوقع. إذا لم يستطع origin ذلك بسهولة، فـ edge delivery حل عملي.
هل يمكن إعادة توجيهها؟
فقط إذا كانت منصة التحقق تقبل ذلك. غالبًا يكون direct response أكثر استقرارًا.
لماذا لا نتركها لـ CMS؟
كثير من CMS جيد للصفحات لكنه ضعيف مع root و/.well-known/. وهذه هي الفجوة التي يجب سدها.
هل هذا خاص بالتطبيقات فقط؟
لا. AASA وassetlinks.json تخص التطبيقات، لكن ads.txt وapp-ads.txt وsecurity.txt تخص الإعلانات والأمان.
المراجع
قدّم ملفات التحقق دون لمس origin
انشر ملفات root و.well-known من edge مع status وContent-Type وownership واضحين.
عرض edge responsesمقالات مرتبطة
عرض الكل
www وapex وwildcard forwarding من دون كسر SEO
تبدو host normalization سهلة حتى تبدأ root وwww وsubdomain وpath وquery string بالعمل وفق قواعد مختلفة. تحديد canonical host أولًا هو الأساس.
جدار حماية الروابط لحركة الإعلانات والعمولة: حظر البوتات والـ proxy والنقرات السيئة
ليس كل نقرة سيئة احتيالًا، لكن كل نقرة سيئة قد تستهلك الميزانية وتشوّه الإحالة وتقارير الشركاء. جدار حماية الروابط يحدد ما يحدث قبل وصول الزيارة إلى الوجهة.