5 مارس 2019 - Google Help Hangout Notes

نشرت: 2019-03-12

ننضم إلى John Mueller في منزله في جلسة Hangout لمساعدة مشرفي المواقع. كان لدينا بعض الأسئلة الرائعة حول Page Speed ​​و hreflang و Backlinks. يمكن العثور على الفيديو والنسخ الكامل بعد فصل الصيف لدينا. إذا كنت تحب هذا ، ففكر في الاشتراك في النشرة الإخبارية الأسبوعية! نلخص أفضل مقالات تحسين محركات البحث لهذا الأسبوع في لقيمات سهلة الهضم.

هل يمكنك شرح مشكلة استخدام json - ld عبر مدير العلامات؟

11:18

5 مارس 2018 مساعدة Hangout John Mueller لذلك أعتقد أن ما تحدثنا عنه كان عددًا من المرات ومجموعة من جلسات Hangout هذه أيضًا وهناك منشورات مدونة جديدة مكتوبة حول هذا الأمر أيضًا من أشخاص مختلفين بما في ذلك Barry أيضًا. ولكن هذا يعود بشكل أساسي إلى ، لكي نكون قادرين على سحب المحتوى من مدير العلامات يعني أننا بحاجة إلى أن نكون قادرين على تقديم معالجة JavaScript لملفات البرامج النصية من مدير العلامات وإخراج الكتابة هناك وتضمين جانب الفهرسة. لذلك هذا شيء يتطلب دائمًا الكثير من العمل لأنظمتنا وليس دائمًا شيئًا نقوم به لجميع الصفحات ، لا سيما عندما نرى أن الصفحة بخلاف ذلك ستكون هي نفسها ، فمن الصعب نوعًا ما على أنظمتنا تبرير ذلك نحتاج أيضًا إلى معالجة كل هذا جافا سكريبت. علاوة على ذلك ، فإن الكثير من أدوات الاختبار لا يقومون بمعالجة مدير العلامات والإخراج أيضًا ، لذلك من الصعب حقًا على الأدوات التأكد من أن هذا الترميز يعمل بشكل صحيح. يستغرق الأمر وقتًا أطول حتى تتم معالجته في البحث ، فقد يكون غير مستقر قليلاً وأنك لا تعرف حقًا ما الذي يتم فهرسته فيه بالضبط في أي وقت. هذه كلها أسباب تجعلني من وجهة نظري لا بأس باستخدام مدير العلامات لأي شيء آخر. من الجيد استخدامه لهذا أيضًا مع JsonLD للبيانات المنظمة في البحث ولكن يجدر بنا أن نأخذ في الاعتبار أنه ليس أسلوبًا رائعًا للبيانات المنظمة بشكل خاص في البحث. إنها طرق أكثر وضوحًا لتوفير بيانات الهيكل مباشرة على صفحة الويب ، مما يجعل من السهل إجراء الصيانة ، مما يسهل تتبع اختبار كل ذلك. لذلك ، هذا ما أوصي به ، لا أقول أنه لا يمكنك استخدام مدير العلامات هنا لهذا ، يمكنك بالتأكيد استخدامه وسنبذل قصارى جهدنا لاستلامه واستخدامه ، لكن الأمر ليس كذلك نفس المستوى من السرعة والمرونة ، والأمان عندما يتعلق الأمر بتوفير بيانات الهيكل مباشرة على الصفحات.


الملخص: على الرغم من أنه من الممكن استخدام JSON-LD والبيانات المنظمة الأخرى عبر Google Tag Manager ، إلا أنها ليست أفضل طريقة. لجوجل لسحب شكل المحتوى إدارة العلامات ويجب أن تقدم جافا سكريبت. معالجة البرنامج النصي من إدارة العلامات وإخراج الكتابة ثم الفهرسة. هناك طرق مباشرة لتقديم البيانات المنظمة مباشرة على الصفحة والتي تجعلها أسهل على Google.


كيف يختار Google عنوان URL لعرضه في البحث؟

15:20

