تأثير تحديث Google الأساسي في 4 مايو على منتديات Discourse

مجتمع
91

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

النقطة التقنية “الملموسة” الوحيدة التي قدمتها فعليًا هي أن جوجل أعلنت علنًا أنها ستستخدم LCP (وإشارات الويب الحيوية الأخرى) starting in May 2021.

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

لو كان لدى المنشورات ذات النوايا الحسنة التي تجادل بأن LCP يؤثر على تحسين محركات البحث، وكانوا متأكدين من “نتائجهم” ودعوا Discourse إلى إجراء تغييرات هيكلية في كودها بسبب “نتائجهم”، وكان الكود متاحًا للمراجعة، كمصدر مفتوح، بحيث يتمكن الجميع من فحصه، لكانت “أدلتهم”، بعد مراجعة الأقران، مقنعة.

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

من حيث “العدالة التقنية”، لم نرَ فعليًا أي “دليل” على أن جوجل تستخدم LCP كإشارة حاليًا. إنه مجرد تخمين، ولا يوجد كود لمراجعته أو إجراء مراجعة أقران له لدعمه.

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

تدعي جوجل أنها لا تستخدم LCP كإشارة حاليًا؛ وستبدأ في استخدام LCP كإشارة لتحسين محركات البحث في مايو 2021. حتى الآن، لم نرَ أي سبب للشك في ما أعلنته جوجل علنًا؛ ولم نرَ أي “دليل صلب خضع لمراجعة الأقران” ينفي ذلك.

أتمنى أن يكون هذا مفيدًا.

4 إعجابات
92

إذن، بالنسبة لجميع من اشتكوا من مايو 2020، لم يكن الأمر شيئًا مقارنة بما قد يأتي في مايو 2021؟ :wink: أعني، أنت أيضًا تقول إن مجتمعات Discourse قد تتأثر من حيث نتائج البحث في العام المقبل (سنرى ما سيحدث بالفعل).

إعجابَين (2)
93

نعم، أنا أتفق تمامًا معك ومع الجميع هنا القلقين بشأن LCP والتأثير الذي ستحدثه مقاييس الويب الأساسية من Google.

علاوة على ذلك، أقدّر بشدة الجميع الذين يسعون جاهدين لتقديم إجابات وحلول لهذه المشكلة الوشيكة.

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

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

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

ومع ذلك، فإن LCP ستكون مهمة للغاية، بغض النظر، في لمح البصر.

تحياتي.

4 إعجابات
94

هذا بالفعل كيف يعمل Discourse منذ زمن بعيد :laughing:

الأمر الجديد هو أن LCP يتم التقاطه من هواتف أندرويد للأشخاص. يُعد أندرويد أبطأ منصة نعمل عليها، وهذا يؤثر علينا بشكل غير متناسب.

ما اقترحه @sam كان أيضًا تقديم ذلك العرض لبعض المستخدمين المجهولين عبر إضافة، لكن هذا ليس شيئًا سنقوم به قريبًا.

7 إعجابات
95

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

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

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

سيكون الأمر مثل مطعم رائع (=منتدى Discourse)، حيث تقوم بإنشاء مطعم drive-in مع طلبات للأكل خارجي. نفس الطعام الرائع (=المحتوى) لكن بدون أي من التجربة. تطلب من مكبر صوت عند الدخول (=بحثك في محرك البحث) وتُلقى معبأة مسبقًا من خلال نافذتك. الفكرة بأكملها هي أن ما يُطلب هو المهم، وأن الطعام (=المحتوى) وسرعة التسليم هما الأهم. إذا أعجب الناس الطعام، ربما سيعودون ويستمتعون بالتجربة الكاملة في الداخل.

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

