ساعات عمل كبار المسئولين الاقتصاديين في المكتب - 8 أكتوبر 2021

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

عدد الصفحات المفهرسة مقابل سلطة الموقع

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

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

تقييم الغرض الأساسي لموقع الويب

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

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

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

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

إعادة توجيه الروابط

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

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

[...] فيما يتعلق بـ 301 أو 302 ، لا أعتقد أنه مهم هناك ، لأننا إما سنرى هذا باعتباره 404 ناعمًا ، أو سنراه سؤالًا أساسيًا. إذا كان خطأ soft 404 ، فلن يكون الرمز مهمًا. إذا كان سؤالًا أساسيًا ، فسيتم تحديد عنوان URL الذي نعرضه في نتائج البحث. وعادة ما يكون للمستوى الأعلى إشارات أقوى على أي حال ، وسنركز على المستوى الأعلى. لا يهم إذا كان ذلك 301 أو 302 في هذه الحالة.

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

[…] أعتقد أن [تحديث] خرائط الموقع وحدها ربما لا يكفي. أود حقًا التأكد من أن الارتباط الداخلي واضح أيضًا ".

التعافي من التحديثات الأساسية

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

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

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

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

الروابط في مشاركات الضيف

28:24 "[...] إذا كان [موقع ويب] منشور ضيف ، ولا تعرف Google ما إذا كانت مدفوعة أم لا ، فكيف ستحدد Google حينئذٍ [عليهم] أخذ هذا الرابط أو نسخ هذا الرابط؟ ما هو الجواب حتى نكون في مأمن من كل الزوايا؟ "

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

سعر المنتج كعامل ترتيب

32:25 "إذا كان هناك موقعان متنافسان للتجارة الإلكترونية يبيعان نفس المنتج تمامًا - يعرض أحدهما المنتج بسعر 500 دولار والآخر 100 دولار ، فإن جميع إشارات تحسين محركات البحث متساوية. هل سيكون لموقع الويب الأقل تكلفة فرصة أفضل في الترتيب نظرًا لوجود فرق في السعر لنفس المنتج بالضبط؟ ".

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

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

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

نقل عناوين URL بين خرائط المواقع

34:04 "إذا كان لدينا 200 ملف خريطة موقع ، و 20٪ إلى 30٪ من عناوين URL تنتقل من ملف إلى آخر كل أسبوع ، فما مدى سوء ذلك؟ أم هل يجب أن نحتفظ بعناوين URL الخاصة بنا في الملف نفسه إلى الأبد؟ "

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

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

محتوى متعدد المناطق

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

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

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

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

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

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

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

إعادة التوجيه في موقع نقل

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

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

API والزحف الميزانية

46:13 لدي موقع ويب يتصل بواجهات برمجة التطبيقات من جانب العميل للحصول على البيانات. هل يتم تضمين عناوين URL هذه في ميزانية الزحف؟ إذا لم تسمح بعناوين URL هذه ، [...] فهل سيؤدي ذلك إلى حدوث أية مشكلات؟ "

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

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

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

جافا سكريبت وجوجل مخبأ

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

لذا فإن السؤال يتكون من جزأين. في الأساس ، لماذا هذا السلوك؟ وثانيًا ، هل سيؤثر هذا السلوك على ترتيبي؟ أرى تلك الصفحات تظهر في نتائج البحث التي ليست في ذاكرة التخزين المؤقت لـ Google ".

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

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

https://www.youtube.com/watch؟v=Vd0rEQrwHDc