5 مارس 2018 مساعدة Hangout John Mueller لذا ، فإن هذا النوع من الخوض في السؤال العام حول كيفية اختيار Google لعنوان URL لعرضه في البحث ، ومن ناحية أخرى ، هناك جانب في هذه الحالة مثل الصفحة المقصودة للصورة 1 التي تحتوي على مجموعة أساسية rel to the view all page (عرض الكل) ، يعني أن هذه الصفحات ليست متكافئة. لذا من الخطأ أو الضرب نوعًا ما أن نلتقطه ونستخدمه على الإطلاق ، أعتقد أن هذا جانب واحد يجب أن نضعه في الاعتبار. الشيء الآخر الذي يجب أخذه في الاعتبار هو أنه حتى عندما نفهم أن هذه الصفحات يمكن اعتبارها مكافئة ، فإن الأمر يتعلق بنا باستخدام عوامل متعددة لتحديد أي من هذه الصفحات هي الصفحة الأساسية الفعلية. لذلك ، نستخدم rel canonical ، نستخدم عمليات إعادة التوجيه إذا كان لدينا أي شيء. نحن نستخدم روابط خارجية داخلية نستخدم أشياء مثل خرائط المواقع وروابط hreflang ، وكل ذلك ساعدنا في فهم أي من عناوين URL هذه هو العنوان الذي يجب أن نعرضه وما إذا كان عنوان URL الأساسي الذي تحدده هو عنوان لا تستخدمه أبدًا في البقية من موقع الويب الخاص بك ، فمن المحتمل أن نقول ، إن جعل هذا الرابط rel canonical كان خطأً لم يكن مشرف الموقع يقصده في الواقع على هذا النحو ، وربما يتعين علينا اختيار عنوان URL مختلف باعتباره عنوانًا أساسيًا. لذا أعتقد أن ما سيحدث هنا هو إما أننا سنتجاهل العلامة المتعارف عليها لأن هذه ليست نفس الشيء أو سنختار واحدة من الصفحات الأخرى الموجودة بدلاً من ذلك لأن هذه واحدة من الصفحات المرتبطة بقوة داخل الموقع. لذلك لا أعتقد أن هذا الإعداد المحدد سيكون مفيدًا في حالتك.


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


هل من الجيد تضمين المؤلفين في منشورات المدونة بدلاً من مستخدم محرر عام؟

17:38

5 مارس 2018 مساعدة Hangout John Mueller

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


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


ما هي التوصية إذا كان من الممكن ترجمة واجهة المستخدم الخاصة بك إلى لغات أخرى ولكن المحتوى التكميلي ، مثل المحتوى الذي ينشئه المستخدم ، يبقى بلغة أخرى؟

21:48

