فهرسة التطبيقات (الروابط العميقة للتطبيقات للبحث)

الخلاصة — كانت «فهرسة التطبيقات» (App Indexing) ميزة قديمة من Google تستخرج المحتوى من تطبيق الهاتف وتعرضه في نتائج البحث. أوقفتها Google. وما يُستخدم الآن يُسمّى الروابط العميقة للتطبيقات — وهي روابط تفتح نتيجة البحث داخل التطبيق بدلًا من متصفح الهاتف إذا كان التطبيق مثبتًا لديك أصلًا. المهم: هذا لا يساعدك على تحقيق ترتيب أعلى. تواصل Google ترتيب موقعك؛ والروابط العميقة تغيّر فقط المكان الذي تصل إليه النقرة.

ما كانت عليه «فهرسة التطبيقات»

قبل سنوات، أتاحت Google لك ربط موقعك بتطبيقك الأصلي على الهاتف بحيث تعرض Google محتوى تطبيقك — وروابط تؤدي إليه مباشرة — في نتائج البحث. كان يُسمّى ذلك فهرسة التطبيقات (ثم Firebase App Indexing لاحقًا). فإذا بحثت عن شيء وكان التطبيق المطابق مثبتًا لديك، كان بإمكان Google نقلك إلى التطبيق بدلًا من صفحة ويب.

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

ما الذي حلّ محلها

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

• Android يسمّيها App Links.
• iOS يسمّيها Universal Links.

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

النقطة التي يخطئ فيها معظم الناس

الروابط العميقة للتطبيقات لا تساعدك على تحقيق ترتيب أفضل. هذه هي الخرافة التي ينبغي التخلّي عنها. تزعم مقالات قديمة أن «فهرسة تطبيقك» ترفع ترتيبك. وقد قالت Google بوضوح إن الأمر ليس كذلك — فما يزال البحث يستخدم محتوى صفحة الويب لتحديد ترتيبك. لا تغيّر الروابط العميقة إلا التجربة بعد النقرة للمستخدمين الذين لديهم تطبيقك. إنها ميزة لتسهيل الاستخدام، وليست حيلة للترتيب.

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

هل تريد التاريخ الكامل، والملفات والخطوات الدقيقة لنظامَي Android وiOS، وطريقة قياس ذلك في Search Console؟ انتقل إلى علامة التبويب Advanced.

الخلاصة — Google App Indexing (2013) ← Firebase App Indexing (2016، مع تجربة قصيرة لـ «app streaming») ← أُعلنت مهجورة نحو 2021. والبديل هو الروابط العميقة للتطبيقات: Android App Links (تُتحقق عبر ملف Digital Asset Links في /.well-known/assetlinks.json مع مرشحات النوايا android:autoVerify) وiOS Universal Links (تُتحقق عبر ملف apple-app-site-association مع استحقاق Associated Domains). ووفق إرشادات Google الصادرة في مايو 2025، لا تغيّر الروابط العميقة الفهرسة أو الترتيب — فما يزال البحث يرتب صفحة الويب — وينبغي أن يطابق هدف الرابط العميق محتوى عنوان URL على الويب. قِس سلوك روابط التطبيقات باستخدام تحليلات المنصة والتطبيق، ولا تفترض توافر تقرير مخصص لها في Search Console.

ثلاثة عصور، واسم واحد مربك

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

2013–2016 — Google App Indexing. في أكتوبر 2013 أعلنت Google أن «Googlebot can now index content in your Android app» (ترجمة) «يمكن لـ Googlebot الآن فهرسة المحتوى في تطبيق Android لديك»، وأنها ستعرض روابط عميقة إلى التطبيق «مباشرةً في نتائج البحث عندما تراه ملائمًا… وإذا كان التطبيق مثبتًا لدى المستخدم». كنت تعلن عن محتوى التطبيق عبر خريطة موقعك الحالية وWebmaster Tools. كانت هذه Google تزحف داخل التطبيقات، بالطريقة التي تزحف بها إلى صفحات الويب.

2016–~2021 — Firebase App Indexing. بعد استحواذ Google على Firebase في 2014، أُعيدت تسمية App Indexing إلى Firebase App Indexing تقريبًا في مؤتمر Google I/O لعام 2016. وأضافت دعم iOS، وتجربةً سُمّيت app streaming لفترة — وهي زر «Try Now» يتيح للمستخدمين تشغيل تطبيق غير مثبت داخل المتصفح لبضع دقائق مباشرةً من نتيجة بحث. كانت app streaming تجربة محدودة من حقبة 2015–2016، وقد اختفت منذ زمن؛ فلا تبنِ خطتك عليها.

~2021–الحاضر — مهجور. تحمل واجهة AppIndexApi وسم deprecated في وثائق Android المرجعية الخاصة بـ Google. وتذكر وثائق Firebase الحالية أن Firebase App Indexing «is no longer the recommended way of indexing content for display as suggested results in Google Search App,» (ترجمة) «لم تعد الطريقة الموصى بها لفهرسة المحتوى لعرضه كاقتراحات في تطبيق Google Search»، مع تنبيه صريح إلى أن «the Google Search App for Android no longer uses local content indexed via Firebase App Indexing to provide results to users.» (ترجمة) «تطبيق Google Search لنظام Android لم يعد يستخدم المحتوى المحلي المفهرس عبر Firebase App Indexing لتقديم النتائج للمستخدمين». وتوجّهك Firebase الآن إلى App Links وUniversal Links بوصفهما المسار الموصى به. حدث الانتقال في 2021 — فإشعار الإيقاف موجود في نسخة أرشيفية من أكتوبر 2022 لكنه غائب عن نسخة أكتوبر 2020.

ما الذي حلّ محل فهرسة التطبيقات: الروابط العميقة للتطبيقات

الروابط العميقة هي، بحسب تعبير Google، «special URIs that take users beyond your mobile app’s homepage, leading them directly to specific in-app content» (ترجمة) «معرّفات URI خاصة تتجاوز الصفحة الرئيسية لتطبيق الهاتف وتقود المستخدمين مباشرةً إلى محتوى محدد داخل التطبيق». والتحول الذهني الأساسي عن النموذج القديم هو أن هذه عملية تحقق وتوجيه تُدار على مستوى نظام التشغيل والمتصفح — وليست مسار فهرسة تديره Google. لا يوجد هنا شيء «يُرسل إلى فهرس».

