Vue.js و SEO: كيفية تحسين مواقع الويب التفاعلية لمحركات البحث والروبوتات

أصبحت أطر عمل JavaScript التفاعلية (مثل React و Vue.js و Angular) شائعة في الآونة الأخيرة ، ولا عجب أنها تُستخدم في المزيد والمزيد من مواقع الويب والتطبيقات نظرًا لمرونتها ونمطيتها وسهولة الاختبار الآلي.

تسمح أطر العمل هذه بتحقيق أشياء جديدة لم يكن من الممكن تصورها مسبقًا على موقع ويب أو تطبيق ، ولكن كيف تعمل من حيث تحسين محركات البحث؟ هل الصفحات التي تم إنشاؤها باستخدام هذه الأطر يتم فهرستها بواسطة Google؟ نظرًا لأن جميع - أو معظم - عرض الصفحة باستخدام هذه الأطر يتم إجراؤه في JavaScript (ويكون HTML الذي يتم تنزيله بواسطة الروبوتات فارغًا في الغالب) ، يبدو أنها محظورة إذا كنت تريد فهرسة مواقع الويب الخاصة بك محركات البحث أو حتى تم تحليلها بواسطة الروبوتات بشكل عام.

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

بعض المعلومات الأساسية عن المشكلة

كيف تعمل الفهرسة

لكي تتم فهرسة موقع الويب الخاص بك بواسطة Google ، يجب أن يتم الزحف إليه بواسطة Googlebot (برنامج فهرسة آلي يزور موقع الويب الخاص بك ويحفظ محتويات الصفحات في فهرسه) باتباع الروابط داخل كل صفحة. يبحث Googlebot أيضًا عن ملفات XML الخاصة بخريطة الموقع في مواقع الويب للعثور على الصفحات التي قد لا يتم ربطها بشكل صحيح من موقعك العام ولتلقي معلومات إضافية حول عدد المرات التي تتغير فيها الصفحات في موقع الويب ومتى تم تغييرها آخر مرة.

قليلا من التاريخ

قبل بضع سنوات (قبل عام 2009) ، اعتادت Google على فهرسة محتوى HTML لموقع الويب - باستثناء كل المحتوى الذي تم إنشاؤه بواسطة JavaScript. كانت معرفة مُحسّنات محرّكات البحث الشائعة هي عدم كتابة الروابط والمحتوى المهم بواسطة JavaScript نظرًا لأنه لن تتم فهرستها بواسطة Google ، وقد يتسبب ذلك في فرض عقوبة على موقع الويب لأن Google قد تعتبره "محتوى مزيفًا" كما لو كان مالك موقع الويب يحاول لتظهر للمستخدمين شيئًا مختلفًا عما تم عرضه على محركات البحث ومحاولة خداع الأخير.

كان من الشائع جدًا للمحتالين وضع الكثير من المحتوى الملائم لتحسين محركات البحث في HTML وإخفائه في JavaScript ، على سبيل المثال. لقد حذرت Google دائمًا من هذه الممارسة:

"يعتبر تقديم محتوى Googlebot مختلف عما يراه المستخدم العادي إخفاءً للهوية ، وسيكون مخالفًا لإرشادات مشرفي المواقع الخاصة بنا."

يمكن أن تعاقب على هذا. في بعض الحالات ، قد تتم معاقبتك على تقديم محتوى مختلف لوكلاء مستخدم مختلفين على جانب الخادم ، ولكن أيضًا بسبب تبديل المحتوى عبر JavaScript بعد تحميل الصفحة. أعتقد أن هذا يوضح لنا أن Google كانت تقوم بفهرسة مواقع الويب التي تنفذ JavaScript لفترة طويلة - على الأقل من أجل مقارنة HTML النهائي لموقع الويب (بعد تنفيذ JavaScript) و HTML الخام الذي كانت تحلله لفهارسها. لكن Googlebot لم ينفذ JavaScript طوال الوقت ، ولم تكن Google تستخدم المحتوى الذي تم إنشاؤه بواسطة JavaScript لأغراض الفهرسة.

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

