22 يناير 2019 - Google Help Hangout Notes

هذا الأسبوع ، جون في بيج آبل ، نيويورك. انضم إلى IRL ، من اليسار إلى اليمين ، بواسطة Martin Splitt من فريق Java Script في Google ، و Chris Love ، و Lily Ray ، و Marie Haynes ، و Dave Minchala ، و Quason Carter. طرحت هذا الأسبوع بعض الأسئلة الرائعة حول Cloudfare و The QRG و The New Page Speed ​​Tool. يمكن العثور على رابط الفيديو والنص الكامل أدناه!

هل يحظر Cloudflare أحيانًا Googlebot؟

7:58

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

الملخص: في بعض الأحيان ، عند الاختبار ، قد يبدو أن Cloudflare يحظر Googlebot. ما يحدث على الأرجح هنا هو أن Cloudflare يحظر الأشخاص الذين يتظاهرون بأنهم Googlebot. لذلك ، إذا كنت تستخدم أداة مثل Screaming Frog واخترت Googlebot كوكيل مستخدم ، فقد لا تتمكن من الزحف إلى المواقع باستخدام Cloudflare .

هل يمكن أن تستمر الروابط غير الطبيعية في الإضرار بالموقع من خلال الخوارزميات؟ إذا كان الأمر كذلك ، فهل يمكن أن يساعد استخدام أداة التنصل؟

14:01

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

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

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

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

كيف تقيس خوارزميات Google معدل الأكل للناشرين؟

33:40

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

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

إذا كان هناك شيء ما في إرشادات مقيّمي الجودة ، فهل من المعقول افتراض أن Google تريد أن ينعكس ذلك في خوارزمياتهم؟

34:44

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

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

هل هناك مخطط لمساعدة المواقع في الظهور بشكل أعلى لنتائج البحث الصوتي؟

36:10

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

الملخص: لم يتم استخدام الترميز المنطوق في جميع المواقع الجغرافية حتى الآن. لكن هذا مكان جيد للبدء.

بعض النصائح حول الفوز بالمقتطفات المميزة

38:03

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

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

هل يجب إضافة مخطط الموقع إلى جميع الصفحات؟

50:47

الإجابة 51:42 - على حد علمي ، إنها الصفحة الرئيسية فقط. لا أعلم. هل يعرف اي منكم؟

إجابة من ليز 51: 4 7 - من المفترض أن تكون صفحة واحدة فقط عادة مع المؤسسة والشركات. هذه هي التوصية بشكل عام.

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

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

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

لماذا تعتبر أداة PageSpeed ​​Insights الجديدة ، المستندة إلى Lighthouse ، أكثر قسوة عند تسجيل مواقع الويب؟

53:05

ماري هاينز: هذا ليس سؤالي ، ولكن لإعطاء بعض السياق ، فإن بيانات Lighthouse الجديدة لسرعة الصفحة أكثر قسوة مما كانت عليه في السابق Page Speed ​​Insights. لذا فإن الشيء الذي حصل على نتيجة مثل 80 في Page Speed ​​Insights قد يكون باللون الأحمر 29 في Lighthouse. لذلك هذا سؤال جيد. هل من المحتمل أن يتسبب ذلك في - لأننا نعلم أنه يمكن تخفيض ترتيب المواقع البطيئة جدًا في الجوال. فهل من الجيد أن نقول ، كما تعلمون ، إذا كنت في المنطقة الحمراء في اختبار Lighthouse ، يجب علينا حقًا تحسين الأشياء لأنه قد يتسبب في خفض رتبتك ، أو هل هناك حد؟

الإجابة 54:07 - لذلك ليس لدينا تخطيط واحد لواحد للأدوات الخارجية وكل ما نستخدمه للتواصل الاجتماعي. نعم ، هذا يجعل من الصعب حقًا قول ذلك ، ولكن في البحث ، نحاول استخدام مزيج من بيانات الاختبارات المعملية الفعلية ، والتي تشبه نوعًا ما اختبار Lighthouse ، وبيانات تقرير Chrome UX ، حيث نحن نقيس ما سيراه مستخدمو الموقع.

