أطر JavaScript من جانب العميل
تشترك React وVue وAngular وSvelte وSolidJS في مشكلة SEO واحدة: يرسل العرض من جانب العميل قشرة فارغة. والحل هو إدارة head مع استراتيجية عرض.
اللغات
React وVue وAngular وSvelte وSolidJS مكتبات واجهة مستخدم ترسل افتراضياً قشرة HTML شبه فارغة وتبني الصفحة في المتصفح بالعرض من جانب العميل. وهذا يترك الزواحف أمام صفحة فارغة حتى تشغيل JavaScript؛ تستطيع Google عرضها عبر طابور مؤجل، بينما تقل موثوقية Bing وزواحف الذكاء الاصطناعي. والحل واحد: حزمة لإدارة head كي توجد وسوم meta لكل مسار، واستراتيجية عرض مثل العرض المسبق أو SSR أو الإطار الفوقي الموافق. يشرح هذا المحور المشكلة والحل المشتركين، ثم يحيل إلى الأدلة الخاصة بكل إطار.
الخلاصة — React وVue وAngular وSvelte وSolidJS أدوات يستخدمها المطورون لبناء مواقع تفاعلية. وهي ترسل افتراضياً إلى المتصفح صفحة HTML شبه فارغة، ثم تنشئ المحتوى الفعلي باستخدام JavaScript. هذا مفيد للمستخدمين لكنه ينطوي على مخاطرة في SEO، إذ قد يصل زاحف البحث إلى صفحة فارغة. والحل واحد للجميع: أدر وسم
<title>ووسوم meta لكل صفحة، وتأكد من وجود المحتوى في HTML قبل تشغيل JavaScript.
ما أطر العمل من جانب العميل
يمكن لأطر العمل من جانب العميل عرض محتوى المسار في المتصفح بعد استجابة HTML الأولية. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: MDN: Client-side frameworks تستطيع Google عرض JavaScript، لكن توافر الموارد وعملية العرض يظلان مؤثرين في ما تتم معالجته. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: Google: JavaScript SEO basics
إطار العمل من جانب العميل مكتبة JavaScript تنشئ الصفحة داخل متصفح الزائر. وأكثر خمسة ستصادفها هي React وVue وAngular وSvelte وSolidJS. وبها تُبنى معظم تطبيقات الويب الحديثة ولوحات المعلومات.
تكمن المشكلة في عبارة من جانب العميل. ترسل هذه الأطر افتراضياً ملف HTML صغيراً يبدو تقريباً هكذا:
<body>
<div id="root"></div>
<script src="/bundle.js"></script>
</body>لا يوجد محتوى في ملف HTML هذا، بل حاوية فارغة وبرنامج نصي فقط. ينزّل المتصفح البرنامج ويشغله، وبعد ذلك يظهر العنوان والنص والروابط وكل شيء آخر. يسمى هذا السلوك الافتراضي العرض من جانب العميل (CSR)، وغالباً ما يسمى الموقع المبني بهذه الطريقة تطبيق الصفحة الواحدة (SPA).
لماذا يمثل ذلك مشكلة لـSEO
زاحف البحث ليس شخصاً يتنقل بالنقر. عندما يجلب Googlebot أو زاحف آخر صفحتك، يكون أول ما يتلقاه تلك القشرة الفارغة. وإذا لم يشغّل الزاحف JavaScript، فإنه يرى صفحة فارغة بلا محتوى يمكن فهرسته.
تستطيع Google تشغيل JavaScript، ولذلك ترى محتواك في النهاية غالباً. لكن:
- يحدث ذلك بعد تأخير، لأن العرض خطوة مستقلة تدخل طابوراً.
- أما الزواحف الأخرى، مثل Bing وزواحف الذكاء الاصطناعي التي تغذي أدوات مثل ChatGPT، فهي أقل موثوقية بكثير في تشغيل JavaScript.
لذلك لا تعني عبارة «يعمل في متصفحي» أن «محركات البحث تستطيع رؤيته».
الحل واحد للأطر الخمسة
أياً كان إطار العمل الذي اخترته، يتكون الحل من جزأين:
- أدر قسم head. تحتاج كل صفحة إلى وسم
<title>ووصف meta خاصين بها. يحتوي تطبيق CSR البسيط على ملف HTML واحد، لذلك تشترك كل الصفحات في العنوان نفسه من دون أداة مساعدة. ولكل إطار حزمة صغيرة تعالج ذلك (المزيد في علامة التبويب Advanced). - اختر استراتيجية عرض. ضع محتواك في HTML قبل تشغيل JavaScript، إما عبر العرض المسبق (إنشاء HTML ثابت مسبقاً)، أو العرض من جانب الخادم (SSR)، أو الانتقال إلى إطار العمل الفوقي الموافق (Next.js لـReact وNuxt لـVue، وهكذا).
هل تريد تفاصيل كل إطار، مثل حزمة إدارة head وخيار العرض وكيف تتعامل Google فعلياً مع هذه التطبيقات؟ انتقل إلى علامة التبويب Advanced، ثم إلى الدليل المخصص لإطارك.
الخلاصة — React وVue وAngular وSvelte وSolidJS مكتبات واجهة مستخدم تعتمد افتراضياً العرض من جانب العميل: ترسل قشرة HTML شبه فارغة وتبني DOM في المتصفح. مشكلة SEO واحدة في الأطر الخمسة؛ فالزاحف يتلقى قشرة فارغة ولا يوجد المحتوى إلا بعد تنفيذ JavaScript. تعرض Google هذه التطبيقات، لكن عبر طابور مؤجل، بينما يقل الاعتماد على Bing وزواحف الذكاء الاصطناعي. والحل واحد أيضاً: (1) إدارة head بحزمة لكل مسار لوسم
<title>ووسوم meta، و**(2) استراتيجية عرض**، مثل العرض المسبق أو SSR أو الانتقال إلى إطار العمل الفوقي الموافق. وتكمن الفروق أساساً في اسم الحزمة والاستراتيجية، كما توضحه الأدلة المتخصصة أدناه.
إنها مكتبات وليست أطر عمل كاملة — وهذا أصل المشكلة
تختلف معماريات الأطر، ولذلك لا يعني العرض من جانب العميل تلقائياً فشل الفهرسة. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: MDN: Client-side frameworks يقلل العرض من الخادم أو العرض المسبق الاعتماد على تنفيذ JavaScript لدى الزاحف، من دون أن يضمن الفهرسة. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: Google: JavaScript SEO basics
React وVue وAngular وSvelte وSolidJS هي أساساً مكتبات لعرض واجهة المستخدم. تتمثل مهمتها في تحويل بياناتك إلى DOM وإبقائه متزامناً عند تغير الحالة. ويُبنى DOM افتراضياً في المتصفح؛ وهذا بالضبط ما يجعلها سريعة وشبيهة بالتطبيقات، وما ينشئ مشكلة SEO أيضاً.
يرسل البناء الافتراضي قشرة HTML بعقدة تحميل فارغة (<div id="root"> أو <div id="app"> أو <app-root>) وحزمة JavaScript. وكل ما يهم محرك البحث، من العناوين والنص والروابط الداخلية والبيانات المنظمة، تحقنه الحزمة بعد تنزيلها وتنفيذها. وقبل تشغيل JavaScript لا يوجد شيء هناك.
هذا هو العرض من جانب العميل، أي سلوك المكتبات المجردة فور إخراجها من الصندوق قبل إضافة إطار فوقي أو خطوة عرض مسبق أثناء البناء. وليس خطأ، بل نقطة البداية الافتراضية. لكن «الافتراضي» لا يعني «دائماً» أو «عالمياً»: يتغير باختلاف الإصدار وأداة CLI أو القالب المستخدم، وقد يعمل مساران في التطبيق نفسه بنمطي عرض مختلفين بحسب بنائهما، كصفحة تسويق معروضة مسبقاً ولوحة معلومات بقيت CSR خالصاً. لا تستنتج السلوك من اسم الإطار؛ افحص ما يرسله مسار بعينه في بناء بعينه.
المشكلة المشتركة: قشرة فارغة
توضح Google أنها تعالج تطبيقات JavaScript على مراحل: الزحف ثم العرض ثم الفهرسة، وأنه “without rendering Google might not see that content.” (ترجمة) «من دون العرض قد لا ترى Google ذلك المحتوى». وفي تطبيق CSR يوجد كل المحتوى خلف خطوة العرض. وينتج عن ذلك ثلاثة آثار:
- العرض مؤجل ومدة الانتظار غير ثابتة. العرض خطوة مستقلة تدخل طابوراً بعد الزحف. توثق Google الزحف والعرض والفهرسة بوصفها ثلاث مراحل منفصلة، لكنها لا تلتزم بمدة انتظار عالمية لكل صفحة. يختلف التأخير حسب عنوان URL وموارد Google المتاحة حينها؛ ولا يوجد محتواك للفهرسة حتى يكتمل العرض فعلياً، مهما استغرق ذلك للصفحة.
- لا يمكن افتراض سلوك الزواحف غير التابعة لـGoogle. يعرض Bing JavaScript بصورة غير متسقة، ولا تنفذ معظم زواحف الذكاء الاصطناعي إلا قدراً قليلاً من JavaScript أو لا تنفذه إطلاقاً. هذه شركات وبنى تحتية منفصلة، فلا يجوز تعميم وثائق Google عليها؛ تحقق من السلوك الحالي لكل مزود بدلاً من افتراض مطابقته لـGoogle أو لاختبار العام الماضي. وقد يصبح موقع CSR فقط شبه غير مرئي للزواحف التي لا تعرض JavaScript، مع نمو حصة زواحف الذكاء الاصطناعي من الزيارات.
- بيانات التعريف الخاصة بكل صفحة مفقودة. يعني ملف HTML واحد وجود
<title>واحد ووصف meta واحد لكل المسارات، ما لم تدر قسم head لكل مسار بفاعلية.
الحل المشترك، الجزء الأول: إدارة head
لأن تطبيق SPA يملك مستند HTML واحداً، تحتاج إلى شفرة تحدّث head المستند عند انتقال المستخدم (وعارض الزاحف) بين المسارات. ولكل إطار حزمة معتمدة أو واجهة API مدمجة لهذا الغرض:
- React ←
react-helmet-async(أو واجهة metadata في الإطار إذا انتقلت إلى Next.js). - Vue ←
@unhead/vue(المحرك وراء أدوات SEO في Nuxt). - Angular ← خدمتا
TitleوMetaالمدمجتان من@angular/platform-browser، بلا تبعية إضافية. - Svelte ← العنصر المدمج
<svelte:head>. - SolidJS ←
@solidjs/meta(وSolidStart لمسار SSR).
تمنحك إدارة head وسوم meta صحيحة وفريدة، لكنها لا تحل مشكلة القشرة الفارغة وحدها. فالوسوم لا تظهر إلا بعد تشغيل JavaScript. ولهذا تحتاج أيضاً إلى الجزء الثاني.
الحل المشترك، الجزء الثاني: استراتيجية عرض
لوضع المحتوى الحقيقي (ووسوم head) في HTML قبل تنفيذ JavaScript، اختر أحد ثلاثة أساليب، مرتبة بحسب مقدار مخاطرة SEO التي تزيلها:
- العرض المسبق / التوليد الثابت (SSG). أنشئ HTML ثابتاً لكل مسار وقت البناء. وهو الأقل مخاطرة للمحتوى الذي لا يتغير مع كل طلب. ولكل مكتبة مسار عرض مسبق، مثل العرض المسبق المدمج في SolidJS وإضافات Vue والعرض المسبق في Angular.
- العرض من جانب الخادم (SSR). اعرض HTML على الخادم لكل طلب، ثم نفذ hydration في المتصفح. وهنا تأتي الأطر الفوقية: Next.js لـReact وNuxt لـVue وAngular SSR (المعروف سابقاً باسم Angular Universal) وSvelteKit لـSvelte وSolidStart لـSolidJS. واعتماد الإطار الفوقي الموافق هو الحل الأنظف لمعظم مواقع المحتوى التي تحتاج إلى الترتيب.
- ابقَ على CSR كاملاً واجعله قابلاً للزحف. قد يكون ذلك مقبولاً لواجهات شبيهة بالتطبيقات خلف تسجيل الدخول ولا تحتاج إلى الترتيب، لكنه افتراضي ضعيف لأي شيء تريده في البحث.
اتخذ القرار لكل مسار، لا لكل تطبيق. فقد تقع صفحة تسويق ولوحة معلومات لمستخدم مسجل في صفين مختلفين من القائمة نفسها بصورة منطقية. واسأل عن كل مسار:
- المخرجات — هل يجب أن يكون المحتوى في الاستجابة الأولية، أم يكفي ظهوره بعد تشغيل JavaScript؟
- الحداثة — هل هو ثابت بما يكفي لبنائه مرة واحدة (عرض مسبق)، أم يتغير مع كل طلب (SSR)؟
- التخصيص — هل يختلف لكل زائر؟ لا يفيد العرض المسبق هنا، وعليك الاختيار بين SSR وCSR.
- تكلفة الخادم — يضيف SSR معالجة لكل طلب، بينما يحمّل العرض المسبق تلك التكلفة وقت البناء.
- الاعتماد على JavaScript — ما مقدار فائدة المسار المعتمدة على تشغيل JavaScript لدى العميل؟
- سلوك الفشل — إذا فشل JavaScript أو حُجب، فهل يتراجع المسار إلى شيء قابل للاستخدام أم إلى لا شيء؟
السؤال واحد بصرف النظر عن الإطار: هل يحتاج هذا المحتوى إلى الترتيب أو الاستشهاد به؟ إذا كانت الإجابة نعم، فضَعْه في HTML المعروض على الخادم أو مسبقاً. وإذا كان مجرد واجهة تطبيق تفاعلية، فإن CSR مناسب.
كيف تتعامل Google مع هذه التطبيقات (ولماذا لا تفعل الجهات الأخرى الشيء نفسه)
تستطيع Google عرض كل هذه الأطر؛ فهي تشغل Chrome دائم التحديث من دون واجهة وتنفذ JavaScript. لكنها تفعل ذلك عبر طابور مؤجل، والعارض عديم الحالة (لا يحتفظ بملفات تعريف الارتباط أو localStorage، ولا يستخدم service workers، ولا يتفاعل أو يمرر أو ينقر). لذلك تنطبق قواعد JS-SEO نفسها من محور JavaScript SEO فوق اختيار الإطار: روابط <a href> حقيقية، وتكافؤ DOM الخام والمعروض، وعدم حجب المحتوى خلف تفاعل، وعدم حقن noindex عبر JavaScript.
خارج Google تبدو الصورة أسوأ. فعرض JavaScript لدى Bing أقل اتساقاً، ومعظم زواحف الذكاء الاصطناعي لا تعرضه إطلاقاً. وقد يعني ذلك في تطبيق CSR أن المحتوى يوجد لدى Google في النهاية، لكنه لا يوجد لدى Bing أو أدوات الذكاء الاصطناعي التي يبحث بها عدد متزايد من الناس. يغلق SSR أو العرض المسبق هذه الفجوة أمام الجميع لا Google وحدها؛ وهذه أقوى حجة ضد نشر محتوى CSR فقط.
الأطر الخمسة في لمحة
| الإطار | الافتراضي | إدارة head | SSR / الإطار الفوقي | ملاحظة SEO |
|---|---|---|---|---|
| React | CSR | react-helmet-async | Next.js (واجهة Metadata) | أشهر SPA يبدأ بـCSR؛ وNext.js هو حل SEO القياسي |
| Vue | CSR | @unhead/vue | Nuxt (useSeoMeta()) | يستخدم Nuxt SSR افتراضياً؛ وتحتاج Vue المجردة إلى العرض المسبق أو Nuxt |
| Angular | CSR (SPA) | خدمتا Title/Meta المدمجتان | Angular SSR (Universal سابقاً) | تطبيقات SPA كبيرة؛ وتضيف Angular الحديثة SSR وhydration تزايدياً |
| Svelte | CSR (Svelte) / SSR (SvelteKit) | <svelte:head> | SvelteKit (SSR افتراضياً) | يستخدم SvelteKit SSR افتراضياً؛ انتبه إلى فخ ssr:false الثابت |
| SolidJS | CSR | @solidjs/meta | SolidStart | تفاعلية دقيقة الحبيبات؛ ويضيف SolidStart العرض المسبق وSSR |
النمط ثابت: CSR افتراضي، وحزمة لإدارة head، واستراتيجية عرض (غالباً الإطار الفوقي الموافق). وما يختلف هو الأسماء وبعض التفاصيل الحادة.
الخطوة التالية: الأدلة المتعمقة لكل إطار
هذا المحور هو الخريطة. ولكل إطار دليل خاص بالحزم والإعدادات والمشكلات المحددة:
- React SEO — لماذا ينشئ React الذي يبدأ بـCSR مخاطرة فهرسة، وReact Router وHistory API و
react-helmet-async، ومتى تستخدم Next.js. - Vue SEO — افتراضي CSR في Vue 3 و
createWebHistory()و@unhead/vueوالعرض المسبق من دون إطار فوقي، ومتى يكون Nuxt الخيار الصحيح. - Angular SEO — افتراضيات SPA في Angular و
@angular/ssrوخدمتاTitleوMetaالمدمجتان والعرض المسبق وhydration التزايدي. - Svelte SEO — الفرق بين Svelte وSvelteKit، وSSR الافتراضي في SvelteKit، و
<svelte:head>، وفخadapter-staticمعssr: false، وآثاره على زواحف الذكاء الاصطناعي. - SolidJS SEO — افتراضي CSR في SolidJS و
@solidjs/metaوSolidStart لـSSR والعرض المسبق، وتأثير نموذجه الدقيق في المخرجات المعروضة.
لأنماط العرض نفسها (CSR وSSR وSSG وISR وhydration والعرض الديناميكي) وقواعد العرض والتكافؤ الأوسع، راجع محور JavaScript SEO الأب.
ملخص الذكاء الاصطناعي
خلاصة مكثفة للنسخة المتقدمة:
- نقطة بداية مشتركة. تعتمد React وVue وAngular وSvelte وSolidJS افتراضياً العرض من جانب العميل، أي قشرة HTML شبه فارغة (
<div id="root">وحزمة) تبني DOM في المتصفح. يتغير هذا الافتراضي بحسب الإصدار والقالب والإطار الفوقي، وقد يختلف من مسار إلى آخر داخل التطبيق نفسه؛ افحص ما يرسله المسار فعلياً ولا تفترضه من اسم الإطار. - تعرضه Google لكن الانتظار غير ثابت. العرض خطوة مستقلة تدخل طابوراً بعد الزحف، ولا تلتزم Google بتأخير عالمي واحد لكل الصفحات؛ فهو يختلف حسب URL. والعارض عديم الحالة ولا يمرر أو ينقر.
- لا يمكن افتراض سلوك الزواحف الأخرى. يعرض Bing JavaScript بصورة غير متسقة، ومعظم زواحف الذكاء الاصطناعي لا تعرضه إطلاقاً. فهي شركات مستقلة، لذلك تحقق من السلوك الحالي لكل مزود.
- حل مشترك من جزأين. (1) إدارة head بحزمة لكل مسار لوسم
<title>ووسوم meta:react-helmet-asyncو@unhead/vueوخدمتاTitle/Metaو<svelte:head>و@solidjs/meta. (2) استراتيجية عرض: العرض المسبق/SSG أو SSR أو الإطار الفوقي الموافق (Next.js / Nuxt / Angular SSR / SvelteKit / SolidStart). - إدارة head وحدها لا تكفي؛ فالوسوم لا تظهر إلا بعد تشغيل JavaScript، وما زلت تحتاج إلى استراتيجية تملأ القشرة.
- قرر لكل مسار وفق توقيت المخرجات والحداثة والتخصيص وتكلفة الخادم والاعتماد على JavaScript وسلوك الفشل، لا لكل تطبيق. ضع المسار المطلوب ترتيبه أو الاستشهاد به في HTML المعروض على الخادم أو مسبقاً، واترك CSR لواجهة التطبيق خلف تسجيل الدخول.
الوثائق الرسمية
وثائق المصادر الأولية من محركات البحث والأطر.
- فهم أساسيات تحسين محركات البحث لـJavaScript — مراحل الزحف ← العرض ← الفهرسة، والروابط القابلة للزحف، واختبار HTML المعروض.
- إصلاح مشكلات JavaScript المرتبطة بالبحث — معالجة أخطاء soft-404 بعد التوجيه من جانب العميل وHistory API وقيود العارض.
- دليل متعمق إلى آلية عمل بحث Google — موضع العرض ضمن الزحف ← الفهرسة ← التقديم.
Bing / Microsoft
- سلسلة bingbot: JavaScript والعرض الديناميكي والإخفاء — عرض Bing لـJavaScript وسبب وجود العرض الديناميكي.
الأطر (head والعرض)
- وثائق React — المكتبة التي أشاعت SPA الذي يبدأ بـCSR؛ راجع أيضاً بيانات التعريف في Next.js.
- Vue.js — العرض وSSR وأدوات SEO في Nuxt.
- Angular — العرض من جانب الخادم وخدمتا
TitleوMeta. - SvelteKit — خيارات الصفحة للعرض والعرض المسبق و
<svelte:head>. - SolidStart — العرض من جانب الخادم والعرض المسبق و
@solidjs/meta.
اقتباسات من المصدر
تصريحات موثقة تؤسس لمشكلة CSR المشتركة وحلها. وكل رابط لمحرك بحث رابط عميق ينقلك إلى المقطع المقتبس.
Google — العرض وسبب أهمية القشرة
- “Google processes JavaScript web apps in three main phases: 1. Crawling 2. Rendering 3. Indexing.” (ترجمة) «تعالج Google تطبيقات الويب المبنية بـJavaScript في ثلاث مراحل رئيسية: 1. الزحف 2. العرض 3. الفهرسة». الانتقال إلى الاقتباس
- “Rendering is important because websites often rely on JavaScript to bring content to the page, and without rendering Google might not see that content.” (ترجمة) «العرض مهم لأن المواقع تعتمد غالباً على JavaScript لإحضار المحتوى إلى الصفحة، ومن دونه قد لا ترى Google ذلك المحتوى». الانتقال إلى الاقتباس
- “Google can only discover your links if they are <a> HTML elements with an href attribute.” (ترجمة) «لا تستطيع Google اكتشاف روابطك إلا إذا كانت عناصر HTML من نوع <a> تحمل سمة href» — وينطبق ذلك على موجه كل إطار. الانتقال إلى الاقتباس
- “Google Search does not interact with your page.” (ترجمة) «لا يتفاعل بحث Google مع صفحتك» — لن يمرر العارض أو ينقر لكشف المحتوى. الانتقال إلى الاقتباس
Patrick Stox (عملي — دليل شامل إلى تحسين محركات البحث لـJavaScript)
- “Any kind of SSR, static rendering, and prerendering setup is going to be fine for search engines.” (ترجمة) «سيكون أي إعداد لـSSR أو العرض الثابت أو العرض المسبق مناسباً لمحركات البحث» — وهي الفكرة الجامعة لكل إطار في هذا المحور.
- يأخذ العارض توجيه robots الأكثر تقييداً بين HTML الخام والمعروض؛ ولذلك يمكن لإطار يحقن
noindexمن جانب العميل أن يزيل الصفحة من الفهرس حتى لو قالت القشرةindex.
قائمة تحقق SEO لأطر العمل من جانب العميل
تصلح لـReact وVue وAngular وSvelte وSolidJS على السواء:
- تعرف هل تطبيقك اليوم CSR أو SSR أو معروض مسبقاً (افحص View Source: هل المحتوى في HTML الخام أم لا توجد سوى عقدة تحميل فارغة؟).
- المحتوى الذي يجب أن يرتب أو يُستشهد به موجود في HTML المعروض على الخادم أو مسبقاً، لا يُحقن بعد تشغيل JavaScript فقط.
- تتم إدارة
<title>ووصف meta لكل مسار بحزمة head أو API مدمجة، وهما فريدان لكل صفحة في HTML المعروض. - روابط الموجه عناصر
<a href>حقيقية (توجيه History API، لا أجزاء#أوonclickعلى<div>). - JavaScript وCSS غير محجوبين في
robots.txt، لأن Google لن تعرض من ملفات محجوبة. - لا يوجد محتوى محجوب خلف تمرير أو نقرة أو تحويم.
- تعيد عروض «غير موجود» من جانب العميل حالة
404فعلية أو تحملnoindex، بلا قشرة soft 404. - لا يحقن JavaScript توجيه
noindexيناقض HTML الخام؛ إذ تأخذ Google الأكثر تقييداً. - أخذت Bing وزواحف الذكاء الاصطناعي في الحسبان، لا Google فقط؛ وSSR أو العرض المسبق هو الحل الموثوق الوحيد لها.
- تحققت عبر URL Inspection من HTML المعروض ولقطة الشاشة ووحدة التحكم، لا من متصفحك وحده.
تجمع هذه الفحوص عدة مخرجات متميزة في صفحة واحدة. تحقق من كل مرحلة منفردة، فقد ينجح المسار في واحدة ويفشل في التالية:
| المرحلة | ما الذي يجب فحصه |
|---|---|
| الاستجابة المباشرة (JavaScript معطل/محجوب) | اجلب URL مع تعطيل JavaScript. هل يوجد العنوان الفريد والنص، أم عقدة التحميل فقط؟ |
| الأجزاء المتدفقة (عند استخدام streaming) | هل يصل المحتوى تدريجياً، أم يؤخر جزء بطيء كل ما بعده؟ |
| DOM المعروض (JavaScript منفذ) | بعد تشغيل الحزمة، هل DOM النهائي مكتمل بالعناوين والروابط والبيانات المنظمة؟ |
| Hydration | هل يتولى العميل الصفحة بسلاسة، أم تظهر أخطاء وحدة التحكم أو عدم تطابق hydration؟ |
| تنقل العميل | هل يحدّث تغيير المسار داخل التطبيق URL والعنوان وcanonical كما يفعل التحميل المباشر؟ |
| رموز الحالة | هل يعيد مسار 404/410/5xx فعلي تلك الحالة مباشرة، لا رسالة يعرضها العميل داخل 200؟ |
| بيانات التعريف | هل <title> والوصف وcanonical وتوجيه robots المعروضة صحيحة لكل مسار، لا موجودة فقط؟ |
الأطر ← الحل، في لمحة
| الإطار | العرض الافتراضي | إدارة head | SSR / الإطار الفوقي | مسار العرض المسبق |
|---|---|---|---|---|
| React | CSR | react-helmet-async | Next.js | Next.js SSG / react-snap |
| Vue | CSR | @unhead/vue | Nuxt | Nuxt nuxi generate / إضافة عرض مسبق |
| Angular | CSR (SPA) | Title / Meta مدمجان | Angular SSR (Universal سابقاً) | عرض ng build المسبق |
| Svelte | CSR (Svelte) / SSR (SvelteKit) | <svelte:head> | SvelteKit | adapter-static (انتبه إلى ssr:false) |
| SolidJS | CSR | @solidjs/meta | SolidStart | عرض SolidStart المسبق |
الحل ذو الجزأين (احفظه)
- إدارة head ←
<title>ووسوم meta فريدة لكل مسار. - استراتيجية العرض ← العرض المسبق (SSG) أو SSR أو الإطار الفوقي الموافق. لا تملأ إدارة head وحدها القشرة الفارغة.
سلم المخاطر (من أدنى مخاطرة SEO إلى أعلاها)
| الأسلوب | مخاطرة SEO | متى |
|---|---|---|
| العرض المسبق / SSG | الأدنى | محتوى ثابت لكل طلب |
| SSR (إطار فوقي) | منخفضة | محتوى ديناميكي لكل طلب ويجب أن يرتب |
| Hydration (متماثل) | منخفضة | مزيج تطبيق ومحتوى |
| CSR كامل | الأعلى | واجهة تطبيق خلف تسجيل الدخول ولا تحتاج إلى الترتيب |
تحقق من واقع الزواحف
| الزاحف | هل يشغّل JavaScript؟ |
|---|---|
| Googlebot | نعم، لكن بصورة مؤجلة وفي طابور ومن دون حالة |
| Bingbot | بصورة غير متسقة |
| زواحف الذكاء الاصطناعي (LLM / بحث AI) | في معظمها لا |
المحتوى المعتمد على CSR وحده مجازفة في كل مكان عدا Google، وحتى هناك يتأخر. ويزيل SSR أو العرض المسبق المجازفة للجميع.
مشكلات SEO الشائعة في أطر العمل من جانب العميل
تعرض أدوات البحث صفحة فارغة أو قشرة التطبيق فقط
العَرَض: لا يحتوي HTML الخام إلا على عنصر تحميل مثل #root أو #app أو app-root، بينما تحتوي الصفحة المرئية على النص الحقيقي. السبب المرجح: المسار معروض بالكامل من جانب العميل. الإصلاح: اعرض المسارات الثابتة مسبقاً أو انقل المسار إلى الإطار الفوقي الداعم لـSSR. وأكد الإصلاح بجلب URL مع تعطيل JavaScript والعثور على عنوانه الفريد ونصه في الاستجابة.
لكل المسارات العنوان أو canonical نفسه
العَرَض: تعرض عدة عناوين URL مشاهد مختلفة لكنها تكشف العنوان أو الوصف أو canonical نفسه. السبب المرجح: قشرة HTML المشتركة تملك head ولا تحدّثه تغييرات المسار. الإصلاح: استخدم API الخاصة بإدارة head في الإطار واضبط metadata من بيانات المسار. وأكد أن DOM النهائي لكل مسار يحتوي canonical واحداً يشير إلى نفسه وعنوانه الخاص.
تعمل الروابط للمستخدمين لكن الزواحف لا تكتشف المسارات
العَرَض: يعمل التنقل في المتصفح، لكن المسارات المرتبطة تظل غير مكتشفة. السبب المرجح: حلت معالجات النقر على أزرار أو عناصر div محل الروابط القابلة للزحف. الإصلاح: اعرض روابط <a href="..."> حقيقية ودع الموجه يحسنها. وأكد ظهور الوجهة كسمة href في DOM المعروض من دون نقر.
تعرض وحدة التحكم أخطاء hydration أو محتوى غير متطابق
العَرَض: يبدو HTML المعروض على الخادم أو مسبقاً صحيحاً، لكن وحدة تحكم المتصفح تسجل تحذيرات hydration، أو يومض المحتوى ويتغير مباشرة بعد التحميل. السبب المرجح: تختلف مخرجات الخادم عن أول عرض للعميل، غالباً بسبب تنسيق التاريخ/اللغة أو معرفات عشوائية أو شفرة تعتمد على window أثناء العرض الأولي. الإصلاح: اجعل الخادم والعميل يعرضان نتيجة حتمية للمدخل نفسه، وانقل منطق المتصفح فقط ليعمل بعد hydration لا أثناءه. وأكد ذلك بتحميل المسار مع JavaScript والتحقق من انعدام أخطاء hydration في وحدة التحكم.
تتغير حالة المسار في المتصفح لكن عنوان URL المباشر لا يطابقها
العَرَض: ينتج التنقل بالنقر داخل التطبيق صفحة عاملة، لكن طلب URL نفسه مباشرة أو بعد التحديث يعيد نتيجة مختلفة، مثل قشرة عامة أو رمز حالة خاطئ أو metadata قديمة. السبب المرجح: يحدّث تنقل العميل المشهد داخل المتصفح من دون معالج مسار مماثل على الخادم، ولذلك لم تكن الحالة الناتجة عن الانتقال صفحة حقيقية قابلة للطلب المستقل. الإصلاح: تأكد من أن كل مسار يمكن للمستخدم بلوغه بالتنقل قابل أيضاً للطلب المباشر ويعيد المحتوى والحالة وmetadata نفسها. وأكد ذلك بتحميل URL من جديد، لا بالنقر للوصول إليه، مع تعطيل JavaScript أولاً ثم تفعيله.
اختبر نفسك: أطر العمل من جانب العميل
خمسة أسئلة سريعة عن مشكلة SEO المشتركة وحلها في React وVue وAngular وSvelte وSolidJS. اختر إجابة لكل سؤال ثم تحقق.
موارد تستحق وقتك
كتاباتي ذات الصلة
- دليل شامل إلى تحسين محركات البحث لـJavaScript — دليلي الكامل إلى العرض وتكافؤ DOM وقاعدة التوجيه الأكثر تقييداً واختيار إعداد العرض؛ وهو الأساس لكل إطار في هذا المحور.
- دليل المبتدئين إلى تحسين محركات البحث التقني — موضع العرض من جانب العميل وJavaScript SEO في الصورة الأوسع.
محاضراتي
- كيف يعمل البحث (SlideShare) — شرحي للزحف والعرض والفهرسة والترتيب. وينطبق تنبيهي الدائم: “This is my understanding of systems… not going to be 100% complete or accurate.” (ترجمة) «هذا فهمي للأنظمة… ولن يكون كاملاً أو دقيقاً بنسبة 100%».
من أنحاء المجال
- web.dev — العرض على الويب — شرح فريق Chrome المعتمد للفروق بين CSR وSSR وSSG وhydration، وهو أفضل نموذج ذهني مستقل عن الأطر لنصف الحل المتعلق باستراتيجية العرض.
- Google Search Central — أساسيات تحسين محركات البحث لـJavaScript — وثائق مصدر أولي رسمية عن عملية الزحف ← العرض ← الفهرسة والروابط القابلة للزحف.
- Google Search Central — إصلاح مشكلات JavaScript المرتبطة بالبحث — حالات الخطأ الزائف بعد التوجيه من جانب العميل وHistory API التي تصادف كل موجهات SPA.
- قائمة Martin Splitt لتشغيل فيديوهات JavaScript SEO — سلسلة فيديو Google الرسمية عن تعاملها مع تطبيقات JavaScript، مستقلة عن الأطر.
- محور Onely عن JavaScript SEO — مقالات تقنية معمقة عن العرض وتدقيق JS-SEO من وكالة متخصصة.
سجل التغييرات
تم التحديث في 11 أغسطس 2026.
ملخص تحريري وتفاصيل التغيير المسجلة.تفاصيل التغيير
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
المقارنة الكاملة غير متاحة — لم تُؤرشف لقطة سابقة لهذه المراجعة.
تم التحديث في 17 يوليو 2026.
ملخص تحريري وتفاصيل التغيير المسجلة.تفاصيل التغيير
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
المقارنة الكاملة غير متاحة — لم تُؤرشف لقطة سابقة لهذه المراجعة.