SEO لتطبيقات الصفحة الواحدة: لماذا لا تتصدر تطبيقات SPA النتائج، وكيف يعالج ذلك SSR والتوليد الثابت والعرض المسبق، وكيف تجعل تطبيقك مقروءًا لزواحف الذكاء الاصطناعي.

باختصار
يحمّل تطبيق الصفحة الواحدة (SPA) هيكل HTML واحدًا ويبني كل واجهة باستخدام JavaScript داخل المتصفح. يستطيع Google عرض JavaScript، لكن هذا العرض متأخر وهشّ، أما الزواحف التي تعمل لصالح ChatGPT وClaude وPerplexity فلا تنفّذه إطلاقًا. لكي تتصدر النتائج ويُستشهد بك، تحتاج كل واجهة في تطبيق SPA إلى عنوان URL خاص بها، ورابط حقيقي يحتوي على href، وعنوان ووصف فريدين، ورمز حالة صحيح، وقبل كل شيء أن يكون محتواها الرئيسي موجودًا في HTML الذي يرسله الخادم، عبر العرض من جهة الخادم أو التوليد الثابت أو العرض المسبق.
هل تريد التعمق أكثر؟ اسأل
SEO لتطبيقات الصفحة الواحدة هو مجموعة التقنيات التي تجعل تطبيق JavaScript المبني بـ React أو Vue أو Angular أو Svelte سهل الزحف مثل أي موقع تقليدي. المشكلة موثقة جيدًا: يشرح Google في أساسيات SEO لـ JavaScript أنه يعالج صفحات JavaScript على ثلاث مراحل (الزحف، والعرض، والفهرسة)، وكل نقطة ضعف في SPA تقع في مكان ما من هذه السلسلة. يركز هذا الدليل على تطبيقات SPA؛ أما مواقع JavaScript عمومًا، فاقرأ دليلنا حول SEO لـ JavaScript.
يعيد الموقع التقليدي مستند HTML كاملًا لكل عنوان URL. أما تطبيق SPA فيعيد المستند نفسه تقريبًا لكل عنوان: عنصر <div id="root"> فارغ، وبعض وسوم meta، وحزمة JavaScript كبيرة. يحمّل المتصفح الحزمة، ويستدعي واجهة API، ثم يرسم الصفحة. وعندما ينقر الزائر على رابط، يستبدل JavaScript المحتوى دون إعادة تحميل الصفحة.
بالنسبة إلى شخص يستخدم هاتفًا سريعًا، تبدو النتيجة فورية. أما بالنسبة إلى الزاحف، فالاستجابة الأولى هيكل فارغ: لا عنوان، ولا نص، ولا روابط. كل شيء يتوقف على ما إذا كان الروبوت ينفّذ JavaScript، ومتى. هذه الحقيقة وحدها تفسر معظم مشكلات SEO في تطبيقات SPA:
/#/pricing)، والجزء الذي يلي # لا يُرسل إلى الخادم أبدًا، فتندمج كل الواجهات في عنوان واحد.<title> واحدًا، وإذا لم يحدّثه الموجّه (router)، تتشاركه كل الصفحات.href: الأزرار ومعالجات onClick تنقل المستخدمين، لكنها لا تترك للزواحف أي شيء تتبعه.يجلب Googlebot أولًا HTML الخام ويقرأ الروابط والتوجيهات التي يجدها فيه. ثم توضع الصفحات التي تعيد الرمز 200 في قائمة انتظار خدمة Web Rendering Service، وهي متصفح Chromium بلا واجهة. يذكر Google أن الصفحة «قد تبقى في قائمة الانتظار هذه بضع ثوانٍ، لكن الأمر قد يستغرق أكثر من ذلك». بعد العرض، يُحلَّل HTML الناتج مرة أخرى بحثًا عن المحتوى والروابط، ثم يُفهرس.
أربعة تفاصيل من وثائق Google مهمة لتطبيقات SPA:
<a> التي تحتوي على href هي وحدها الروابط الموثوقة. الروابط التي يضيفها JavaScript مقبولة ما دامت تتبع هذا الشكل.pushState) بدلًا من مسارات #. وقد أوقف العمل بنظامه القديم للزحف إلى AJAX (عناوين #!) في أكتوبر 2015.noindex في HTML الأصلي هو الذي يُعتمد. قد يتخطى Google العرض عندما يرى noindex، لذا فإن إزالته لاحقًا بواسطة JavaScript لا تجدي.النتيجة العملية: يستطيع Google فهرسة تطبيق SPA معروض من جهة العميل، لكنك تضيف إلى كل صفحة خطوة ثانية وتأخيرًا ونقطة فشل. انتهاء المهلة، أو استدعاء API محظور، أو خطأ JavaScript أثناء العرض، كلها تترك النسخة المفهرسة فارغة. تحقق مما يراه Google باستخدام أداة فحص عنوان URL في Search Console، واقرأ دليلنا حول كيفية عمل الفهرسة في Google إذا بقيت صفحات خارج الفهرس.
في الغالب لا. في دراسة نُشرت في ديسمبر 2024 حول حركة المرور على شبكة Vercel، وجدت Vercel وMERJ أنه «لا يوجد حاليًا أي زاحف كبير من زواحف الذكاء الاصطناعي يعرض JavaScript»: فكل من GPTBot وOAI-SearchBot وChatGPT-User (OpenAI)، وClaudeBot (Anthropic)، وPerplexityBot، وMeta-ExternalAgent، وBytespider يقرأ HTML الخام فقط. هذه الزواحف تحمّل ملفات JavaScript (نحو 11.5% من طلبات ChatGPT و23.8% من طلبات Claude) لكنها لا تشغّلها. الاستثناءان هما Gemini، الذي يعتمد على بنية العرض لدى Google، وAppleBot، الذي يستخدم زاحفًا قائمًا على متصفح.
بالنسبة إلى تطبيق SPA معروض من جهة العميل، يعني ذلك أن زواحف الذكاء الاصطناعي التي تغذي ChatGPT وClaude وPerplexity ترى صفحة فارغة. قد يتصدر منتجك نتائج Google ويظل غير مرئي في إجابات الذكاء الاصطناعي، لأن المساعد لم يقرأ منه كلمة واحدة. وينطبق الأمر نفسه على معظم روبوتات معاينة الروابط في الشبكات الاجتماعية وتطبيقات المراسلة، التي تقرأ وسوم Open Graph في HTML الخام. بمجرد أن يصبح المحتوى في HTML، تحقق أيضًا من أن ملف robots.txt يسمح لزواحف الذكاء الاصطناعي التي تريدها.
الحل هو إرسال HTML حقيقي منذ الاستجابة الأولى. يصف Google العرض الديناميكي (تقديم نسخة معروضة مسبقًا للروبوتات فقط) بأنه «حل التفافي وليس حلًا موصى به» في وثائق العرض الديناميكي، ويوجّه بدلًا من ذلك إلى العرض من جهة الخادم أو العرض الثابت أو hydration. تستند التعريفات أدناه إلى المرجع Rendering on the Web على موقع web.dev.
| الاستراتيجية | طريقة العمل | المحتوى في HTML الأول | الأنسب لـ | الحدود |
|---|---|---|---|---|
| العرض من جهة العميل (CSR) | يبني المتصفح الصفحة انطلاقًا من JavaScript وواجهة API | لا | لوحات التحكم والصفحات التي تتطلب تسجيل الدخول | فهرسة متأخرة في Google، وغير مرئي لمعظم زواحف الذكاء الاصطناعي |
| العرض من جهة الخادم (SSR) | يعرض الخادم HTML عند كل طلب، ثم يفعّله JavaScript عبر hydration | نعم | الكتالوجات، وصفحات القوائم، والمحتوى الذي يتغير كثيرًا أو المخصص | تكلفة الخادم، وزمن استجابة أبطأ دون تخزين مؤقت |
| التوليد الثابت (SSG) | يُولَّد HTML وقت البناء لكل عنوان URL ويُقدَّم من شبكة CDN | نعم | صفحات التسويق، والمدونة، والتوثيق، وصفحات الهبوط | تلزم إعادة البناء عند تغير المحتوى (توجد خيارات تدريجية) |
| العرض المسبق وقت البناء | يلتقط متصفح بلا واجهة الحالة الأولية لكل مسار في صورة HTML ثابت | نعم | تطبيقات SPA القائمة ذات العدد المحدود من المسارات العامة | بيانات مجمدة وقت البناء، ويجب سرد المسارات |
| العرض الديناميكي | تتلقى الروبوتات لقطة معروضة مسبقًا، ويتلقى المستخدمون تطبيق SPA | نعم، للروبوتات المدرجة فقط | حل مؤقت لتطبيق قديم | حل التفافي رسميًا، وتكلفة صيانة، وخطر تقديم محتوى مختلف للروبوتات |
تتيح معظم أطر العمل الحديثة المزج بين الاستراتيجيات حسب المسار: ثابت لصفحات التسويق، ومعروض على الخادم للكتالوج، ومعروض لدى العميل للتطبيق بعد تسجيل الدخول. يمنح هذا الإعداد الهجين الزواحف HTML كاملًا حيث تأتي زيارات البحث، ويحافظ على تجربة SPA حيث تضيف قيمة.
| المكتبة | إطار العمل أو الميزة لتقديم HTML عند التحميل الأول |
|---|---|
| React | Next.js (مكونات الخادم، وSSR، والتوليد الثابت)، وReact Router في وضع framework، وGatsby |
| Vue | Nuxt (العرض الشامل افتراضيًا، مع توفر التوليد الثابت) |
| Angular | Angular SSR (العرض على الخادم والعرض المسبق وقت البناء) |
| Svelte | SvelteKit (العرض على الخادم افتراضيًا، والعرض المسبق لكل مسار) |
| أيٌّ منها | Astro (HTML ثابت افتراضيًا، وجزر تفاعلية لا تُحمَّل إلا حيث تلزم) |
تستحق المواقع التي تولّدها أدوات بناء المواقع بالذكاء الاصطناعي إشارة خاصة: كثير منها يصدّر تطبيق React معروضًا من جهة العميل. إذا بنيت موقعك بإحداها، فاطلع على ملاحظاتنا حول SEO وGEO في Lovable قبل أن تفترض أن Google وChatGPT قادران على قراءته.
استخدم History API (/pricing، وليس /#/pricing أبدًا)، وعنوان URL واحدًا لكل محتوى، والعنوان نفسه سواء وصل الزائر مباشرة أو عبر التنقل داخل التطبيق. يجب أن يحمّل كل عنوان المحتوى الصحيح عند فتحه في علامة تبويب جديدة، وهذا هو الاختبار الذي يجريه الزاحف.
كل عنصر تنقل يؤدي إلى صفحة قابلة للفهرسة يجب أن يكون <a href="/path">. مكونات الروابط في أطر العمل (Link وNuxtLink وrouterLink) تُنتج هذا الترميز؛ أما معالجات النقر المخصصة على عناصر div أو button فلا. والروابط الجيدة تحمل أيضًا بنية موقعك: إذا لم يكن هناك رابط إلى صفحة ما، فنادرًا ما تجدها الزواحف.
يحتاج كل مسار إلى عنوان ووصف meta ووسم canonical ووسوم Open Graph خاصة به، تُولَّد على الخادم كلما أمكن. تسرد صفحتنا حول وسوم meta ما يجب ضبطه. احتفظ بـوسم canonical واحد فقط: يوصي Google بضبطه في HTML، وإذا غيّره JavaScript، فيجب ألا تتعارض النتيجة مع الأصل.
يجب ألا تجيب المنتجات غير الموجودة والمقالات المحذوفة بالرمز 200 مع رسالة خطأ. مع SSR، أعد رمز 404 أو 410 حقيقيًا من الخادم. وفي تطبيق SPA خالص، يقبل Google بديلين: إعادة التوجيه بواسطة JavaScript إلى عنوان URL يعيد 404، أو إضافة وسم meta robots يحتوي على noindex إلى واجهة الخطأ.
يجب أن تكون العناوين، ونص الصفحة، والأسعار، والأسئلة الشائعة، والبيانات المنظمة بصيغة JSON-LD ضمن استجابة الخادم، لا أن تُحمَّل بعد نقرة أو تمرير. المحتوى المخفي خلف علامات تبويب تُعرض عند الطلب، أو خلف أزرار «تحميل المزيد»، غالبًا ما يفوت الزواحف.
قسّم الحزمة حسب المسار، وأجّل ما لا يلزم للعرض الأول، وتجنب إعادة عرض الصفحة بأكملها أثناء hydration. لاحظ أن بيانات الاستخدام الفعلي في Chrome (CrUX) تنسب مقاييس التنقلات داخل التطبيق إلى عنوان URL الذي حمّله الزائر أولًا، لذا اختبر قوالبك الرئيسية كلًّا على حدة.
قارن ثلاث نسخ من كل قالب رئيسي: HTML الخام (اعرض المصدر أو اجلب الصفحة بأداة سطر أوامر)، وHTML المعروض لدى Google (فحص عنوان URL، ثم «عرض الصفحة التي تم الزحف إليها»)، والصفحة مع تعطيل JavaScript. إذا لم يظهر النص الرئيسي إلا في النسخة الثانية، فإن زواحف الذكاء الاصطناعي لا تراه. تُجري أداة تدقيق قابلية الزحف للذكاء الاصطناعي المجانية لدينا وأداة فحص قابلية الفهرسة هذه الاختبارات على أي عنوان URL.
| العَرَض | السبب المحتمل | الإصلاح |
|---|---|---|
| يعرض Search Console صفحات كثيرة بحالة «تم الزحف إليها - غير مفهرسة حاليًا» | HTML فارغ أو شبه متطابق قبل العرض | SSR أو SSG أو العرض المسبق للمسارات العامة |
كل نتيجة في بحث site: تعرض العنوان نفسه | العنوان لا يُحدَّث حسب المسار | إدارة وسوم head على مستوى المسار في الخادم |
| الصفحة الرئيسية وحدها مفهرسة | التوجيه بعلامة hash أو روابط بلا href | History API وروابط <a> حقيقية |
| صفحات الخطأ تظهر في الفهرس | أخطاء soft 404 (الرمز 200 في كل مكان) | 404 من الخادم، أو إعادة توجيه بـ JavaScript إلى عنوان URL يعيد 404، أو noindex |
| يتصدر في Google لكن ChatGPT أو Perplexity لا يستشهدان به أبدًا | المحتوى لا يظهر إلا بعد تنفيذ JavaScript | المحتوى في أول استجابة HTML |
| يظهر محتوى قديم في النسخة المعروضة لدى Google | ملفات JavaScript أو CSS مخزنة مؤقتًا | أسماء ملفات ذات بصمة |
لسنوات، كان العرض من جهة العميل مخاطرة يمكن التحكم فيها لأن Google كان يعرض JavaScript في النهاية. ومع انتقال جزء من الاكتشاف اليوم إلى ChatGPT وClaude وGemini وPerplexity، تغيّرت الكلفة: الصفحة التي لا توجد إلا بعد تنفيذ JavaScript تغيب عن المصادر التي تستطيع معظم المساعدات قراءتها. أصبحت قابلية الزحف في HTML الخام الشرط الأول لتحسين الظهور في المحركات التوليدية.
بمجرد أن يكتمل HTML، يتبع الباقي القواعد المعتادة: الصفحات التي تجيب بوضوح عن سؤال واحد، مع حقائق موثقة المصادر وبيانات منظمة، هي التي تستشهد بها المساعدات. تساعدك ميزات تحسين GEO في Sorank على كتابة هذا المحتوى ونشره، ويُظهر تتبع الإشارات في الذكاء الاصطناعي ما إذا كان ChatGPT وClaude وGemini يستشهدون بعلامتك التجارية بعد إصلاح العرض.
القاعدة الأساسية لـ SEO تطبيقات الصفحة الواحدة تختصرها جملة واحدة: كل ما تريد أن يرتّبه Google ويستشهد به الذكاء الاصطناعي يجب أن يكون في HTML الذي يرسله الخادم. احتفظ بتطبيق SPA لتجربة ما بعد تسجيل الدخول، واعرض الصفحات العامة على الخادم أو وقت البناء، ثم اختبر ما تتلقاه الروبوتات قبل كل إصدار وبعده.
لا يعاقب Google تطبيقات الصفحة الواحدة، لكن إعدادها الافتراضي، أي العرض من جهة العميل مع هيكل HTML واحد، يجعل الفهرسة أبطأ وأقل موثوقية. معظم زواحف الذكاء الاصطناعي لا تنفّذ JavaScript، لذا ترى صفحة فارغة. ومع العرض من جهة الخادم أو التوليد الثابت أو العرض المسبق على المسارات العامة، يمكن لتطبيق SPA أن يتصدر النتائج مثل أي موقع تقليدي.
React في حد ذاته محايد: المهم هو المكان الذي يُنتَج فيه HTML. تطبيق React الذي يُعرض في المتصفح فقط يعاني المشكلات المعتادة لتطبيقات SPA، بينما المكونات نفسها عند عرضها على الخادم باستخدام Next.js أو React Router في وضع framework تقدّم HTML كاملًا للزواحف. اختر إطار عمل يدعم العرض على الخادم أو العرض الثابت للصفحات التي تريد فهرستها.
فقط كإجراء مؤقت. يصف Google العرض الديناميكي بأنه حل التفافي وليس حلًا موصى به، لأن الحفاظ على نسخة منفصلة للروبوتات يضيف تكلفة ومخاطر. العرض من جهة الخادم أو التوليد الثابت أو العرض المسبق وقت البناء تقدّم HTML نفسه لكل زائر، وهي الحلول الدائمة.
لقد جربوا SORANK قبلك