MARTIN SPLITT 55:37 - من المهم أيضًا أن ترى Lighthouse ، على سبيل المثال ، يقيس بشكل خاص اتصال 3G في النهاية المتوسطة - أو مثل هاتف متوسط ​​الأداء ، نعم. لذلك ، بشكل أساسي ، إذا كنت تستخدم جهاز Apple McIntosh حديثًا أو جهاز كمبيوتر يعمل بنظام Windows سريعًا مع اتصال جيد مثل الاتصال السلكي أو اتصال Wi-Fi جيد حقًا في مكتبك ، فبالطبع ترى وقت تحميل يبلغ ثانيتين ، ولكن ربما لا يرى مستخدم حقيقي بهاتفه في البرية ذلك. لذا فهذه إحدى هذه الحالات لا يضير فيها أبدًا جعل موقع الويب الخاص بك أسرع ، ولكن من الصعب حقًا أن نقول كيف سيبدو من منظور الدواخل ، لأننا نستخدم مقاييس محددة جدًا لا ترسم بالضرورة أحدًا إلى واحد لما تعرضه الأدوات .... بالطبع من المهم إصلاح ذلك ، لأنك لا تريد أن ينتظر المستخدمون على موقع الويب الخاص بك إلى الأبد. هذا سيؤذيك. هذا سوف يضر المستخدمين. هذا سيؤذيك فقط في البحث. لكنني لا أدفع - أود أن أقول فقط انظر إلى الأدوات. إذا كانت الأدوات تخبرك بأنك تقوم بعمل جيد ، فلا داعي للقلق كثيرًا حيال ذلك. إذا كانت الأدوات تخبرك بأنك لا تفعل شيئًا جيدًا حقًا ، فأعتقد أن الوقت الذي يقضيه في معرفة سبب ظهوره - مثل ، إذا كان ما يقوله مناسبًا ، فإنه يضيع. يجب عليك بدلاً من ذلك النظر في جعل الموقع أسرع.

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

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

الملخص: يقيس Lighthouse سرعات اتصال 3G ، لذلك ستعمل معظم المواقع بسرعة أكبر بكثير مما هو معروض هنا لغالبية الجلسات. ملاحظة: بعد الانتهاء من جلسة Hangout هذه ، ذهب مارتن ليقول إن هذا هو "الرسم الأول المحتوي على المحتوى" وهو الأهم فيما يتعلق بالتخفيضات المحتملة للترتيب.

إذا كنت تحب أشياء مثل هذه ، فستحب رسالتي الإخبارية!

أبلغ أنا وفريقي كل أسبوع عن آخر تحديثات خوارزمية Google والأخبار ونصائح تحسين محركات البحث.

فيديو ونص كامل

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

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

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

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

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

السؤال 7:58 - لدي سؤال مباشر. لذا فإن عددًا من مواقعنا ، كما تعلم ، تستخدم Cloudflare ، وقد لاحظنا أنها تحظر Googlebot مباشرةً ، أليس كذلك؟ لكن لم يكن لها تأثير كبير على تصنيفاتنا ، وعلى ظهورنا ، وما إلى ذلك. لذا نوعًا ما تحاول معرفة كيف ، على سبيل المثال ، هل تستخدمون روبوتًا آخر للزحف إلى فهرس خارج Googlebot مباشرةً ، وكيف يجب أن نفكر في ذلك عندما تخرج شبكات CDN عن طريقها لمنع الروبوت؟

الإجابة 8:33 - نعم ، لا أعرف كيف يتم الإعداد مع Cloudflare في الوقت الحالي ، لكنني أعرف في الماضي أنهم اعتادوا على حظر الأشخاص الذين يقومون بتزوير Googlebot. لذلك إذا كنت تستخدم ، مثل ، خاص بك ، لا أعرف ، Screaming Frog أو شيء ما - قلت ، أنا أستخدم وكيل مستخدم Googlebot ، فسيحظرون ذلك لأنهم يستطيعون أن يقولوا ، مثل ، هذا ليس شرعيًا Googlebot. يمكننا منع ذلك. ولكن بالنسبة للجزء الأكبر ، أعتقد أن لديهم ممارسة كافية للتعرف على برامج Googlebots العادية والسماح لهذا الزحف بالزحف بشكل طبيعي.

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