على سبيل المثال ، إذا كان المحتوى الذي قرأته AJAX يأتي من خدمة ويب خارجية ، كان من الضروري تكرار نفس مكالمات خدمة الويب من جانب الخادم ، وإنتاج نفس HTML من جانب الخادم الذي كان من الممكن أن يتم إنتاجه من جانب العميل جافا سكريبت - أو على الأقل مشابهة جدًا. كان هذا معقدًا للغاية لأنه ، قبل ظهور Node.js ، كان يتطلب على الأقل تكرار نفس منطق العرض جزئيًا في لغتي برمجة مختلفتين: JavaScript للواجهة الأمامية و PHP و Java و Python و Ruby وما إلى ذلك ، الخلفية. يسمى هذا " العرض من جانب الخادم " ، وقد يؤدي إلى جحيم الصيانة: إذا أجريت تغييرات مهمة على كيفية عرض المحتوى في الواجهة الأمامية ، فسيتعين عليك تكرار هذه التغييرات على الواجهة الخلفية.

كان البديل الوحيد لتجنب تكرار المنطق هو تحليل موقعك باستخدام متصفح يقوم بتنفيذ JavaScript وحفظ النتائج النهائية على خادمك وتقديمها إلى Googlebot. هذا يشبه إلى حد ما ما يسمى الآن " العرض المسبق ".

تضمن Google (مع نظام الزحف AJAX الخاص به) أيضًا أنك ستتجنب العقوبات نظرًا لحقيقة أنك في هذه الحالة كنت تقدم محتوى مختلفًا لبرنامج Googlebot وللمستخدم. ومع ذلك ، منذ عام 2015 ، أوقفت Google هذه الممارسة من خلال منشور مدونة رسمي يخبر مديري مواقع الويب بما يلي:

"اليوم ، طالما أنك لا تمنع Googlebot من الزحف إلى ملفات JavaScript أو CSS ، فإننا قادرون بشكل عام على عرض وفهم صفحات الويب الخاصة بك مثل المتصفحات الحديثة."

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

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

كيف تقوم Google فعليًا بفهرسة الصفحات التي تم إنشاؤها باستخدام إطارات عمل الواجهة الأمامية؟

التجربة

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

محتويات الموقع مأخوذة من وصف كتاب Infinite Jest بقلم David Foster Wallace في Infinite Jest Wiki ( شكرًا يا رفاق! ). يوجد نصان تمهيديان للكتاب بأكمله ، وقائمة من الشخصيات مع سيرتهم الذاتية الفردية:

• بعض النصوص في HTML الثابت ، خارج الحاوية الرئيسية Vue.js ؛
• يتم تقديم بعض النصوص على الفور بواسطة Vue.js لأنها مضمنة في متغيرات موجودة بالفعل في كود التطبيق: يتم تعريفها في كائن data المكون ؛
• يتم عرض بعض النصوص بواسطة Vue.js من كائن data ، ولكن بتأخير قدره 300 مللي ثانية ؛
• تأتي السير الشخصية من مجموعة من واجهات برمجة التطبيقات (API) الباقية ، والتي قمت بإنشائها عن قصد باستخدام Sandbox. نظرًا لأنني كنت أفترض أن Google ستنفذ كود موقع الويب وتتوقف بعد بعض الوقت لأخذ لقطة للحالة الحالية للصفحة ، فقد قمت بتعيين كل خدمة ويب للرد بتأخير متزايد ، الأولى بـ 0 مللي ثانية ، والثانية بـ 300 مللي ثانية ، الثالث بـ 600 مللي ثانية وهكذا حتى 2700 مللي ثانية.

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

لقد قمت بنشر موقع الاختبار الصغير هذا على صفحات Github الخاصة بي وطلبت الفهرسة - ألق نظرة.

النتائج

وجاءت نتائج التجربة (الخاصة بالصفحة الرئيسية) كالتالي:

• يتم فهرسة المحتويات الموجودة بالفعل في محتوى HTML الثابت بواسطة Google (وهو أمر واضح إلى حد ما) ؛
• دائمًا ما تتم فهرسة المحتويات التي يتم إنشاؤها بواسطة Vue في الوقت الفعلي بواسطة Google ؛
• يتم أيضًا فهرسة المحتويات التي تم إنشاؤها بواسطة Vue ، ولكن يتم عرضها بعد 300 مللي ثانية ؛
• قد تتم فهرسة المحتويات التي تأتي من خدمة الويب ، مع بعض التأخير ، ولكن ليس دائمًا. لقد تحققت من فهرسة Google للصفحة في لحظات مختلفة ، وأحيانًا تتم فهرسة المحتوى الذي تم إدراجه أخيرًا (بعد بضع ثوانٍ) ، وأحيانًا لم يتم ذلك. المحتوى الذي يتم عرضه بسرعة كبيرة تتم فهرسته في معظم الأوقات ، حتى لو جاء من استدعاء غير متزامن لخدمة ويب خارجية. يعتمد هذا على أن Google لديها ميزانية عرض لكل صفحة وموقع ، والتي تعتمد على الخوارزميات الداخلية الخاصة بها ، وقد تختلف بشكل كبير اعتمادًا على ترتيب موقعك والحالة الحالية لقائمة انتظار عرض Googlebot. لذلك لا يمكنك الاعتماد على المحتوى القادم من خدمات الويب الخارجية للفهرسة ؛
• لا تتم فهرسة الصفحات الفرعية (حيث لا يمكن الوصول إليها كرابط مباشر) كما هو متوقع.

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

تحسين محركات البحث التنافسية

حسنًا ، تتم فهرسة المحتوى ، لكن ما لا تخبرنا به هذه التجربة هو: هل سيتم ترتيب المحتوى بشكل تنافسي؟ هل تفضل Google موقع ويب به محتوى ثابت على موقع ويب يتم إنشاؤه ديناميكيًا؟ هذا ليس بالسؤال السهل للاجابة عليه.

من واقع خبرتي ، يمكنني القول أن المحتوى الذي يتم إنشاؤه ديناميكيًا يمكن أن يحتل المرتبة الأولى في SERPS. لقد عملت على موقع ويب لطراز جديد لشركة سيارات كبرى ، حيث أطلقت موقعًا إلكترونيًا جديدًا بنطاق جديد من المستوى الثالث. تم إنشاء الموقع بالكامل باستخدام Vue.js - مع القليل جدًا من المحتوى في HTML الثابت إلى جانب علامات <title> وأوصاف meta .

بدأ الموقع في الترتيب لعمليات البحث البسيطة في الأيام القليلة الأولى بعد النشر ، وأبلغت المقتطفات النصية في SERPs عن كلمات قادمة مباشرة من المحتوى الديناميكي.

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

ولكن بالنظر إلى حقيقة أنه كان علينا مواجهة معارضة قوية من شركة تحسين محركات البحث (SEO) التي كانت مسؤولة عن المشروع ، أعتقد أن النتيجة كانت لا تزال رائعة.

نظرًا لضيق المواعيد النهائية وضيق الوقت الممنوح للمشروع ، كنا بصدد نشر الموقع دون عرض مسبق.

نص متحرك

ما لا تقوم Google بفهرسته هو نص متحرك بشكل كبير. يحتوي موقع إحدى الشركات التي أعمل معها ، Rabbit Hole Consulting ، على الكثير من الرسوم المتحركة النصية ، والتي يتم إجراؤها أثناء قيام المستخدم بالتمرير ، وتتطلب تقسيم النص إلى عدة أجزاء عبر علامات مختلفة.

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

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

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

ماذا عن العرض المسبق؟

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

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

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

يوصى بالقراءة : كيف يؤثر تصميم الويب للجوال في البحث المحلي (وماذا تفعل حيال ذلك)

اعتبارات أخرى

التوافق

حتى وقت قريب ، استخدم Googlebot إصدارًا قديمًا إلى حد ما من Chromium (مشروع مفتوح المصدر يعتمد عليه Google Chrome) ، أي الإصدار 41. وهذا يعني أن بعض ميزات JavaScript أو CSS الحديثة لا يمكن عرضها بواسطة Google بشكل صحيح (مثل IntersectionObserver ، بناء جملة ES6 ، وما إلى ذلك).

أعلنت Google مؤخرًا أنها تشغل الآن أحدث إصدار من Chromium (74 ، وقت كتابة هذا التقرير) في Googlebot ، وأنه سيتم تحديث الإصدار بانتظام. قد يكون لحقيقة أن Google كانت تشغل Chromium 41 آثارًا كبيرة على المواقع التي قررت تجاهل التوافق مع IE11 والمتصفحات القديمة الأخرى.

يمكنك مشاهدة مقارنة بين دعم Chromium 41 و Chromium 74 للميزات هنا ، ومع ذلك ، إذا كان موقعك يقوم بالفعل بإعادة تعبئة الميزات المفقودة للبقاء متوافقًا مع المتصفحات القديمة ، فلا ينبغي أن تكون هناك مشكلة.

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