5 مارس 2018 مساعدة Hangout John Mueller لذلك هذا شيء يحدث قليلاً خاصةً بالنسبة للمحتوى الذي ينشئه المستخدم. لذلك إذا كان لديك منتدى أو مدونة أو شيء ما وكان الأشخاص يعلقون بلغة واحدة ولكنك قمت بالإعداد بحيث يمكن تغيير واجهة المستخدم إلى لغات أخرى. ثم لديك موقف سريع حيث يمكن أن تكون واجهة المستخدم باللغة الفرنسية أو الألمانية ولكن قد يظل المحتوى باللغة الإسبانية على سبيل المثال لأن الجميع يعلقون باللغة الإسبانية وهذا في الأساس شيء يمكنك التعامل معه بطرق متعددة. لذا يمكنك القول أن نسختي الأساسية هي النسخة الإسبانية وكل شيء يشبه النسخة الإسبانية ، وهذا أحد الخيارات التي يمكنك القيام بها. يمكنك استخدام التعليقات التوضيحية hreflang بين هذه الإصدارات لتقول أن هذا هو الإصدار الفرنسي الأكثر من المحتوى الخاص بي الذي يمكنني تقديم المحتوى الرئيسي فيه ليس باللغة الفرنسية ولكن واجهة المستخدم باللغة الفرنسية ، لذلك سيتمكن المستخدم الذي ينتقل إلى الصفحة من التنقل نوعًا ما موقع الويب الخاص بي هذا شيء يمكنك القيام به. وهذه هي في الأساس الاختلافات المختلفة التي يمكنك تقديمها نوعًا ما هناك لإعلامنا بالمزيد حول ماهية تفضيلاتك. من وجهة نظر عملية ، يعود الأمر إليك في النهاية فيما يتعلق بكيفية ظهورك في البحث. لذلك ، إذا كنت تعتقد أنه من المفيد أن يأتي مستخدم فرنسي إلى موقعك ويهبط على الصفحة التي تحتوي على المحتوى باللغة الإسبانية وواجهة المستخدم باللغة الفرنسية ، ثم استخدم التعليقات التوضيحية hreflang بين هذه الإصدارات. إذا كنت تعتقد أن مستخدمًا في فرنسا سيواجه مشكلة في التنقل في موقعك على الإطلاق إذا كان المحتوى الرئيسي باللغة الإسبانية حتى إذا كانت واجهة المستخدم باللغة الفرنسية ، فربما يكون من المنطقي الاحتفاظ بالنسخة الإسبانية مع فهرسة واجهة المستخدم الإسبانية. لذا فإن الأمر متروك لكم في النهاية ، وأعتقد أن أياً من هذه الحلول لا يعتبر حلاً مثالياً. في بعض الأحيان ، يعتمد الأمر قليلاً على مدى انتظام المحتوى الخاص بك في مدى وضوح فهمك لإصدارات اللغة التي تريد فهرستها والإصدارات التي يتوقع المستخدمون رؤيتها في نتائج البحث. لذلك على سبيل المثال ، إذا كنت منتدى دوليًا للغاية ويقوم الأشخاص بالنشر بجميع أنواع اللغات المختلفة ، فمن المحتمل أن يكون من الصعب القول أنك تريد فقط فهرسة نسخة واجهة المستخدم هذه ، فربما يكون من المنطقي أن يتم فهرسة جميع إصدارات واجهة المستخدم. الجانب السلبي بالطبع لفهرسة جميع إصدارات واجهة المستخدم هو أنه يضاعف عدد عناوين url الخاصة بموقعك فجأة. وهذا يعني أنه يتعين علينا الزحف إلى المزيد ، وإذا كان موقع محتوى ضخمًا أنشأه المستخدم ، فهذا يعني أنه يتعين علينا الزحف ، فمن ناحية واحدة إلى كل المحتوى الذي ينشئه المستخدم ، ثم يتعين علينا الزحف إلى جميع مضاعفات ذلك لكل منها إصدار اللغة ، والذي لا أعرف ما إذا كان ذلك مفيدًا ، إذا كان ذلك كثيرًا من الزحف إلى موقع الويب الخاص بك إذا كان ذلك يمنع ربما المحتوى الأحدث من الظهور بسرعة في نتائج البحث. هذا شيء آخر يجب أن يثقل كاهلنا هناك. إذا كنت تتحدث فقط عن بضعة آلاف من المقالات ، فربما تكون هذه مشكلة أقل.


الملخص: يمكنك اختيار إصدار لغة واحد كإصدار أساسي أو يمكنك إضافة تعليقات hreflang التوضيحية بين إصدارات اللغات هذه.


هل يجب علي التنصل من عدد كبير من عناوين url العشوائية التي ترتبط بموقعي؟

27:58

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


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


ما هي أهمية سرعة الصفحة في Google؟

42:30

5 مارس 2018 مساعدة Hangout John Mueller

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


الملخص: السرعة مهمة للغاية عندما يتعلق الأمر بـ Google. إنه مقياس واحد يمكن تتبعه بسهولة وقابل للتنفيذ بسهولة. هناك أدوات رائعة تقدم رؤى رائعة حول كيفية أداء موقعك وما يمكنك فعله للمساعدة في زيادة سرعة الصفحة.


إذا دفعت مقابل إعلانات Google ، فهل سيكون ترتيبي أفضل أم أسوأ؟

47:24