الإجابة 9:21 - حسنًا ، أجل. حسنًا ، ليس لدينا أي حل بديل. مثل ، إذا كانت مواقع الويب تحظرنا ، فنحن عالقون نوعًا ما. ولكن عادةً إذا كانت خدمة مثل Cloudflare تحظرنا افتراضيًا ، فسيؤثر ذلك على الكثير من مواقع الويب. وسوف نلاحظ ذلك. من المحتمل أن نتواصل مع Cloudflare بشأن شيء من هذا القبيل. ربما يكون لديهم مستويات خدمة مختلفة. لذلك يبدو الأمر كما لو كنت في المستوى الأدنى ، فهي تشبه الخدمة المجانية ، لكن لدينا حدًا لمقدار حركة المرور. لا أعرف ما إذا كان لديهم شيء من هذا القبيل. هذا شيء رأيته مع بعض المضيفين الآخرين ، حيث إذا كان لديك نوع من إعداد الاستضافة الافتراضية المجانية ، فحينئذٍ يكون لديهم في بعض الأحيان حد أقصى لحركة المرور ، ويقومون بحظر الأشياء.

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

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

السؤال 14:01 - عظيم. لدي سؤال حول أداة التنصل. لذلك نحصل دائمًا على الأشخاص الذين يريدون منا إجراء عمليات تدقيق الروابط. ومنذ إصدار Penguin 4.0 ، في سبتمبر 2016 ، حيث قال Gary Illyes ، وأعتقد أنك قلت أيضًا ، مثل ، Google جيد جدًا في تجاهل الروابط غير الطبيعية. لذلك كان تفكيري في ذلك الوقت ، حسنًا ، لا يجب علينا استخدام أداة التنصل لمطالبة Google بتجاهل الروابط التي يتجاهلونها بالفعل ، إلا إذا كان لديك إجراء يدوي بشأن روابط غير طبيعية. لذلك كنا نوصي به فقط للمواقع التي كانت نشطة ، كما تعلم ، تبني روابط ، تحاول التلاعب بالأشياء ، الأشياء التي تعتبر روابط غير طبيعية. لكني أعتقد أن هناك الكثير من الالتباس بين مشرفي المواقع لأنني أرى الناس طوال الوقت ، كما تعلمون ، يتقاضون الكثير من المال للتدقيق - للتنصل من الروابط التي هي فقط - أعلم أنه يتم تجاهلهم. لذلك أود لو كان بإمكاننا الحصول على المزيد من التوضيح. لذلك ربما إذا كان بإمكاني إعطائك مثالًا ، مثل ، إذا كان هناك صاحب عمل استأجر شركة تحسين محركات البحث قبل بضع سنوات ، وأن شركة تحسين محركات البحث تلك قامت بمجموعة من النشرات كضيف فقط للروابط والأشياء التي كان نوعًا ما متوسط ​​الجودة ، إذا كنت تعرف ما أعنيه ، ليس محتوى غير مرغوب فيه للغاية ، فهل يمكننا أن نكون واثقين من أن Google تتجاهل هذه الروابط؟ أم يجب أن ندخل وننكر؟

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

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

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

السؤال 17:24 - لا يزال من الجيد التنصل بشكل أساسي فقط لمنع إجراء يدوي ، أليس كذلك؟

الإجابة 17:29 - أعتقد أنه إذا كنت في حالة من الواضح حقًا أن فريق البريد العشوائي على الويب سوف يعطيك إجراء يدويًا بناءً على الموقف الحالي ، فهذا ما سأنكره.

السؤال 17:37 - لذلك من الجيد أن تفكر كما في Google - مثل شخص في فريق البريد العشوائي في Google يفكر فقط ، مثل ، كما تعلمون ، إذا نظروا إلى هذا ، ماذا سيفعلون إذا فعلوا؟

الإجابة 17:47 - نعم.

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

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