روابط تطبيق Android (Digital Asset Links / assetlinks.json)

إن Android App Links، وفقًا لـ Google، هي «an enhanced deep linking capability that verifies deep links to your own website by establishing a trusted association between your app and your website. After they are verified, deep links to your website can immediately open corresponding content in your app, without requiring the user to select your app from a disambiguation dialog» (ترجمة) «قدرة محسّنة للروابط العميقة تتحقق من الروابط العميقة إلى موقعك أنت عبر إنشاء ارتباط موثوق بين تطبيقك وموقعك. وبعد التحقق منها، يمكن للروابط العميقة إلى موقعك فتح المحتوى المطابق مباشرةً في تطبيقك، من دون مطالبة المستخدم باختيار تطبيقك من مربع حوار إزالة الالتباس». وتدعمها إصدارات Android 6 والإصدارات الأحدث، وتصفها Google بأنها «نهج موصى به» للروابط العميقة إلى موقعك أنت.

ملف Digital Asset Links هو حلقة التحقق. عندما تضع android:autoVerify="true" في مرشح نوايا ويكون التطبيق مثبتًا، فإن «Android queries the corresponding websites for the Digital Asset Links file at https://hostname/.well-known/assetlinks.json» (ترجمة) «يستعلم Android من المواقع المقابلة عن ملف Digital Asset Links في المسار https://hostname/.well-known/assetlinks.json». ويسرد ملف JSON ذلك حزمة التطبيق وبصمة شهادة التوقيع المسموح لها بالتعامل مع روابط نطاقك. ويضيف Android 15 Dynamic App Links، ما يتيح تحسين سلوك مطابقة عناوين URL من دون شحن إصدار جديد من التطبيق.

هناك حدّان مهمان للإصدار والتوقيع ينبغي الانتباه إليهما. أولًا، تعمل Dynamic App Links على توسيع ارتباط البيان الأساسي بدلًا من استبداله — ففي إصدارات Android الأقدم من 15، يظل التحقق يجري اعتمادًا على تطابق البيان القياسي وassetlinks.json وحده. ثانيًا، يفشل التحقق كليًا، لا جزئيًا، إذا لم تطابق بصمة شهادة التوقيع المدرجة في assetlinks.json هوية التوقيع الفعلية للبناء المثبت تطابقًا تامًا — فالبناء التجريبي الموقّع بمفتاح يختلف عن الإدخال في assetlinks.json لن يتحقق أبدًا، حتى لو كان كل حقل آخر صحيحًا.

التمييز الذي يستحق أن يبقى واضحًا: يستخدم الرابط العميق الأساسي في Android مرشحات النوايا، لكنه قد يطلق مربع حوار إزالة الالتباس «بأي تطبيق تريد فتح هذا؟». أما App Links فتضيف تحقق Digital Asset Links، بحيث يفتح النطاق المتحقق منه مباشرةً في تطبيقك بلا مربع حوار.

iOS Universal Links (apple-app-site-association)

المقابل في Apple هو Universal Links. تقول Apple: «When users tap or click a universal link, the system redirects the link directly to your app without routing through the person’s default web browser or your website… because universal links are standard HTTP or HTTPS links, one URL works for both your website and your app. If the person hasn’t installed your app, the system opens the URL in their default web browser» (ترجمة) «عندما ينقر المستخدمون على رابط عام أو يضغطون عليه، يوجّه النظام الرابط مباشرةً إلى تطبيقك من دون المرور بمتصفح الويب الافتراضي للشخص أو بموقعك… ولأن الروابط العامة هي روابط HTTP أو HTTPS قياسية، يعمل عنوان URL واحد لكل من موقعك وتطبيقك. وإذا لم يكن الشخص قد ثبّت تطبيقك، يفتح النظام عنوان URL في متصفح الويب الافتراضي لديه».

ملف التحقق هنا هو apple-app-site-association المستضاف على خادم الويب لديك: «When someone installs your app, the system checks a file stored on your web server to verify that your website allows your app to open URLs on its behalf» (ترجمة) «عندما يثبّت شخص تطبيقك، يفحص النظام ملفًا مخزنًا على خادم الويب لديك ليتحقق من أن موقعك يسمح لتطبيقك بفتح عناوين URL نيابةً عنه». وعلى جانب التطبيق تحتاج إلى استحقاق Associated Domains المطابق للنطاقات الموجودة في ذلك الملف. والمبدأ هو نفسه في Android — حلقة ثقة بين الموقع والتطبيق يفحصها الجهاز، لا إشارة إلى ترتيب البحث.

لا يضمن ملف apple-app-site-association صالح واستحقاق مطابق بصورة صحيحة أن تفتح كل نقرة التطبيق، رغم ذلك. توثّق Apple حالات حقيقية يظل فيها Universal Link مفتوحًا في Safari رغم عمل الارتباط — مثل النقر على الرابط من داخل Safari أثناء تصفح النطاق نفسه أصلًا، أو عندما يكون الشخص قد اختار سابقًا إبقاء روابط ذلك النطاق مفتوحة في المتصفح. وعندما لا يكون التطبيق مثبتًا فعلًا، أو لا يطابق الارتباط، فمن المفترض أن يعود رابط HTTP(S) القياسي إلى الفتح في المتصفح بدلًا من الوصول إلى طريق مسدود بسبب مخطط مخصص معطوب — فهذا الرجوع هو عمل النظام كما صُمّم، وليس خطأً ينبغي مطاردته.

يدعم Google Search المنصتين كلتيهما كهدفين للروابط العميقة.

هل تؤثر الروابط العميقة للتطبيقات في الترتيب؟ (لا — وهذه هي العبارة الدقيقة)

