19 فبراير 2019 - Google Help Hangout Notes
نشرت: 2019-02-26إنها جلسة Hangout أخرى لمساعدة مشرفي المواقع ، مع رجلنا الرئيسي ، جون مولر. هذا الأسبوع كان لديه بعض الأفكار الرائعة حول الروابط وسرعة الصفحة و UTM والروابط التابعة. كما هو الحال دائمًا ، يمكن العثور على مقطع الفيديو والنسخة الكاملة أدناه. أيضًا إذا وجدت هذه الملخصات مفيدة ، فعليك التحقق من نشرتنا الإخبارية! نحن نجمع وننظم جميع أفضل مقالات تحسين محركات البحث في الأسبوع ونلخصها لك في ملخصات سريعة وسهلة الهضم.
إذا سبق لك اتخاذ إجراء يدوي بشأن روابط غير طبيعية ، فهل سيؤدي ذلك إلى وصم الموقع إلى الأبد؟
5:20
من الصعب التحدث أحيانًا ولكن بشكل عام إذا تم حل إجراء يدوي ، فلن يؤثر هذا الإجراء اليدوي على الموقع بعد الآن. لذلك لا يوجد أي نوع من تأثير التراجع الذي من شأنه أن يبقي موقع الويب متوقفًا ويحب القول ، حسنًا ، لقد فعلوا نفس الأشياء بشكل خاطئ ، وبالتالي سنمنعهم مرة واحدة من الظهور في مكان مرتفع في البحث ، فلا يوجد شيء من هذا القبيل. ولكن على وجه الخصوص عندما يتعلق الأمر بالروابط إذا كان لديك الكثير من الروابط المخالفة وربما كان موقعك يحتل مرتبة بسبب تلك الروابط غير الطبيعية بدلاً من تنظيف تلك الروابط غير الطبيعية ، فهناك بالطبع موقف جديد يتعين على خوارزمياتنا التكيف معه نوعًا ما أول. لذلك هذا شيء يمكن أن يكون له تأثير هناك إلى حد ما. والطريقة التي سأتعامل بها مع هذا هي فقط مواصلة العمل على موقع الويب بالطريقة المعتادة والتأكد من عدم مواجهة هذا الموقف مرة أخرى حيث يعمل فريق البريد العشوائي على الويب عبر المشكلات المتعلقة بالروابط الخاصة بك. لذلك لا تحب الانطلاق والقول مثل ، لقد أزلت هذه الروابط ، لذا سأذهب لشراء بعض الروابط من موقع آخر بدلاً من ذلك ، وتأكد نوعًا من أن ما تفعله هو حقًا للاستخدام طويل المدى لموقعك على الويب .
ملخص: بمجرد إزالة الإجراء اليدوي ، يتم إزالته بالكامل. ومع ذلك ، لا تزال الروابط غير الطبيعية لديها القدرة على إلحاق الضرر بالموقع بطريقة حسابية. قد يستغرق هذا وقتًا طويلاً للتوضيح.
إذا تم تحميل موقعك بسرعة للمستخدمين ، ولكن أداة PageSpeed Insights من Google تصفه بأنه بطيء ، فهل يجب اتخاذ إجراء؟
11:29
لذلك يتم تقديم الكثير من هذه المقاييس التي تنظر إليها من المنارة بشكل أساسي لك فيما يتعلق بنوع المستخدم الذي يواجه جانبًا من الأشياء. لذلك من وجهة نظرنا من وجهة نظر البحث ، نأخذ مجموعة متنوعة من هذه المقاييس معًا لمعرفة كيف يجب أن نرى الموقع فيما يتعلق بالسرعة ولكن نوع القياسات المطلقة التي تراها هناك في المنارة هي الأشياء التي من المرجح أن يكون لها تأثير أقوى على كيفية رؤية المستخدمين لموقعك. لذا فبدلاً من سؤال Google فيما يتعلق بـ SEO ، هل هذا الموقع بطيء جدًا ، أود أن أنظر إليه مع المستخدمين ونوعًا من الحصول على تعليقاتهم بدلاً من ذلك ، وإذا كنت تقول أن موقعك سريع جدًا للمستخدمين ، فإنه يوفر المحتوى بسرعة إلى حد ما ، فمن المحتمل أنك في حالة جيدة هناك.
الملخص: الأهم هو ما إذا كانت صفحاتك يتم تحميلها بسرعة للمستخدمين الفعليين.
ملاحظتك فكرنا الحالي هو أننا نرغب في رؤية تحسينات سرعة الصفحة للمواقع التي لديها درجات منخفضة من "الرسم الأول للمحتوى" على Lighthouse حيث أن هذا الرقم هو تقريب للمدة التي يستغرقها المحتوى الذي يمكن قراءته للظهور.
إذا تم تصنيف الصفحة لكلمات رئيسية معينة ، وقمت بإعادة توجيهها إلى صفحة جديدة ، فهل ستكون هذه الصفحة قادرة على تصنيف هذه الكلمات الرئيسية؟
16:25
لذلك فإننا نحاول أساسًا إذا كان بإمكاننا حقًا نقل كل شيء واحد إلى آخر إلى المجال الجديد ، فسيكون هذا المجال الجديد بدلاً من المجال الأقدم. ويمكنه ترتيب الكلمات الرئيسية القديمة ويمكنه ترتيب الكلمات الرئيسية الجديدة ومرة أخرى إذا قمت بإجراء تغييرات مهمة أثناء هذه الخطوة ، فبالطبع يجب أخذ هذه الحالة الجديدة في الاعتبار وليس الأمر كما لو أنه يمكننا إعادة توجيه كل شيء إلى الجديد واحد لأن الإصدار الجديد ليس مجرد نسخة منقولة من القديم.
ملخص: عندما ترى Google الروابط تمر عبر إعادة توجيه ، فإنها تحاول تحديد ما إذا كان سيتم تمرير إشارات الارتباط معها أم لا. إذا كانت الصفحة الجديدة متشابهة ، فهناك فرصة جيدة لأن تمر إشارات الارتباط التي تشير إلى الصفحة السابقة أيضًا.
هل من المقبول استخدام معلمات UTM على الروابط الداخلية؟
17:33
أعتقد أن هذا دائمًا موقف صعب بعض الشيء لأنك تعطينا إشارات مختلطة بشكل أساسي. من ناحية أخرى ، أنت تقول أن هذه هي الروابط التي أريد فهرستها لأن هذه هي الطريقة التي تربط بها داخليًا داخل موقع الويب الخاص بك. من ناحية أخرى ، فإن تلك الصفحات عند فتحها يكون لديها rel canonical يشير إلى عنوان URL مختلف. إذاً فأنت تقول فهرس هذا ومن ذلك الذي تقوله جيدًا ، افهرس مؤشرًا مختلفًا. لذا فإن ما تفعله أنظمتنا هناك هو أنها تحاول الموازنة بين الأنواع المختلفة لعناوين URL التي نجدها لهذا المحتوى. يمكننا على الأرجح أن ندرك أن هذا المحتوى تؤدي عناوين URL هذه إلى نفس المحتوى. لذلك يمكننا نوعًا ما وضعها في نفس المجموعة ثم الأمر يتعلق باختيار أي واحد لاستخدامه فعليًا للفهرسة ومن ناحية أخرى لدينا الروابط الداخلية التي تشير إلى إصدارات UTM ، ومن ناحية أخرى لدينا rel canonical مشيرا إلى نوع النسخة الأنظف. من المحتمل أن يكون الإصدار الأكثر نظافة هو أيضًا عنوان URL أقصر وعنوان URL أكثر جمالًا يتم تشغيله بشكل مضمّن معنا أيضًا ، لكنه لا يزال غير مضمون من وجهة نظرنا أننا سنستخدم دائمًا الأقصر.
لذا من الواضح أن rel canonical هو إشارة قوية لأن الارتباط الداخلي يعد أيضًا نوعًا من الإشارة الأقوى ، من حيث أن هذا شيء تحت سيطرتك. لذلك إذا قمت بالربط صراحةً بعناوين URL هذه ونعتقد أنك تريد فهرستها على هذا النحو. لذا من الناحية العملية ، ما قد يحدث هنا على الأرجح هو أننا سنقوم بفهرسة مزيج من عناوين URL ، وبعضها نقوم بفهرسة النسخة الأقصر لأننا ربما نجد إشارات أخرى تشير إلى الإصدار الأقصر أيضًا. ربما نفهرس بعضها بإصدار UTM وسنحاول ترتيبها بشكل طبيعي كإصدار UTM.
من الناحية العملية في البحث ، لن ترى أي اختلاف في الترتيب ، سترى فقط أن عناوين URL هذه قد تظهر في نتائج البحث. لذلك سيتم تصنيفهم تمامًا مع UTM أو بدون UTM وسيتم إدراجهم بشكل فردي في نتائج البحث. ومن وجهة نظر عملية ، فهذا يعني فقط أنه في وحدة تحكم البحث قد ترى مزيجًا من عناوين URL هذه. قد ترى نوعًا من هذا المزيج في تقرير الأداء. في تقرير الفهرسة ، قد ترى مزيجًا في بعض التقارير الأخرى. ربما حول AMP أو البيانات المنظمة إذا كنت تستخدم أي شيء من هذا القبيل ، فقد ترى أيضًا هذا المزيج. قد ترى أيضًا في بعض الحالات موقفًا يتم فيه التبديل بين عناوين URL ، لذا قد نقوم بفهرسته باستخدام معلمات UTM في وقت ما ثم بعد ذلك بأسبوعين إذا انتقلنا إلى الإصدار الأنظف ونقول ، ربما يكون هذا الإصدار الأنظف أفضل ، ثم في مرحلة ما لاحقًا أو خوارزمية للنظر إليه مرة أخرى والقول جيدًا في الواقع تشير المزيد من الإشارات إلى إصدار UTM الذي سنقوم بالرجوع إليه ، وقد يحدث ذلك من الناحية النظرية أيضًا.
لذا فإن ما أوصي به هناك هو إذا كان لديك تفضيل فيما يتعلق بعناوين url الخاصة بك ، فتأكد من أنك واضح قدر الإمكان داخل موقع الويب الخاص بك حول الإصدار الذي تريد فهرسته. باستخدام معلمات UTM ، أنت أيضًا تنشئ الموقف الذي يتعين علينا الزحف إليه في كلا الإصدارين ، لذا يكون الأمر أكثر قليلاً إذا كان مجرد إصدار إضافي واحد ربما لا يكون بهذه الأهمية. إذا كان لديك العديد من معلمات UTM التي تستخدمها عبر موقع الويب ، فسنحاول الزحف إلى جميع الأشكال المختلفة والتي بدورها قد تعني أننا ربما نقوم بالزحف ، لا أعرف ، ضعف عدد عناوين URL مثل موقع الويب الخاص بك في الواقع يجب أن يكون قادرًا على مواكبة الفهرسة. لذلك ربما هذا شيء تريد تجنبه. لذا فإن توصيتي ستكون حقًا محاولة تنظيف ذلك قدر الإمكان ، حتى نتمكن من الالتزام بعناوين URL النظيفة. إلى عناوين URL التي تريد فهرستها بدلاً من أن ينتهي بها الأمر في هذه الحالة حيث ربما نلتقطها بهذه الطريقة ، ربما نلتقطها بهذه الطريقة ، وفي تقاريرك قد تكون هكذا ، قد تكون مثله. عليك أن تنتبه لذلك طوال الوقت. لذا اجعلها بسيطة قدر الإمكان.
ملخص: كن حذرًا. توضح الروابط الداخلية لـ Google الصفحات المهمة على موقعك. إذا قمت بالارتباط بصفحات تحتوي على معلمات UTM ، فقد ينتهي بك الأمر إلى قيام Google بالزحف إلى عناوين URL متعددة تحتوي على نفس المحتوى. هذه ليست مشكلة لصفحتين ، ولكن من المحتمل أن تؤثر على قدرة Google على الزحف إلى الموقع إذا تم القيام به على نطاق واسع.
وضح تمامًا ما هي النسخة المتعارف عليها بحيث تنتقل جميع الإشارات إلى تلك الصفحة. ما يلي سوف يساعد:
- استخدم علامة أساسية في جميع إصدارات الصفحة تشير إلى عنوان url غير بتنسيق utm
- تأكد من أن المحتوى في كل نسخة من الصفحة هو نفسه
هل من المقبول إظهار نص رابط مختلف لبرنامج Googlebot على الروابط عما يراه المستخدمون الفعليون؟
23:08
لذلك من المفترض أن يرى Googlebot الإصدار المكافئ للصفحة كما يراه المستخدمون. لذا ، إذا كان هذا مفيدًا للمستخدمين ، فإنني أوصي بعرضه على Googlebot أيضًا. إنه شيء إذا كنت تتحدث عن السرعة التي تتطلبها لعرض هذه الصفحات ، فمن الجدير أن نأخذ في الاعتبار أننا ننظر إلى السرعة بطريقة شاملة لا ننظر فقط إلى سرعة الصفحة مثل Googlebot جلب تلك الصفحة عندما يتعلق الأمر بالسرعة فيما يتعلق باستخدام السرعة كعامل ترتيب. للزحف بالطبع ، وجود الصفحات المتوفرة بسرعة كبيرة والتي تساعدنا كثيرًا بحيث يكون من المنطقي جعل الأشياء سريعة بالنسبة لـ Google للزحف على الأقل. هناك شيء واحد أوصي به هنا وهو محاولة تجنب غلاف Googlebot الخاص إذا كان ذلك ممكنًا لأنه يعني أن الصيانة أصعب كثيرًا. إذا كنت تقوم بعمل خاص لبرنامج Googlebot ، فسيكون من الصعب جدًا معرفة ما إذا كان Googlebot يرى أخطاء في الصفحة ويشاهد المستخدمون محتوى عاديًا ويبدأ Googlebot في إسقاط هذه الصفحات من البحث بسبب هذه الأخطاء. لذلك من الناحية المثالية ، عاملهم كثيرًا مثلهم مثل المستخدمين. إحدى الطرق للقيام بذلك هنا هي استخدام نوع من JavaScript لتحميل هذه المعلومات الإضافية بشكل غير متزامن. لذلك عادةً ما يكون هذا الأمر سهل التنفيذ وربما يكون جهدًا أقل من إخفاء الهوية لبرنامج Googlebot في حالة كهذه.
ملخص: لا. أنت لا تريد إنشاء حالات خاصة حيث يرى Googlebot محتوى مختلفًا عن المستخدم العادي.
ملاحظتنا: يمكن اعتبار ذلك إخفاءً للهوية وقد يتسبب في تسرب الصفحات من الفهرس.
إذا كانت هناك روابط تشير إلى الصفحة "أ" وكانت الصفحة "أ" متعارف عليها إلى الصفحة "ب" ، فهل يرى محرك البحث Google هذه الروابط على أنها تشير إلى الصفحة "ب"؟
26:18
لذا من وجهة نظرنا ، هناك العديد من الأشياء التي لعبت دورها هنا. أعتقد أولاً أن هذه الصفحات يجب أن تكون متكافئة إذا كنت تقول أن هناك صفحة أساسية لتلك الصفحة يجب أن تكون مكافئة للصفحة الأخيرة أيضًا. لذلك لا يهم أي من هذه الصفحات يتم استخدامها لإعادة توجيه الروابط لأنك تخبرنا أن هذه الصفحات هي نفسها التي يمكننا التعامل معها بنفس الطريقة. لذلك لا يهم بالنسبة لخوارزمياتنا مثل ما إذا كنا نلتقط تلك الروابط من تلك الصفحة أو نلتقط الروابط من الصفحة الأخرى. لذلك أفترض أيضًا أنه ليس دائمًا نوعًا ما يشبه السؤال الآخر مع معلمات UTM ، سنختار عنوان URL المحدد على أنه أساسي مثل العنوان الذي نقوم بفهرسته بالفعل. لذلك إذا كانت هذه الروابط مختلفة عبر إصدارات الصفحات ، فهذا شيء قد لا نجتاز فيه نظام ترتيب الصفحات بالطريقة التي تتوقعها. إذن كل هذا النوع يأتي معًا ومن وجهة نظري ما أوصي به هو التأكد حقًا من أن هذه الصفحات متكافئة. بحيث لا داعي للقلق بشأن من أين ، وما هي الروابط التي تتجاوز نظام ترتيب الصفحات. لكن افترض بدلاً من ذلك أنه يمكن أن تكون هذه الصفحة ، قد تكون الصفحة الأخرى ، فإن rel canonical هو إشارة قوية بالنسبة لنا ولكنه ليس توجيهًا يمنعنا من استخدام تلك الصفحة بالكامل.
ملخص: إذا كانت الصفحات متكافئة حقًا ، فعندئذٍ نعم ، ستساعد الروابط التي تشير إلى الصفحة "أ" في دعم الصفحة "ب".
هل يجب عليك إنشاء موقع ويب منفصل لكل بلد تريد أن تتم رؤيته فيه؟
26:58
لذا فإن الإجابة المختصرة هي "لا" ، فهذه فكرة سيئة. خاصة إذا لم يكن لديك حقًا محتوى فريد لكل بلد في العالم. على وجه الخصوص ، إذا كنت تستخدم hreflang بين إصدارات البلد واللغات المختلفة. عليك أن تضع في اعتبارك أن hreflang لا تجعل تلك الصفحات في مرتبة أعلى في تلك البلدان ، فهي تقوم فقط بتبديل عناوين URL تلك. لذلك لا يزال عليك أن تكون قادرًا على الترتيب في تلك المواقع الفردية. مما يعني أنه إذا كان لديك جزء واحد من المحتوى وقمت بتقسيمه عبر كل بلد في العالم وضربته في كل لغة ، فستخفف محتوياتك بشكل كبير عبر عدد كبير من عناوين URL. مما يعني أن أي جزء من المحتوى سيكون هناك الكثير من المشاكل التي تظهر في نتائج البحث. لأنه بدلاً من صفحة واحدة قوية يمكن أن نعرضها في جميع أنحاء العالم ، لدينا عدد كبير من الصفحات المختلفة التي تعرض جميعها نفس المحتوى بشكل أو بآخر وليس أي منها قوي بشكل خاص. لذلك عندما يتعلق الأمر باستراتيجية التدويل ، فإنني أوصي بشدة بالحصول على المساعدة من الأشخاص الذين فعلوا ذلك بنجاح لمواقع الويب الأخرى. حتى تتمكن من الموازنة بين الإيجابيات والسلبيات هناك. من ناحية ، لديك ميزة القدرة على استهداف البلدان واللغات الفردية بمحتوى فريد من نوعه حقًا مخصص لها ، ومن ناحية أخرى ، عليك أن تزن ذلك إذا كنت تخفف المحتوى كثيرًا ، فكل هؤلاء ستواجه الإصدارات وقتًا أكثر صعوبة لتظهر في البحث. لذا فمن ناحية ، الاستهداف الجيد من ناحية أخرى هو نوع من التأكد من أن الإصدارات المتوفرة لديك قوية بما يكفي لتكون مرئية بالفعل في البحث وأعتقد بشكل عام أن هناك خطأ في جانب استخدام إصدارات أقل بدلاً من باستخدام المزيد من الإصدارات. لذلك ، ما لم تكن لديك حالة استخدام قوية حقًا لوجود محتوى يستهدف البلدان الفردية على وجه التحديد ، وأنا أخطئ إلى جانب أنه ربما يكون موقع ويب عالمي واحدًا أفضل من تقسيم الأشياء.
الملخص: في معظم الحالات ، من المنطقي أن يكون لديك موقع ويب واحد فقط وأن تستخدم hreflang بالشكل المناسب لمساعدة Google في إظهار الإصدار الصحيح. قد تكون هناك بعض الحالات التي يكون فيها من المنطقي أن يكون لديك مواقع ويب ذات نطاقات TLD منفصلة على مستوى الدولة. غالبًا ما يكون هذا قرارًا صعبًا. ينصح جون بالتشاور مع أحد كبار المسئولين الاقتصاديين الذي لديه خبرة في التدويل.
هل يمكنك استخدام مخطط التصنيف ومخطط الأسئلة والأجوبة على نفس المحتوى؟
29:33
بالتأكيد لا أرى مرتجلاً لما لا. الشيء الرئيسي الذي يجب أخذه في الاعتبار هو أن البيانات المنظمة يجب أن تركز على المحتوى الأساسي للصفحة. لذلك لا أعرف بالضبط كيف ستجمع نوعًا ما بين التصنيف ومخطط ضمان الجودة على إحدى الصفحات ، لكن ربما يكون الأمر كما لو كان لديك أسئلة وإجابات لمنتج ولديك تقييمات في هذا المنتج أيضًا. قد يكون هذا خيارًا هناك ولكن بشكل عام لا يعني أن هذه الأنواع من العلامات حصرية ولا يمكنك استخدام سوى نوع واحد يمكنك دمج أنواع متعددة من الترميز.
ملخص: نعم
هل يُنظر إلى الروابط التابعة على أنها علامة على موقع ويب منخفض الجودة؟
41:05
لذلك بشكل عام ، هذا ليس بقدر ما أعلم أننا لا ندخل صراحة إلى الموقع ونقول ، حسنًا ، هناك روابط تشبه الروابط التابعة ، لذلك سنتعامل مع هذا الموقع على أنه أقل جودة. بشكل عام ، القضايا الرئيسية التي أراها فيما يتعلق بالمواقع التابعة هي أنها تميل إلى أن تكون أقل جودة فقط. لذلك ، لا يتعلق الأمر بمكان تدفق عملية التحقق ، بل يتعلق الأمر بشكل عام بأن المحتوى غالبًا ما يكون ذا جودة منخفضة ، وبسبب المحتوى منخفض الجودة ، فهذا شيء قد تلتقطه خوارزمياتنا وتقول ، حسنًا ، هذا على الأرجح ليس كذلك النتيجة الأكثر صلة التي يتم عرضها في نتائج البحث ، ويمكن أن تكون هناك مواقع ويب تابعة عالية الجودة وأيها جيدة. لذا فإن الأمر لا يتعلق كثيرًا بما إذا كان هناك ارتباط تابع أم لا ، ولكن بالأحرى مثل ماذا عن بقية الموقع؟ هل هذا شيء من شأنه أن يكون مناسبًا لعرضه على المستخدمين أم أن هناك شيئًا ربما يمثل مشكلة هناك؟ أعتقد ، على الأقل بقدر ما أعلم ، أنه سيتم تطبيقه في جميع المجالات ، لذلك لن يكون من المهم حقًا ما هو مجال الموضوع المحدد لموقع الويب ولكن بشكل عام هناك بعض المواقع التابعة الجيدة حقًا وهناك بعض المواقع الرهيبة حقًا المواقع التابعة. إذن فالأمر يتعلق أكثر بالموقع الجيد أم أن الموقع سيئ؟
الملخص: لا يعد وجود الروابط التابعة علامة على تدني الجودة. ومع ذلك ، إذا كان لديك موقع تابع ، من أجل الحصول على ترتيب جيد ، يجب أن تقدم قيمة كافية حتى ترغب Google في ترتيب المحتوى الخاص بك إلى جانب محتوى البائع الأصلي.
إذا تلقى موقعك تدفقًا من الروابط غير ذات الصلة ، فهل يجب التنصل منها؟
47:01
بالتأكيد يمكنك فعل ذلك. نعم ، هذا نوع من الغرض من إدخال المجال في ملف التنصل ، وبهذه الطريقة يشبه كل هذه الملايين أو الآلاف من الروابط ، يمكنك فقط قول كل شيء من هذا الموقع ليس لدي أي علاقة بذلك. عادةً ما يحدث في مثل هذه الحالات التي ترى فيها ارتباطًا عشوائيًا تمامًا بالموقع هو أنه من المحتمل أن يكون هذا الموقع قد تعرض للاختراق ولأي سبب قرر شخص ما إسقاط كل هذه الروابط هناك عند اختراق موقع الويب وعادة ما نكون جيدًا في اختيار ذلك ومحاولة منع الدولة من قبل اختراق أنظمتنا. لذلك ربما نتجاهل بالفعل هذه الروابط ، فمن الممكن أن يكون موقع الويب أو حتى فهرسته من قبل بدلاً من المحتوى الذي تم الاستيلاء عليه. هذا شيء لا أقلق فيه كثيرًا لأن هذا النوع من الاختراقات شائع حقًا ولدينا القليل من التدريب في محاولة للتعامل مع ذلك. ولكن إذا كنت قلقًا بشأن هذا الأمر ، فأنت تعلم أن هذا أمر مجنون حقًا وأعتقد أن روابط إصلاح الأجهزة ربما لا تكون شيئًا ترغب في قوله ، أوه هذا سيقتل موقع الويب الخاص بي إذا كنت مرتبطًا بالكمان ، ربما يكون محتوى البالغين شيئًا تكون أكثر حذرًا بشأنه ، ثم سأستخدم ملف التنصل فقط ، وأرسله وأنت متأكد من أنه لم يتم أخذها في الاعتبار. \
ملخص: في معظم الحالات مثل هذه ، تتجاهل Google بالفعل التدفق غير المعتاد للروابط. من المثير للاهتمام ملاحظة أن جون أوصى بأنه قد يكون من الجيد التنصل إذا كانت هذه الروابط ذات طبيعة خاصة بالبالغين على سبيل المثال ، إذا تلقى موقع إصلاح الموسيقى الخاص بك آلاف الروابط غير الطبيعية التي تشير إليها باستخدام "إصلاح الكمان" ، فقد ترغب في التنصل منها.
إذا كنت تحب أشياء مثل هذه ، فستحب رسالتي الإخبارية!
أبلغ أنا وفريقي كل أسبوع عن آخر تحديثات خوارزمية Google والأخبار ونصائح تحسين محركات البحث.
النجاح!! تحقق الآن من بريدك الإلكتروني لتأكيد اشتراكك في Google Update Newsletter.
فيديو كامل ونسخة
السؤال 1:25 - هل ستقوم رؤوس X robots meta HTTP بإيقاف Google بعد إعادة توجيه الموقع مثل 301 أو 302؟
الإجابة 1:37 - لا. لذا فإن nofollow ينطبق فقط على الروابط الموجودة في تلك الصفحة ، وبما أنها إعادة توجيه من جانب الخادم ، فلن ننظر حتى إلى محتوى الصفحة. لذلك لن تكون هناك روابط نتبعها حتى لا يغير ذلك أي شيء.
السؤال 1:58 - أحد عملائنا هو متجر للتجارة الإلكترونية. لقد تم حظرهم من قبل العديد من مزودي خدمة الإنترنت ومزودي خدمة الإنترنت المتنقلين وتساءلنا عن كيفية تأثير تصنيفاتهم العضوية.
الإجابة 2:15 - لذلك أعتقد أن الشيء الرئيسي من وجهة نظرنا هو ما إذا كان Googlebot سيتم حظره أيضًا أم لا ، وإذا لم يتم حظر Googlebot ، فسنكون قادرين على الزحف إلى فهرس المحتوى بشكل طبيعي. ولكن بالطبع إذا تم حظر Googlebot أيضًا لأنه ، لا أعرف أنه محظور ، في الولايات المتحدة على سبيل المثال ، فسيؤدي ذلك بالطبع إلى استبعاد هذه الصفحات من البحث. ولكن إذا كان الأمر يتعلق فقط بالمستخدمين الفرديين ، فأنا لا أملك حق الوصول إلى ذلك ، وكانت الفهرسة والزحف على خلاف ذلك يعملان بشكل طبيعي ، فعادة ما تكون هذه مشكلة أقل ، بالطبع ، لديك نوع من التأثيرات غير المباشرة التي لن يتمكن هؤلاء المستخدمون من التوصية بالموقع و لن نتمكن من اختيار تلك التوصيات لأنها ليست موجودة من هؤلاء المستخدمين. لذلك من الواضح أنك إذا كنت تحظر معظم المستخدمين على موقعك ، فسيذهب ذلك إلى موقع الويب الخاص بك والذي من المحتمل أن يكون له تأثير طويل المدى على الموقع.
الإجابة 3:25 - وهذا شيء تفعله بعض المواقع عن قصد ليس خاصة مستخدمي الهاتف المحمول مقابل سطح المكتب ولكن بعض المواقع ستقول ، ليس لدي أي شيء يمكنني تقديمه للمستخدمين في هذه البلدان الفردية أو لأي سبب من أسباب السياسة المحتوى الخاص بي غير قانوني في سويسرا لأنه ليس محايدًا بدرجة كافية أو أيًا كان ، فقد يختار هذا الموقع حظر المستخدمين في تلك البلدان ولا يزال هذا أمرًا يتعين علينا التعامل معه. لذلك لن يتمكن هؤلاء المستخدمون من التوصية به ، فقد يكون هناك بعض التأثيرات طويلة المدى هناك ، ولكن إذا كان لا يزال بإمكاننا الزحف إلى المحتوى وفهرسته ، فهذا جيد بشكل عام.
كان لدينا دليل إجراء بسبب الروابط. كنا نتسلق ببطء إلى أسفل الصفحة 1 في بعض الأحيان إلى أعلى الصفحة 2. كنت أتساءل عما إذا كان ذلك بسبب نقص الروابط الآن أم أن هناك شيئًا يمكننا القيام به لاستعادة تلك الثقة حتى نتمكن من العودة إلى موقعنا موقف الأصلي؟
الإجابة 5:20 - يصعب التحدث أحيانًا ولكن بشكل عام إذا تم حل إجراء يدوي ، فلن يؤثر هذا الإجراء اليدوي على الموقع بعد الآن. لذلك لا يوجد أي نوع من تأثير التراجع الذي من شأنه أن يبقي موقع الويب متوقفًا ويحب القول ، حسنًا ، لقد فعلوا نفس الأشياء بشكل خاطئ ، وبالتالي سنمنعهم مرة واحدة من الظهور في مكان مرتفع في البحث ، فلا يوجد شيء من هذا القبيل. ولكن على وجه الخصوص عندما يتعلق الأمر بالروابط إذا كان لديك الكثير من الروابط المخالفة وربما كان موقعك يحتل مرتبة بسبب تلك الروابط غير الطبيعية بدلاً من تنظيف تلك الروابط غير الطبيعية ، فهناك بالطبع موقف جديد يتعين على خوارزمياتنا التكيف معه نوعًا ما أول. لذلك هذا شيء يمكن أن يكون له تأثير هناك إلى حد ما. والطريقة التي سأتعامل بها مع هذا هي فقط مواصلة العمل على موقع الويب بالطريقة المعتادة والتأكد من عدم مواجهة هذا الموقف مرة أخرى حيث يعمل فريق البريد العشوائي على الويب عبر المشكلات المتعلقة بالروابط الخاصة بك. لذلك لا تحب الانطلاق والقول مثل ، لقد أزلت هذه الروابط ، لذا سأذهب لشراء بعض الروابط من موقع آخر بدلاً من ذلك ، وتأكد نوعًا من أن ما تفعله هو حقًا للاستخدام طويل المدى لموقعك على الويب .
السؤال 7:32 - يدور السؤال بشكل عام حول موقع ويب تم نقله إلى اسم مجال مختلف وقاموا بنقل إطار عمل مختلف وأيضًا إلى نظام أساسي مختلف من خلال موقع زاوي بدلاً من موقع HTML ثابت ومنذ قيامهم بهذا الانتقال قاموا شهدنا انخفاضًا كبيرًا في التصنيفات ، من أجل الرؤية في البحث بشكل عام.
الإجابة 7:57 - لقد نظرت إلى مجموعة من المواضيع من موقع الويب وأحاول المتابعة مع بعض الأشياء داخليًا لمعرفة ما يحدث بالضبط هنا وهو نوع من الموقف المعقد حيث لا أملك حقًا إجابة مباشرة. على وجه الخصوص ، هناك الانتقال من نوع نطاق المستوى الأعلى لرمز الدولة إلى نطاق المستوى الأعلى العام ، لذلك يتم فقد نوع من معلومات الاستهداف الجغرافي قليلاً هناك. كانت هناك بعض المشكلات في البداية تتعلق بالقدرة على فهرسة المحتوى على الإطلاق. على وجه الخصوص في الموقع الجديد وهناك بعض التغييرات المهمة في طريقة تقديم المحتوى على الموقع الجديد مقارنة بالموقع القديم. لذلك بشكل عام ، هناك الكثير من التغييرات المهمة جدًا على طول الطريق وبعضها كان يمثل مشكلة مثل عدم القدرة على فهرسة المحتوى وبعضها كان مجرد تغيير في الطريقة التي يمكن أن تحدث بشكل طبيعي على موقع ويب حيث يمكنك تغيير المحتوى بشكل كبير على سبيل المثال. وأعتقد أن ما يحدث هنا هو أن كل هذه التغييرات جعلت من الصعب إلى حد ما على خوارزمياتنا اكتشاف المرحلة المستقرة الجديدة لهذا الموقع ، وربما يكون الأمر مجرد شيء يستغرق وقتًا أطول بكثير مما تستغرقه عملية نقل الموقع العادية . لذلك أعتقد أن هذا هو أحد تلك المواقف الحذرة حيث تريد إجراء مجموعة من التغييرات وإجراء تغييرات مهمة إلى حد ما دفعة واحدة ، فأنت تسبب الكثير من الارتباك فيما يتعلق بخوارزمياتنا. حيث قد يكون من المنطقي اتخاذ هذه التغييرات خطوة بخطوة لاختبارها بشكل فردي لمعرفة أن كل خطوة بينهما تعمل كما ينبغي حتى تكون متأكدًا من أن السلسلة الكاملة للتغييرات التي تجريها لا تنتج بالضرورة في تأثيرات سلبية أكبر فيما يتعلق بالبحث. لذلك أعتقد أن توصيتي هنا هي الاستمرار في ذلك ومواصلة النظر في الموقع الذي يعمل على الموقع لتحسينه. أعتقد من وجهة نظر الفهرسة أنك في حالة جيدة جدًا ، فأنت تستخدم نوعًا من العرض المسبق من جانب الخادم مما يجعل من الممكن لنا التقاط المحتوى بسرعة إلى حد ما. يبدو أنك أجريت بعض التغييرات المهمة على سرعة موقع الويب بشكل عام ، لذا يعد هذا تغييرًا إيجابيًا أيضًا. وأظن أن كل هذه الأشياء ستتراكم بمرور الوقت لتنعكس نوعًا ما في البحث أيضًا. أتمنى أن تتم معالجة هذا النوع من التغييرات بشكل أسرع قليلاً ، لذلك كنت أتواصل مع بعض الأشخاص في جانب هندسة البحث أيضًا للتحقق مرة أخرى من أن كل شيء يعمل كما هو متوقع هناك. ولكن بشكل عام مع وجود الكثير من التغييرات الوعرة على الموقع والانتقال إلى مجال مختلف ، يمكن أن تجعل كل هذه الأشياء من الصعب بعض الشيء إنشاء موقع.
السؤال 11:03 - لدينا محتوى ذي مغزى جيد أولًا لمدة ثانيتين ، لكن وقت التفاعل بين 12 إلى 15 ثانية يتأثر بكمية كبيرة من البرامج النصية وفقًا للمنارة على الرغم من تحميلها بسرعة كبيرة للمستخدمين. نحن على وشك إطلاق موقع ويب جديد ونتساءل عما إذا كان من الضروري إصلاح ذلك قبل الإطلاق أم أنه يمكن الانتظار بضعة أشهر ، كيف ترى Google الوقت للتفاعل؟
الإجابة 11:29 - لذا فإن الكثير من هذه المقاييس التي تنظر إليها من المنارة يتم تقديمها لك بشكل أساسي فيما يتعلق بنوع المستخدم الذي يواجه جانبًا من الأشياء. لذلك من وجهة نظرنا من وجهة نظر البحث ، نأخذ مجموعة متنوعة من هذه المقاييس معًا لمعرفة كيف يجب أن نرى الموقع فيما يتعلق بالسرعة ولكن نوع القياسات المطلقة التي تراها هناك في المنارة هي الأشياء التي من المرجح أن يكون لها تأثير أقوى على كيفية رؤية المستخدمين لموقعك. لذا فبدلاً من سؤال Google فيما يتعلق بـ SEO ، هل هذا الموقع بطيء جدًا ، أود أن أنظر إليه مع المستخدمين ونوعًا من الحصول على تعليقاتهم بدلاً من ذلك ، وإذا كنت تقول أن موقعك سريع جدًا للمستخدمين ، فإنه يوفر المحتوى بسرعة إلى حد ما ، فمن المحتمل أنك في حالة جيدة هناك.
الإجابة 12:24 - أوضحت Google للتو في مستند تقني صدر قبل بضعة أيام أنها تستخدم PageRank عبر روابط عبر الويب لتقييم الموثوقية والجدارة بالثقة من خلال الخوارزميات. هل يمكننا أن نفترض أن الخبرة يتم تقييمها بشكل أساسي من خلال جودة المحتوى خوارزميًا؟ هل يمكنك توضيح هذا على الإطلاق؟
الإجابة 12:51 - ليس لدي أي فكرة هناك. لذلك هذا شيء ليس لدي أي شيء خاص به هناك. لقد رأيت للتو ذلك المستند التعريفي التمهيدي الذي لا أعرفه بالأمس أو اليوم السابق كذلك. يبدو مثيرًا للاهتمام ولكنه بالطبع عبارة عن ورقة طويلة إلى حد ما وهناك الكثير من الموضوعات المختلفة فيه ونظام ترتيب الصفحات عبارة عن تعليق جانبي إلى حد ما هناك . لذلك لا أريد أن أقول إن كل شيء مجرد نظام ترتيب الصفحات.
السؤال 13:23 - قبل بضعة أشهر ، أصدر فريق مختبرات Google Chrome رابطًا سريعًا. مما يوفر عمليات تحميل أسرع للصفحة اللاحقة عن طريق الجلب المسبق في روابط منفذ العرض أثناء وقت الخمول. أعلم أن هذا مفيد للمستخدمين ولكن هل سيكون له أي تأثير على Googlebot والترتيب أم أن كل صفحة يزورها Googlebot تعتبر زيارة لأول مرة ، قائمة نظيفة؟
الجواب 13:45 - أنت محق. لذلك في كل مرة يقوم Google بتحميل صفحة يُنظر إليها على أنها زيارة جديدة لأول مرة على ذلك الموقع أو على تلك الصفحة ، فإننا عمومًا لا نحتفظ بأي ملفات تعريف ارتباط ، فليس الأمر أننا نحتفظ بحالة الجلسة حيث نقول ، أوه لقد قمنا بتحميل هذا صفحة واحدة ونحن نتابع الروابط هنا ، لذلك سنحتفظ بهذه الحالة ونود النقر على هذه الروابط للوصول إلى تلك الصفحات الجديدة ، ولكن بدلاً من ذلك سنجد عناوين URL هذه ثم نجلب عناوين URL هذه بشكل فردي. لذلك في مثل هذه الحالة ، لا أرى أي تأثير إيجابي أو سلبي على Googlebot هنا يبدو أنه شيء من شأنه أن يسرع الأمور للمستخدمين بشكل كبير ، وهذا أمر جيد وربما ترى بعض التأثيرات غير المباشرة هناك وهذا عندما يكون المستخدمون قادرين على استخدام موقعك بسرعة كبيرة ، فغالبًا ما يقضون وقتًا أطول على الموقع ، فإنهم ينظرون حولهم أكثر قليلاً ، وبالتالي من المحتمل أن يكونوا قادرين على التوصية بهذا الموقع للآخرين أيضًا وهو شيء التي قد نتمكن من التقاطها.
السؤال 12:52 - كم من الوقت يمكن أن تستغرقه استعادة التصنيفات إذا قمت بنقل موقع من نطاق قديم إلى نطاق جديد تمامًا وتأكدت من أن جميع عمليات إعادة التوجيه 301 موجودة؟
الإجابة 15:02 - لذلك هذا شيء يمكن أن يحدث بسرعة كبيرة إذا قمت بنقل موقع نظيف من مجال إلى آخر حيث كل شيء هو نفسه بشكل أساسي حيث يمكننا التعرف على عنوان URL القديم هذا يتم إعادة توجيهه إلى نفس عنوان URL على المجال الجديد ثم يمكننا عمومًا أن ننتقي ذلك سريعًا إلى حد ما ، وعادةً ما ترى نوعًا من نظرة عامة على الفهرسة في وحدة تحكم البحث ، سترى أن إحداها تنخفض تمامًا بينما ترتفع الأخرى وتتغير الأمور مع مرور يوم أو نحو ذلك نوع من نتوء بينهما. من ناحية أخرى ، إذا قمت بإجراء تغييرات كبيرة عبر موقع الويب الخاص بك بحيث تختلف عناوين URL باختلاف الأطر لأنواع مختلفة من المحتوى ، فكل ذلك يمكن أن يجعل الأمر أكثر صعوبة بالنسبة لنا وعلينا حقًا إعادة تقييم الموقع الجديد بالكامل وبناءً على يكتشف الموقع الجديد كيف يجب أن نضع هذا الموقع. هذا نوع من الاختلافات هناك ، ولكن إذا كان عنوان URL واحدًا نظيفًا فقط ينتقل إلى نفس عنوان URL في نوع آخر من التغيير ، فلا مشكلة حقًا.
السؤال 16:18 - هل سيرث المجال الجديد عصير تحسين محركات البحث وأيضًا ترتيب الكلمات الرئيسية الجديدة؟
الإجابة 16:25 - إذن نحن نحاول أساسًا إذا كان بإمكاننا حقًا نقل كل شيء واحد إلى آخر إلى المجال الجديد ، فسيكون هذا المجال الجديد بدلاً من المجال الأقدم. ويمكنه ترتيب الكلمات الرئيسية القديمة ويمكنه ترتيب الكلمات الرئيسية الجديدة ومرة أخرى إذا قمت بإجراء تغييرات مهمة أثناء هذه الخطوة ، فبالطبع يجب أخذ هذه الحالة الجديدة في الاعتبار وليس الأمر كما لو أنه يمكننا إعادة توجيه كل شيء إلى الجديد واحد لأن الإصدار الجديد ليس مجرد نسخة منقولة من القديم.
السؤال 16:58 - سؤال يتعلق بعناوين URL للمعلمات مع روابط UTM. هل ستضعف هذه الروابط من قيمة الارتباط إذا كانت مرتبطة بشدة داخليًا؟ نقوم بفهرسة الصفحات باستخدام المعلمات حيث يشير النص الأساسي إلى الإصدار المفضل ، وكيف سيؤثر ذلك على المدى الطويل إذا كنا مرتبطين داخل موقع الويب بمعلمات 80٪ و 20٪ عناوين URL نظيفة.
الإجابة 17:33 - أعتقد أن هذا دائمًا ما يكون موقفًا صعبًا بعض الشيء لأنك تعطينا إشارات مختلطة بشكل أساسي. من ناحية أخرى ، أنت تقول أن هذه هي الروابط التي أريد فهرستها لأن هذه هي الطريقة التي تربط بها داخليًا داخل موقع الويب الخاص بك. من ناحية أخرى ، فإن تلك الصفحات عندما نفتحها يكون لديها rel canonical يشير إلى عنوان URL مختلف. إذاً أنت تقول فهرس هذا ومن ذلك الذي تقوله جيدًا ، افهرس في الواقع مؤشرًا مختلفًا. لذا فإن ما تفعله أنظمتنا هناك هو أنها تحاول الموازنة بين الأنواع المختلفة لعناوين URL التي نجدها لهذا المحتوى. يمكننا أن ندرك على الأرجح أن هذا المحتوى يؤدي إلى نفس المحتوى. So we can kind of put them in the same group and then it's a matter of picking which one to actually use for indexing and on the one hand we have the internal links pointing to the UTM versions, on the other hand we have the rel canonical pointing to kind of the cleaner version. The cleaner version is probably also a shorter URL and nicer looking URL that kind of plays in inline with us as well but it's still not guaranteed from our point of view that we would always use the shorter.
So rel canonical is obviously a strong sign internal linking is also kind of a stronger signal, in that that's something that's under your control. So if you explicitly linked to those URLs and we think maybe you want them indexed like that. So in practice what what would probably happen here is we would index a mix of URLs some of them we would index the shorter version because maybe we find other signals pointing at the shorter version as well. Some of them we probably index with the UTM version and we would try to rank them normally as the UTM version.
In practice in search you wouldn't see any difference in ranking you would just see that these URLs might be shown in the search results. So they would rank exactly the same with UTM or without UTM and they would just be listed individually in the search results. And from a practical point of view that just means that in search console you might see a mix of these URLs. In the the performance report you might see kind of this mix. In the indexing report you might see a mix in some of the other reports. Maybe around the AMP or structured data if you use anything like that you might also see this mix. You might also see in some cases situation where it swaps between the URLs so it might be that we index it with UTM parameters at one point and then a couple weeks later if we switch to the cleaner version and we say, well probably this cleaner version is better, and then at some point later on or algorithm to look at it again and say well actually more signals point to the UTM version we'll switch back, that could theoretically happen as well.
So what I would recommend doing there is if you have a preference with regards to your urls make sure that you're being as clear as possible within your website about what version you want to have indexed. With UTM parameters you're also creating the situation that we'd have to crawl both of those versions so it's a little bit more overhead if it's just one extra version that's probably not such a big deal. If you have multiple UTM parameters that you're using across the website then we would try to crawl all of the different variations which would in turn mean that maybe we crawl, I don't know, a couple times as many URLs as your website actually has to be able to keep up with indexing. So that's probably something you'd want to avoid. So my recommendation would be really to try to clean that up as much as possible, so that we can stick to the clean URLs. To the URLs that you want to have indexed instead of ending up in this state where maybe we'll pick them up like this, maybe we'll pick them up like this, and in your reporting it could be like this, it could be like this. You have to watch out for that all the time. So keep it as simple as possible.
Question 21:56 - Will there be any ability to test and view desktop renders with screenshots in the URL inspection tool in search console?
Answer 22:05 - I get these kind of questions all the time. It's like will you do this in search console or will you do that. And in general we try not to pre-announce things so I don't really have any insight that I can give you there with regards to what will happen in the future. It does seem like something that is kind of a missing aspect of the tool in that it's focusing on mobile at the moment but it might be nice to actually test the desktop version as well. So I'll definitely pass that on to your team to make sure that that's on their radar somewhere.
Question 22:41 - On one website with a couple million pages we have a sidebar which has internal links in it and next to each there's a number which represents how many sub pages that link leads to. Sort of as an information informative visual aid and generating those numbers takes a lot of time is it okay to remove those numbers for the front page when Googlebot is detected?
Answer 23:08 - So Googlebot should be seeing the equivalent version of the page as users would be seeing. So if this is something that's useful for users I'd recommend showing it to Googlebot as well. It's something where if you're talking about the speed that it takes to to render these pages it's worth keeping in mind that we look at speed on kind of a holistic way we don't just look at the speed of a page as Googlebot is fetching that page when it comes to speed with regards to using speed as a ranking factor. For crawling of course having the pages that are available very quickly that helps us quite a bit so that makes sense to kind of make things fast for Google for crawling at least. One thing I'd recommend here though is try to avoid special casing Googlebot if if at all possible because it does mean that maintenance is a lot harder. If you're doing special for Googlebot then it's a lot harder to tell if Googlebot is seeing errors on the page and users are seeing normal content and Googlebot starts dropping those pages from search because of those errors. So ideally treat them a lot the same as users. One way you could do that here is to use some kind of JavaScript to just asynchronously load that extra information. So that's usually pretty easily doable probably less effort than cloaking to Googlebot in a case like this.
Question 24:47 - Does link equity pass through links on canonical pages or is it just ignored and everything flows to the canonical? So I think the question is more that you have one page it has a rel canonical pointing to a different page and the question is will those links on that original page kind of work pass PageRank or will only that pay the links on the specified canonical page pass PageRank?
Answer 25:18 - So from our point of view there are multiple things I've come into play here. I think first of all those pages should be equivalent if you're saying that there's a canonical for that page it should be equivalent to the final page as well. So it shouldn't matter which of these pages is used for forwarding links because you're essentially telling us these pages are the same we can treat them the same. So it shouldn't matter for our algorithms like if we pick up those links on that page or we pick up the links on the other page. So II would also assume there that not always kind of like in the other question with UTM parameters we would pick the URL that is specified as canonical as the one that we actually index. So if those links are different across versions of pages then that's something where we might not pass PageRank in the way that you're expecting. So all of that kind of comes together and from my point of view what I'd recommend there is just really making sure that those pages are equivalent. So that you don't have to worry about from where, which links are passing PageRank. But rather assume that it could be this page, it could be the other page, the rel canonical is a strong signal for us but it's not a directive that prevents us from using that page completely.
Question 26:50 - Is it a good idea to create a website for every country in the world?
Answer 26:58 - So the short answer there is no that's a terrible idea. Especially if you don't really have content that's unique to every country in the world. In particular if you're using hreflang between the different country and language versions. You need to keep in mind that hreflang does not make those pages rank higher in those countries it just swaps out those URLs. So you still have to be able to rank in those individual locations. Which means if you have one piece of content and you split it up across every country in the world and multiply it by every language then you'll have diluted your contents significantly across a large number of URLs. Which means that any piece of content there will have a lot more trouble being shown in the search results. Because instead of one strong page that we could show potentially worldwide, we have a ton of different pages that all show more or less the same content and none of them are particularly strong. So that's something where when it comes to an internationalization strategy I would strongly recommend getting help from people who have done this successfully for other websites. So that you can really weigh kind of the pros and the cons there. On the one hand you have the advantage of being able to target individual countries and languages with content that's really uniquely kind of specialized for them and on the other hand you have to weigh that if you're diluting the content too much then all of those versions will have a lot harder time to be visible in search. So on the one hand targeting well on the other hand kind of making sure that the versions that you do have available are strong enough to actually be be visible in search and my general thought there is to err on the side of using fewer versions rather than using more versions. So unless you have a really strong use case for having content specifically targeted for individual countries and I err on the side of well maybe one global website is better rather than splitting things up.
Question 29:25 - Can we use both rating schema and question-and-answer schema for question answers
Answer - 29:33 - Sure I don't see offhand why not. The main thing to keep in mind is that the structured data should be focused on the primary content of the page. So I don't know how exactly you would kind of combine the rating and the QA schema on a page but maybe it's something like you have questions and answers to a product and you have ratings at that product as well. That might be an option there but in general it's not that these types of markups are exclusive and you can only use one type you can combine multiple types of markup.
Question 30:41 - So our site had maybe like 5,000 Google visitors per day for several months now we're down to under 500. This was due to a sudden, just happened in one day, we think it's due to an automatic security penalty that we got removed within one business day and we just haven't seen any change within three weeks. So I'm wondering how long was something like that it might take to recover from and if there's anything else that would cause just a sudden one day drop like that?
We got a message in search console that social engineering content was detected. It turns out that was due to our email service provider there click track my software was was automatically flagged because I guess another clients was using it so we were we got a manual review and within a business day and they said it was ok but you know.
Answer 31:48 - Ok so if there was a manual review then that would be resolved. So it's not that there is kind of a hold back after manual review that says, oh we have to be careful with this website, but that should be resolved there. I know It's kind of hard to say just in a general case with regards to a site like that there there are sometimes algorithmic changes that happen that roll out we're bigger change happens with within a day or so. So that might also be playing a role here it might also be that there's something else kind of playing in with the site there. So what what I generally recommend doing is maybe starting a thread in the webmaster help forum with the URL of your site and some of the queries where you're seeing changes. So not just like we had this many queries and now it's like down to this but rather like people are searching for our company name they're still finding our company name but for this particular kind of query we're no longer visible anymore. So that that kind of thing is it's really useful to post in the webmaster help forum and usual also when when people can't find an answer for that, the experts there are able to escalate that on to us so that we can take a look at that as well.
Question 33:24 - So they have multiple sites in German for different countries and they have the a hreflang setup. It sounds like instead of properly. So this is just what the example URLs, it's hard to say but they're saying that they're not seeing a lot of indexing of these URLs across the different country versions so what what could be happening here?
الإجابة 33:54 - لذلك عادةً عندما أرى أسئلة مثل هذه ، يتلخص الأمر في خوارزمياتنا التي تبحث في هذه الصفحات وتقول جيدًا أن هذه الصفحات مكررة بشكل أساسي من بعضها البعض. لذا يمكننا فهرسة أحد هذه الإصدارات ويمكننا إظهار ذلك للمستخدمين لأنهم جميعًا متشابهون. لذلك على وجه الخصوص باللغة الألمانية ، هذا شيء أراه كثيرًا أتخيله في بعض اللغات الأخرى ، ربما يكون مشابهًا في الإسبانية حيث توجد العديد من البلدان الناطقة بالإسبانية أو الإنجليزية بالطبع بالإضافة إلى أن المحتوى هو نفسه بشكل أساسي ويستهدف فقط دول مختلفة. إذن ما يحدث هنا هو من وجهة نظر الفهرسة ، من المحتمل على الأقل ، على الأقل ، طي عناوين URL هذه معًا ، لذا نختار النسخ الألمانية المتعددة نسخة ألمانية واحدة ونقول أن هذا هو الأساسي للإصدار الألماني مع ترميز hreflang نحن " d لا يزال قادرًا على إظهار عناوين URL الأخرى بالرغم من ذلك. لذلك ربما نقوم بفهرسة النسخة الألمانية السويسرية ، وإذا كنا نبحث عن مستخدم في ألمانيا ، فسنكون قادرين على تبديل عنوان URL هذا مع النسخة الألمانية في نتائج البحث. ولكن في تقرير الفهرسة في وحدة التحكم في البحث ، سترى فقط عنوان URL الذي تتم فهرسته للإصدار السويسري وهو الإصدار الذي اخترناه الأساسي. لذلك لن ترى ذلك بالنسبة للإصدار الألماني ، من الناحية العملية يمكن أن يكون ذلك جيدًا إذا كانت هذه الصفحات متطابقة تمامًا لأننا نتبادل عنوان URL الذي يصل المستخدمون إلى الإصدار الصحيح الذي لا بأس به إلى حد كبير ويمكن أن تكون الصعوبة أنه إذا كان لديك شيء ما في العنوان أو إذا كان لديك أسعار أو بيانات منظمة أخرى على تلك الصفحات ، فقد يكون هذا شيئًا قد يربك المستخدمين لأن مستخدمًا في ألمانيا ربما يبحث ، فنحن نعرض عنوان URL الألماني ولكن في المقتطف يحتوي على Swiss العملة كسعر في مكان ما. لذلك قد يكون هذا محيرًا للناس ، لذلك عادة ما يكون هناك طريقتان لذلك من ناحية ، يمكنك اتباع النهج والقول حسنًا إن طي عناوين URL هذه معًا أمر جيد ، إنه نوعًا ما يجعل هذه اليورو أقوى قليلاً بالنسبة لي ، فلا بأس بذلك. ثم قد تذهب إلى هناك وتقول جيدًا أنني سأتأكد من أن هذه الصفحات عامة تتخطى جميع الإصدارات الألمانية بحيث لا يهمني عنوان URL الذي تتم فهرسته بالفعل. الطريقة الأخرى هي التأكد من أن عناوين URL هذه يُنظر إليها بوضوح على أنها عناوين URL رائدة منفصلة. لذا ، تأكد من أن المحتوى مختلف حقًا عبر إصدارات اللغات المختلفة بحيث تقول أنظمتنا عندما تنظر إلى هذه الصفحات ، حسنًا ، هذه صفحة ألمانية واحدة وهذه صفحة ألمانية مختلفة ، يوجد رابط hreflang بين هذين حتى نتمكن من تبديل عناوين URL هذه ولكنها صفحات فريدة يجب فهرستها بشكل فردي بمفردها. هذان نوعان من الطريقتين هناك من ناحية ، يمكنك طي الأشياء معًا من ناحية أخرى ، يمكنك القول ، حسنًا ، أريد فصلهما بشكل واضح.
السؤال 37:00 - ما الذي تنصح به إذا كان للعلامة التجارية وجود دولي وبمجرد إغلاقها في مناطق معينة. ماذا تفعل بالمواقع التي تستهدف دول أخرى في حال إعادة توجيه الموقع الرئيسي؟
الإجابة 37:14 - بشكل أساسي ، هذا نوع من حالة ترحيل الموقع ، أعتقد أنه إذا كان لديك موقع دولة ما وتقول جيدًا أن هذا الموقع لم يعد متاحًا ، فسأعيد توجيهه إلى نسخة أخرى من نفسي. هذا شيء يمكنك القيام به. ما لا يمكنك فعله حقًا هو التحديد في البحث لإخبارنا أنه لا ينبغي لنا عرض هذا الموقع في بلدان معينة. لذا يمكنك نوعًا من طي نسخك الألمانية معًا والقول مثل ألمانيا والنمسا وسويسرا ، يجب أن يكونوا جميعًا هو الموقع الألماني الوحيد الذي لا بأس به ، لكني لا أريد أن أعرض موقعي على المستخدمين في سويسرا ربما ولكن لا يمكنك ذلك. لا توجد علامة وصفية حيث يمكنك إخبار Google بعدم إظهار موقعي في سويسرا. لذا فإن ما يمكنك فعله على الأكثر هو منع المستخدمين في هذا البلد من الوصول إلى الموقع ولكن لا يمكنك إخبار Google بعدم إظهاره في نتائج البحث الخاصة بهذا البلد.
السؤال 38:18 - كان هذا سؤالي. موقعنا باللغة الإنجليزية ولدينا محتوى فريد من نوعه مع دول مختلفة. لذلك بسبب قرارات العمل ، فهم نوعًا ما يغلقون مناطق معينة. لذلك إذا قمنا ببعض إعادة التوجيه للموقع ، فهل سيؤثر ذلك نوعًا ما على موقع الويب الرئيسي الخاص بي ، فهل سيكون ذلك نوعًا من التأثير السلبي أو الإيجابي؟ أعني أن لدينا حاليًا هذا hreflang في جميع المجموعات الفرعية التي لها صفحات مشتركة حيث يمكننا أن نرى كما أعني أننا نقدم منتجًا واحدًا في بلد معين ومنتج واحد في بلد آخر بمحتوى مختلف وجميع المحتوى المحلي للمنطقة. لذا أتساءل ماذا سيحدث لتلك الصفحات؟ إذا قمت بإعادة توجيه هذه الصفحات إلى موقعي الرئيسي ، فهل سيتم تصنيف صفحاتي الرئيسية لتلك المناطق المحددة؟
الإجابة 39:19 - من المحتمل أن يحدث هذا ولكني مرة أخرى هذا ليس شيئًا يمكنك التحكم فيه حقًا. لذلك إذا كنت تعيد توجيه هذه الصفحات إذا كانت هذه الصفحات لا تزال موجودة ، فقد يتم ترتيبها في تلك المواقع أيضًا ، لا يمكنك القول أنه لا توجد علامة وصفية أو يمكنك القول جيدًا أنه يجب فهرسة موقع الويب الخاص بي ولكن لا يظهر في هذا تحديدًا بلد.
الأسئلة 39:50 - لدى Google دليل تجربة المستخدم هذا للحصول على أفضل الممارسات لإسعاد المستخدمين في مجالات مختلفة. هل تعتبر هذه جزءًا من الترتيب أم يمكنك إعطاء نظرة ثاقبة على ذلك؟
الإجابة 40:02 - لذلك تم وضع كتيبات لعب UX كما أعلم من قبل فريق الإعلانات ، والأمر يتعلق أكثر ، حسنًا ، هذه هي أفضل ممارسات UX وأشياء جيدة يجب القيام بها على موقع ويب ، وليست بالضرورة شيئًا نتمتع به. لنفترض أن هذه الأشياء تلعب دورًا في الترتيب ، ولكن من الواضح أنك إذا أنشأت موقعًا جيدًا يعمل بشكل جيد للمستخدمين ، فبالتأكيد يمكنك بشكل غير مباشر أن ترى تأثيرًا في الترتيب. ولكن ليس الأمر أننا ننظر إلى كتيبات لعب UX هذه ونستخدمها على وجه التحديد كعوامل للترتيب.
السؤال 40:38 - ما هو تأثير الروابط التابعة عند مزجها بالمحتوى الذي يستهدف الموضوعات الحساسة. نحن نعلم أن تحقيق الدخل بشكل مكثف يمكن أن يمثل مشكلة خاصة عندما لا يتم الكشف عن الروابط التابعة للمستخدمين وعندما يكون التركيز على تحقيق الدخل أكثر أهمية من توفير محتوى رائع للمستخدمين ، لكني أتساءل كيف سيعمل ذلك في موضوعات مثل الصحة والطبية والمالية إلخ.؟
الإجابة 41:05 - بشكل عام ، هذا ليس بقدر ما أعلم أننا لا ندخل صراحة إلى الموقع ونقول ، حسنًا ، هناك روابط تبدو مثل الروابط التابعة لذلك سوف نتعامل مع هذا الموقع على أنه أقل جودة. بشكل عام ، القضايا الرئيسية التي أراها فيما يتعلق بالمواقع التابعة هي أنها تميل إلى أن تكون أقل جودة فقط. لذلك ، لا يتعلق الأمر بمكان تدفق عملية التحقق ، بل يتعلق الأمر بشكل عام بأن المحتوى غالبًا ما يكون ذا جودة منخفضة ، وبسبب المحتوى منخفض الجودة ، فهذا شيء قد تلتقطه خوارزمياتنا وتقول ، حسنًا ، هذا على الأرجح ليس كذلك النتيجة الأكثر صلة التي يتم عرضها في نتائج البحث ، ويمكن أن تكون هناك مواقع ويب تابعة عالية الجودة وأيها جيدة. لذا فإن الأمر لا يتعلق كثيرًا بما إذا كان هناك ارتباط تابع أم لا ، ولكن بالأحرى مثل ماذا عن بقية الموقع؟ هل هذا شيء من شأنه أن يكون مناسبًا لعرضه على المستخدمين أم أن هناك شيئًا ربما يمثل مشكلة هناك؟ أعتقد ، على الأقل بقدر ما أعلم ، أنه سيتم تطبيقه في جميع المجالات ، لذلك لن يكون من المهم حقًا ما هو مجال الموضوع المحدد لموقع الويب ولكن بشكل عام هناك بعض المواقع التابعة الجيدة حقًا وهناك بعض المواقع الرهيبة حقًا المواقع التابعة. إذن فالأمر يتعلق أكثر بالموقع الجيد أم أن الموقع سيئ؟
السؤال 42:35 - مع إهمال الجلب والعرض من وحدة تحكم البحث القديمة واستبدالها بأداة فحص عنوان URL ، سيتم تحديث أداة فحص UL لتشمل مقارنة مرئية جنبًا إلى جنب لكيفية رؤية Googlebot للصفحة مقابل رؤية المستخدم للصفحة يراهم؟
الإجابة 42:53 - لا أعرف كما هو الحال مع السؤال الآخر ، نحاول عدم الإعلان مسبقًا عن الأشياء ، لذا فهذا ليس شيئًا يمكنني من خلاله قول أي شيء على وجه التحديد فيما يتعلق بما سيحدث في المستقبل. يسعدني أيضًا أن أنقل هذا إلى الفريق لإلقاء نظرة عليه لمعرفة ما يتعلق بتحديد الأولويات. من وجهة نظر عملية ، شعرت دائمًا أن هذه المقارنة أقل فائدة في الوقت الحاضر لأن معظم المواقع جيدة جدًا في التأكد من إمكانية عرض الصفحة لمحركات البحث. على الأقل المواقع التي نظرت إليها تميل إلى أن تكون نوعًا ما في الجانب الجيد هناك. لذلك على وجه الخصوص في البداية عندما لم تكن المواقع معتادة على محركات البحث التي تحاول فعليًا عرض صفحة كانت شيئًا كبيرًا ولكن في الوقت الحاضر لا أعرف ما إذا كانت هذه مشكلة كبيرة حقًا ، مثل ما إذا تم حظر جافا سكريبت بواسطة ملف robots.txt ، هذا النوع من الأشياء التي أشعر أنها تغيرت بشكل كبير على مر السنين ، لكنني سعيد بدفعها إلى الفريق وربما سيتحققون مرة أخرى لمعرفة ما إذا كانت هناك بالفعل مشكلات نحتاج إلى حلها.
السؤال 44:12 - هل يمكن للربط التنصل من تعزيز الترتيب؟
الإجابة 44:17 - يا إلهي هذا سؤال كبير. لذلك ، من الناحية النظرية ، إذا تم تخفيض رتبة موقع الويب الخاص بك بإجراء يدوي فيما يتعلق بالروابط التي اشتريتها أو تم شراء شخص آخر لموقع الويب الخاص بك بمرور الوقت. ربما مُحسّنات محرّكات بحث سابقة ، أو ربما شيء تم إعداده قبل وقتك مع تلك الشركة ، وبعد ذلك يمكنك استخدام أداة التنصل لإزالة تلك الروابط من أنظمتنا ، وبعد ذلك يمكنك استخدام نموذج طلب إعادة النظر لإعلامنا بهذا التغيير ثم يقوم فريق البريد العشوائي اليدوي بإلقاء نظرة والتحقق مرة أخرى لمعرفة أن الحالة الحالية على ما يرام. وإذا كانت الحالة الحالية نظيفة ، فسيقومون بحل هذا الإجراء اليدوي ، وبوجه عام ، سيكون موقع الويب الخاص بك قادرًا على الترتيب بشكل طبيعي مرة أخرى. هذا شيء قد يرتفع فيه موقع الويب قليلاً في كثير من الحالات وقد يكون الترتيب في بعض الحالات هو أن هذه الروابط غير الطبيعية كانت تدعم موقع الويب بشكل غير طبيعي في البداية. لذلك من خلال إزالة هذه الروابط ، قد يكون هذا الدعم قد انتهى وهو نوع من الحالة الطبيعية. لذلك أعتقد أن الإجابة الأقصر هي أنه لا يوجد نعم أو لا هنا في هذا التنصل من الروابط يغير ما نراه كروابط إلى موقع الويب الخاص بك ويمكن أن يؤثر ذلك على موقع الويب الخاص بك بشكل إيجابي أو سلبي. لذا فإن توصيتي عمومًا باستخدام أداة التنصل هي استخدام هذا إذا كان لديك إجراء يدوي فيما يتعلق بالروابط ولا يمكنك إزالة هذه الروابط أو إذا نظرت إلى روابطك التي تدركها ، فقد كان هناك هذا الشيء المجنون الذي نحن ربما قبل عامين ولم يلاحظ فريق البريد العشوائي على الويب ولكن ربما حان الوقت لتنظيف عملنا وتنظيفه ، فهذا شيء يجعل من المنطقي استخدام أداة التنصل. لن أستخدم هذا بشكل عشوائي وأقول جيدًا أن هذه روابط غريبة ولا أريد أن أكون مرتبطًا بها ، آمل أن تصنف Google موقع الويب الخاص بي بشكل أفضل عندما أزيل مثل هذه الروابط ، لذا من غير المرجح أن يحدث ذلك.
السؤال 46:27 - هل يمكنني أن أسأل جون سؤالاً بناءً على التنصل هنا. لذلك نرى في بعض الأحيان ، أظن أنه ربما منافسون ، سنرى حرفيًا مكانًا واحدًا أرسل روابط 1.1 أو 1.2 إلى صفحتنا الرئيسية. خارج الموضوع تمامًا ، موقع لإصلاح الأجهزة خارج أيرلندا ، لا علاقة له بما نفعله بوضوح. لا أمتلك الأدوات أو القدرة على التنصل من جميع الروابط ، فهل من الأفضل التنصل من الموقع بعد ذلك؟
الإجابة 47:01 - بالتأكيد يمكنك فعل ذلك. نعم ، هذا نوع من الغرض من إدخال المجال في ملف التنصل ، وبهذه الطريقة يشبه كل هذه الملايين أو الآلاف من الروابط ، يمكنك فقط قول كل شيء من هذا الموقع ليس لدي أي علاقة بذلك. عادةً ما يحدث في مثل هذه الحالات التي ترى فيها ارتباطًا عشوائيًا تمامًا بالموقع هو أنه من المحتمل أن يكون هذا الموقع قد تعرض للاختراق ولأي سبب قرر شخص ما إسقاط كل هذه الروابط هناك عند اختراق موقع الويب وعادة ما نكون جيدًا في اختيار ذلك ومحاولة منع الدولة من قبل اختراق أنظمتنا. لذلك ربما نتجاهل بالفعل هذه الروابط ، فمن الممكن أن يكون موقع الويب أو حتى فهرسته من قبل بدلاً من المحتوى الذي تم الاستيلاء عليه. هذا شيء لا أقلق فيه كثيرًا لأن هذا النوع من الاختراقات شائع حقًا ولدينا القليل من التدريب في محاولة للتعامل مع ذلك. ولكن إذا كنت قلقًا بشأن هذا الأمر ، فأنت تعلم أن هذا أمر مجنون حقًا وأعتقد أن روابط إصلاح الأجهزة ربما لا تكون شيئًا ترغب في قوله ، أوه هذا سيقتل موقع الويب الخاص بي إذا كنت مرتبطًا بالكمان ، ربما يكون محتوى البالغين شيئًا تكون أكثر حذرًا بشأنه ، ثم سأستخدم ملف التنصل ، وأرسله وأنت متأكد من أنه لم يتم أخذها في الاعتبار.
السؤال 48:44 - سؤالان سريعان بخصوص عنوان URL هذا ، إنه عنوان URL لفئة لموقع التجارة الإلكترونية الذي يحتوي على نوع من معلمة عرض الكل بشكل أساسي تتمثل مشكلتنا في أن عنوان URL له عنوان URL أساسي للإصدار بدون المعلمة. إنه مرتبط بالإصدار بدون المعلمة في جميع أنحاء موقع الويب ، إنه موجود في خريطة الموقع بدون المعلمة ولكن بطريقة ما يقرر Google أن هذا هو الإصدار الأساسي وكل إشاراتنا تشير إلى الإصدار الآخر ولا أعتقد أنه يعمل بنفس القدر ولكن لا أفهم لماذا لا تختار Google نسختنا عندما تشير جميع إشاراتنا إلى نفس الاتجاه؟
السؤال 48:24 - لا أعرف ، من الصعب أن أقول مرتجلاً. لذلك أعتقد أن شيئًا واحدًا يجب أخذه في الاعتبار هو أنه ضمن الفهرسة الأولى للجوال. لذلك ربما يكون إصدار الهاتف مختلفًا بعض الشيء ، فربما يكون هناك عنصر أساسي هناك ربما يكون هناك شيء ما في JavaScript يغير rel canonical الذي لا أعرفه ولكن هذا دائمًا شيء يجب مراعاته نوعًا ما. لذلك عندما تقوم باختباره في المتصفح وتأكد من التحقق مرة أخرى من عرض الهاتف المحمول ولكن نوعًا ما مثل كل من الأسئلة الأخرى السابقة ، فمن الممكن أيضًا أنه لأي أسباب أخرى نقررها جيدًا ، فهذا هو الأنظف في الواقع إصدار.
السؤال 50:33 - إذا لم يكن مرتبطًا من أي مكان وأنت تعلم أن الروابط الداخلية لا تشير إليه. إنها لن تكون خريطة موقع ، ومع فحص عنوان URL إلى Google ، فإنه يرى الحق الأساسي الصحيح الذي قلناه فقط من اختيار Google الأساسي ، إنه لا يزال هو هذا بدلاً من ما وضعنا علامة عليه. لذلك لا أعرف ما إذا كان سيكون له أي تأثير ، فأنا قلق فقط من أنه قد يكون هناك شيء نفتقده قد يؤثر على الصفحات الأخرى أيضًا.
الإجابة 51:11 - أجل ، لا أعرف ، يجب أن ألقي نظرة. بشكل عام ، إذا كان المحتوى هو نفسه ، فسيكون الترتيب هو نفسه. لذا ليس الأمر أن أي شيء سيتغير هناك. لا أعرف ما إذا كانت رشوتي بمنتجات العناية بالشعر ستكون مفيدة بشكل خاص ولكني لا أعرف. لذا أعني أنها حالة يكون لديك فيها نوع من صفحة عرض الكل والنسخة الأخرى من الصفحة حيث قد نلتقط بعض الإشارات التي تقول جيدًا أن هذا هو العرض الذي يجب أن نحتفظ به هذا بدلاً من الآخر لأنه قد يكون مرقمًا أو شيء من هذا القبيل ولكن نعم لا أعرف ما إذا كان عليّ البحث في ذلك. الشيء الآخر الذي قد يجدر ذكره هو أننا نرغب في تجميع بعض المستندات فيما يتعلق بأفضل الممارسات حول مواقع التجارة الإلكترونية بشكل عام. لذا ، إذا مررت بأشياء غريبة مثل هذه التي نستخدمها جيدًا مع مواقع التجارة الإلكترونية ، فغالبًا ما يكون لديك صفحات الفئات هذه التي تحتوي على الكثير من المحتوى وتقسيم الصفحات والتصفية وعرض كل الأشياء أمر صعب نوعًا ما ، فهذا شيء حيث أحب الحصول على تعليقات حول. لذلك ربما تكون الأمثلة مجرد أسئلة عامة فيما يتعلق بمواقع التجارة الإلكترونية ، كل ذلك سيكون مفيدًا حقًا. من الناحية المثالية ، ربما أرسل هؤلاء عبر Twitter حتى أتمكن من جمع هؤلاء هناك ، لقد بدأت تغريدة عن ذلك ، وآمل أن نتمكن من وضع شيء ما مع البعض ، أعتقد أن أفضل الممارسات فيما يتعلق بمواقع التجارة الإلكترونية حول كيفية التأكد من الفهرسة والزحف يعمل بشكل مثالي.