السؤال 19:27 - لدي سؤال حول أحد مواقع عملائنا على الويب. لذلك لديهم نادٍ - لديهم نادٍ في ثلاث مدن في نيو ساوث ويلز. ولكل نادي نطاق فرعي على الموقع. الآن عندما يضيفون أي صفحة إلى موقع الويب الخاص بهم ، فإنهم يقومون بإنشاء الصفحة لكل مجال فرعي. لقد قاموا مؤخرًا بإضافة صفحة تتعلق بأنشطة النادي الخاصة بهم ، وقد أضافوا هذه الصفحة إلى - جميع المجالات الفرعية الخاصة بهم. لذلك فهذا يعني أن جميع النطاقات الفرعية لها نفس المحتوى ، باستثناء عنوان الصفحة مختلف. لأنه عندما يضيفون إلى - لسيدني ، فإنهم يضيفون اسم موقعهم في علامة العنوان. عندما يضيفونه إلى Newcastle ، يضيفون Newcastle في علامة العنوان ، لكن باقي المحتوى على الصفحة هو نفسه. فهل ستكون مشكلة لأن لديهم 50 نطاقًا فرعيًا ، وقد قاموا بإنشاء 50 صفحة ، والتي تحتوي على نفس المحتوى باستثناء العنوان؟

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

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

الإجابة 22:10 - الموقع - نعم. أعتقد أن هذا قد يكون منطقيًا لأنك بعد ذلك تجمع الأشياء مرة أخرى. ثم تقوم بإنشاء صفحة واحدة قوية بدلاً من مجموعة من الصفحات المخففة.

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

الإجابة 23:08 - حسنًا ، ولكن أعتقد أنه إذا كان لديك صفحات منفصلة تحتاج إلى الحصول عليها لأسباب فنية على الموقع ، وقمت بوضع الكنسي ، فهذا أسلوب جيد.

السؤال 23:21 - هل سيكون ذلك مثل - مثل شركة لديها امتيازات متعددة في مواقع مختلفة والتي سيكون لها أساسًا نفس المحتوى لكل امتياز سيكون في مدينة أو بلدة مختلفة ، أو أيًا كان ، ونوع من القمع من وجهة نظر العودة إلى صفحة واحدة؟

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

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

الإجابة 24:57 - هذا صعب. لا أعتقد أن لدينا توجيهات واضحة بشأن ذلك في الوقت الحالي. هذا شيء حيث كل هذه الأنواع المختلفة من الأساليب يمكن أن تكون منطقية. بشكل عام ، أحاول تجنب استخدام ملف robots.txt لذلك لأن ما يمكن أن يحدث هو أننا نجد عناوين URL. نحن فقط لا نعرف ما هو هناك. لذلك ، ما لم تكن ترى بالفعل مشكلات تسببت في الكثير من التحميل على الخادم ، فأنا أحاول استخدام أشياء مثل no index ، واستخدام rel canonical. ربما تستخدم rel no-follow مع الروابط الداخلية لنوع من تحويل الأشياء لجعلها أكثر وضوحًا فيما يتعلق بما يجب الزحف إليه في الفهرس بدلاً من استخدام ملف robots.txt. لكن نوعًا من القرار بشأن متى يتم دمج الأشياء في صفحة على مستوى الفهرس ومتى يتم منعها من الفهرسة ، ومتى يتم توجيهها بهدوء نحو مثل عنوان URL أساسي واحد ، هذا - هذا أمر صعب حقًا في بعض الأحيان.

السؤال 25:53 - لأنه في بعض الأحيان يتم تجاهل العناصر الأساسية إذا كان محتوى الصفحة مختلفًا جدًا.

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