هذا هو التصحيح الأهم في الموضوع كله، لأن صفحات تشرح الترتيب ما تزال تخطئ فيه. ستجد مقالات تزعم أمورًا مثل «App Indexing will influence ranking… whether or not the user has your app installed» (ترجمة) «ستؤثر فهرسة التطبيقات في الترتيب… سواء كان التطبيق مثبتًا لدى المستخدم أم لا»، أو «Google will use the content within your app as a signal in ranking» (ترجمة) «ستستخدم Google المحتوى داخل تطبيقك إشارةً في الترتيب». هذه الادعاءات خاطئة، وتقول مقالة Google الخاصة بمايو 2025 ذلك مباشرةً:

“Adding deep links to your website connects the website’s URLs with the relevant app pages. It doesn’t change how Google Search shows your content; Search continues to use the content of your web pages for indexing and ranking. App deep links enable users to go from Search results directly to the corresponding app page (if installed), resulting in a better user experience.” (ترجمة) «تصل إضافة الروابط العميقة إلى موقعك عناوين URL الخاصة بالموقع بصفحات التطبيق ذات الصلة. ولا تغيّر طريقة عرض Google Search لمحتواك؛ فما يزال البحث يستخدم محتوى صفحات الويب الخاصة بك للفهرسة والترتيب. وتمكّن الروابط العميقة للتطبيقات المستخدمين من الانتقال مباشرةً من نتائج البحث إلى صفحة التطبيق المطابقة (إذا كان مثبتًا)، ما ينتج تجربة مستخدم أفضل.”

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

الشرط الحقيقي الوحيد: تطابق المحتوى

هناك قاعدة جوهرية واحدة بالضبط، وهي تتعلق بالصدق مع المستخدم. تقول Google:

“Because Search uses your web page content for indexing and ranking, you should only add deep links in cases where the app page contains the same content as the corresponding web page. Otherwise, the title and snippet shown for the page in Google Search could mislead users about the content they will see after they click. Layout or other UX differences between app pages and the corresponding web pages are OK, as long as the content matches.” (ترجمة) «لأن البحث يستخدم محتوى صفحة الويب للفهرسة والترتيب، لا ينبغي لك إضافة روابط عميقة إلا عندما تحتوي صفحة التطبيق على المحتوى نفسه الموجود في صفحة الويب المقابلة. وإلا فقد يضلل العنوان والمقتطف المعروضان للصفحة في Google Search المستخدمين بشأن المحتوى الذي سيرونه بعد النقر. ولا بأس باختلاف التخطيط أو تجربة المستخدم بين صفحات التطبيق وصفحات الويب المقابلة ما دام المحتوى متطابقًا.»

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

كيف تنفّذه اليوم

Android: استخدم App Links. اربط تطبيقك بموقعك في بيان التطبيق (مرشحات النوايا مع android:autoVerify="true")، ثم انشر /.well-known/assetlinks.json على موقعك مع إدراج اسم حزمة التطبيق وبصمة شهادة التوقيع. يتحقق Android من الارتباط عند التثبيت. ويساعدك App Links Assistant في Android Studio وصفحة Deep Links في Play Console على إنشاء الإعداد والتحقق منه.

iOS: نفّذ Universal Links. انشر ملف apple-app-site-association على خادم الويب لديك يصف المسارات التي ترتبط بتطبيقك، وأضف استحقاق Associated Domains إلى تطبيقك للنطاقات المطابقة. وتشرح إرشادات Apple لتصحيح Universal Links حالات الفشل الشائعة (نوع محتوى خاطئ للملف، أو استحقاق مفقود، أو ارتباط مخزّن مؤقتًا).

لا يُزحف إلى أي من الملفين داخل «فهرس بحث» بالطريقة التي أوحت بها فهرسة التطبيقات — إنهما حلقات ثقة يفحصها الجهاز. إذا أخطأت فيهما، تعود الروابط ببساطة إلى المتصفح؛ وإذا أصبتهما، يوجّه المستخدمون الذين ثبّتوا التطبيق إلى داخله.

فحص ملف الارتباط الأدنى

curl -sI https://example.com/.well-known/assetlinks.json
curl -sI https://example.com/.well-known/apple-app-site-association

ينبغي أن تعيد نقطتا النهاية 200 من دون إعادة توجيه وأن تعرضا استجابة JSON المتوقعة. وتحتوي عدسة Scripts على فحوص موسعة لنوع المحتوى، وإعادة التوجيه، وPowerShell، وDevTools، وbookmarklet.

كيف تقيسه: مرشح Android app في Search Console

تعرض Google أداء الروابط العميقة للتطبيقات محليًا: «Search Console includes performance of your site’s app deep links for Android. In the Performance report, you can use the Android App Search appearance filter to see when your Android app deep links are found and shown to users.» (ترجمة) «تتضمن Search Console أداء الروابط العميقة لموقعك على Android. وفي تقرير الأداء، يمكنك استخدام مرشح مظهر البحث Android App لرؤية متى تُعثر على روابط تطبيقك العميقة وتُعرض للمستخدمين». وهذا يمنحك النقرات ومرات الظهور وCTR والموضع للنتائج التي ظهر فيها الرابط العميق لتطبيق Android — وهي الطريقة الحالية والملموسة لمعرفة ما إذا كان لأي من ذلك أثر. (أُضيف هذا المرشح في 2019؛ وما يزال الأداة الحالية وفق مقالة Google لعام 2025.)

لكن افصل بين الوظيفتين. فمرشح Search Console هو تقرير حركة مرور/مظهر — خاص بـ Android، ويعتمد على أن تعرض Google معالجة الرابط العميق للتطبيق فعليًا لاستعلام معين، وليس دليلًا بحد ذاته على فهرسة أي شيء أو ترتيبه. والتأكد من أن الرابط العميق يعمل تقنيًا تمرين مختلف: جلب ملفات الارتباط واختبار الانتقال بالنقر على أجهزة حقيقية (انظر علامتَي Scripts وValidation Tests). لا تتعامل مع تقرير Search Console الهادئ كدليل على أن إعدادك معطوب، ولا تتعامل مع النقرات في التقرير كإشارة SEO — فهو يخبرك بحجم التوجيه، لا بالترتيب.

Bing والروابط العميقة للتطبيقات