ما هو مطلوب هو إضافة أو وحدة نمطية لتوليد هذه الصفحات الثابتة عند إضافة محتوى إلى المنتدى (أعتقد أنه لا ينبغي أن يكون معقدًا بشكل مفرط). ستقوم فقط بإضافة رابط هنا وهناك إلى المنتدى الفعلي الخاص بك (مُعد على “عدم الزحف” لمحركات البحث). سيكون الأمر متروكًا لكل مدير نظام لاستخدام هذا الحل أو عدمه.

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

إعجاب واحد (1)
96

نحن نخدم بالفعل HTML عاديًا خاليًا من JavaScript للزواحف :upside_down_face:

كما قلت أعلاه، المشكلة هي أن درجة LCP الجديدة تُلتقط من متصفحات المستخدمين، وليس من الزواحف.

7 إعجابات
97

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

إعجابَين (2)
98

أداء Android في المعالجة أحادية النواة أبطأ من المتوسط، مما يؤثر على تطبيقات الصفحة الواحدة الثقيلة مثل Discourse. نناقش هذا الأمر بتفصيل في حالة JavaScript على Android في عام 2015 هي… ضعيفة

أحدث إصدار من iPhone أسرع بـ 10 مرات من آخر جهاز Pixel عند عرض Discourse. لا تأخذ Google في الاعتبار عمليات عرض iPhone ضمن LCP، لأنه لا يمكنها ذلك نظرًا لعدم وجود متصفح Chrome حقيقي على iOS.

9 إعجابات
99

إذن قد يكون هناك بالفعل ميزة في هذا الصدد لإنشاء موقع من “صفحات صغيرة” لتقديمه لمحركات البحث بدلاً من ذلك. هل لا يستحق العناء؟ (ربما لا). أم أن على المشرفين تقديم هواتف عالية الجودة جديدة لمستخدميهم؟ :wink: هل هذا هو هدف كل هذه الإعلانات التي تدعي أنك ربحت أحدث آيفون؟ :rofl:

شكرًا لك على الشرح، يا فالكو!

إعجاب واحد (1)
100

من خلال التصفح السريع لـ Overview of CrUX  |  Chrome UX Report  |  Chrome for Developers يبدو أن جوجل تحصل على المعلومات من خلال مراقبة المستخدمين (بموافقتهم)، لذا ستحتاج إلى إقناع الكثير منهم باستخدام نظام Discourse البسيط الخاص بك :slight_smile:

4 إعجابات
103

يبدو أنك تخلط بين Ember و Ember CLI. إن Ember هو الإطار الذي نستخدمه بالفعل (ونستخدمه منذ أكثر من 8 سنوات). أما Ember CLI فهو أدوات سطر الأوامر التي ننتقل إليها بدلاً من استخدام خط أنابيب الأصول (asset pipeline) الخاص بـ Rails. أذكر هذا لأن بعض ما تقوله (مثل أن الإصدارات السابقة عن 3 تتطلب إعادة كتابة) لا ينطبق على Ember CLI، لكنه قد ينطبق على Ember.

مرة أخرى، لا يقوم Ember CLI بالتصيير. بل يقوم بذلك Ember، وفي بعض الأحيان يواجه مشاكل في الأداء. لاحظ أن هذا ليس أمراً خاصاً بـ Ember فقط؛ فجميع الأطر الحالية تحتوي على فخاخ أداء يجب أن تكون على دراية بها. بعد سنوات من العمل مع Ember، حددنا مسارين حرجين (الصفحة الرئيسية وعرض الموضوع) كانا بحاجة إلى أداء أفضل، فانتقلنا إلى نهج يعتمد على DOM الافتراضي.

قد لا نحتاج دائماً إلى القيام بذلك، اعتماداً على كيفية عمل Glimmer/Ember Octane، لكن الكود مستقر جداً ويعمل بسرعة حتى على الأجهزة المحمولة الأقدم الآن.