السؤال 26:46 - إذن هناك سيناريو كنت أحاول اكتشافه مع اثنين من عملائي مؤخرًا. نحاول اكتشاف سبب عدم قدرتنا على التخلص من موقع غير مهم بشكل أساسي لا يزال يستخدم HTTP ويبدو أنه مهجور أكثر أو أقل لأن الصفحة لم يتم تحديثها منذ فترة ، والمحتوى قديم وقديم وعموم نوع من النحافة ، ولدي بضع نظريات حول هذا الموضوع. أعتقد أن جزءًا منه هو أنه ربما كان موجودًا في الفهرس لفترة طويلة بحيث يكون لديك نوعًا ما عامل ثقة تم إنشاؤه معهم. And it's kind of hard to unseat them. That's part of my theory on that. So I'm just trying to figure out what's going on because I know HTTPS is a factor. I don't know how much of a factor it can be, but I also think the age might be part of the problem of trying to provide that newer, fresher content that-- in most cases, what we have done over last year is a lot more thorough than what was written, say 10, 12 years ago. So we're trying to figure out why is it taking so long to essentially move ahead of those pages in a lot of cases.

Answer 27:46 - So HTTPS is a ranking factor for us. But it's really kind of a soft ranking factor. It's really a small thing.

Question 27:55 - One of the things I've noticed about when I encounter sites that are still using HTTP is they haven't really-- they haven't been updated, in general, in two or three years, usually. So to me, it's kind of like they've almost been abandoned. To me I'm looking at it as a signal of freshness and stuff like that.

Answer 28:10 - Yeah, I mean, freshness is always an interesting one, because it's something that we don't always use. Because sometimes it makes sense to show people content that has been established. If they're looking at kind of long-term research, then like some of this stuff just hasn't changed for 10, 20 years.

Question 28:30 - I'll give you a pragmatic examples since I'm a web developer. I see pages that were written, say in 2006 or 2007. They haven't actually been changed, but the web standards, web specifications, or just the general way of handling those things has evolved. But that page is still written as if it's 2006. And yet I've got something that's fresher, you know, that's more in depth and things like that, and I'm like at number 11. They're sitting at number four, for example, like, why are they still up there, you know?

Answer 28:59 - Yeah. It's hard to say without looking at the specific cases. But it can really be the case that sometimes we just have content that looks to us like it remains to be relevant. And sometimes this content is relevant for a longer time. I think it's tricky when things have actually moved on, and these pages just have built up so much kind of trust, and links, and all of the kind of other signals over the years, where like, well, it seems like a good reference page. But we don't realize that, actually, other pages have kind of moved on and become kind of more relevant. So I think long-term, we would probably pick that up. But it might take a while.

I don't know if we call it trust or anything crazy like that. It's more-- it feels more like we just have so many signals associated with these pages, and it's not that-- like, if they were to change, they would disappear from rankings. It's more, well, they've been around. They're not doing things clearly wrong or for as long time, and people are maybe still referring to them, still linking to them. Maybe they're kind of misled in kind of linking to them because they don't realize that, actually, the web has moved on. Or maybe, I don't know, a new PHP version came out, and the old content isn't as relevant anymore. But everyone is still linking to, I don't know, version 3 or whatever.

Question 30:42 - But I've also seen that kind of in the health and fitness space as well, you know, like workout types were more popular 10 years ago, but the particular, you know, approach to it isn't necessarily as popular now or been kind of proven to not necessarily be as good. You know, it's just some other general observations I've made too.

Answer 31:06 - Yeah, I think it's always tricky because we do try to find a balance between kind of showing evergreen content that's been around and kind of being seeing more as reference content and kind of the fresher content and especially when we can tell that people are looking for the fresher content. But we'll try to shift that as well. So it's not something that would always be the same.

Question 32:20 - "We have a large e-commerce site that's not in the mobile-first index yet. We know we serve different HTML for the same URL, depending on the user agent. Could this harm us?

Answer 32:38 - So you don't have a ranking bonus for being in the mobile-first index. So it's not that you need to be in there. But it's more a matter of when we can tell that a site is ready for the mobile-first index, then we'll try to shift it over. And at the moment, it's not at the stage where we'd say, we're like flagging sites with problems and telling them to fix things. But more where we're just trying to get up to the current status and say, OK, we've moved all of the sites over that we think are ready for mobile-first indexing. And kind of as a next step, we'll trying to figure out the problems that people are still having and let them know about these issues so that they can resolve them for mobile-first indexing. So it's not that there is any kind of mobile-first indexing bonus that's out there. It's more that we're, step by step, trying to figure out what the actual good criteria should be.