لا تفترض التكافؤ بين Google وBing هنا. فقد أدار Bing برنامج «app linking» متمحورًا حول Windows ابتداءً من أبريل 2014، وكان يستهدف Windows 8,1 وWindows Phone — لكن تلك الصفحات ماتت الآن (فعنوان المطور يعيد 404، أي خطأ عدم العثور، ومنشورات المدونة تعيد التوجيه إلى الصفحة العامة للمدونة)، كما أُوقف Windows Phone نفسه. ولا يوجد حاليًا بديل منشور من Bing لإرشادات Google لعام 2025 الخاصة بالروابط العميقة للتطبيقات. والخلاصة العملية: ما تزال App Links وUniversal Links تعملان في Bing/Edge على الهاتف لأنهما معياران على مستوى نظام التشغيل والمتصفح، وليسا شيئًا يحتاج محرك البحث إلى الاشتراك فيه — لذا تنفذهما بالطريقة نفسها بغض النظر عن المحرك. لكن لا توجد وثيقة من Bing يمكنك الاستناد إليها.

أشياء قديمة ما زلت تراها في البرية

تسبب تقنيتان متجاورتان بعض الالتباس، لذا سمِّهما ثم واصل:

• ترميز potentialAction / ViewAction في schema.org مع هدف رابط عميق android-app://. هذه تقنية قديمة مرتبطة بعصر فهرسة التطبيقات السابق. قد تجدها ما تزال في قواعد الشيفرة وفي مفردات الإجراءات في schema.org، لكن توصية Google الحالية هي إعداد App Links / Universal Links، لا هذا الترميز. تعامل معها بوصفها «شيئًا قد تراه ما يزال»، لا توصية.
• Firebase Dynamic Links منتج Firebase مختلف ومهجور على نحو منفصل — خدمة لاختصار عناوين URL / والروابط العميقة المؤجلة لأغراض الإسناد التسويقي، وليست نظام فهرسة محتوى التطبيقات. ويجري إنهاؤها هي الأخرى، كما تشير إرشادات ترحيلها إلى App Links وUniversal Links. لا تخلط بين عمليتي الإيقاف.

النموذج الواضح الذي ينبغي أن تغادر به: (1) نظام الزحف والبث القديم لـ Google App Indexing / Firebase App Indexing = منتهٍ؛ (2) الروابط العميقة عبر App Links / Universal Links = حالية، للتوجيه وتجربة المستخدم فقط، بلا أثر في الترتيب؛ (3) برنامج Bing القديم لربط التطبيقات في حقبة Windows = منتهٍ أيضًا، ولا بديل موثق له.

ملخص بالذكاء الاصطناعي

خلاصة مركزة للنسخة المتقدمة:

• فهرسة التطبيقات مهجورة. Google App Indexing (2013) ← Firebase App Indexing (2016) ← أُعلنت مهجورة نحو 2021. تحمل AppIndexApi وسم deprecated في وثائق Google؛ ولم يعد تطبيق Google Search يستخدم محتوى Firebase App Indexing.
• ما حلّ محلها: الروابط العميقة للتطبيقات — Android App Links (تُتحقق عبر ملف Digital Asset Links في /.well-known/assetlinks.json مع مرشحات النوايا android:autoVerify) وiOS Universal Links (تُتحقق عبر apple-app-site-association مع استحقاق Associated Domains). هذه عملية تحقق وتوجيه على مستوى نظام التشغيل والمتصفح، وليست فهرسًا تديره Google.
• الروابط العميقة لا تؤثر في الترتيب. وفق مقالة Google في مايو 2025، فهي «don’t change how Google Search shows your content; Search continues to use the content of your web pages for indexing and ranking» (ترجمة) «لا تغيّر طريقة عرض Google Search لمحتواك؛ فما يزال البحث يستخدم محتوى صفحات الويب الخاصة بك للفهرسة والترتيب». وهي لا توجّه المستخدم المثبت التطبيق إلا إلى داخله بعد النقرة.
• القاعدة الحقيقية الوحيدة هي تطابق المحتوى: لا تربط بعمق إلا شاشة تطبيق تعرض المحتوى نفسه الموجود في صفحة الويب (اختلاف التخطيط وتجربة المستخدم مقبول).
• قِس ذلك باستخدام مرشح مظهر البحث Android app في Search Console — لكنه تقرير حركة مرور، وليس دليلًا على عمل الارتباط التقني أو على اختلاف الترتيب؛ فتحقق من الارتباط نفسه باختبارات الجهاز والملف.
• لا تضمن أي من المنصتين فتح التطبيق عند كل نقرة متحقَّق منها. يفشل تحقق Android كليًا عند عدم تطابق شهادة التوقيع (وتوسّع Dynamic App Links في Android 15 تطابق البيان ولا تستبدله)؛ وتوثق iOS حالات مشروعة — تصفح Safari للنطاق نفسه، أو اختيار المستخدم سابقًا — يظل فيها Universal Link مفتوحًا في المتصفح رغم عمل الارتباط.
• Bing لا يملك إرشادات مكافئة حالية؛ وبرنامجه القديم في حقبة Windows انتهى، لكن App Links وUniversal Links ما زالت تعمل في Edge لأنها معايير على مستوى نظام التشغيل.
• لا تخلط بين فهرسة التطبيقات وFirebase Dynamic Links (منتج منفصل مهجور بدوره)، ولا تتعامل مع ترميز potentialAction/ViewAction بوصفه أفضل ممارسة حالية.

الوثائق الرسمية

وثائق المصادر الأولية من Google وAndroid وApple.

Google — الإرشادات الحالية

• الروابط العميقة للتطبيقات: ربط موقعك بتطبيقك (2 مايو 2025) — الشرح الحالي المعتمد: ما الذي تفعله الروابط العميقة، وبيان عدم تأثيرها في الترتيب، وتطابق المحتوى، ومرشح Search Console.
• Firebase App Indexing — الصفحة الحالية التي تحمل إشعار الإيقاف والإحالة إلى App Links / Universal Links.

Google — تاريخيًا (لفهم ما أُوقف)