5 مارس 2018 مساعدة Hangout John Mueller لذلك نتلقى هذا السؤال بين الحين والآخر والسؤال هنا ، هل سيتأثر ترتيبي ولكن الجزء الأفضل أو الأسوأ هو شيء نسمع عنه أيضًا أن بعض الأشخاص يقولون إن ترتيبك لن يتحسن إذا كنت تستخدم إعلانات Google يقول بعض الأشخاص إن ترتيبك سينخفض ​​إذا كنت تستخدم إعلانات Google لأننا نريدك أن تشتري المزيد من الإعلانات وليس أيًا منهما صحيحًا. لذا فإن نتائج البحث لدينا مستقلة تمامًا عما إذا كنت تستخدم إعلانات Google أم لا ، فهي مستقلة تمامًا عن التقنيات التي تستخدمها على موقع الويب الخاص بك. لذلك إذا كنت تستخدم شيئًا مثل التحليلات أو أي أداة تتبع أخرى ، فهذا أمر متروك لك تمامًا. إذا كنت تحقق الدخل باستخدام Adsense أو أي من شبكات الإعلانات الأخرى ، فهذا متروك لك تمامًا. لذا سواء كنت تستخدم منتجات Google داخل موقع الويب الخاص بك أم لا ، فإن استخدام خدمات Google الأخرى لموقعك على الويب متروك لك تمامًا. هذا شيء نفضل أن تكون هذه الخدمات قائمة بذاتها ، وإذا قلت هذا أحد الأسباب المحددة لكون خدمة Google ليست رائعة ، فأنا لا أرغب في استخدامها ، فلا تتردد في استخدام شيء آخر. لا نريد أن نضعك في هذا المربع حيث تكون عالقًا بين التركيز على موقع الويب الخاص بك والقيام بما تعتقد أنه مناسب لمستخدميك وبين الاضطرار إلى استخدام هذا المنتج بعينه. لذا فالحقيقة هي أننا لا نربط هذه الأشياء معًا ونفعل ذلك بشكل صريح ونعمل بجد للتأكد من أن هذه الأشياء تعمل بشكل جيد.


الملخص: لا يؤثر إعلانات Google على التصنيفات المجانية.


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

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

النجاح!! تحقق الآن من بريدك الإلكتروني لتأكيد اشتراكك في Google Update Newsletter.

كان هناك خطأ في إرسال اشتراكك. حاول مرة اخرى.

فيديو كامل ونسخة

السؤال 1:14 - منذ أسبوعين فقد موقعنا الإلكتروني 94٪ من حركة مرور Google بين عشية وضحاها. مع حركة البحث المتسقة على مدار العشرين عامًا الماضية وعدم وجود تغييرات كبيرة ، نفترض أن شيئًا تقنيًا يمكن أن يشارك IPS أو SSL عبر CDN مثل Cloudfare يسبب انخفاضًا كبيرًا في حركة المرور باستخدام الخوارزميات. لقد بحثنا بشكل أعمق ووجدنا أن بعض المواقع بها محتوى محفوف بالمخاطر للغاية على نفس عنوان IP. يمكننا تغيير موضوعنا والحصول على شهادة مخصصة ولكننا لا نزال نعاني من حركة المرور ، ما الذي يمكن أن يحدث هنا؟

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

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

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

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

السؤال 11:18 - هل يمكنك شرح المشكلة باستخدام json-ld عبر مدير العلامات؟ يتم استخدام إدارة العلامات للتحقق من وحدة التحكم في البحث وربما التحليلات ، لذلك من المؤكد أنها مستقرة بدرجة كافية.

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

السؤال 14:00 - أجرى عميل ترحيل HTTPs عن طريق الانتقال باستخدام 302 بدلاً من 301 ، هل يحتاجون إلى تغيير ذلك إلى 301؟ ما المدة التي سيستغرقها محرك بحث Google في فهم أن هذه إعادة توجيه دائمة؟

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

السؤال 15:20 - تحتوي معارض الصور الخاصة بنا على عنوان URL فريد للصور مثل / gallery / image1 أو / image2 أو / image 3 ونريد إضافة معرض / عرض الكل واستخدام هذا باعتباره عنوان url الأساسي ولكن ليس لدينا هذا الرابط في أي مكان على الموقع يمكننا القيام بذلك؟ هل يجب أن يكون العرض مرئيًا للقارئ؟