Question 33:40 - Given that the search quality guidelines are an indication of where Google wants its algorithm to go, how does the current algorithm handle measuring the expertise and credibility of publishers?

Answer 33:59 - I don't know. I think that's probably hard to kind of figure out algorithmically. And if there were any kind of technical things that you should do, then we would let you know. So if there are things like authorship markup that we had at some points that we think would be useful for something like this, we would definitely bring that out there. But a lot of things are really more kind of soft quality factors that we try to figure out, and it's not something technical that you're either doing or not doing. It's more, like, trying to figure it out how a user might look at this. So not anything specific that I could point at.

Question 34:44 - Is that reasonable to assume that if something is in the Quality Raters' Guidelines that Google-- I mean, that's what Ben Gomes said, right? That's where the Google wants the algorithm to go. So I mean, we may be guilty putting too much emphasis on the Quality Raters' Guidelines, but it's all good stuff in there, right? So is it reasonable to make that assumption? Like, if it's in there, we should aim for that sort of standard of quality?

Answer 35:09 - I think, in general, it's probably good practice to aim for that. I avoid trying to focus too much on what Google might use as an algorithmic factor and look at it more as-- we think this is good for the web, and, therefore, we will try to kind of go in that direction and do these kind of things. So not so much it's like I'm making a good website just so that I can rank better, but I'm making a good website because when I do show up in search, I want people to have a good experience. And then they'll come back to my website, and maybe they'll buy something. So that's kind of the direction I would see that, not as, like, do this in order to rank, but do this in order to kind of have a healthy, long-term relationship on the web.

Question 36:10 - Is there a particular type of schema that is more likely to obtain featured snippets of voice search results?

Answer 36:18 - I don't know. I can't think of anything offhand. So there is the speakable markup that you can use, which is probably reasonable to-- kind of look into to see where it could make sense on a page. I don't think we'll use that in all locations yet.

Question 36:41 - Is that the goal to us it in more locations?

Answer 36:47 - I believe-- I guess. I mean, it's always a bit tricky because, sometimes, we try them out in one location, and we try to refine it over time. And usually, that means we roll it out in the US, and where we can kind of process the feedback fairly quickly, we can look to see how it works, how sites start implementing it or not. And based on that, we can refine things and say, OK, we're doing this in other countries, and other languages, and taking it from there. But it's not always the case that that happens. Sometimes it happens that we keep it in the US for a couple of years, and then we just said, oh, actually, this didn't pan out the way that we wanted it. So we'll try something new, or we'll give it up. Yeah. But a lot of the structured data types, we do try to roll out in other countries, other languages. I imagine the speakable markup is tricky with regards to the language. So that's something more where we'd say, well, Google Assistant isn't available in these languages. So, like, why do we care what markup is actually used there.

I don't know how many places this system is available yet. Maybe that's everywhere now. But featured snippets, in particular, I don't think we have any type of markup that's specific to that. So that's something where if you have clear kind of structure on the page, that helps us a lot. If we can recognize like tables on a page, then we can pull that out a lot easier. Whereas if you use fancy HTML and CSS to make it look like a table, but it's not actually a table, then that's a lot harder for us to pull out.

Question 38:37 - John, do internal links help with featured snippets if you have an anchor? Sorry, not an internal, like, an anchor like-- do you think that that would help?

Answer 38:48 - I don't know. I do know we sometimes show those anchor links in search as a sub site link-type thing. But I don't know if that would work for featured snippets.

Question 39:04 - Does cross domain site map submissions still work when 301 redirecting to an external sitemap file URL?

Answer 39:16 - Hopefully.

Question 39:17 - What about using meta-refresh? This was something that was recommended by a video hosting company. People said, we'll host the site map on our site, but, you know, the XML file will metarefresh over to our site where all the links are located.

Answer 39:33 - I don't think that would work. So sitemap files are XML files, and we process those kind of directly.

So if you do something that's more like a JavaScript redirect or that uses JavaScript to get us the sitemap content, then that would work. It would really need to be a server-side redirect. What you can also do is use the robots.txt file to specify a sitemap file on a different host. That also confirms to us that actually you told us specifically to use a sitemap file from there. So I probably use something like that more than any kind of a redirect. I imagine the 301 server-side redirect would work. But, no, I don't know, you should be able to see some of that in Search Console too, like, if we're picking the sitemap up in the index composition tool, you can pick the sitemap file, then that's a pretty clear sign that we can process that.