• فهرسة التطبيقات مثل المواقع (31 أكتوبر 2013) — الإعلان الأصلي عن فهرسة التطبيقات.

Android

• حول الروابط العميقة — الروابط العميقة وApp Links ونموذج التحقق (مُحدّث في 2026-06-18).
• التحقق من Android App Links — android:autoVerify ومتطلب Digital Asset Links / assetlinks.json.

Apple

• السماح للتطبيقات والمواقع بالربط بمحتواك — نظرة عامة على Universal Links ونموذج التحقق من ملف الخادم.
• دعم النطاقات المرتبطة — ملف apple-app-site-association واستحقاق Associated Domains.

المعيار الصناعي (ليس خاصًا بـ Google)

• ViewAction / Actions (schema.org) — مفردات potentialAction/ViewAction القديمة؛ مفيدة للسياق، وليست توصية حالية من Google.

اقتباسات من المصدر

تصريحات موثقة من Google وAndroid وApple. كل رابط من Google/Android هو رابط عميق يقفز إلى المقطع المقتبس في صفحة المصدر.

Google — الإعلان الأصلي عن فهرسة التطبيقات (2013)

• “Just like it crawls and indexes websites, Googlebot can now index content in your Android app… If both the webpage and the app contents are successfully indexed, Google will then try to show deep links to your app straight in our search results when we think they’re relevant for the user’s query and if the user has the app installed.” (ترجمة) «كما يزحف إلى المواقع ويفهرسها، يستطيع Googlebot الآن فهرسة المحتوى في تطبيق Android لديك… وإذا فُهرس محتوى صفحة الويب ومحتوى التطبيق بنجاح، فستحاول Google بعد ذلك عرض روابط عميقة إلى تطبيقك مباشرةً في نتائج البحث عندما نراها ملائمة لاستعلام المستخدم وإذا كان التطبيق مثبتًا لديه». — Lawrence Chang، مدير المنتج في Google. الانتقال إلى الاقتباس

Google — Firebase App Indexing مهجور (الوثائق الحالية)

• “Firebase App Indexing is no longer the recommended way of indexing content for display as suggested results in Google Search App.” (ترجمة) «لم تعد Firebase App Indexing الطريقة الموصى بها لفهرسة المحتوى لعرضه كاقتراحات في تطبيق Google Search». الانتقال إلى الاقتباس

Google — الروابط العميقة لا تغيّر الترتيب (مايو 2025)

• “It doesn’t change how Google Search shows your content; Search continues to use the content of your web pages for indexing and ranking.” (ترجمة) «لا يغيّر ذلك طريقة عرض Google Search لمحتواك؛ فما يزال البحث يستخدم محتوى صفحات الويب الخاصة بك للفهرسة والترتيب». — John Mueller (علاقات البحث في Google) وSabs (علاقات مطوري Android). الانتقال إلى الاقتباس
• “You should only add deep links in cases where the app page contains the same content as the corresponding web page.” (ترجمة) «لا ينبغي لك إضافة روابط عميقة إلا في الحالات التي تحتوي فيها صفحة التطبيق على المحتوى نفسه الموجود في صفحة الويب المقابلة». الانتقال إلى الاقتباس

Android — App Links وملف التحقق

• “Android App Links is an enhanced deep linking capability that verifies deep links to your own website by establishing a trusted association between your app and your website.” (ترجمة) «Android App Links قدرة محسّنة للروابط العميقة تتحقق من الروابط العميقة إلى موقعك أنت عبر إنشاء ارتباط موثوق بين تطبيقك وموقعك». — Android Developers. الانتقال إلى الاقتباس
• “Android queries the corresponding websites for the Digital Asset Links file at https://hostname/.well-known/assetlinks.json.” (ترجمة) «يستعلم Android من المواقع المقابلة عن ملف Digital Asset Links في المسار https://hostname/.well-known/assetlinks.json». الانتقال إلى الاقتباس

Apple — Universal Links

• “When users tap or click a universal link, the system redirects the link directly to your app without routing through the person’s default web browser or your website… If the person hasn’t installed your app, the system opens the URL in their default web browser.” (ترجمة) «عندما ينقر المستخدمون على رابط عام أو يضغطون عليه، يوجّه النظام الرابط مباشرةً إلى تطبيقك من دون المرور بمتصفح الويب الافتراضي للشخص أو بموقعك… فإن النظام يفتح عنوان URL في متصفح الويب الافتراضي للشخص إذا لم يكن التطبيق مثبتًا لديه». — وثائق Apple للمطورين، «السماح للتطبيقات والمواقع بالربط بمحتواك».

هل ينبغي لك إعداد روابط عميقة للتطبيق؟

مسار سريع للإجابة عن سؤال «هل أحتاج إلى هذا أصلًا؟» — لأن الإجابة الصادقة هي «لا» بالنسبة إلى كثير من المواقع.

1. هل لديك تطبيق أصلي للهاتف يعكس محتوى موقعك؟

• لا يوجد تطبيق ← توقّف. لا شيء يمكن ربطه بعمق. فهرسة التطبيقات / الروابط العميقة غير ذات صلة بك. (وإذا وجدت «فهرسة التطبيقات» في قائمة تدقيق، فاحذف ذلك السطر — فقد أُوقفت.)
• نعم ← تابع.

2. هل تفعل هذا من أجل الترتيب؟

• نعم ← توقّف وأعد القراءة. لا تؤثر الروابط العميقة في الفهرسة أو الترتيب. إذا كان الظهور في SEO هو الهدف، فاستثمر في صفحة الويب على الهاتف، لا في بنية الروابط العميقة.
• لا — أريد توجيه المستخدمين الذين ثبّتوا التطبيق إلى داخله ← تابع.

3. هل تعرض شاشة التطبيق المحتوى نفسه الموجود في صفحة الويب المطابقة؟

• لا (محتوى مختلف) ← لا تربط عنوان URL هذا بعمق. فعدم التطابق يضلل المستخدمين، لأن المقتطف بُني من صفحة الويب. أصلح التطابق أولًا (اختلاف التخطيط وتجربة المستخدم مقبول — اختلاف المحتوى غير مقبول).
• نعم ← تابع.