أخطاء JavaScript

إذا كنت تعتمد على Googlebot في تنفيذ JavaScript لعرض المحتوى الحيوي ، فيجب تجنب أخطاء JavaScript الرئيسية التي قد تمنع عرض المحتوى بأي ثمن. على الرغم من أن برامج الروبوت قد تحلل وتفهرس HTML وهي ليست صالحة تمامًا (على الرغم من أنه من الأفضل دائمًا أن يكون لديك HTML صالح على أي موقع!) ، إذا كان هناك خطأ JavaScript يمنع تحميل بعض المحتوى ، فلا توجد طريقة لفهرسة Google هذا المحتوى.

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

من الأفضل أن يكون لديك بعض برامج التحقق من الأخطاء في الوقت الفعلي (مثل Sentry أو LogRocket) والتي ستنبهك إلى أي أخطاء في حالة الحافة قد لا تختارها أثناء الاختبار اليدوي أو الوحدة. هذا يضيف إلى تعقيد الاعتماد على جافا سكريبت لمحتوى تحسين محركات البحث.

محركات بحث أخرى

لا تعمل محركات البحث الأخرى مثل Google ذات المحتوى الديناميكي. لا يبدو أن Bing يقوم بفهرسة المحتوى الديناميكي على الإطلاق ، ولا يفعله DuckDuckGo أو Baidu. ربما تفتقر محركات البحث هذه إلى الموارد وقوة الحوسبة التي تتمتع بها Google.

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

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

روبوتات أخرى

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

الصفحات الفرعية

إذا كان موقعك يسمى "موقع ويب صفحة واحدة" ، وكان كل المحتوى ذي الصلة موجودًا في HTML رئيسي واحد ، فلن تواجه مشكلة في فهرسة هذا المحتوى بواسطة Google. ومع ذلك ، إذا كنت تريد أن تقوم Google بفهرسة وعرض أي صفحة ثانوية على موقع الويب ، فستظل بحاجة إلى إنشاء HTML ثابت لكل منها - حتى إذا كنت تعتمد على JavaScript Framework الخاص بك للتحقق من عنوان URL الحالي وتقديم المحتوى ذي الصلة لوضعه في تلك الصفحة. نصيحتي ، في هذه الحالة ، هي إنشاء صفحات من جانب الخادم (أو ثابتة) توفر على الأقل علامة title الصحيحة ووصف التعريف / المعلومات.

الاستنتاجات

الاستنتاجات التي توصلت إليها أثناء البحث في هذه المقالة هي كما يلي:

1. إذا كنت تستهدف Google فقط ، فلا يلزم استخدام العرض المسبق لفهرسة موقعك بالكامل ، ومع ذلك:
2. يجب ألا تعتمد على خدمات الويب التابعة لجهات خارجية للمحتوى الذي يجب فهرسته ، خاصةً إذا لم يردوا بسرعة.
3. تتم فهرسة المحتوى الذي تقوم بإدراجه في HTML الخاص بك على الفور عبر عرض Vue.js ، ولكن لا يجب عليك استخدام نص متحرك أو نص يتم إدراجه في DOM بعد إجراءات المستخدم مثل التمرير وما إلى ذلك.
4. تأكد من اختبار أخطاء JavaScript لأنها قد تؤدي إلى عدم فهرسة صفحات / أقسام كاملة ، أو عدم فهرسة موقعك على الإطلاق.
5. إذا كان موقعك يحتوي على صفحات متعددة ، فلا تزال بحاجة إلى بعض المنطق لإنشاء صفحات يمكن لـ Google ، أثناء الاعتماد على نفس نظام عرض الواجهة الأمامية مثل الصفحة الرئيسية ، فهرستها كعناوين URL فردية.
6. إذا كنت بحاجة إلى وصف مختلف ومعاينة الصور للوسائط الاجتماعية بين الصفحات المختلفة ، فستحتاج إلى معالجة هذا أيضًا ، إما من جانب الخادم أو عن طريق تجميع الصفحات الثابتة لكل عنوان URL.
7. إذا كنت تريد أداء موقعك على محركات البحث بخلاف Google ، فستحتاج بالتأكيد إلى عرض مسبق من نوع ما.