ساعات عمل كبار المسئولين الاقتصاديين في المكتب ، 12 نوفمبر 2021

هذا ملخص لأكثر الأسئلة والأجوبة إثارة للاهتمام من ساعات عمل Google SEO مع جون مولر في 12 نوفمبر 2021.

صفحات Noindex في Google Search Console

8:16 " تم تعيين [بعض الصفحات] خطأ على noindex. تم إصلاح هذا قبل شهرين. [...] حاولنا طلب الفهرسة عبر Search Console [و] إعادة إرسال ملفات sitemap ولكن مع ذلك ، لم تتم فهرسة هذه الصفحات. هل لديك أي أفكار حول سبب عدم استماع Googlebot لطلبات الفهرسة أو ما إذا كانت هناك أية مشكلات معروفة في Search Console تتعلق بالفهرسة؟ "

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

شيء آخر هو أنه نظرًا لأن Search Console تقدم تقارير عن عناوين URL التي نعرفها بشكل أساسي لموقع الويب ، فقد تكون الصورة تبدو أسوأ مما هي عليه في الواقع. قد يكون هذا شيئًا يمكنك الاطلاع عليه ، على سبيل المثال ، البحث في تقرير الأداء والتصفية لهذا القسم من موقع الويب ، أو أنماط عنوان URL هذه ، لمعرفة ما إذا كان هذا العدد من صفحات noindex عالية في Search Console يبلغ عن الصفحات التي لم تكن مهمة حقًا وتم بالفعل فهرسة الصفحات المهمة من تلك الأقسام ".

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

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

العلامات المتعارف عليها والبديلة

14:25 "أنا أستخدم موقع WordPress ، وأستخدم مكونين إضافيين. يضيف واحد [منهم] تلقائيًا رابط rel = ”canonical” إلى كل صفحة. [...] [الآخر هو مكون إضافي للمترجم] يضيف [إلى] كل صفحة رابط rel = ”alternate”. هل يجعل من المنطقي أن تقول: بالنسبة إلى عنوان URL هذا ، فهو أساسي ، ولكنه أيضًا بديل؟ هل تتعارض في مكان ما في الزاحف؟ "

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

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

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

Canonical أو علامة noindex

16:49 "لدينا موقع ويب به متجر للتجارة الإلكترونية به الكثير من أشكال المنتجات التي تحتوي على محتوى ضعيف أو مكرر. لقد أعددت قائمة بجميع عناوين URL التي نريد فهرستها [...] ، ولا نريد فهرستها. [...] لست متأكدًا أيهما أفضل: تحديد العنوان المتعارف عليه أم noindex؟ "

قال جون ، "أعتقد أن السؤال العام حول هل يجب أن أستخدم noindex أو rel =” canonical "لصفحة أخرى هو شيء ربما لا توجد فيه إجابة مطلقة. [...] إذا كنت تكافح مع ذلك ، فأنت لست الشخص الوحيد الذي يعجبك ، أوه أي واحد يجب أن أستخدمه؟ هذا يعني أيضًا أنه يمكن أن يكون كلا الخيارين على ما يرام. لذلك عادة ، ما أود أن أنظر إليه هناك هو ما هو تفضيلك القوي حقًا. إذا كان التفضيل القوي هو أنك لا تريد حقًا عرض هذا المحتوى على الإطلاق في البحث ، فعندئذٍ سأستخدم noindex. إذا كان تفضيلك أكبر ، فأنا أريد حقًا دمج كل شيء في صفحة واحدة [...] ، فعندئذٍ سأستخدم rel = ”canonical”. في النهاية ، يكون التأثير مشابهًا من حيث أنه من المحتمل ألا تظهر الصفحة التي تشاهدها في البحث ، ولكن باستخدام علامة noindex - لم يتم عرضها بالتأكيد ، ومع rel = ”canonical” - من المرجح ألا يتم عرضها. "

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

الفهرسة والزحف التي تعطي أولوية للأجهزة الجوّالة

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

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

تقنيات الويب مقابل الترتيب

36:00 " هل هناك أي علاقة أو تأثير على تصنيفات المواقع التي يتم إجراؤها باستخدام HTML و CSS و JS عادي وآخر - PWA؟ [...] اعتمده أحد منافسينا الرئيسيين مؤخرًا ، ولاحظنا قفزة كبيرة في تصنيفات SERP الخاصة بهم ".

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

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

مقارنة بين PageSpeed ​​Insights من Google و Lighthouse

37:39 "هل النتائج في البيانات المعملية في Google PageSpeed ​​Insights هي نفسها نتائج Lighthouse في متصفح Chrome الخاص بي؟ هل يستخدمون نفس الصيغة؟ "

قال جون ، "لا أعرف مائة بالمائة ، لكن يتم إجراؤهم بشكل مختلف تمامًا. [...] إذا كنت تستخدم PageSpeed ​​Insights الذي يتم تشغيله في مركز بيانات في مكان ما به أجهزة تمت محاكاتها بشكل أساسي حيث نحاول التصرف كجهاز كمبيوتر عادي ، ولدينا قيود تجعله أبطأ قليلاً. [...] في Lighthouse ، يعمل بشكل أساسي على جهاز الكمبيوتر الخاص بك مع اتصالك بالإنترنت. أعتقد أن Lighthouse داخل Chrome لديها أيضًا بعض القيود التي تنطبق عليها لجعلها تبدو أبطأ قليلاً مما قد يكون جهاز الكمبيوتر الخاص بك قادرًا على فعله فقط للتأكد من أنه قابل للمقارنة.

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

اكتشف جوجل

47:09 "لقد لاحظنا مشكلة كبيرة في Google Discover على موقعنا على الإنترنت. في غضون يومين ، انخفضت حركة المرور بنسبة سبعين بالمائة. [...] لذا فإننا نتساءل عما إذا كنا قد ارتكبنا خطأ ما؟ [...] هل يمكنك توضيح ما حدث بالضبط لأنه تعادل جذري؟ [...] هل يمكن أن يكون خطأ تقني؟ "

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

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

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

وقت الاستجابة

50:41 "ما هو وقت الاستجابة المناسب لموقع وسائط إخبارية جديد؟"

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

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