4. ما المنصة أو المنصات؟

• Android ← App Links: مرشحات نوايا android:autoVerify + ملف Digital Asset Links في /.well-known/assetlinks.json.
• iOS ← Universal Links: ملف apple-app-site-association على خادمك + استحقاق Associated Domains.
• كلتاهما ← نفّذ الاثنين؛ فهما مستقلان.

5. كيف ستعرف أنه يعمل؟

• افحص مرشح مظهر البحث Android app في Search Console لنظام Android.
• اختبر الانتقال الفعلي بالنقر على أجهزة حقيقية، وتحقق من ملفات الارتباط (App Links Assistant على Android؛ وإرشادات Apple لتصحيح Universal Links على iOS).

قاعدة عامة: الروابط العميقة ترقية لتجربة المستخدم والتوجيه في المواقع التي تملك تطبيقًا حقيقيًا يطابق المحتوى — وليست مشروعًا لرفع ترتيب SEO، وليست شيئًا تضيفه لمجرد أن دليلًا قديمًا ذكر «فهرسة التطبيقات».

قائمة تدقيق لإعداد الروابط العميقة للتطبيقات

لا صلة لها إلا إذا كان لديك تطبيق أصلي يعكس محتوى موقعك:

• تأكدت من أنك لا تتوقع رفعًا في الترتيب — فالروابط العميقة تغيّر التوجيه، لا الترتيب.
• تم التحقق من تطابق المحتوى: تعرض كل شاشة تطبيق مرتبطة بعمق المحتوى نفسه الموجود في صفحة الويب المقابلة (اختلاف التخطيط وتجربة المستخدم مقبول).
• Android: تستخدم مرشحات النوايا android:autoVerify="true" لنطاقك.
• Android: نُشر /.well-known/assetlinks.json ويُخدم عبر HTTPS بنوع المحتوى الصحيح، مع إدراج اسم حزمة تطبيقك وبصمة شهادة التوقيع.
• iOS: نُشر apple-app-site-association على خادمك (بنـوع محتوى صحيح ومن دون إعادة توجيه) مع أنماط المسارات المناسبة.
• iOS: أُضيف استحقاق Associated Domains إلى التطبيق، وهو يطابق النطاقات في ملف الارتباط.
• اختُبر الانتقال الفعلي بالنقر على أجهزة Android وiOS مادية (في حالات تثبيت التطبيق وعدم تثبيته).
• تمت مراجعة مرشح مظهر البحث Android app في Search Console لمرات الظهور والنقرات بعد الإطلاق.
• أُزيلت كل الإشارات المهجورة — وسوم خرائط موقع App Indexing القديمة، أو استدعاءات Firebase App Indexing SDK، أو ترميز potentialAction/android-app:// الذي كنت تعتمد عليه بوصفه الآلية الوحيدة.

أنماط مضادة ينبغي تجنبها

• التعامل مع فهرسة التطبيقات باعتبارها حالية. تحمل AppIndexApi وسم deprecated، ولم يعد تطبيق Google Search يستخدم محتوى Firebase App Indexing. فإذا أخبرك دليل أو إضافة أو قائمة تدقيق «بتمكين فهرسة التطبيقات»، فهو قديم.
• توقع دفعة في الترتيب. أكثر الخرافات تكرارًا في صفحات الترتيب القديمة هي أن «فهرسة تطبيقك تؤثر في الترتيب». تقول Google العكس — فالـ Search يرتب صفحة الويب، والروابط العميقة لا تغيّر ذلك.
• الربط بعمق إلى محتوى غير مطابق. إرسال مستخدم نقر على مقتطف صفحة ويب إلى شاشة تطبيق ذات محتوى مختلف. تحذر Google صراحةً من أن هذا يضلل المستخدمين. يتعلق التطابق بالمحتوى، لا بالمظهر.
• مطاردة «app streaming». اختفت ميزة المعاينة «Try Now» لتطبيق غير مثبت، التي كانت تجربة في 2015–2016. لا تصمم اعتمادًا عليها.
• الخلط بين Firebase App Indexing وFirebase Dynamic Links. منتجان مختلفان، وكلاهما مهجور، ويحل كل منهما مشكلة مختلفة (فهرسة المحتوى مقابل اختصار عناوين URL/الإسناد). وكلاهما يشير الآن إلى App Links / Universal Links.
• افتراض التكافؤ مع Bing. انتهى برنامج Bing القديم لربط التطبيقات في حقبة Windows من دون بديل موثق. وما تزال App Links وUniversal Links تعمل في Edge لأنها معايير على مستوى نظام التشغيل — لكن لا توجد وثيقة من Bing تتبعها.
• تخطي التحقق ثم التساؤل عن سبب «عدم عمله». يؤدي نوع المحتوى الخاطئ، أو إعادة التوجيه في ملف الارتباط، أو الاستحقاق المفقود إلى إعادتك بصمت إلى المتصفح. فالملفات حلقة مصافحة صارمة، وليست اقتراحًا.

حالات فشل شائعة في الروابط العميقة للتطبيقات

ما يزال رابط الويب يفتح في المتصفح على Android

العَرَض: لا يستولي تطبيق مثبت على عنوان URL مطابق عبر HTTPS. السبب المحتمل: فشل التحقق من النطاق لأن المضيف في البيان، أو اسم الحزمة، أو بصمة شهادة التوقيع، أو استجابة assetlinks.json غير متطابقة. الإصلاح: افحص هوية توقيع البناء المثبت، واجلب ملف الارتباط مباشرةً، وأعد تشغيل التحقق من روابط Android قبل اختبار النقرة مرة أخرى.

يفتح Universal Link في Safari بدلًا من تطبيق iOS