السؤال 42:29 - كان عن مواقع وكالات السفر للسفر. اخترنا البحث الداخلي لإظهار المحتوى الديناميكي ، مثل أفضل 10 فنادق رخيصة في مدينة البحث ، حسنًا؟ لذلك يتم تحميل إطار الصفحة في لحظة. ولكن يتم تحميل أفضل 10 نتائج لأرخص الفنادق بشكل ديناميكي في 30 ثانية تقريبًا منذ إجراء البحث لأنه يتعين على موقع الويب إجراء هذا البحث في الخلف ثم مقارنة النتائج وتحسينها من أجل سرد أفضل 10 نتائج للباحث. الفنادق. لذلك يستغرق الأمر بعض الوقت لإدراجها في القائمة. حتى الآن ، لا يرى Googlebot سوى خلفية الصفحة. ثم كانت تلك العناصر النائبة العشرة الفارغة هي المكان الذي سيتم فيه تحميل النتائج بعد فترة وجيزة بعد إجراء البحث الداخلي. نظرًا لأن هذا اتجاه لمواقع السفر لتقديم معلومات جديدة قدر الإمكان ودقيقة قدر الإمكان ، أعتقد أن ما تفعله Google حيال ذلك. بالطبع ، يمكننا سرد بعض المحتوى الثابت على هذه الصفحات مثل جميع مواقع الويب الأخرى التي تقدمها في الوقت الحاضر لـ Google ، إذا جاز لي القول. لكن هذا النوع من المحتوى يتعارض مع الغرض مما يريد معظم المستخدمين رؤيته الآن ، جديدًا ورخيصًا.

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

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

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

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

السؤال 46:48 - هل تستطيع - هل تستطيع أن تعطيني إطاراً زمنياً؟ كم تنتظر؟

مارتن سبليت : إنه أمر صعب حقًا لأنه في الأساس - إذن السبب هو ، السبب في عدم قدرتنا على منحك إطارًا زمنيًا هو أن الوقت - وسيبدو هذا غريبًا حقًا ، وسيصمد معي لثانية . الوقت في عرض Googlebots خاص ولا يتبع بالضرورة مبادئ أينشتاين. [ضحك] لذا لا يمكنني قول الكثير حقًا. ما يمكنني قوله هو أنه إذا كانت الشبكة مشغولة وكانت الشبكة هي عنق الزجاجة ، فربما ننتظر ، لكننا ننتظر فقط لفترة طويلة. لذلك إذا استغرقت دقيقة أو 30 ثانية ، فمن المحتمل أن تكون المهلة بيننا. لكن ليس هناك صعوبة - إذا أخبرتك 10 ثوانٍ ، فقد ينجح ذلك وقد لا ينجح. إذا أخبرتك 30 ثانية ، فقد ينجح ذلك وقد لا ينجح. لذلك أفضل عدم ذكر رقم. ما أود قوله ، حاول إدخاله بأسرع ما يمكن. وإذا لم تتمكن من الحصول عليها بسرعة ، فحاول شيئًا مثل التخزين المؤقت لنتائج البحث بحيث يصبح البحث أكثر أو أقل في - أو يصبح إنتاج النتائج على الصفحة أكثر وأكثر - أكثر أو أقل. أو جرّب العرض الديناميكي من جانبك والذي قد يكون حلاً بديلاً لذلك. ما يمكنك تجربته أيضًا هو أنه يمكنك محاولة وضعه على جانب الخادم ومحاولة إنشاء أكبر قدر ممكن من المحتوى في المسار الأول. هذا شيء يفيد المستخدمين أيضًا ، خاصةً إذا كانوا على شبكات بطيئة. إذن أجل. عذرًا ، ليس لدي أي إجابة بسيطة ، لكن الوقت في Googlebot غير تقليدي.

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

