أسباب الرفض للمضيفين عند الإضافة إلى الدلائل

لا يدخل جميع موفري الاستضافة الذين يرسلون طلبات الإضافات إلى دللي VPS Search و VPS.today ، ويختفي البعض منهم بمرور الوقت. يحدث هذا لأننا نقدر سمعتنا كثيرًا ونحاول عرض معلومات حول الخدمات المقدمة بشكل دقيق وكامل ، بالإضافة إلى حماية المستخدمين من المزالق المحتملة بالتعاون مع المضيف. أريد اليوم أن أتحدث عن القواعد وأن أشرح بالتفصيل سبب استخدامنا لكل منها.

يجب أن يكون لدى المضيف موقع عمل وفوترة

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

تزامن الأسعار على الموقع وفي الفواتير

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

الرد على التذاكر في غضون 24 ساعة في أيام العمل

لم يظهر هذا البند منذ بداية المشروع ، ولكن في الآونة الأخيرة. معناه أنه يجب على المضيف تقديم إجابة لطلب المستخدم في غضون 24 ساعة من لحظة إنشائه. لا تعني الإجابة بالضرورة حل المشكلة ، ولكن على الأقل مجرد إشعار بأن المضيف على قيد الحياة وقبل قبول طلب المستخدم للنظر فيه. إن سبب ظهور مثل هذه القاعدة بسيط للغاية من جانبنا: إذا لم يتمكن المضيف من الإجابة على سؤال المستخدم في غضون 24 ساعة ، فليس من الواضح ما سيحدث في حالة حدوث أي مشاكل ، وكم عدد المستخدمين الذين يحتاجون إلى انتظار إجابة في هذه الحالة. أحيانًا نسأل أنفسنا بعض الأسئلة البسيطة للمضيف (على سبيل المثال ، هل يقبل الدفع من خلال Yandex.Money) ، وإذا لم نحصل على أي رد على هذا السؤال أو إذا كانت الإجابة تأتي في غضون أيام قليلة ، فإننا نخفي مثل هذا المضيف.

إعادة بيع خدمات مضيف آخر دون تقديم أي مزايا

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

يجب أن تستخدم فوترة المضيف اتصال HTTPS آمنًا

الآن لا يوجد عمليا مثل هؤلاء المضيفين (بفضل منشئي المتصفحات) ، ولكن نادرا ما يمكن العثور على الفواتير بدون SSL. نظرًا لأن الفوترة تخزن بيانات مهمة ، فإننا لا نضيف أو نعطل المضيفين الذين لا يستخدمون اتصالًا آمنًا (ونعطل أيضًا المضيفين الذين انتهت صلاحيتهم مؤقتًا).

يجب أن يحتوي موقع الويب الخاص بالمضيف على نموذج ملاحظات أو بريد إلكتروني للتواصل بشأن مشكلات ما قبل البيع

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

يجب أن يكون لدى المضيف معدلات ثابتة ، وليس منشئ

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

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

يجب ذكر السعر الشهري بشكل صريح

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

لا قيود على الحد الأدنى لفترة الدفع

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

يجب أن يوفر المضيف وصول الجذر أو المسؤول إلى الخادم

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

نحن لا نضيف أسعارًا متخصصة أو مع أي شروط غير عادية

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

توفير خوادم مضادة للرصاص

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

بعض التعريفات غير متاحة للبيع باستمرار.

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

عدد كبير جدا من التعريفات

اضطررنا عدة مرات لرفض المضيفين الذين كان لديهم الكثير من التعريفات (أكثر من 100). تتم إضافة جميع التعريفات وتحديثها يدويًا ، ومن الصعب جدًا معالجة هذا العدد الكبير دون ارتكاب أخطاء. لذلك ، لسوء الحظ ، على الرغم من أن هؤلاء المضيفين ليس لديهم شيء إجرامي ، كان علينا أن نرفضهم.

باستخدام فوترة مضيف آخر

في بعض الأحيان يحدث أن يعرض المضيف إجراء أعمال استضافة متكاملة باستخدام قدراتهم الخاصة. من وجهة نظر فنية ، اتضح أنه تم إنشاء "مشروع فرعي" في الفوترة الرئيسية للمضيف ، ويستخدم الشريك هذا الفوترة لبيع خدماته. في هذه الحالة ، نرفض أيضًا إضافة التعريفات ، نظرًا لأنه من الصعب التحدث عن الأمان أو الخصوصية هنا.

استخدام الفواتير كموقع

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

فشل برنامج الإحالة

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

سأكون سعيدا لسماع التعليقات حول هذه القواعد. ربما يكون بعضها غير ضروري ، أم أنه يستحق تصفية المضيفين ببعض المعلمات الأخرى؟ سيكون من دواعي سروري النظر في آرائكم وانتقاداتكم البناءة حول ذلك.

ألق نظرة على VPS.today ، موقع للعثور على خوادم افتراضية. 1400 تعرفة من 120 مضيف ، واجهة مريحة وعدد كبير من المعايير للعثور على أفضل خادم افتراضي.