تم تقديم Ember Octane في الإصدار 3.15، ومنذ ذلك الحين صدر نسختان مستقرتان طويلتا الدعم (LTS) منه (3.16 و3.21). سنقوم بالترقية إليه، لكن بشكل تدريجي. لحسن الحظ، يسمح فريق Ember لك باختيار التنسيق الذي تريد استخدامه (حتى على مستوى الملف!).

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

اليوم، يتمتع Ember بنسبة شعبية أقل مقارنة بأطر أحدث مثل React. ومع ذلك، لم يكن React موجوداً قبل 8 سنوات! كانت خياراتنا الوحيدة هي Angular وEmber وKnockout. إذا كنت تعتقد أن ترقية Ember صعبة، فسترى ما مر به Angular من الإصدار 1 إلى الإصدار 2 (ناهيك عن مغامراته الجانبية مع Dart!).

كانت ترقية Ember على مر السنين شاقة جداً، لكنها على الأقل خيار متاح! لم تقدم أي من الأطر الأخرى مسار ترقية من هذا النوع.

أما بالنسبة لإعادة الكتابة باستخدام Vue/Next/React، فأعتقد أن الناس يقللون بشكل كبير من حجم الكود الذي لدينا والذي يعمل بشكل ممتاز. ستكون هذه عملية عمل لا تُحصى من حيث الجهد.

19 إعجابًا
104

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

6 إعجابات
105

أنا أفكر في الأمر يا @justin و @awesomerobot، لكنني أردت من Robin أن يشارك رأيه أولاً في تفاصيل Ember CLI.

في جوهر الأمر، هناك نوع من “ما الذي يحدث عندما تصطدم قوة لا تُقهر بجسم لا يتحرك؟” هنا.. نحن نعتبر بوضوح تطبيق جافا سكريبت (أو تطبيق صفحة واحدة SPA)، وهذا ينطوي على مفاضلات قررنا اتخاذها في عامي 2012/2013 بناءً على أفضل تخمين لدينا حول كيف سيبدو المستقبل في 2022/2023. وعلى الرغم من أنني متحيز بوضوح، إلا أنني أقول إن تنبؤنا بـ “يا إلهي، أداء متصفح الأجهزة المحمولة سيكون لا يمكن تمييزه عن أداء متصفح سطح المكتب” كان دقيقًا تمامًا.

في الواقع، تجاوزنا الهدف، حيث أن معظم هواتف آبل الحديثة أسرع من أجهزة الكمبيوتر المحمولة وأجهزة سطح المكتب. :astonished_face: هذا.. لم أتوقعه أبدًا!

:bullseye:

بينما سنواصل تحسين ما نستطيع بشأن سرعة التحميل الأولي – والسرعة بشكل عام – أعتقد أن سجلنا هنا يستحق الثناء. على سبيل المثال، حصلنا على قدر كبير من الدعاية في عام 2015 لدرجة أن جوجل أجرت داخليًا مجموعة من التحسينات في V8 و Chrome و Android لمعالجة ضعف أداء شرائح Qualcomm SoC كما تم قياسه في جافا سكريبت.

نقطة ضعفنا (أخيلس) كانت .. Qualcomm. للأسف، لم تحقق Qualcomm أداءً جيدًا حتى الآن من حيث الأداء، حيث أن الجهاز الأندرويد “الأفضل” أداءً لا يزال عند مستوى iPhone 7 تقريبًا. يستغرق الأمر وقتًا طويلاً حتى تتوقف الأجهزة الأندرويد القديمة عن الظهور في السوق، لكن معالجي 855 و 865 كانا أداءً جيدًا عند مستوى iPhone 7 تقريبًا:

image
image2110×1854 536 KB

يجب أن أتردد أكثر للأسفل للوصول إلى جهاز آبل بنفس بطء أسرع جهاز أندرويد، ولكن إذا فعلت ذلك، فإن أقرب تطابق هو iPhone X / iPhone 8 عند حوالي 910 في Geekbench. للأسف، المعالج 865، لأسباب لا أفهمها تمامًا، يؤدي أداءً أقل قليلاً على جانب الويب، لذا لا يزال لدينا مستوى أداء iPhone 7 في Speedometer:

image
image650×650 30.8 KB

أتمنى حقًا أننا نعيش في عالم توجد فيه أجهزة أندرويد تعمل بمجموعة متنوعة من شرائح SoC من شركات مختلفة تتنافس جميعها لبناء أسرع وأقوى شرائح SoC.. :crying_cat: من الناحية الإيجابية، أداء iPhone 7 قوي لمنصة Discourse وسعيد بأن في النهاية جميع أجهزة أندرويد، حتى القديمة منها، ستكون “على الأقل بنفس سرعة iPhone 7”. كما أنني أضع أصابعي على أمل في معالج Snapdragon 875 القادم، ومن المتوقع أن تظهر المزيد من التفاصيل حول ذلك في الأشهر القادمة. :crossed_fingers:

وفقًا لنتائج Geekbench 5، يمكننا أن نرى أن جهاز Xiaomi Mi 11 يعمل بمعالج Snapdragon 875 من الجيل 5 نانومتر (كما أشار إليه مسؤول Xiaomi Lu Weibing). وقد تمكن جهاز Xiaomi Mi 11 القادم من الحصول على 1,102 نقطة في اختبار النواة الفردية و 4,113 نقطة في اختبار النواة المتعددة.

إذا كان هذا صحيحًا، فسيضعه ذلك عند مستوى A12، ونأمل أن يظهر ذلك أيضًا على جانب الويب!

على أي حال، هناك قرار معماري أساسي هنا في Discourse وهو أن نكون تطبيق جافا سكريبت .. ونحن ملتزمون تمامًا بهذا المسار في المستقبل المنظور.

Deal_with_it_dog_gif

23 إعجابًا
109

بالنسبة لأولئك الذين يراقبون إحصائياتهم، إليك تاريخًا آخر لتدوينه. سيكون من المثير للاهتمام رؤية ما يحدث في الأسابيع القادمة فيما يتعلق بأحدث تحديث أساسي من جوجل، ديسمبر 2020.

https://searchengineland.com/googles-december-2020-core-update-was-big-even-bigger-than-may-2020-says-data-providers-344429

إعجاب واحد (1)
110

لا يمكنك نسيان أجهزة ماك الجديدة المجهزة بشريحة أبل سيليكون التي أُعلن عنها مؤخراً! :grinning:

فضولاً، من أين جاءت تلك الدعاية؟

شريحة A10 لا تزال تعمل بصعوبة بالغة.

فقط احتياطاً، سأضع توقعاتي منخفضة. أبل كانت دائماً متقدمة.

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

إعجابَين (2)
111

شكرًا لمشاركتك ذلك. إليك بعض النقاط ذات الصلة بهذه المناقشة مستخلصة من المقال:

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

هذا مفيد أيضًا.

https://searchengineland.com/google-advice-on-improving-your-sites-ranking-for-future-core-ranking-update-320184

7 إعجابات
112

في رأيي، عندما نتحدث عن تحسين محركات البحث (SEO)، وهو تحسين نتائج البحث مقارنة بالمواقع الأخرى، فإن الحديث عن عتاد المستخدم غير ذي صلة في الغالب.

لماذا؟

الأمر في الواقع بسيط جدًا.

لنتناول حالة شخص واحد ونتائج بحثه على جهازه المحمول.

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

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

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

لماذا؟

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

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

بالطبع، سيعمل نظام Discourse، الذي يعتمد على JavaScript كنوع من التطبيقات ذات الصفحة الواحدة (SPA)، بشكل أفضل بعد التحميل إذا كانت الهواتف أسرع. وينطبق نفس الشيء على كل موقع ويب آخر! بشكل عام، ما يهم هو أداء الشبكة بالإضافة إلى أداء الخادم، وليس جهاز المستخدم النهائي فيما يتعلق بتحسين محركات البحث. هذا ليس رأيي، بل هو حقيقة علمية وهندسية. رأيي أو ارتباطي العاطفي بلغة JavaScript أو إطار عمل EmberJS لا يغير كيفية عمل تحسين محركات البحث. ما يعمل لتحسين محركات البحث هو المحتوى وأداء تطبيق الويب.

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