الإجابة 15:46 - إذن ، هذا النوع من الأسئلة يدخل في السؤال العام حول كيفية اختيار Google لعنوان URL لعرضه في البحث ، ومن ناحية أخرى ، هناك جانب من جوانب هذه الحالة مثل الصفحة المقصودة للصورة 1 التي تحتوي على مجموعة rel canonical عرض كل الصفحة ، يعني أن هذه الصفحات ليست متكافئة. لذا من الخطأ أو الضرب نوعًا ما أن نلتقطه ونستخدمه على الإطلاق ، أعتقد أن هذا جانب واحد يجب أن نضعه في الاعتبار. الشيء الآخر الذي يجب أخذه في الاعتبار هو أنه حتى عندما نفهم أن هذه الصفحات يمكن اعتبارها مكافئة ، فإن الأمر يتعلق بنا باستخدام عوامل متعددة لتحديد أي من هذه الصفحات هي الصفحة الأساسية الفعلية. لذلك نستخدم rel canonical ، نستخدم عمليات إعادة التوجيه إذا كان لدينا أي شيء. نحن نستخدم روابط خارجية داخلية نستخدم أشياء مثل خرائط المواقع وروابط hreflang ، وكل ذلك ساعدنا في فهم أي من عناوين URL هذه هو العنوان الذي يجب أن نعرضه وما إذا كان عنوان URL الأساسي الذي تحدده هو عنوان لا تستخدمه أبدًا في البقية من موقع الويب الخاص بك ، فمن المحتمل أن نقول ، إن جعل هذا الرابط rel canonical كان خطأً لم يكن مشرف الموقع يقصده في الواقع على هذا النحو ، وربما يتعين علينا اختيار عنوان URL مختلف باعتباره عنوانًا أساسيًا. لذا أعتقد أن ما سيحدث هنا هو إما أننا سنتجاهل العلامة المتعارف عليها لأن هذه ليست نفس الشيء أو سنختار واحدة من الصفحات الأخرى الموجودة بدلاً من ذلك لأن هذه واحدة من الصفحات المرتبطة بقوة داخل الموقع. لذلك لا أعتقد أن هذا الإعداد المحدد سيكون مفيدًا في حالتك.

السؤال 17:38 - ما توصيتك للمواقع التي تحتوي على الكثير من المحتوى الذي يريدون توفيره للغات والبلدان الأخرى ولكنهم قاموا فقط بترجمة الواجهة حتى الآن ، وليس المحتوى الرئيسي.

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

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

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

السؤال 22:58 - ترميز المخطط بإصدار سطح المكتب وإصدار أمبير ، هل من المقبول أن يتم تنفيذ إصدار سطح المكتب باستخدام microdata لكن إصدار amp يستخدم json-ld؟

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

السؤال 24:19 - فيما يتعلق بعرض المحتوى المخفي: لا يوجد دعم Google جيد وقد ذكر أن الخط الأبيض في الخلفية البيضاء أو حجم الخط صفر سيكون ضد الإرشادات ولكن ماذا عن العرض: لا شيء؟

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

السؤال 25:55 - بعد الإجراء اليدوي للروابط ، ما المدة التي يتعامل معها Google مع النطاق بمجرد قبول طلب إعادة النظر ولكن لم يستعيد تصنيفاته المحتملة في حركة المرور؟

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

Question 27:59 - In looking at some of our backlink profile we had found, I don't even know how our links ended up on these pages, like on pages that have just like 7,000 links and things like that. We disavowed them when we found them. Is there anything we need to be concerned about other than doing that with when we find stuff like that?

Answer 28:20 - No that's that's essentially the right move to do and especially if it's something that you're really worried about. So I think for most websites it doesn't make sense to go out there and disavow things that are just like iffy and weird because for the most part we just ignore those. So in particular with regards to links, if it's something that when you look at it you say well this could be seen as these links be being bought by us, like naturally placed there by us, if someone from the website team were to take a look at this manually and they would assume that, this is us doing something stupid, that's the kind of thing where I'd say probably disavowing them or getting them removed would be the right move there but otherwise if it's just an iffy link and it looks like it's something like there are millions of other links on there someone ran a tool and dropped tons of links into this forum then that's something our algorithms have figured out already. So that's not something I wouldn't worry about.

Question 30:06 - What do you suggest to tackle a low traffic, low quality pages on a site? There lots of suggestions regarding content pruning what recommendations do you have regarding that?

Answer 30:20 - So I think first off the assumption that a page that has low traffic is also low quality is something that I would question and sometimes pages just have low traffic because a lot of people search for them but they're still a really good truck pages. So II would question kind of the assumption that you can just go into analytics and sort of your pages by a number of page views and delete all of the lowest pages there because I don't think that necessarily picks up like that these pages are really low quality or not. So that's kind of a first assumption there, if you know your website then obviously you can combine different metrics to try to figure out where the low quality pages are but I would still recommend making sure that these are really low quality pages before you take any kind of harsh action on those pages. And then as a next step if you do know that these are low quality pages when whenever I talk to our engineers from the quality team they tell us not to tell web masters to just go off and delete those pages but instead to going to improve them. So if you know that they're low quality pages that probably means you know what is missing and that probably means you know there are ways to kind of make these higher quality pages. So that's kind of the direction I would take there and not just delete things that are low quality but figure out a way to make them more high quality instead. So that could be by combining pages maybe it's something where you see this one-page, its kind of thin but it matches this your page and you have otherwise on your website maybe combining them makes sense. So 301 redirecting them to kind of one shared URL instead that might be an option. Rewriting them to be higher quality is obviously a good idea obviously takes work so it's not this one simple magic trick to make number one. Then finally if it's really something that you can't resolve at all or that is such a big mass of pages that are low quality that you can't really fix then maybe deleting them is it right. So those are kind of the different variations there that are available but again I would strongly question the the assumption that low traffic equals low quality. So if you're looking even looking at a larger site don't just assume that because something has low traffic is sign that it's not important for your website or for the rest of the web.

Answered Cont' 34:03 - Yeah so I think one way you could look at this is to say given this state of content that you have what would be your preferred new website look like? So kind of saying like assuming I had all of this content and I had to create a new website out of it what would it look like and then to try to find a way to migrate your existing content into this new structure that you have in mind and like I said it could improve include combining pages, combining maybe tens of different pages together into one stronger page, it could be deleting pages where you say, well these don't make any sense for my website anymore maybe it was something that users cared about a couple years ago but now, I don't know, nobody is playing ingress anymore so all of those ingress pages on my website I have to make a hard decision and delete them. I can see the shocked faces everywhere in here now. But these kind of things happen over time and it makes sense to clean things up over time and sometimes it means deleting, sometimes that means combining, sometimes that just means rewriting and cleaning up. So it's it's hard to have one one answer that works for every side in every situation.

Question 36:36 - How to fix the crawl frequency of low priority pages within a website? Will Google crawl more of such pages because the quantity of these pages is more compared to the important pages?

Answer 36:49 - So I think this was your question as well in general you don't need things the the crawl rate of pages unless these are pages that are being changed more frequently than the crawl rate. So if you have an article that you wrote and it's being crawled once every three months and you're never changing this article that's that's perfectly fine we don't need to crawl it more often. There is no ranking bonus for being crawled more often. So crawling from our site is more of a technical thing where we say, this page has changed we should find a way to pick up this change as quickly as possible. It's not that we would say well the stage has been crawled twice in the last week therefore we will rank it higher those are completely separate parts of our algorithms.

Question 37:48 - I was checking the log files and 90% of our crawl budget is going to those specific URLs only and only 10% is crawling my product pages. So I was wondering I could make them crawl less frequently for those specific sections and maybe Google can start crawling or kind of giving more importance to my other sections of a set?

Answer 38:18 - Okay so you actually want to do the opposite which is I think a good move too. To have those pages crawled less frequently. So from from our point of view there's really no way to do that. So it's something that you would need to almost attack from the other way around to say, that I think these are other pages that are important on my website and therefore I'll link them prominently within my website. I'll make sure that all of my other pages refer to those pages, that they're specifying the sitemap file with the last modification page that we can confirm. So all of those signals to help us understand we need to be able to crawl these pages more frequently because there are changes on these pages. On the other hand if there are no changes on these pages we don't really to recall them for more free company so that's kind of be the other aspect there. If these are pages that are important for you but they are not changing frequently then there's no need to artificially force them to be crawled more often.

