ساعات عمل كبار المسئولين الاقتصاديين في المكتب ، 1 يوليو 2022
نشرت: 2022-07-19هذا ملخص لأكثر الأسئلة والأجوبة إثارة للاهتمام من ساعات عمل Google SEO مع جون مولر في الأول من تموز (يوليو) 2022.
PageSpeed Insights أو Google Search Console - أيهما أكثر دقة؟
0:44 "عندما أتحقق من درجة PageSpeed Insights الخاصة بي على موقع الويب الخاص بي ، أرى رقمًا بسيطًا. لماذا لا يتطابق هذا مع ما أراه في Search Console وتقرير Core Web Vitals؟ أي من هذه الأرقام صحيح؟ "
وفقًا لجون: "[...] لا يوجد رقم صحيح عندما يتعلق الأمر بالسرعة - عندما يتعلق الأمر بفهم كيفية أداء موقع الويب الخاص بك لمستخدميك. في PageSpeed Insights ، بشكل افتراضي ، أعتقد أننا نعرض رقمًا واحدًا عبارة عن درجة من 0 إلى 100 ، والتي تستند إلى عدد من الافتراضات حيث نفترض أن الأشياء المختلفة أسرع قليلاً أو أبطأ للمستخدمين. وبناءً على ذلك ، نحسب النتيجة.
في Search Console ، لدينا معلومات "حيوية الويب الأساسية" ، والتي تستند إلى ثلاثة أرقام للسرعة والاستجابة والتفاعل. وهذه الأرقام مختلفة قليلاً ، بالطبع ، لأنها ثلاثة أعداد ، وليست مجرد رقم واحد. ولكن ، أيضًا ، هناك فرق كبير في الطريقة التي يتم بها تحديد هذه الأرقام. وبالتحديد ، هناك فرق بين ما يسمى بالبيانات الميدانية وبيانات المختبر.
البيانات الميدانية هي ما شاهده المستخدمون عندما يذهبون إلى موقع الويب الخاص بك. وهذا ما نستخدمه في Search Console. هذا ما نستخدمه للبحث أيضًا. في حين أن بيانات المختبر هي عرض نظري لموقع الويب الخاص بك ، حيث يكون لأنظمتنا افتراضات معينة حيث يفكرون ، حسنًا ، ربما يكون المستخدم العادي هكذا ، باستخدام هذا النوع من الأجهزة ، ومع هذا النوع من الاتصال ، ربما. واستنادًا إلى هذه الافتراضات ، سنقدّر ما يمكن أن تكون عليه هذه الأرقام للمستخدم العادي. يمكنك أن تتخيل أن هذه التقديرات لن تكون صحيحة بنسبة 100٪.
وبالمثل ، فإن البيانات التي شاهدها المستخدمون - والتي ستتغير بمرور الوقت أيضًا ، حيث قد يكون لدى بعض المستخدمين اتصال سريع حقًا أو جهاز سريع ، وكل شيء يسير بسرعة على موقع الويب الخاص بهم أو عندما يزورون موقع الويب الخاص بك ، وقد لا يكون الآخرون كذلك امتلكه. وبسبب ذلك ، يمكن أن يؤدي هذا الاختلاف دائمًا إلى أرقام مختلفة.
توصيتنا بشكل عام هي استخدام البيانات الميدانية ، والبيانات التي قد تراها في Search Console ، كطريقة لفهم الوضع الحالي لموقعنا على الويب ، ثم استخدام البيانات المعملية ، أي الاختبارات الفردية التي يمكنك إجراؤها مباشرة بنفسك ، لتحسين موقع الويب الخاص بك ومحاولة تحسين الأمور. وعندما تكون سعيدًا جدًا بالبيانات المعملية التي تحصل عليها من الإصدار الجديد من موقع الويب الخاص بك ، فبمرور الوقت ، يمكنك جمع البيانات الميدانية ، والتي تحدث تلقائيًا ، والتحقق مرة أخرى من أن المستخدمين يرون أنها أسرع أو أكثر استجابة كذلك.
لذا ، باختصار ، مرة أخرى ، لا يوجد رقم صحيح عندما يتعلق الأمر بأي من هذه المقاييس. [...] ولكن ، بدلاً من ذلك ، هناك افتراضات مختلفة وطرق مختلفة لجمع البيانات ، وكل واحدة منها مختلفة تمامًا. "
لماذا يعاني Googlebot من صعوبة فهرسة الصفحات المستندة إلى JavaScript؟
4:19 "لدينا عدد قليل من صفحات العملاء باستخدام Next.js بدون ملف robots.txt أو ملف sitemap. من الناحية النظرية ، يمكن لبرنامج Googlebot الوصول إلى كل هذه الصفحات ، ولكن لماذا يتم فهرسة الصفحة الرئيسية فقط؟ لا توجد أخطاء أو تحذيرات في Search Console. لماذا لا يعثر Googlebot على الصفحات الأخرى؟ "
قال جون ، "[...] Next.js هو إطار عمل JavaScript ، مما يعني أن الصفحة بأكملها يتم إنشاؤها باستخدام JavaScript. ولكن هناك إجابة عامة أيضًا لجميع هذه الأسئلة مثل ، لماذا لا تقوم Google بفهرسة كل شيء - من المهم أن نقول أولاً أن Googlebot لن يقوم أبدًا بفهرسة كل شيء عبر موقع الويب. لا أعتقد أنه يحدث لأي موقع ويب ليس بحجم تافه أن Google ستخرج منه وتفهرس كل شيء تمامًا. من وجهة نظر عملية ، لا يمكن فهرسة كل شيء عبر الويب بالكامل. لذا فإن الافتراض بأن الوضع المثالي هو أن كل شيء مفهرس - سأترك ذلك جانبًا وأقول إنك تريد أن يركز Googlebot على الصفحات المهمة.
الأمر الآخر ، الذي أصبح أكثر وضوحًا ، على ما أعتقد ، عندما اتصل بي الشخص على Twitter وقدم لي مزيدًا من المعلومات حول موقعه على الويب ، هو أن الطريقة التي ينشئ بها موقع الويب روابط للصفحات الأخرى كانت بطريقة لم تتمكن Google من التقاطها. لذلك ، على وجه الخصوص ، باستخدام JavaScript ، يمكنك أن تأخذ أي عنصر في صفحة HTML وتقول ، إذا نقر شخص ما على هذا ، فقم بتنفيذ هذا الجزء من JavaScript. ويمكن أن يكون هذا الجزء من JavaScript هو التنقل إلى صفحة مختلفة ، على سبيل المثال. ولا ينقر Googlebot على جميع العناصر ليرى ما يحدث ، ولكن بدلاً من ذلك ، ننطلق ونبحث عن روابط HTML العادية ، وهي الطريقة التقليدية والعادية التي يمكنك من خلالها الارتباط بصفحات فردية على موقع ويب.
ومع هذا الإطار ، لم يقم بإنشاء روابط HTML العادية. لذلك لم نتمكن من التعرف على أن هناك المزيد للزحف ، والمزيد من الصفحات للنظر فيها. وهذا شيء يمكنك إصلاحه بالطريقة التي تنفذ بها موقع JavaScript الخاص بك. لدينا الكثير من المعلومات على موقع Search Developer Documentation حول JavaScript و SEO ، على وجه الخصوص ، حول موضوع الروابط لأن ذلك يظهر بين الحين والآخر. هناك الكثير من الطرق الإبداعية لإنشاء الروابط ، ويحتاج Googlebot إلى العثور على روابط HTML هذه حتى تعمل. [...] "
وباستثناء وثائق Google الرسمية ، تحقق من الدليل النهائي لـ JavaScript SEO على مدونتنا. "
هل الارتباط بصفحات HTTP يؤثر على مُحسنات محركات البحث لموقعك على الويب؟
7:35 "هل يؤثر ذلك سلبًا على درجة تحسين محركات البحث الخاصة بي إذا كانت صفحتي مرتبطة بموقع ويب خارجي غير آمن؟ لذلك على HTTP وليس HTTPS ".
قال جون ، "أولاً ، ليس لدينا فكرة عن نتيجة تحسين محركات البحث ، لذلك لا داعي للقلق بشأن نتيجة تحسين محركات البحث.
ولكن ، بغض النظر ، أفهم أن السؤال مثل: هل من السيئ أن أقوم بالربط بصفحة HTTP بدلاً من صفحة HTTPS. ومن وجهة نظرنا ، هذا جيد تمامًا. إذا كانت هذه الصفحات على HTTP ، فهذا هو ما تريد الارتباط به. هذا ما يتوقع المستخدمون العثور عليه. لا يوجد شيء ضد الارتباط بمواقع من هذا القبيل. لا يوجد جانب سلبي لموقعك على الويب لتجنب الارتباط بصفحات HTTP لأنها قديمة أو متقشرة وليست رائعة مثل HTTPS. لن أقلق بشأن ذلك ".
هل يجب عليك حذف ملف التنصل الخاص بك؟
10:16 "على مدار الخمسة عشر عامًا الماضية ، قمت بالتنصل من أكثر من 11000 رابط إجمالاً. [...] قد تكون الروابط التي تنصلت منها من مواقع تم الاستيلاء عليها أو من محتوى غير معقول تم إنشاؤه تلقائيًا. نظرًا لأن Google تدعي الآن أن لديها أدوات أفضل لعدم تضمين هذه الأنواع من الروابط المخترقة أو غير المرغوب فيها في خوارزمياتها ، فهل يجب علي حذف ملف التنصل الخاص بي؟ هل هناك أي خطر أو جانب سلبي لمجرد حذفه؟ "
أجاب جون ، "[...] إن التنصل من الروابط هو دائمًا أحد تلك الموضوعات الصعبة لأنه يبدو أن Google ربما لا تخبرك بالمعلومات الكاملة.
ولكن من وجهة نظرنا ، [...] نحن نعمل بجد لتجنب أخذ هذه الروابط في الاعتبار. ونحن نفعل ذلك لأننا نعلم أن أداة التنصل من الروابط هي إلى حد ما أداة متخصصة ، وأن مُحسِّن محركات البحث يعرفون عنها ، لكن الشخص العادي الذي يدير موقعًا على شبكة الإنترنت ليس لديه فكرة عنها. وجميع هذه الروابط التي ذكرتها هي نوع الروابط التي يحصل عليها أي موقع على مر السنين. وتدرك أنظمتنا أن هذه ليست أشياء تحاول القيام بها للتلاعب بخوارزمياتنا.
لذا ، من وجهة النظر هذه ، إذا كنت متأكدًا من عدم وجود شيء حول إجراء يدوي يتعين عليك حله فيما يتعلق بهذه الروابط ، فسأحذف ملف التنصل و [...] اترك كل ذلك جانبًا. شيء واحد أود القيام به شخصيًا هو تنزيله وعمل نسخة حتى يكون لديك سجل بما قمت بحذفه. ولكن ، بخلاف ذلك ، إذا كنت متأكدًا من أن هذه مجرد أشياء عادية متقشرة من الإنترنت ، فسأحذفها وأمضي قدمًا. عندما يتعلق الأمر بمواقع الويب ، هناك الكثير الذي يمكنك قضاء وقتك فيه أكثر من مجرد التنصل من هذه الأشياء العشوائية التي تحدث لأي موقع ويب على الويب ".
هل من الأفضل منع الزحف باستخدام ملف robots.txt أو العلامة الوصفية لبرامج الروبوت؟
14:19 "أيهما أفضل: الحظر باستخدام ملف robots.txt أم استخدام العلامة الوصفية لبرامج الروبوت على الصفحة؟ ما أفضل طريقة لمنع الزحف؟ "
جون: "[...] لقد قمنا مؤخرًا بعمل حلقة بودكاست حول هذا الأمر أيضًا. لذلك أود التحقق من ذلك. [...]
من الناحية العملية ، هناك اختلاف طفيف هنا حيث ، إذا كنت تستخدم مُحسّنات محرّكات البحث وعملت مع محركات البحث ، فمن المحتمل أنك تفهم ذلك بالفعل. ولكن بالنسبة للأشخاص الجدد في المنطقة ، يكون من غير الواضح أحيانًا مكان كل هذه الخطوط بالضبط.
باستخدام ملف robots.txt ، وهو أول ملف ذكرته في السؤال ، يمكنك حظر الزحف. لذا يمكنك منع Googlebot حتى من النظر إلى صفحاتك. وباستخدام العلامة الوصفية لبرامج الروبوت ، عندما يفحص Googlebot صفحاتك ويرى علامة meta لبرامج الروبوت ، يمكنك القيام بأشياء مثل حظر الفهرسة. من الناحية العملية ، ينتج عن كلتا هاتين الصفحتين عدم ظهور صفحاتك في نتائج البحث ، لكنهما مختلفتان تمامًا.
لذلك إذا لم نتمكن من الزحف ، فإننا لا نعرف ما الذي نفتقده. وربما نقول ، حسنًا ، في الواقع ، هناك الكثير من المراجع لهذه الصفحة. ربما هو مفيد لشيء ما. لا نعلم. وبعد ذلك يمكن أن يظهر عنوان URL هذا في نتائج البحث بدون أي من محتوياته لأننا لا نستطيع النظر إليه. بينما باستخدام العلامة الوصفية لبرامج الروبوت ، إذا كان بإمكاننا إلقاء نظرة على الصفحة ، فيمكننا إلقاء نظرة على العلامة الوصفية ومعرفة ما إذا كان هناك علامة noindex هناك ، على سبيل المثال. ثم نتوقف عن فهرسة تلك الصفحة ، ثم نقوم بإسقاطها بالكامل من نتائج البحث.
لذلك إذا كنت تحاول منع الزحف ، فبالتأكيد ، فإن ملف robots.txt هو السبيل للذهاب. إذا كنت لا تريد أن تظهر الصفحة في نتائج البحث ، فسأختار أيهما أسهل بالنسبة لك للتنفيذ. في بعض المواقع ، يكون من الأسهل تعيين مربع اختيار يقول إنني لا أريد العثور على هذه الصفحة في البحث ، ثم يضيف علامة noindex meta tag. في حالات أخرى ، ربما يكون تحرير ملف robots.txt أسهل. [إنها] تعتمد على ما لديك هناك ".
هل يمكنك وضع نفس عنوان URL في ملفات Sitemap متعددة؟
16:40 " هل هناك أي آثار سلبية لوجود عناوين URL مكررة بسمات مختلفة في خرائط مواقع XML الخاصة بك؟ على سبيل المثال ، عنوان URL واحد في ملف Sitemap واحد به تعليق توضيحي hreflang ، ونفس عنوان URL في خريطة موقع أخرى بدون هذا التعليق التوضيحي ".
قال جون ، "[...] من وجهة نظرنا ، هذا جيد تمامًا. […] يحدث هذا بين الحين والآخر. بعض الأشخاص لديهم تعليقات hreflang التوضيحية في ملفات Sitemap منفصلة على وجه التحديد ، ومن ثم يكون لديهم ملف sitemap عادي لكل شيء أيضًا. وهناك بعض التداخل هناك.
من وجهة نظرنا ، نقوم بمعالجة ملفات Sitemap هذه بقدر الإمكان ، ونأخذ كل هذه المعلومات في الاعتبار. ليس هناك جانب سلبي لامتلاك نفس عنوان URL في ملفات خرائط مواقع متعددة.
الشيء الوحيد الذي أود الانتباه إليه هو أنه ليس لديك معلومات متضاربة في ملفات خرائط الموقع هذه. لذلك ، على سبيل المثال ، إذا كنت تقول باستخدام تعليقات hreflang التوضيحية ، هذه الصفحة مخصصة لألمانيا ، ثم في ملف خريطة الموقع الآخر ، فأنت تقول ، حسنًا ، هذه الصفحة مخصصة أيضًا لفرنسا ، [...] ثم قد تكون الأنظمة مثل ، حسنًا ، ما الذي يحدث هنا؟ لا نعرف ماذا نفعل بهذا المزيج من التعليقات التوضيحية. وبعد ذلك يمكن أن نختار أحدهما أو الآخر.
وبالمثل ، إذا قلت ، تم تغيير هذه الصفحة آخر مرة منذ 20 عامًا [...] ، وفي ملف خريطة الموقع الآخر ، تقول ، حسنًا ، في الواقع ، كان ذلك قبل خمس دقائق. ثم قد تنظر أنظمتنا إلى ذلك وتقول ، حسنًا ، أحدكم على خطأ. لا نعرف أيهما. ربما سنتبع أحدهما أو الآخر. ربما نتجاهل تاريخ التعديل الأخير تمامًا. لذلك هذا هو الشيء الذي يجب الانتباه إليه.
ولكن بخلاف ذلك ، إذا تم ذكر ملفات Sitemap المتعددة وكانت المعلومات إما متسقة أو تعمل معًا ، فمن المحتمل أن يكون لأحدهما تاريخ التعديل الأخير ، والآخر به تعليقات hreflang التوضيحية ، فلا بأس بذلك تمامًا ".
كيف تمنع صفحات الفيديو المضمنة من الفهرسة؟
19:00 "أنا مسؤول عن نظام أساسي لإعادة تشغيل الفيديو ، ويتم أحيانًا فهرسة التضمينات الخاصة بنا بشكل فردي. كيف يمكننا منع ذلك؟ "
أجاب جون: "[...] لقد نظرت إلى موقع الويب ، وهذه إطارات مضمنة تحتوي على صفحة HTML مبسطة مع مشغل فيديو مضمن فيها.
من وجهة نظر فنية ، إذا كانت الصفحة بها محتوى iframe ، فسنرى هاتين الصفحتين HTML. ومن الممكن أن تكون أنظمتنا قد قامت بفهرسة كل من صفحات HTML هذه لأنهما صفحات HTML منفصلة. يتم تضمين أحدهما في الآخر ، عادةً ، لكن يمكنهم نظريًا الوقوف بمفردهم أيضًا.
وهناك طريقة واحدة لمنع ذلك ، وهي مزيج جديد تمامًا من العلامات الوصفية لبرامج الروبوت التي يمكنك القيام بها ، وهي باستخدام العلامة الوصفية لبرامج الروبوت المضمنة في الفهرسة جنبًا إلى جنب مع العلامة الوصفية noindex لبرامج الروبوت .
وفي الإصدار المضمن ، إذاً ملف HTML الذي يحتوي على الفيديو بداخله مباشرةً ، يمكنك إضافة مجموعة العلامات الوصفية noindex بالإضافة إلى العلامات الوصفية لبرامج الروبوت المُدمجة. وهذا يعني أنه إذا وجدنا هذه الصفحة بشكل فردي ، فسنرى أن هناك علامة noindex [علامة]. ليس علينا فهرسة هذا.
ولكن مع الفهرس المضمن ، يخبرنا أنه [...] إذا وجدنا هذه الصفحة مع الفيديو المضمّن في موقع الويب العام ، فيمكننا حينئذٍ فهرسة محتوى الفيديو ، مما يعني أن صفحة HTML الفردية لن تتم فهرستها. لكن صفحة HTML مع التضمين ، مع معلومات الفيديو ، سيتم فهرستها بشكل طبيعي. هذا هو الإعداد الذي سأستخدمه هناك. وهذه علامة تعريفية جديدة إلى حد ما لبرامج الروبوت ، لذا فهي شيء لا يحتاجه الجميع. لأن هذا المزيج من محتوى iframe أو المحتوى المضمن نادر. ولكن بالنسبة لبعض المواقع ، من المنطقي أن تفعل ذلك بهذه الطريقة ".