نحن لا نقوم بترتيب مواقعنا الإلكترونية بأنفسنا. بل يقوم ذكاء اصطناعي جوجل بالترتيب.

كما أعلنت جوجل علنًا:

“يمكن التفكير في كيفية عمل التحديث الأساسي بتخيل أنك قمت بإعداد قائمة لأفضل 100 فيلم في عام 2015. بعد بضع سنوات في عام 2019، تقوم بتحديث القائمة. ستتحول بطبيعتها. ستظهر بعض الأفلام الجديدة والرائعة التي لم تكن موجودة من قبل كمرشحة للإدراج. قد تعيد أيضًا تقييم بعض الأفلام وتدرك أنها تستحق مكانًا أعلى في القائمة مما كانت عليه من قبل. ستتغير القائمة، والأفلام التي كانت في مراتب أعلى سابقًا وتنخفض في الترتيب ليست سيئة. ببساطة، هناك أفلام أكثر استحقاقًا تأتي قبلها”، كتبت جوجل.

قدمت الشركة القائمة التالية من الأسئلة التي يجب مراعاتها عند تقييم محتواك:

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

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

https://searchengineland.com/google-advice-on-improving-your-sites-ranking-for-future-core-ranking-update-320184

إعجابَين (2)
113

هذا يتعارض مع السجل - فنحن نعلم أن جوجل تجمع أوقات تحميل الصفحات في العالم الحقيقي من أجهزة أندرويد وتستخدمها لترتيب الصفحات.

4 إعجابات
114

نعم، لكن جميع أجهزة أندرويد (من نفس النوع) تؤدي أداءً متشابهًا بشكل أساسي لجميع مواقع الويب (من نفس النوع). بعبارة أخرى، إذا قمت بتحسين موقع ويب يعتمد على جافا سكريبت يستخدم webpacker و bundler، فإنك تتنافس، من منظور تحسين محركات البحث (SEO)، مع جميع المواقع الأخرى التي تستخدم تطبيقات الصفحة الواحدة (SPA) القائمة على جافا سكريبت وتستخدم webpacker و bundler، وما إلى ذلك.

لم أقل إن جوجل لا تجمع هذه المعلومات. أنا أحاول شرح أن التركيز على جهاز العميل لن يحل مشكلة أداء تحسين محركات البحث لتطبيقات الصفحة الواحدة. “المد الصاعد يرفع جميع القوارب”، لذا فإن المعالج الأسرع الذي يعالج جافا سكريبت المضغوطة بشكل جيد (سريع، محسّن، إلخ) سيعمل بشكل جيد على جميع مواقع الويب المماثلة.

بعبارة أخرى، تحسين محركات البحث يقع على جانب الخادم (كما كتبت سابقًا بتفصيل كبير)، وليس على جانب العميل.

وهذا موثق جيدًا، بالمناسبة.

دعنا نتجاوز ذلك :). أفضل عدم الخوض في نقاش هذا هنا على الميتا. شكرًا لك.

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

إعجابَين (2)
115

من منظور تحسين محركات البحث (SEO)، أنت بالفعل تتنافس مع مواقع مماثلة تقنيًا.

ولكن من منظور تجاري، فإنك تتنافس مع مواقع أخرى في سوقك، بغض النظر عن تقنيتها. وقد يدفع ذلك البعض إلى النظر في الانتقال إلى تقنية يُنظر إليها على أنها “أفضل” من منظور تحسين محركات البحث (SEO). وهذا هو الوضع الذي يجد فيه بعض الأشخاص أنفسهم فيه.

5 إعجابات