تسربت الوثائق الهندسية الداخلية لبحث Google
تسربت الوثائق الداخلية لواجهة برمجة تطبيقات Content Warehouse API الخاصة بمحرك بحث Google. يبدو أن الخدمات الصغيرة الداخلية في Google تعكس ما تقدمه منصة Google Cloud، وقد تم عن طريق الخطأ نشر النسخة الداخلية من الوثائق الخاصة بـ Document AI Warehouse، التي لم تعد مستخدمة، بشكل علني في مستودع التعليمات البرمجية لمكتبة العميل. كما تم التقاط وثائق هذا الكود بواسطة خدمة توثيق آلية خارجية.
استنادًا إلى سجل التغيير، تم إصلاح خطأ مستودع التعليمات البرمجية هذا في 7 مايو، لكن التوثيق الآلي لا يزال موجودًا. في إطار الجهود المبذولة للحد من المسؤولية المحتملة، لن أربطها هنا، ولكن نظرًا لأن جميع التعليمات البرمجية الموجودة في هذا المستودع تم نشرها بموجب ترخيص Apache 2.0، فقد تم منح أي شخص يصادفها مجموعة واسعة من الحقوق، بما في ذلك القدرة على الاستخدام وتعديله وتوزيعه على أي حال.
لقد قمت بمراجعة المستندات المرجعية لواجهة برمجة التطبيقات (API) ووضعتها في سياقها مع بعض التسريبات السابقة الأخرى من Google وشهادة وزارة العدل لمكافحة الاحتكار. أقوم بدمج ذلك مع الأبحاث المكثفة حول براءات الاختراع والأوراق البيضاء التي تم إجراؤها لكتابي القادم، The Science of SEO. على الرغم من عدم وجود تفاصيل حول وظائف تسجيل Google في الوثائق التي قمت بمراجعتها، إلا أن هناك وفرة من المعلومات حول البيانات المخزنة للمحتوى والروابط وتفاعلات المستخدم. هناك أيضًا درجات متفاوتة من الأوصاف (تتراوح من الأوصاف المتناثرة بشكل مخيب للآمال إلى الكاشفة بشكل مدهش) للميزات التي يتم التلاعب بها وتخزينها.
قد تميل إلى تسمية هذه العوامل على نطاق واسع بـ "عوامل التصنيف"، لكن هذا قد يكون غير دقيق. العديد منها، بل معظمها، تعتبر عوامل تصنيف، لكن الكثير منها ليس كذلك. ما سأفعله هنا هو وضع سياق لبعض أنظمة وميزات التصنيف الأكثر إثارة للاهتمام (على الأقل، تلك التي تمكنت من العثور عليها في الساعات القليلة الأولى من مراجعة هذا التسريب الهائل) بناءً على بحثي المكثف والأشياء التي أخبرتها Google/ كذب علينا على مر السنين.
كلمة "كذب" قاسية، لكنها الكلمة الدقيقة الوحيدة التي يمكن استخدامها هنا. على الرغم من أنني لا ألوم بالضرورة ممثلي Google العامين على حماية معلومات الملكية الخاصة بهم، إلا أنني أعترض على جهودهم الرامية إلى تشويه سمعة الأشخاص في عوالم التسويق والتكنولوجيا والصحافة الذين قدموا اكتشافات قابلة للتكرار. نصيحتي لموظفي Google المستقبليين الذين يتحدثون عن هذه المواضيع: في بعض الأحيان يكون من الأفضل أن نقول ببساطة "لا يمكننا التحدث عن ذلك". مصداقيتك مهمة، وعندما تخرج تسريبات كهذه وشهادات مثل محاكمة وزارة العدل، يصبح من المستحيل الوثوق ببياناتك المستقبلية.
المحاذير
أعتقد أننا نعلم جميعًا أن الناس سيعملون على تشويه النتائج والتحليلات التي توصلت إليها من هذا التسريب. سوف يتساءل البعض عن سبب أهمية ذلك ويقولون "لكننا نعرف ذلك بالفعل". لذا، دعونا نتخلص من المحاذير قبل أن نصل إلى الأشياء الجيدة.
الوقت والسياق المحدودان – في عطلة نهاية الأسبوع، لم أتمكن إلا من قضاء حوالي 12 ساعة تقريبًا في التركيز العميق على كل هذا. أنا ممتن للغاية لبعض الأطراف المجهولة التي ساعدتني للغاية في مشاركة أفكارهم معي لمساعدتي في الوصول إلى السرعة بسرعة. وأيضًا، على غرار تسريب Yandex الذي قمت بتغطيته العام الماضي، ليس لدي صورة كاملة. حيث كان لدينا كود مصدر للتحليل ولم يكن لدينا أي تفكير وراء ذلك بالنسبة لـ Yandex، في هذه الحالة لدينا بعض التفكير وراء آلاف الميزات والوحدات النمطية، ولكن لا يوجد كود مصدر. سيتعين عليك أن تسامحني على مشاركة هذا بطريقة أقل تنظيمًا مما سأفعله في غضون أسابيع قليلة بعد أن جلست مع المادة لفترة أطول.
لا توجد وظائف تسجيل - نحن لا نعرف كيف يتم ترجيح الميزات في وظائف التسجيل المختلفة. لا نعرف ما إذا كان كل ما هو متاح يتم استخدامه. نحن نعلم أنه تم إهمال بعض الميزات. ما لم تتم الإشارة إلى ذلك صراحة، فإننا لا نعرف كيف يتم استخدام الأشياء. نحن لا نعرف أين يحدث كل شيء في خط الأنابيب. لدينا سلسلة من أنظمة التصنيف المسماة التي تتوافق بشكل فضفاض مع كيفية شرح Google لها، وكيف لاحظ كبار المسئولين الاقتصاديين التصنيفات في البرية، وكيف تشرح طلبات براءات الاختراع وأدبيات العلاقات الدولية. في النهاية، بفضل هذا التسرب، لدينا الآن صورة أوضح لما يتم النظر فيه والذي يمكن أن يوضح ما نركز عليه مقابل ما نتجاهله في المضي قدمًا في تحسين محركات البحث.
من المحتمل أن يكون الأول من عدة مشاركات - سيكون هذا المنشور بمثابة طعنتي الأولى لما قمت بمراجعته. قد أنشر منشورات لاحقة بينما أواصل البحث في التفاصيل. أظن أن هذه المقالة ستؤدي إلى تسابق مجتمع تحسين محركات البحث (SEO) لتحليل هذه المستندات وسنقوم، بشكل جماعي، باكتشاف الأشياء وإعادة وضعها في سياقها لعدة أشهر قادمة.
يبدو أن هذه معلومات حديثة - بأفضل ما يمكنني قوله، يمثل هذا التسريب البنية الحالية النشطة لتخزين محتوى بحث Google اعتبارًا من مارس 2024. (إشارة إلى أحد موظفي العلاقات العامة في Google يقول إنني مخطئ. في الواقع، دعنا نتخطى الأغنية) والرقص جميعا). استنادًا إلى سجل الالتزام، تم تفعيل التعليمات البرمجية ذات الصلة في 27 مارس 2024 ولم تتم إزالتها حتى 7 مايو 2024.
الارتباط ليس سببية - حسنًا، هذا لا ينطبق حقًا هنا، ولكني أردت فقط التأكد من أنني غطيت جميع القواعد.
هناك 14 ألفًا من ميزات التصنيف والمزيد في المستندات
هناك 2596 وحدة ممثلة في وثائق API مع 14014 سمة (ميزات) تبدو كما يلي:
ترتبط الوحدات بمكونات YouTube، والمساعد، والكتب، وبحث الفيديو، والروابط، ومستندات الويب، والبنية التحتية للزحف، ونظام التقويم الداخلي، وPeople API. تمامًا مثل Yandex، تعمل أنظمة Google على مستودع متجانس (أو "monorepo") وتعمل الأجهزة في بيئة مشتركة. وهذا يعني أنه يتم تخزين كافة التعليمات البرمجية في مكان واحد ويمكن لأي جهاز على الشبكة أن يكون جزءًا من أي من أنظمة Google.
توضح الوثائق المسربة كل وحدة من وحدات واجهة برمجة التطبيقات (API) وتقسمها إلى ملخصات وأنواع ووظائف وسمات. معظم ما ننظر إليه هو تعريفات الخصائص لمختلف المخازن المؤقتة للبروتوكول (أو protobufs) التي يمكن الوصول إليها عبر أنظمة التصنيف لإنشاء SERPs (صفحات نتائج محرك البحث - ما يعرضه Google للباحثين بعد قيامهم بإجراء استعلام).
الصورة عبارة عن مخطط انسيابي يوضح عملية استخدام مخازن البروتوكول المؤقتة (PB) لتسلسل البيانات. يتكون المخطط الانسيابي من أربع خطوات رئيسية، يتم تمثيل كل منها بكتلة بها أسهم تشير إلى اتجاه تدفق العملية: إنشاء ملف .proto لتحديد بنية البيانات الإخراج: ملف .proto إنشاء تعليمات برمجية باستخدام مترجم protoc الإدخال: ملف .proto الإخراج: . java أو .py أو .cc أو ملفات مصدر أخرى قم بتجميع كود PB باستخدام رمز المشروع الخاص بك الإدخال: .java أو .py أو .cc أو ملفات مصدر أخرى الإخراج: الفئات المجمعة استخدم فئات PB لإجراء تسلسل للبيانات ومشاركتها وإلغاء تسلسلها : الفئات المجمعة يتم توصيل كل كتلة بواسطة أسهم تحمل علامة "الإدخال" و"الإخراج" لإظهار التبعيات بين الخطوات. يشرح المخطط الانسيابي بشكل مرئي كيفية الانتقال من تعريف بنيات البيانات في ملف .proto إلى استخدام الفئات المترجمة لتسلسل البيانات وإلغاء التسلسل في المشروع.
لسوء الحظ، تشير العديد من الملخصات إلى روابط Go، وهي عناوين URL على شبكة الإنترانت الخاصة بشركة Google، والتي تقدم تفاصيل إضافية لجوانب مختلفة من النظام. وبدون بيانات اعتماد Google الصحيحة لتسجيل الدخول وعرض هذه الصفحات (وهو الأمر الذي سيتطلب بالتأكيد أن تكون أحد موظفي Google الحاليين في فريق البحث)، فإننا نترك الأمر لأجهزتنا الخاصة لتفسير ذلك.
تكشف مستندات واجهة برمجة التطبيقات (API) عن بعض أكاذيب Google البارزة
لقد بذل المتحدثون الرسميون لشركة Google قصارى جهدهم لتضليلنا وتضليلنا بشأن مجموعة متنوعة من الجوانب المتعلقة بكيفية عمل أنظمتهم في محاولة للتحكم في كيفية تصرفنا كمُحسنات محركات البحث. لن أذهب إلى أبعد من تسميتها "الهندسة الاجتماعية" بسبب التاريخ الحافل لهذا المصطلح. دعنا بدلاً من ذلك نستخدم ... "إضاءة الغاز". ربما لا تكون تصريحات Google العامة بمثابة جهود متعمدة للكذب، بل لخداع مرسلي البريد العشوائي المحتملين (والعديد من مُحسنات محركات البحث المشروعة أيضًا) لإبعادنا عن كيفية التأثير على نتائج البحث.
أقدم أدناه تأكيدات من موظفي Google إلى جانب حقائق من الوثائق مع تعليقات محدودة حتى تتمكن من الحكم بنفسك.
قال المتحدثون باسم Google عدة مرات أنهم لا يستخدمون "سلطة المجال". لقد افترضت دائمًا أن هذا كان كذبًا عن طريق الإغفال والتعتيم.
من خلال قولهم إنهم لا يستخدمون سلطة المجال، يمكن أن يقولوا أنهم على وجه التحديد لا يستخدمون مقياس Moz المسمى "Domain Authority" (من الواضح 🙄). يمكن أن يقولوا أيضًا أنهم لا يقيسون السلطة أو الأهمية لموضوع معين (أو مجال) من حيث صلته بموقع الويب. يسمح لهم هذا الارتباك في الدلالات بعدم الإجابة بشكل مباشر على السؤال حول ما إذا كانوا يحسبون أو يستخدمون مقاييس الاستناد على مستوى الموقع.
وقد كرر غاري إليس، وهو محلل في فريق بحث Google والذي يركز على نشر المعلومات لمساعدة منشئي مواقع الويب، هذا التأكيد عدة مرات.
وغاري ليس وحده. صرح جون مولر، "مدافع البحث الذي ينسق علاقات بحث Google" في هذا الفيديو "ليس لدينا درجة سلطة موقع الويب".
في الواقع، كجزء من إشارات الجودة المضغوطة التي يتم تخزينها على أساس كل مستند، تمتلك Google ميزة تحسبها تسمى "siteAuthority".
لا نعرف على وجه التحديد كيف يتم حساب هذا المقياس أو استخدامه في وظائف التسجيل النهائية، لكننا نعرف الآن بشكل قاطع أنه موجود ويستخدم في نظام التصنيف Q*. تبين أن Google لديها بالفعل سلطة نطاق شاملة. أشير إلى موظفي Google الذين يزعمون "أننا نمتلكه، لكننا لا نستخدمه"، أو "أنت لا تفهم ما يعنيه ذلك"، أو... انتظر، لقد قلت "تعليق محدود"، أليس كذلك؟ المضي قدمًا.
كشفت شهادة Pandu Nayak في محاكمة وزارة العدل لمكافحة الاحتكار مؤخرًا عن وجود نظامي التصنيف Glue وNavBoost. NavBoost هو نظام يستخدم إجراءات تعتمد على النقر لتعزيز الترتيب أو خفضه أو تعزيزه بطريقة أخرى في بحث الويب. أشار ناياك إلى أن Navboost كان موجودًا منذ عام 2005 تقريبًا واستخدم تاريخيًا 18 شهرًا من بيانات النقرات. تم تحديث النظام مؤخرًا لاستخدام بيانات متجددة لمدة 13 شهرًا ويركز على نتائج بحث الويب، بينما يرتبط نظام يسمى Glue بنتائج بحث عالمية أخرى. ولكن، حتى قبل هذا الكشف، كان لدينا العديد من براءات الاختراع (بما في ذلك براءة اختراع التصنيف المستند إلى الوقت لعام 2007) والتي تشير على وجه التحديد إلى كيفية استخدام سجلات النقر لتغيير النتائج.
نحن نعلم أيضًا أن النقرات كمقياس للنجاح هي أفضل الممارسات في استرجاع المعلومات. نحن نعلم أن Google قد تحولت نحو الخوارزميات التي تعتمد على التعلم الآلي وأن تعلم الآلة يتطلب متغيرات استجابة لتحسين أدائها. على الرغم من هذه الأدلة المذهلة، لا يزال هناك ارتباك في مجتمع تحسين محركات البحث (SEO) بسبب التوجيه الخاطئ للمتحدثين باسم Google والنشر المتواطئ بشكل محرج للمقالات عبر عالم التسويق عبر البحث التي تكرر تصريحات Google العامة دون تمحيص.
لقد تناول Gary Ilyes مشكلة قياس النقرات هذه عدة مرات. وفي إحدى الحالات، عزز ما شاركه مهندس بحث جوجل، بول هار، في حديثه في SMX West لعام 2016 عن التجارب الحية، قائلًا إن "استخدام النقرات مباشرة في التصنيفات سيكون خطأ".
وفي وقت لاحق، استخدم منصته بشكل مشهور للانتقاص من راند فيشكين (المؤسس/الرئيس التنفيذي لشركة Moz، وممارس تحسين محركات البحث منذ فترة طويلة) قائلاً: "الوقت الطويل، نسبة النقر إلى الظهور، مهما كانت نظرية فيشكين الجديدة، فهي بشكل عام هراء".
في الواقع، يحتوي Navboost على وحدة محددة تركز بالكامل على إشارات النقر.
يعرّفها ملخص هذه الوحدة على أنها "إشارات النقر والانطباع لـ Craps"، وهو أحد أنظمة التصنيف. كما نرى أدناه، فإن النقرات السيئة، والنقرات الجيدة، وآخر النقرات الأطول، والنقرات غير المسحوبة، والنقرات الأخيرة الأطول غير المضغوطة تعتبر جميعها مقاييس. وفقًا لبراءة اختراع جوجل "تسجيل نتائج البحث المحلية بناءً على بروز الموقع"، فإن "السحق هو وظيفة تمنع إشارة كبيرة واحدة من السيطرة على الإشارات الأخرى". بمعنى آخر، تعمل الأنظمة على تسوية بيانات النقرات لضمان عدم وجود أي معالجة جامحة بناءً على إشارة النقر. يجادل موظفو جوجل بأن الأنظمة الموجودة في براءات الاختراع والتقارير التقنية ليست بالضرورة ما هو قيد الإنتاج، لكن NavBoost سيكون أمرًا لا معنى له إذا لم يكن جزءًا مهمًا من أنظمة استرجاع المعلومات في جوجل.
تم العثور أيضًا على العديد من هذه القياسات المستندة إلى النقرات نفسها في وحدة أخرى تتعلق بإشارات الفهرسة. أحد المقاييس هو تاريخ "النقرة الجيدة الأخيرة" على مستند معين. يشير هذا إلى أن اضمحلال المحتوى (أو فقدان حركة المرور بمرور الوقت) هو أيضًا وظيفة لصفحة التصنيف التي لا تؤدي إلى زيادة العدد المتوقع من النقرات لموضع SERP الخاص بها.
بالإضافة إلى ذلك، تمثل الوثائق المستخدمين كناخبين ويتم تخزين نقراتهم كأصواتهم. يحسب النظام عدد النقرات السيئة ويقسم البيانات حسب البلد والجهاز.
كما يقومون أيضًا بتخزين النتيجة التي حصلت على أطول نقرة خلال الجلسة. لذلك، لا يكفي مجرد إجراء البحث والنقر على النتيجة، بل يحتاج المستخدمون أيضًا إلى قضاء قدر كبير من الوقت على الصفحة. تعد النقرات الطويلة مقياسًا لنجاح جلسة البحث تمامًا مثل وقت المكوث، ولكن لا توجد ميزة محددة تسمى "وقت المكوث" في هذه الوثائق. ومع ذلك، فإن النقرات الطويلة هي في الواقع مقياس للشيء نفسه، وهو ما يتعارض مع تصريحات جوجل في هذا الشأن.
أشارت مصادر مختلفة إلى أن NavBoost "يعد بالفعل أحد أقوى إشارات التصنيف لدى Google". تحدد الوثائق المسربة "Navboost" بالاسم 84 مرة مع خمس وحدات تتضمن Navboost في العنوان. هناك أيضًا أدلة على أنهم يفكرون في تسجيل النقاط على النطاق الفرعي والمجال الجذر ومستوى عنوان URL مما يشير بطبيعته إلى أنهم يتعاملون مع المستويات المختلفة للموقع بشكل مختلف. لن أخوض في حجة النطاق الفرعي مقابل الدليل الفرعي، لكننا سنناقش لاحقًا كيف أثرت البيانات الواردة من النظام أيضًا على خوارزمية Panda.
لذا، نعم، لم يذكر Google "نسبة النقر إلى الظهور" أو "وقت المكوث" بهذه الكلمات المحددة في هذه الوثائق، ولكن تم تضمين روح ما أثبته راند: النقرات على نتائج البحث ومقاييس جلسة البحث الناجحة. الأدلة قاطعة إلى حد ما، ولا يوجد شك في أن Google تستخدم النقرات وسلوك ما بعد النقر كجزء من خوارزميات التصنيف الخاصة بها.
لقد أصر المتحدثون باسم Google على عدم وجود صندوق حماية يتم فصل مواقع الويب عليه بناءً على العمر أو إشارات عدم الثقة. وفي تغريدة محذوفة الآن، رد جون مولر على سؤال حول المدة التي يستغرقها ليكون مؤهلاً للتصنيف مشيراً إلى أنه "لا يوجد وضع رمل".
في وحدة PerDocData، تشير الوثائق إلى سمة تسمى hostAge والتي يتم استخدامها خصيصًا "لحماية البريد العشوائي الجديد في وقت العرض".
وتبين أن هناك رمل بعد كل شيء. من يعرف؟ أوه نعم، عرف راند.
سبق أن نُقل عن Matt Cutts قوله إن Google لا تستخدم بيانات Chrome كجزء من البحث العضوي. وفي الآونة الأخيرة، عزز جون مولر هذه الفكرة.
تتميز إحدى الوحدات المرتبطة بنقاط جودة الصفحة بمقياس للمشاهدات من Chrome على مستوى الموقع. وحدة أخرى يبدو أنها مرتبطة بإنشاء روابط أقسام الموقع لها سمة مرتبطة بـ Chrome أيضًا.
يشير العرض التقديمي الداخلي الذي تم تسريبه من مايو 2016 على نظام RealTime Boost أيضًا إلى أن بيانات Chrome كانت قادمة للبحث. أعني أنك فهمت النقطة.
المتحدثون باسم جوجل حسنو النية، لكن هل يمكننا الوثوق بهم؟
الجواب السريع ليس عندما تقترب أكثر من اللازم من الصلصة السرية.
أنا لا أضمر أي ضغينة تجاه الأشخاص الذين ذكرتهم هنا. أنا متأكد من أنهم جميعًا يبذلون قصارى جهدهم لتقديم الدعم والقيمة للمجتمع ضمن الحدود المسموح بها. ومع ذلك، توضح هذه الوثائق أننا يجب أن نستمر في أخذ ما يقولونه كمدخل واحد ويجب على مجتمعنا الاستمرار في التجربة لمعرفة ما ينجح.
بنية أنظمة التصنيف في GOOGLE
من الناحية النظرية، قد تفكر في "خوارزمية Google" باعتبارها شيئًا واحدًا، معادلة عملاقة تحتوي على سلسلة من عوامل التصنيف المرجحة. في الواقع، إنها سلسلة من الخدمات الصغيرة حيث تتم معالجة العديد من الميزات مسبقًا وإتاحتها في وقت التشغيل لتكوين SERP. بناءً على الأنظمة المختلفة المشار إليها في الوثائق، قد يكون هناك أكثر من مائة نظام تصنيف مختلف. بافتراض أن هذه ليست جميع الأنظمة، ربما يمثل كل نظام من الأنظمة المنفصلة "إشارة تصنيف" وربما هذه هي الطريقة التي يصل بها Google إلى 200 إشارة تصنيف يتحدثون عنها غالبًا.
في حديث جيف دين بعنوان "بناء أنظمة البرمجيات في Google والدروس المستفادة"، ذكر أن التكرارات السابقة لـ Google أرسلت كل استعلام إلى 1000 جهاز للمعالجة والاستجابة في أقل من 250 مللي ثانية. كما قام أيضًا برسم نسخة سابقة من تجريد بنية النظام. يوضح هذا الرسم البياني أن Super Root هو عقل بحث Google الذي يرسل الاستعلامات ويجمع كل شيء معًا في النهاية.
قام زاك فورهيز، المبلغ عن مخالفات جوجل، بتسريب هذه الشريحة التي تعرض العلاقات بين الأنظمة المختلفة داخل جوجل حسب أسمائها الداخلية. يتم الإشارة إلى العديد من هذه في الوثائق.
باستخدام هذه النماذج الثلاثة عالية المستوى، يمكننا أن نبدأ في التفكير في كيفية عمل بعض هذه المكونات معًا. مما يمكنني استخلاصه من الوثائق، يبدو أن واجهة برمجة التطبيقات هذه موجودة أعلى Spanner من Google. Spanner عبارة عن بنية تسمح بشكل أساسي بقابلية التوسع غير المحدودة لتخزين المحتوى والحوسبة أثناء التعامل مع سلسلة من أجهزة الكمبيوتر المتصلة بالشبكة العالمية كجهاز واحد.
من المسلم به أنه من الصعب إلى حد ما تجميع العلاقة بين كل شيء معًا بدءًا من التوثيق فقط، ولكن السيرة الذاتية لـ Paul Haahr تقدم بعض الأفكار القيمة حول ما تفعله بعض أنظمة التصنيف المذكورة. سأسلط الضوء على الأشخاص الذين أعرفهم بالاسم وأقسمهم إلى وظائفهم.
زحف
Trawler – نظام الزحف على شبكة الإنترنت. فهو يتميز بقائمة انتظار الزحف، ويحافظ على معدلات الزحف، ويفهم عدد مرات تغيير الصفحات.
الفهرسة
الإسكندرية – نظام الفهرسة الأساسي.
SegIndexer – النظام الذي يضع المستندات ذات الطبقات في طبقات داخل الفهرس.
TeraGoogle – نظام فهرسة ثانوي للمستندات التي تبقى على القرص لفترة طويلة.
استدعاء
HtmlrenderWebkitHeadless – نظام عرض لصفحات JavaScript. من الغريب أن يتم تسمية هذا باسم Webkit بدلاً من Chromium. هناك ذكر لـ Chromium في المستندات، لذلك من المحتمل أن Google استخدمت WebKit في الأصل وأجرت التبديل بمجرد وصول Headless Chrome.
يعالج
LinkExtractor – يستخرج الروابط من الصفحات.
WebMirror – نظام لإدارة التحديد الأساسي والازدواجية.
تصنيف
موستانج - نظام التسجيل والتصنيف والإرسال الأساسي
Ascorer – خوارزمية التصنيف الأساسية التي تقوم بترتيب الصفحات قبل أي تعديلات لإعادة التصنيف.
NavBoost – نظام إعادة الترتيب بناءً على سجلات النقرات لسلوك المستخدم.
FreshnessTwiddler – نظام إعادة ترتيب المستندات على أساس الحداثة.
WebChooserScorer – يحدد أسماء الميزات المستخدمة في تسجيل المقتطفات.
خدمة وا Serving
Google Web Server – GWS هو الخادم الذي تتفاعل معه الواجهة الأمامية لـ Google. يتلقى حمولات البيانات لعرضها للمستخدم.
SuperRoot – هذا هو عقل بحث Google الذي يرسل الرسائل إلى خوادم Google ويدير نظام ما بعد المعالجة لإعادة الترتيب وعرض النتائج.
SnippetBrain – النظام الذي يقوم بإنشاء مقتطفات للنتائج.
الغراء – نظام تجميع النتائج العالمية باستخدام سلوك المستخدم.
كتاب الطبخ – نظام لتوليد الإشارات. هناك إشارة إلى أنه يتم إنشاء القيم في وقت التشغيل.
كما قلت، هناك العديد من الأنظمة الموضحة في هذه المستندات، ولكن ليس من الواضح تمامًا ما تفعله. على سبيل المثال، تم تمثيل SAFT وDrishti من الرسم البياني أعلاه أيضًا في هذه المستندات، لكن وظائفهما غير واضحة.
ما هم الأطفال الصغار؟
هناك معلومات محدودة عبر الإنترنت حول Twiddlers بشكل عام، لذلك أعتقد أنه من المفيد شرحها هنا حتى نتمكن من وضع سياق أفضل لأنظمة Boost المختلفة التي نواجهها في المستندات.
Twiddlers هي وظائف إعادة ترتيب يتم تشغيلها بعد خوارزمية بحث Ascorer الأساسية. إنها تعمل بشكل مشابه لكيفية عمل المرشحات والإجراءات في WordPress حيث يتم تعديل ما يتم عرضه مباشرة قبل تقديمه للمستخدم. يستطيع Twiddlers ضبط درجة استرجاع المعلومات للمستند أو تغيير ترتيب المستند. يتم تنفيذ الكثير من التجارب الحية والأنظمة المسماة التي نعرفها بهذه الطريقة. وكما يوضح Xoogler، فهي مهمة جدًا عبر مجموعة متنوعة من أنظمة Google:
يمكن أن يقدم Twiddlers قيودًا على الفئات، مما يعني أنه يمكن تعزيز التنوع عن طريق تحديد نوع النتائج على وجه التحديد. على سبيل المثال، قد يقرر المؤلف السماح بثلاث مشاركات مدونة فقط في SERP معين. يمكن أن يوضح هذا متى يكون الترتيب سببًا خاسرًا بناءً على تنسيق صفحتك.
عندما تقول Google إن شيئًا مثل Panda لم يكن جزءًا من الخوارزمية الأساسية، فهذا يعني على الأرجح أنه تم إطلاقه باعتباره Twiddler كحساب تعزيز إعادة الترتيب أو خفض الرتبة ثم انتقل لاحقًا إلى وظيفة التسجيل الأساسية. فكر في الأمر على أنه مشابه للفرق بين العرض من جانب الخادم والعميل
من المفترض أن أيًا من الوظائف التي تحتوي على لاحقة Boost تعمل باستخدام إطار عمل Twiddler. فيما يلي بعض التعزيزات المحددة في المستندات:
- NavBoost
- QualityBoost
- RealTimeBoost
- WebImageBoost
من خلال اصطلاحات التسمية الخاصة بهم، فإنهم جميعًا واضحون بذاتهم.
هناك أيضًا مستند داخلي حول Twiddlers قمت بمراجعته يتحدث عن هذا بمزيد من التفصيل، ولكن يبدو أن هذا المنشور كما لو أن المؤلف رأى نفس المستند الذي رأيته.
الكشف الرئيسي الذي قد يؤثر على كيفية قيامك بتحسين محركات البحث
دعنا نصل إلى ما أتيت من أجله حقًا. ما الذي تفعله Google ولم نكن نعرفه أو لم نكن متأكدين منه وكيف يمكن أن يؤثر على جهود تحسين محركات البحث الخاصة بي؟
ملاحظة سريعة قبل أن نذهب أبعد من ذلك. هدفي دائمًا هو تعريض صناعة تحسين محركات البحث (SEO) لمفاهيم جديدة. ليس هدفي أن أقدم لك وصفة طبية حول كيفية استخدامه لحالة الاستخدام المحددة الخاصة بك. إذا كان هذا هو ما تريده، فيجب عليك استئجار iPullRank لتحسين محركات البحث الخاصة بك. بخلاف ذلك، هناك دائمًا ما يكفي لاستقراء حالات الاستخدام الخاصة بك وتطويرها.
كيف تعمل الباندا
عندما تم طرح باندا كان هناك الكثير من الارتباك. هل هو التعلم الآلي؟ هل يستخدم إشارات المستخدم؟ لماذا نحتاج إلى تحديث أو تحديث للتعافي؟ هل هو على مستوى الموقع؟ لماذا فقدت حركة المرور لدليل فرعي معين؟
تم إطلاق سراح باندا تحت إشراف أميت سينغال. كان سينغال بالتأكيد ضد التعلم الآلي بسبب محدودية إمكانية ملاحظته. في الواقع، هناك سلسلة من براءات الاختراع التي تركز على جودة الموقع لـ Panda، ولكن ما أريد التركيز عليه هو "ترتيب نتائج البحث" غير الوصفي. توضح براءة الاختراع أن الباندا أبسط بكثير مما كنا نعتقد. كان الأمر يتعلق إلى حد كبير ببناء مُعدِّل للتسجيل استنادًا إلى الإشارات الموزعة المتعلقة بسلوك المستخدم والروابط الخارجية. يمكن تطبيق هذا المعدل على مستوى المجال أو المجال الفرعي أو مستوى الدليل الفرعي.
"يقوم النظام بإنشاء عامل تعديل لمجموعة الموارد من عدد الروابط المستقلة وعدد الاستعلامات المرجعية (الخطوة 306). على سبيل المثال، يمكن أن يكون عامل التعديل نسبة عدد الروابط المستقلة للمجموعة إلى عدد الاستعلامات المرجعية للمجموعة. أي أنه يمكن التعبير عن عامل التعديل (M) على النحو التالي:
م = إيل / ر ق،
حيث IL هو عدد الروابط المستقلة المحسوبة لمجموعة الموارد وRQ هو عدد الاستعلامات المرجعية المحسوبة لمجموعة الموارد."
الروابط المستقلة هي في الأساس ما نعتقد أنه يربط بين النطاقات الجذرية، لكن الاستعلامات المرجعية أكثر تعقيدًا بعض الشيء. وإليك كيفية تعريفها في براءة الاختراع:
"يمكن أن يكون الاستعلام المرجعي لمجموعة معينة من الموارد بمثابة استعلام بحث تم إرساله مسبقًا وتم تصنيفه على أنه يشير إلى مورد في مجموعة معينة من الموارد. يمكن أن يتضمن تصنيف استعلام بحث معين تم إرساله مسبقًا على أنه يشير إلى مورد في مجموعة معينة من الموارد ما يلي: تحديد أن استعلام البحث المحدد الذي تم إرساله مسبقًا يتضمن مصطلحًا واحدًا أو أكثر تم تحديده للإشارة إلى المورد في مجموعة معينة من الموارد. "
الآن وبعد أن أصبح لدينا إمكانية الوصول إلى هذه الوثائق، فمن الواضح أن الاستعلامات المرجعية هي استعلامات من NavBoost.
يشير هذا إلى أن تحديثات Panda كانت مجرد تحديثات لنافذة الاستعلامات المتجددة المشابهة لكيفية عمل حسابات Core Web Vitals. قد يعني ذلك أيضًا أن تحديثات الرسم البياني للارتباط لم تتم معالجتها في الوقت الفعلي لـ Panda.
ليس الهدف التغلب على حصان ميت، ولكن براءة اختراع أخرى لشركة Panda، وهي نقاط جودة الموقع، تتأمل أيضًا في النتيجة التي تمثل نسبة بين الاستعلامات المرجعية واختيارات المستخدم أو النقرات.
خلاصة القول هنا هي أنك تحتاج إلى جذب المزيد من النقرات الناجحة باستخدام مجموعة أوسع من الاستعلامات وكسب المزيد من تنوع الروابط إذا كنت تريد الاستمرار في التصنيف. من الناحية النظرية، هذا أمر منطقي لأن المحتوى القوي جدًا سيفعل ذلك. سيؤدي التركيز على جذب عدد أكبر من الزيارات المؤهلة للحصول على تجربة مستخدم أفضل إلى إرسال إشارات إلى Google بأن صفحتك تستحق التصنيف. يجب عليك التركيز على ذلك للتعافي من تحديث المحتوى المفيد.
المؤلفون هي سمة واضحة
لقد كتب الكثير عن E-E-A-T. العديد من مُحسنات محركات البحث (SEOs) غير مؤمنين بسبب مدى غموض تسجيل الخبرة والسلطة. لقد سلطت الضوء سابقًا أيضًا على مدى ضآلة ترميز المؤلف الموجود فعليًا على الويب. قبل أن أتعلم عن التضمين المتجهي، لم أكن أعتقد أن التأليف كان إشارة قابلة للتطبيق بدرجة كافية على نطاق الويب.
ومع ذلك، يقوم Google بشكل صريح بتخزين المؤلفين المرتبطين بالمستند كنص:
