التحقق من الزيارات: كيف تتأكد من أن الروابط تؤدي إلى النطاق الصحيح

ما الذي يُعد انتقالًا إلى النطاق الصحيح

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

تحقق ليس فقط من اسم النطاق، بل من صيغته أيضًا: www وبدون www، وHTTP وHTTPS، والنطاق الرئيسي والنطاق الفرعي. قد تنتمي العناوين site.example وwww.site.example وpromo.site.example إلى مشروع واحد، لكنها بالنسبة للمتصفح والتحليلات والسجلات مضيفات مختلفة.

افتح الرابط بالطريقة التي يفتحه بها الجمهور

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

• قارن المضيف النهائي بنطاق صفحة الهبوط.
• تحقق من المسار: قد يؤدي الرابط إلى النطاق الصحيح لكن إلى قسم قديم.
• تأكد من أن الانتقال عبر الجوال لا ينتهي إلى نطاق فرعي تقني.
• قارن النتيجة للرابط مع وسوم UTM وبدونها.
• تحقق من بقاء معاملات الحملة بعد كل الانتقالات.

عيب التحقق اليدوي: أنه يُظهر سيناريو واحدًا فقط — متصفحك وجهازك ومنطقتك ومجموعة ملفات تعريف الارتباط لديك. وقد تعمل القواعد بشكل مختلف لجزء من الجمهور.

تحقق من سلسلة إعادة التوجيه كاملة في المتصفح وعبر curl

للتحقق التقني استخدم curl مع المعاملين -I و-L: سيعرض الأمر ترويسات الاستجابة ويمر عبر عمليات إعادة التوجيه. ابحث عن الحالات 301 و302 و307 و308 وترويسات Location. فهي تُظهر العنوان الذي يوجّه الخادم المستخدم إليه في كل خطوة.

للتحقق في متصفح حقيقي، افتح أدوات المطور، وانتقل إلى تبويب Network وفعّل Preserve log. ثم افتح الرابط الأصلي. في قائمة الطلبات تظهر عمليات إعادة التوجيه والمستند النهائي والطلبات التي تُنفَّذ بعد تحميل الصفحة.

1. فعّل Preserve log حتى لا تُمسح القائمة بعد إعادة التوجيه.
2. عطّل ذاكرة التخزين المؤقت للمتصفح عند الحاجة.
3. افتح الرابط الأصلي من المنشور أو الصقه في تبويب جديد.
4. ابحث عن الاستجابات ذات الحالات 3xx.
5. قارن Request URL لكل خطوة بقيمة Location.
6. تحقق من نطاق وعنوان URL للمستند الأخير ذي الحالة 200.

متى يكون النطاق القديم في السلسلة طبيعيًا ومتى يكون خطأ

وجود نطاق قديم في السلسلة لا يعني دائمًا وجود مشكلة. بعد الانتقال، يكون المسار الطبيعي مثل old-site.example/stream → site.example/stream: يستقبل العنوان القديم الطلب ويعيد توجيه المستخدم باستمرار إلى صفحة مكافئة في الموقع الجديد. النطاق النهائي صحيح، والمسار محفوظ، ووسوم UTM لم تختفِ.

الخطأ هو الحالة التي يؤدي فيها old-site.example/stream إلى الصفحة الرئيسية للموقع الجديد أو إلى صفحة هبوط أخرى أو يُبقي المستخدم على النطاق القديم. وتنشأ مشكلة منفصلة إذا اختفى بعد إعادة التوجيه النص الذي يلي علامة الاستفهام: يصل المستخدم إلى الصفحة الصحيحة، لكن التحليلات تفقد utm_source وutm_medium وutm_campaign.

تحقق ليس فقط من النطاق الأخير، بل من المسار مع المعاملات. فالانتقال إلى site.example دون الصفحة المطلوبة أو الوسوم قد يشوّه بيانات الحملة بقدر ما يفعل الانتقال إلى مضيف آخر.

ضع في الحسبان إعادة التوجيه عبر JavaScript ومعاملات الرابط

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

في Network تحقق ليس فقط من المستند الرئيسي، بل من لحظة تغيّر العنوان بعد تحميله. إذا اختفت وسوم UTM، قارن عنوان URL الأصلي وقيمة Location والسطر النهائي في شريط العنوان. بهذه الطريقة يمكنك معرفة الخطوة التي أسقطت فيها قاعدة إعادة التوجيه المعاملات.

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

تحقق من المتصفحات المدمجة في التطبيقات

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

افتح الرابط مباشرة من تطبيق المنصة التي نُشر فيها. ثم أعد الاختبار عبر خيار «فتح في المتصفح» إن كان متاحًا. قارن النطاق النهائي والمسار ووسوم UTM وسلوك النموذج أو الدفع أو تسجيل الدخول.

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