Question 40:11 - Can you tell if with redirection only link penalty passes or link penalty and content penalties both pass for example at website with pure spam manual action is redirected to another site so technically the URLs will be a soft 404, will it affect the redirected website?

Question 40:37 - So I'm not quite sure with which part of this question you're you're kind of focusing on. On the one hand if a random spammy website redirects to your website that's usually something we can recognize and just ignore. On the other hand if yours is that spammy website and you're redirecting to another website to try to escape that penalty then probably we will be able to follow that site migration and apply that manual action or algorithmic action to the new website as well. So my recommendation there would be instead of trying to get away by doing fancy redirects or other types of site moves. I would recommend just cleaning up the issues so that you don't have to worry about those anymore. So if there are link actions with regards to that website then clean up those those links so that you're in a clean state again. The reconsideration process is great for that because someone from the web spam team will take a manual look at your website and they'll say, this looks good this is fine like. You did good work and clean things up it's clear that you understand what you should be doing now so we can remove them. So I think that's really useful to have there from a practical point of view. So that would be kind of my recommendation if you're the website that has this problem. On the other hand if like I mentioned some random website redirects to your website and that's usually something that we can recognize, this is not a normal site move this is just the read website redirecting to you to another website and we can get that.

Question 42:30 - John two quick general questions one related to site load speed, we've read and heard various things including recently people saying that like every microsecond counts and things like that, what is the current policy I know in the past you said as long as it's not ridiculously long to load you're fine?

Answer 42:53 - What is the current policy? So speed is something that does matter quite a bit to us and it has a big effect on users so that's something that I would personally take quite seriously and I think the the nice part about speed is there various tools that gives you pretty objective measures there that you can actually work on. With regards to a lot of us or other issues around SEO like, I don't know the quality of their content things like that speed is something that that is quite measurable and something that you can kind of work on, and it should also be something we're used a direct effect from your users behavior within your website. So it's not just something that from from Google's point of view like we say speed is important it is rank tracker but it's something that you will see directly when users come to your website and your website is suddenly taking a couple seconds longer to load those users will react quite differently on your website and you'll have more trouble converting them into customers however you define customers on your website.

Question 44:08 - From the standpoint of like if it's 1.1 seconds versus 1.2 second that kind of thing would would you say that that's very important to try to really optimize those?

Answer 44:21 - I think the tricky part with speed is there's so many different measures in the meantime that it's hard for me to say like, load time is the only thing you should be thinking about, but there ways to to kind of determine how quickly the page is is generally accessible. How quickly they the content is visible on the page, even kind of ignoring the aspect that maybe the rest of the page below the fold is still rendering and still takes a bit of time to actually be ready, maybe the part that users care about is actually visible fairly quickly. So from from that point of view usually small differences are less of a thing but kind of like I mentioned speed is something where you can use these different tools who could come up with a different metrics and you can focus on those metrics and try to improve those and you can measure that yourself and you can kind of work on that without having to go through various Google tools and waiting for things to update in the index in these tools.

Question 45:47 - Can I use Google official videos in my blog or can I only link to them for example Matt Cutts videos about SEO. I will use Adsense on the blog when I have enough adsense my blog will be complete in 6 months.

Answer 46:03 - I don't think there are any restrictions with regards to embedding videos for a channel but if there were no restrictions then I think the embed option YouTube wouldn't be available there. So if the embed option is there then then go for it. I think in in general I'd be cautious about using just a video as the primary piece of content on a web page and you should really work to kind of use the video in a way that supports your primary content but not that it replaces your primary. So for example I wouldn't take any of these videos and just put them on a blog post and add a title to them and expect them to show up highly in search. But if you have specific content around that video if you have a transcription of that many don't you have some comments to that transcription to the content that are shown in the video or you're using that video as kind of a point of reference with regards to your content and I think that's a perfectly fine approach. But just purely using a video on a page is something that atleast in a web search point view makes it really hard for us to determine what is actually useful on this page and why should we show it in the search results.

Question 47:27 - If I pay for Google Ads will my ranking be better or worse?

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