السؤال 50:29 - بالنسبة لمواقع الويب الكبيرة جدًا ، هل ترتيب عناوين URL في خرائط مواقع XML مهم؟

الإجابة 50:34 - لا. نحن لا نهتم. إنه ملف XML. نقوم بسحب جميع البيانات. نقوم بمعالجتها كلها مرة واحدة.

السؤال 50:44 - ماذا عن معلمة الأولوية في خرائط المواقع؟

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

الإجابة 51:42 - على حد علمي ، إنها الصفحة الرئيسية فقط. لا أعلم. هل يعرف اي منكم؟

إجابة من ليز 51: 4 7 - من المفترض أن تكون صفحة واحدة فقط عادة مع المؤسسة والشركات. هذه هي التوصية بشكل عام.

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

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

ماري هاينز: هذا ليس سؤالي ، ولكن لإعطاء بعض السياق ، فإن بيانات Lighthouse الجديدة لسرعة الصفحة أكثر قسوة مما كانت عليه في السابق Page Speed ​​Insights. لذا فإن الشيء الذي حصل على نتيجة مثل 80 في Page Speed ​​Insights قد يكون باللون الأحمر 29 في Lighthouse. لذلك هذا سؤال جيد. هل من المحتمل أن يتسبب ذلك في - لأننا نعلم أنه يمكن تخفيض ترتيب المواقع البطيئة جدًا في الجوال. فهل من الجيد أن نقول ، كما تعلمون ، إذا كنت في المنطقة الحمراء في اختبار Lighthouse ، يجب علينا حقًا تحسين الأشياء لأنه قد يتسبب في خفض رتبتك ، أو هل هناك حد؟

الإجابة 54:07 - لذلك ليس لدينا تخطيط واحد لواحد للأدوات الخارجية وكل ما نستخدمه للتواصل الاجتماعي. نعم ، هذا يجعل من الصعب حقًا قول ذلك ، ولكن في البحث ، نحاول استخدام مزيج من بيانات الاختبارات المعملية الفعلية ، والتي تشبه نوعًا ما اختبار Lighthouse ، وبيانات تقرير Chrome UX ، حيث نحن نقيس ما سيراه مستخدمو الموقع.

MARTIN SPLITT 55:37 - من المهم أيضًا أن ترى Lighthouse ، على سبيل المثال ، يقيس بشكل خاص اتصال 3G في النهاية المتوسطة - أو مثل هاتف متوسط ​​الأداء ، نعم. لذلك ، بشكل أساسي ، إذا كنت تستخدم جهاز Apple McIntosh حديثًا أو جهاز كمبيوتر يعمل بنظام Windows سريعًا مع اتصال جيد مثل الاتصال السلكي أو اتصال Wi-Fi جيد حقًا في مكتبك ، فبالطبع ترى وقت تحميل يبلغ ثانيتين ، ولكن ربما لا يرى مستخدم حقيقي بهاتفه في البرية ذلك. لذا فهذه إحدى هذه الحالات لا يضير فيها أبدًا جعل موقع الويب الخاص بك أسرع ، ولكن من الصعب حقًا أن نقول كيف سيبدو من منظور الدواخل ، لأننا نستخدم مقاييس محددة جدًا لا ترسم بالضرورة أحدًا إلى واحد لما تعرضه الأدوات .... بالطبع من المهم إصلاح ذلك ، لأنك لا تريد أن ينتظر المستخدمون على موقع الويب الخاص بك إلى الأبد. هذا سيؤذيك. هذا سوف يضر المستخدمين. هذا سيؤذيك فقط في البحث. لكنني لا أدفع - أود أن أقول فقط انظر إلى الأدوات. إذا كانت الأدوات تخبرك بأنك تقوم بعمل جيد ، فلا داعي للقلق كثيرًا حيال ذلك. إذا كانت الأدوات تخبرك بأنك لا تفعل شيئًا جيدًا حقًا ، فأعتقد أن الوقت الذي يقضيه في معرفة سبب ظهوره - مثل ، إذا كان ما يقوله مناسبًا ، فإنه يضيع. يجب عليك بدلاً من ذلك النظر في جعل الموقع أسرع.

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

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