العَرَض: يعمل عنوان HTTPS نفسه على الويب لكنه يتجاوز التطبيق المثبت. السبب المحتمل: لا يصرّح استحقاق Associated Domains أو مسارات apple-app-site-association بعنوان URL — لكن افحص أولًا الحالات الموثقة التي لا تعني عطلًا: تشرح إرشادات Apple نفسها أن الروابط التي يُنقر عليها داخل Safari في النطاق نفسه، أو نطاقًا اختار الشخص سابقًا إبقاءه مفتوحًا في المتصفح، تُفتح في المتصفح بصورة متوقعة وليست إخفاقات تحقق. الإصلاح: تحقق من استحقاق النطاق، وتوافر الملف، وقواعد المسارات، ثم أعد الاختبار بعد إعادة التثبيت أو تحديث حالة الارتباط في الجهاز — واستبعد سلوك النطاق نفسه أو اختيار المستخدم السابق قبل افتراض أن الارتباط معطوب.

يفتح التطبيق الشاشة الخطأ

العَرَض: ينجح التحقق لكن يصل التطبيق إلى الصفحة الرئيسية أو إلى محتوى غير مطابق. السبب المحتمل: ارتباط نظام التشغيل صحيح، لكن تعيين المسار في التطبيق غير مكتمل. الإصلاح: اربط المسار والمعلمات الواردة بالشاشة المقابلة، وحافظ على رجوع آمن إلى الويب، وقارن محتوى التطبيق بصفحة الويب التي قدمت مقتطف البحث.

الروابط العميقة للتطبيقات — ورقة غش

آنذاك مقابل الآن

ملفات التحقق

حقائق سريعة

• تغيّر الروابط العميقة التوجيه بعد النقرة، لا الفهرسة أو الترتيب.
• لا تربط بعمق إلا شاشات التطبيق ذات المحتوى المطابق لصفحة الويب.
• يحتاج Android إلى مرشحات نوايا android:autoVerify="true".
• يحتاج iOS إلى استحقاق Associated Domains.
• قِس ذلك باستخدام مرشح مظهر البحث Android app في GSC.
• Bing: لا توجد إرشادات مكافئة حالية؛ وما تزال المعايير تعمل في Edge.

افحص ملفات الارتباط لديك

تفشل الروابط العميقة بصمت، لذلك أسرع خطوة لتصحيحها هي التأكد من وجود ملفَي التحقق، وأنهما يعيدان 200 ويقدمان نوع المحتوى الصحيح.

macOS / Linux — جلب الملفات وفحصها

# Android — Digital Asset Links. Expect HTTP 200 and application/json.
curl -sI https://example.com/.well-known/assetlinks.json | grep -iE "HTTP/|content-type"
curl -s https://example.com/.well-known/assetlinks.json | head

# iOS — apple-app-site-association. Must be 200, JSON, and NOT redirected.
# -L follows redirects; if the final URL differs, that's a problem for iOS.
curl -sIL -o /dev/null -w "final: %{url_effective}  code: %{http_code}\n" \
  https://example.com/.well-known/apple-app-site-association

Windows (PowerShell) — جلب الملفات وفحصها

# Android
(Invoke-WebRequest -Uri "https://example.com/.well-known/assetlinks.json").Headers["Content-Type"]

# iOS — confirm status and that it isn't redirecting away
Invoke-WebRequest -Uri "https://example.com/.well-known/apple-app-site-association" -MaximumRedirection 0

وحدة تحكم Browser DevTools — فحص سريع لإمكانية الوصول

// Paste in the console on your own domain. Both should log ok:true.
["/.well-known/assetlinks.json", "/.well-known/apple-app-site-association"]
  .forEach(async p => {
    const r = await fetch(p, { redirect: "manual" });
    console.log(p, "ok:", r.ok, "type:", r.headers.get("content-type"));
  });

Bookmarklet — فحص الموقع الحالي بنقرة واحدة

javascript:(async()=>{for(const p of["/.well-known/assetlinks.json","/.well-known/apple-app-site-association"]){try{const r=await fetch(p,{redirect:"manual"});alert(p+"\nstatus: "+r.status+"\ntype: "+(r.headers.get("content-type")||"—"));}catch(e){alert(p+" — fetch failed: "+e.message);}}})();

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

أدوات إعداد الروابط العميقة وتصحيحها

• Android Studio — App Links Assistant — ينشئ مرشحات النوايا، وينشئ Digital Asset Links (assetlinks.json) ويتحقق منه، ويختبر التعامل مع الروابط.
• Google Play Console — صفحة Deep Links — تعرض حالة الروابط العميقة لتطبيقك والتحقق منها.
• التحقق من Digital Asset Links — تأكد من أن assetlinks.json المنشور يربط نطاقك وحزمة تطبيقك/بصمتها على نحو صحيح.
• تصحيح Universal Links من Apple — إرشادات Apple لتشخيص سبب فتح Universal Link في المتصفح بدلًا من التطبيق (نوع محتوى ملف الارتباط، والاستحقاق، والتخزين المؤقت).
• Google Search Console — تقرير الأداء — يعرض مرشح مظهر البحث Android app مرات الظهور والنقرات وCTR والموضع للنتائج التي ظهر فيها الرابط العميق لتطبيق Android.
• curl / DevTools / bookmarklet — أسرع فحص أولي للتأكد من أن ملفَي الارتباط يعيدان 200 بنوع المحتوى الصحيح ومن دون إعادة توجيه (انظر علامة التبويب Scripts).

موارد تستحق وقتك

كتاباتي

• الفهرسة أولًا للهاتف تنتقل إلى الهاتف فقط — مفهوم مرتبط لكنه مختلف، يتعلق بنسخة صفحتك التي تفهرسها Google (لا تخلطه بالروابط العميقة للتطبيقات).
• دليل المبتدئ لتحسين محركات البحث التقني — موضع موضوعات الهاتف والتطبيقات المجاورة ضمن صورة الزحف والفهرسة والترتيب الأكبر.

محادثاتي

• How Search Works (SlideShare) — شرحي للزحف والتصيير والفهرسة والترتيب، بما في ذلك زحف Googlebot كما لو كان هاتفًا ذكيًا. (إخلاء المسؤولية الثابت: “This is my understanding of systems… not going to be 100% complete or accurate.” (ترجمة) «هذا فهمي للأنظمة… ولن يكون كاملًا أو دقيقًا بنسبة 100٪».)

من أنحاء المجال