قارن الانتقالات من مناطق وظروف مختلفة

إذا كان الموقع يستخدم إعادة توجيه جغرافية أو CDN أو إصدارات مختلفة من صفحات الهبوط، فأعد التحقق عبر VPN أو بروكسي أو جهاز بعيد في المنطقة المطلوبة. قارن النطاق النهائي والمسار ومعاملات URL ومحتوى صفحة الهبوط.

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

عيب VPN والبروكسي: لا يعيدان دائمًا إنتاج ظروف المشاهد الحقيقي بالكامل. فقد تُحدَّد الموقع الجغرافي عبر عدة إشارات، لذا يؤكد هذا الاختبار مشكلة محتملة لكنه لا يغطي الجمهور كله.

أكّد النطاق في Yandex Metrica وGA4

في Yandex Metrica اطّلع على تقارير صفحات الدخول وعناوين URL للصفحات. رشّح البيانات حسب العنوان الكامل أو النطاق المطلوب، ثم أضف شريحة حسب وسم UTM أو المصدر أو الحملة. بهذه الطريقة يمكنك رؤية المضيف الذي بدأت عليه الزيارات بعد نشر معين.

في GA4 استخدم لهذا التحقق البُعد Hostname مع صفحة الهبوط ومصدر الجلسة والحملة. قارن عدد الجلسات التي وصلت إلى النطاق الرئيسي والعنوان القديم والنطاقات الفرعية المهمة. إذا كانت العلامة مثبتة على عدة مضيفات، فسيُظهر التقرير سريعًا اختلاط الزيارات.

عيب التحليلات: لا تسجل العدادات جزءًا من الزيارات بسبب مانعات الإعلانات أو تعطيل JavaScript أو إغلاق الصفحة قبل تحميل العلامة. كما لن تساعد البيانات في نطاق لم تُثبَّت عليه العداد أصلًا.

تحقق من الطلبات في سجلات الخادم

تؤكد سجلات الخادم الطلبات التي وصلت فعليًا إلى بنية الموقع. للتحقق تحتاج إلى حقول الوقت وHost وURL ورمز الاستجابة وuser-agent وreferer إن كان يُمرَّر. ابحث عن الطلبات في فترة إطلاق الرابط، وانظر بشكل منفصل إلى الطلبات الموجهة إلى النطاق القديم والمستهدف.

ستُظهر الاستجابات 301 و302 و307 و308 أن الخادم أعاد توجيه المستخدم. وستؤكد الطلبات ذات الحالة 200 إلى المضيف المستهدف أن الصفحة قُدِّمت من النطاق المطلوب. إذا وُجدت في السجلات انتقالات إلى المضيف القديم لكن دون طلبات إلى الجديد، فتحقق من قواعد إعادة التوجيه وأخطاء الاتصال المحتملة.

عيب السجلات: تصل إليها الروبوتات وأدوات الفحص والطلبات التقنية. وغالبًا يغيب Referer عند الانتقالات من التطبيقات وتطبيقات المراسلة، لذا لن يكون من الممكن دائمًا استعادة مصدر زيارة معينة.

افصل النطاق الرئيسي والنطاقات الفرعية في التقارير

قد توجد صفحة الهبوط والحساب الشخصي والدفع وقاعدة المعرفة على نطاقات فرعية مختلفة. إذا جُمعت في تقرير واحد دون شرائح، فقد لا تلاحظ أن رابطًا من البث يؤدي إلى promo.site.example بدلًا من الموقع الرئيسي أو إلى checkout.site.example قبل التعرف على العرض.

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

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

قائمة تحقق للرابط قبل النشر

• افتح الرابط من المكان الذي سيراه الجمهور.
• تحقق من النطاق النهائي والمسار والمعاملات في شريط العنوان.
• اطّلع على سلسلة 3xx وترويسات Location عبر curl أو Network.
• تأكد من أن النطاق القديم يحفظ المسار ووسوم UTM عند إعادة التوجيه.
• أعد الانتقال في المتصفح المدمج في التطبيق.
• تحقق من منطقة أخرى إذا كانت تُستخدم قواعد جغرافية.
• قارن Hostname وصفحات الهبوط في التحليلات بعد الإطلاق.
• أكّد الطلبات إلى المضيف المطلوب عبر سجلات الخادم.

بعد تغيير النطاق أو CDN أو صفحة الهبوط أو قواعد إعادة التوجيه، تحقق من الروابط الجديدة والقديمة معًا. فقد تستمر أوصاف البث القديمة والمقاطع والمنشورات المثبتة في جلب الجمهور إلى مسار قديم.