• الروابط العميقة للتطبيقات: ربط موقعك وتطبيقك (Google) — الإرشادات الحالية المعتمدة، ومصدر عبارات عدم التأثير في الترتيب وتطابق المحتوى.
• Firebase App Indexing (Google/Firebase) — إشعار الإيقاف الحالي الذي يشير إلى App Links / Universal Links.
• حول الروابط العميقة (Android) — App Links ونموذج التحقق.
• التحقق من Android App Links (Android) — متطلب assetlinks.json.
• السماح للتطبيقات والمواقع بالربط بمحتواك (Apple) — Universal Links وapple-app-site-association.
• تحول Google App Indexing إلى Firebase App Indexing (Search Engine Land) — تغطية Barry Schwartz لإعادة التسمية في Google I/O لعام 2016.

إحصاءات تستحق الاقتباس

• الروابط العميقة للتطبيقات لا تغيّر الفهرسة أو الترتيب — تقول Google نفسها في مايو 2025 إن البحث «continues to use the content of your web pages for indexing and ranking» (ترجمة) «يواصل استخدام محتوى صفحات الويب الخاصة بك للفهرسة والترتيب». وهذه أهم حقيقة في الموضوع وأكثرها تعرضًا للقول الخاطئ. المصدر
• Firebase App Indexing مهجور — لم يعد تطبيق Google Search لنظام Android «no longer uses local content indexed via Firebase App Indexing» (ترجمة) «يستخدم المحتوى المحلي المفهرس عبر Firebase App Indexing»، وفق وثائق Firebase الحالية. حدث الانتقال في 2021 (وهو موجود في أرشيف أكتوبر 2022 وغائب عن أكتوبر 2020). المصدر
• App Links مدعومة في Android 6 وما بعده — تصفها Google بأنها «a recommended approach» (ترجمة) «نهج موصى به» للروابط العميقة إلى موقعك، وتتحقق منها عبر ملف Digital Asset Links في /.well-known/assetlinks.json. المصدر

مطالبات لاختبار جودة الروابط العميقة للتطبيقات

راجع بيانات ارتباط Android

Review this Android intent-filter and assetlinks.json together. Check host/path
coverage, android:autoVerify, package name, relation value, and certificate
fingerprints for internal consistency. Return: definite mismatches, items that require
device verification, affected URL patterns, and exact tests to run. Do not assume an
unshown signing certificate or redirect behavior.

MANIFEST:
[paste]

ASSETLINKS_JSON:
[paste]

أنشئ مصفوفة لاختبار تطابق المحتوى

Turn this list of web URLs and intended app destinations into a QA matrix. For each
row include web content identity, Android destination, iOS destination, installed-app
behavior, no-app fallback, and a pass/fail content-parity check. Flag rows where the
app screen's content appears different from the web page; do not treat layout changes
as content mismatches.

[paste URL-to-screen mapping]

تحقّق من إصدار رابط عميق للتطبيق

اختبر ملفات الارتباط العامة

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

اختبر سلوك التطبيق عند التثبيت وعدم التثبيت

الاختبار المطلوب: انقر على روابط HTTPS ممثلة في أجهزة Android وiOS حقيقية مع تثبيت التطبيق، ثم من دونه. النتيجة المتوقعة: يصل المستخدمون الذين ثبّتوا التطبيق إلى شاشة التطبيق المطابقة؛ ويصل المستخدمون الآخرون إلى عنوان URL نفسه على الويب. تفسير الفشل: التحقق أو التوجيه أو سلوك الرجوع غير مكتمل. نافذة المراقبة: فورًا مع كل إصدار للتطبيق. مُشغّل التراجع: إذا وصلت الروابط إلى طريق مسدود، أو فتحت الشاشة الخطأ، أو تعذر رجوعها إلى الويب.

اختبر تطابق المحتوى

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

قِس سلامة الروابط العميقة للتطبيقات

مظهر بحث تطبيق Android

المقياس: مرات الظهور والنقرات لمظهر بحث Android App. ما الذي يخبرك به: عدد مرات عرض Google لنتائج بمعالجة رابط عميق لنظام Android وحجم الحركة التي استخدمتها. طريقة استخراجه: أداء Search Console، مع تصفيته إلى مظهر بحث Android App. المعيار / النطاق الواقعي: أنشئ خط أساس حسب الاستعلام والصفحة؛ فالأهلية تعتمد على انتشار التطبيق والنتائج الملائمة، لذلك لا يوجد هدف عام. الدورية: شهريًا، مع تعليقات على الإصدارات.

معدل فتح المسار بنجاح

المقياس: عمليات فتح الروابط العميقة الصالحة مقسومة على محاولات روابط التطبيقات. ما الذي يخبرك به: هل تصل الروابط المتحقق منها إلى الشاشة المقصودة بدلًا من الرجوع أو الخطأ. طريقة استخراجه: أحداث تحليلات التطبيق عند استلام الرابط وتصوير الوجهة، مع استبعاد معاملات URL الحساسة. المعيار / النطاق الواقعي: استخدم خطك الأساسي الخاص بالمنصة والإصدار؛ وابحث في التراجع المستمر بعد إصدار ما. الدورية: أسبوعيًا ومع كل إصدار للتطبيق.

عدد استثناءات التطابق

المقياس: عناوين URL للويب المرتبطة التي لم تعد وجهة التطبيق تحتوي على محتوى مكافئ لها. ما الذي يخبرك به: هل ما يزال التوجيه يفي بالشرط المركزي لتطابق المحتوى. طريقة استخراجه: سجل مستمر لربط عنوان URL بالشاشة مع فحوص الجودة عند الإصدار. المعيار / النطاق الواقعي: الهدف المناسب هو صفر من الاستثناءات المعروفة. الدورية: مع كل إصدار وبعد تغييرات كبيرة في بنية معلومات الويب أو التطبيق.

اختبر نفسك: فهرسة التطبيقات

خمسة أسئلة سريعة عن ماهية فهرسة التطبيقات، وما حلّ محلها، وما تفعله فعليًا لتحسين محركات البحث. اختر إجابة لكل سؤال، ثم تحقّق منها.

سجل التغييرات