SEO التقني لمواقع SaaS

الخلاصة — تحسين محركات البحث التقني لمواقع SaaS هو SEO تقني اعتيادي — زحف وعرض وفهرسة — مطبّق على إعدادات تقنية تتكرر في مواقع شركات البرمجيات. لا توجد «خوارزمية SaaS» خاصة؛ المختلف هو شكل الموقع: موقع تسويقي مبني كتطبيق، ووثائق مساعدة على عنوان منفصل، ومنتج مجاني أو تجريبي يولّد عناوين URL بلا نهاية، وصفحات تسعير لبلدان متعددة تحتاج معالجة دقيقة.

Evidence for this claim Google processes JavaScript pages through crawling, rendering, and indexing, and not every bot supports JavaScript equivalently. Scope: Google JavaScript processing; server rendering can improve portability and reliability. Confidence: high · Verified: 2026-07-14 Google Search Central: JavaScript SEO basics Evidence for this claim Google warns that faceted navigation and other effectively infinite URL spaces can waste crawling resources. Scope: Large or rapidly expanding URL spaces, including parameterized application URLs. Confidence: high · Verified: 2026-07-14 Google Search Central: Managing crawling of faceted navigation URLs

لماذا تحتاج مواقع SaaS إلى قائمة فحص تقنية خاصة بها؟

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

1. الموقع التسويقي مبني كتطبيق

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

2. الوثائق موجودة في مكان آخر

غالبًا ما توجد وثائق المساعدة على عنوان مستقل مثل docs.example.com بدل example.com/docs/. لا يعاقب Google أيًا من الخيارين، فالقرار يعود إليك فعلًا. لكن العنوان المنفصل يُعامل بوصفه «موقعًا» مستقلًا، ولذلك هو مقايضة لا فائدة مجانية.

3. المنتج المجاني أو التجريبي ينشئ عددًا هائلًا من عناوين URL

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

4. اختلاف البلدان يحتاج عناية

إذا عرضت أسعارًا مختلفة في بلدان مختلفة، فالوسوم التي تخبر Google بأن هذه «نسخة المملكة المتحدة» — أي hreflang — تعالج اللغة والمنطقة، لكنها لا تعالج العملة. وهذا خلط شائع ينبغي إدراكه.

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

الخلاصة — لا توجد خوارزمية SaaS؛ بل خط الزحف ← العرض ← الفهرسة ← الترتيب نفسه، والمميز هو البنية التقنية. قد تُجمع مواقع التسويق ذات غلاف التطبيق كصفحات مكررة ويُختار لها عنوان أساسي خاطئ، لذا تحتاج صفحات التسويق والتسعير والوثائق والمدونة إلى SSR/SSG، بينما يمكن أن تبقى واجهة المنتج بعد تسجيل الدخول معروضة لدى العميل. والنطاق الفرعي للوثائق مقابل المجلد الفرعي مقايضة حقيقية في الزحف والسلطة لا عقوبة. كما تنشئ تطبيقات freemium نسخة SaaS من التنقل متعدد الأوجه ومساحات العناوين اللانهائية، والحل معماري — بوابة مصادقة أو robots.txt — لأن noindex لا يوفر ميزانية الزحف. والخطأ الكلاسيكي هو الحجب في robots.txt مع إضافة noindex، فلا تراه Google؛ كما أن حقنه عبر JavaScript هش أكثر. ويستهدف hreflang اللغة والمنطقة لا العملة.

Evidence for this claim Google processes JavaScript pages through crawling, rendering, and indexing, and not every bot supports JavaScript equivalently. Scope: Google JavaScript processing; server rendering can improve portability and reliability. Confidence: high · Verified: 2026-07-14 Google Search Central: JavaScript SEO basics Evidence for this claim Google warns that faceted navigation and other effectively infinite URL spaces can waste crawling resources. Scope: Large or rapidly expanding URL spaces, including parameterized application URLs. Confidence: high · Verified: 2026-07-14 Google Search Central: Managing crawling of faceted navigation URLs

ابدأ من البنية التقنية، لا من الخوارزمية

كل ما يخص SaaS في SEO التقني يأتي من شكل الموقع لا من نظام الترتيب. يمرر Google وBing موقع SaaS في خط الزحف ← العرض ← الفهرسة ← الترتيب نفسه، لكن ذلك الخط يواجه موقعًا تسويقيًا ذا غلاف تطبيق، ووثائق على نطاق فرعي، وانفجار عناوين freemium، وتسعيرًا متعدد المناطق. إذن هذا ليس تخصصًا مختلفًا، بل SEO تقني عادي مطبّق على مجموعة محددة ومتكررة من الحقائق البنيوية.

تسرد قائمة فحص SEO لمواقع SaaS الشقيقة ما ينبغي فحصه عبر أنواع الصفحات. أما هذا الشرح فيتناول لماذا يحدث وكيف يعمل: لماذا تخطئ أغلفة التطبيقات في كشف التكرار، ولماذا تتصرف ميزانية الزحف بصورة مختلفة مع freemium، ولماذا يجمع noindex مع robots.txt نتيجة عكسية، ولماذا يمثل نطاق الوثائق الفرعي مقابل المجلد الفرعي مقايضة، ولماذا لا يمس hreflang العملة. وعندما تكون الآليات العامة في مقالاتها — SEO لـJavaScript، وميزانية الزحف، والنطاق الفرعي مقابل المجلد الفرعي، وhreflang، وتحديد العنوان الأساسي — سأشير إليها وأركز هنا على تطبيق SaaS.

إخلاء المسؤولية المعتاد: هذا فهمي لكيفية عمل هذه الأنظمة وطريقتي في تناول المشكلة، لا ضمانًا؛ فمحركات البحث تتغير باستمرار، لذا تحقّق من الوثائق الأصلية المرتبطة في تبويبي الوثائق الرسمية والاقتباسات.

مشكلة غلاف التطبيق: عندما يكون موقعك التسويقي تطبيق صفحة واحدة

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

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

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

ما الذي يحتاج عرضًا من جهة الخادم، وما الذي يمكن أن يبقى لدى العميل؟

يعتمد القرار على أهمية SEO لا على الشكل. أي صفحة غرضها أن يجدها ويقرأها شخص غير مسجل الدخول — التسويق والتسعير والمقارنة والوثائق والمدونة — يجب ألا تعتمد على JavaScript لدى العميل لكي توجد في DOM. ينبغي أن يظهر محتواها في استجابة الخادم عبر SSR أو التوليد الثابت أو hydration؛ فهذه الأساليب مناسبة لمحركات البحث. أما العرض الكامل لدى العميل فهو الطرف الخطر.

واجهة المنتج الفعلية داخل التطبيق — لوحة المعلومات التي يصل إليها المستخدم بعد المصادقة — هي الحالة المعاكسة. لن تزحف Google خلف تسجيل الدخول، لذا لا توجد أهمية SEO لطريقة عرضها ويمكن أن تكون CSR كاملة. تظهر المشكلة فقط حين تتسرب أنماط CSR الشبيهة بالتطبيق إلى واجهة التسويق العامة قبل تسجيل الدخول. ارسم الحد عند جدار الدخول: الجانب العام يعرضه الخادم، والجانب الخاص يختار فريق المنتج ما يناسبه.

هناك حجة إضافية لـSSR ازدادت قوة: معظم موجة زواحف الذكاء الاصطناعي لا تنفذ JavaScript. إذا لم يوجد المحتوى العام إلا بعد العرض لدى العميل، فلن تراه الزواحف الأضعف ولا هذه المجموعة كلها، وهذا سبب آخر لعرض المحتوى العام السابق للدخول على الخادم.

اختلاف Google وBing بشأن العرض الديناميكي

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

موقفي الشخصي معاكس، وأصفه بوضوح كرأي. كتبت في دليل JavaScript أن العرض الديناميكي حل التفافي لم أوصِ به، لأنه يعقّد الإعداد واستكشاف الأخطاء، وهو عمليًا إخفاء. موقف Bing الرسمي يجيزه، ووثائق Google تتعامل معه كحل قديم لا كخيار أول، أما أنا فأتجنبه. إن استطعت تنفيذ SSR/SSG حقيقي فافعله. وقدّم المسألة للفريق كخلاف قائم لا كأفضل ممارسة محسومة.

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

الوثائق: نطاق فرعي أم مجلد فرعي، ولماذا هي مقايضة حقيقية؟

تواجه كل شركة SaaS تقريبًا هذا القرار: هل توجد الوثائق في example.com/docs/ أم docs.example.com؟ كثيرًا ما تفرض أدوات مثل Mintlify وReadMe وGitBook والوثائق القائمة على Notion نطاقًا فرعيًا أو نطاق طرف ثالث، لذا يلزم فهم الآلية سواء ملكت الخيار أم لا.

ابدأ بإسقاط الخرافة: لا توجد عقوبة ترتيب للنطاق الفرعي. قال John Mueller في تغطية Search Engine Journal إن Google ترى الخيارين بالطريقة نفسها عمومًا، وإنه يفضّل شخصيًا إبقاء الأشياء مجتمعة قدر الإمكان. وفي الحالة التي لا يهم فيها الاختيار قال: “if you’re like ‘well I don’t care either way’ then I would just keep it within the same site.” (الترجمة العربية): «إذا لم تكن تهتم بأي الخيارين، فسأبقيه ببساطة داخل الموقع نفسه.» وترد بقية النصوص الحرفية في تبويب الاقتباسات.

لكن «لا عقوبة» لا تعني «لا فرق». تؤكد وثائق أسماء المواقع أن Google تعامل النطاق الفرعي بوصفه «موقعًا» مستقلًا؛ فأسماء المواقع غير مدعومة على مستوى المجلد الفرعي. وهذه حقيقة تقنية رسمية لها نتائج ملموسة:

• ميزانية الزحف لكل اسم مضيف. يحصل نطاق الوثائق الفرعي على حصة منفصلة. قد يكون ذلك ميزة لأن بطء الوثائق لا يحرم الموقع التسويقي، وكلفة لأن السلطة وإشارات الروابط الداخلية لا تعبر الحد تلقائيًا.
• يتعامل Search Console معه كخاصية مستقلة. يجب التحقق من docs.example.com ومراقبته وحده، ومن السهل نسيان ذلك.
• الوثائق ذات الإصدارات تضاعف التكرار. قد تنشئ أشجار v1/v2/legacy هدرًا ضخمًا؛ اجعل النسخ القديمة غير المتغيرة تشير أساسيًا إلى الحالية أو ميّزها بوضوح.

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

ميزانية الزحف ومشكلة عناوين freemium

لماذا قد يواجه موقع SaaS مشكلة ميزانية زحف وهو ليس متجرًا بملايين المنتجات؟ لأن المنتجات المجانية والتجريبية تولد امتداد عناوين مماثلًا بآلية مختلفة. يمكن لكل حالة لوحة معلومات وكل ملف مستخدم وكل صفحة تقرير قابلة للمشاركة وكل خطوة تجربة أن تنشئ عنوان URL فريدًا وقابلًا للزحف تقنيًا.

بالنسبة إلى Googlebot لا يختلف ذلك عن فئات العناوين منخفضة القيمة التي يسميها Google منذ سنوات: التنقل متعدد الأوجه ومعرّفات الجلسات ومساحات العناوين اللانهائية. يشرح دليل ميزانية زحف المواقع الكبيرة ومنشور Gary Illyes الأصلي هذه الفئات، وتطابقها حالات SaaS مباشرة: ملفات المستخدم وحالات اللوحة هي التنقل متعدد الأوجه، وخطوات التجربة وصفحات مشاركة التقارير هي مساحات العناوين اللانهائية.

يصوغ Bing الفكرة بصرامة أكبر. يقول Fabrice Canel في Search Engine Land إن القليل أفضل لـSEO وإن تقليل عناوين URL المطلوب زحفها أفضل؛ ويرد النص الحرفي في تبويب الاقتباسات. كما شرح Illyes أن Google ترتب عناوين الموقع حسب الأهمية وتعمل داخل الحصة التي يتحملها الخادم (تغطية Search Engine Roundtable)، لذا تنافس العناوين الرديئة صفحات التسويق والوثائق على قدرة جلب محدودة.

هذه بنية معمارية، لا تنظيف

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

صحّح الخرافة المغرية: noindex لا يوفر ميزانية الزحف. ما يزال على Google طلب الصفحة لقراءة الوسم، لذا تظل الصفحة مزحوفة. إذا كان الهدف وقف الجلب في قسم كامل فاستخدم حظر robots.txt أو المصادقة. وإصلاح الهدر يحسن الكفاءة لا الترتيب بذاته؛ فزيادة معدل الزحف لا ترفع المواقع تلقائيًا، كما ذكر Google في منشور ميزانية الزحف. الهدف أن يصل الزحف إلى صفحات التسويق والتسعير والوثائق بدل تبديلات اللوحات؛ وكما شرحت في دليل ميزانية الزحف، لا يعني المزيد من الزحف ترتيبًا أفضل، لكن الصفحة التي لا تُزحف ولا تُفهرس لا تستطيع الترتيب.

noindex مقابل robots.txt: تعارض SaaS الكلاسيكي

هذا أكثر الأخطاء التقنية الواقعية شيوعًا. يريد الفريق إبقاء /app/ أو /dashboard/ أو /trial/ خارج Google، فيطبق الاثنين: يحجب المساحة في robots.txt ويضيف noindex إلى القوالب ظنًا أن الجمع أكثر أمانًا.

النتيجة عكسية. يحتاج noindex إلى أن تكون الصفحة قابلة للزحف لكي تراه Google، بينما يمنع حظر robots.txt ذلك الجلب. في العنوان المحجوب والموسوم معًا لا تزحف Google، ولا ترى noindex، وقد يبقى العنوان ظاهرًا بلا مقتطف إذا ارتبط به موقع خارجي. لقد صنعت التسرب الذي أردت منعه، ولا تستطيع إصلاحه بـnoindex لأن الحظر يمنع الزحف اللازم لقراءته.

تذكر وثائق noindex الآلية والشرط مباشرة: إذا زحف Googlebot ورأى الوسم يحذف الصفحة من نتائج Google بصرف النظر عن الروابط إليها، لكن فعالية القاعدة تتطلب ألا يحجب ملف robots.txt الصفحة وأن تكون متاحة للزاحف. استخدم أداة واحدة لكل هدف: noindex لإبقاء صفحة قابلة للزحف خارج الفهرس، وrobots.txt لوقف زحف مساحة كاملة. لا تجمعهما على العنوان نفسه.

حقن noindex عبر JavaScript أكثر هشاشة في غلاف التطبيق

هناك التفاف يخص SaaS. إذا كانت JavaScript لدى العميل هي التي تضيف وسم noindex ولم يكن في استجابة الخادم الأولية، فإن ظهوره يعتمد على نجاح Google في عرض الصفحة. وهذه أقل طبقات بنية غلاف التطبيق موثوقية. وقد أبلغ Search Engine Roundtable عن خلل لدى Google لم يُحترم فيه دائمًا noindex المحقون عبر JavaScript في تطبيق شبيه بـReact، ففُهرست صفحات رغم ذلك.

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

SaaS متعدد المناطق: canonical وhreflang ليسا حلًا للتسعير

النمط الأخير يخص المنتجات التي تبيع في بلدان متعددة. الخلط المتكرر هو اعتبار hreflang حلًا للعملة، وليس كذلك. عقد hreflang كله استهداف اللغة والمنطقة: إخبار Google بأي عنوان URL يستبدله في SERP لباحث في لغة أو منطقة معينة. ولا يقول شيئًا عن السعر المعروض.

إذن لا يحل hreflang وحده صفحات تسعير الولايات المتحدة والمملكة المتحدة وأستراليا المكتوبة كلها بالإنجليزية وتعرض عملات مختلفة. فهذه مشكلتان منفصلتان:

• سؤال استهداف المنطقة — أي الصفحات الإنجليزية الثلاث تظهر لباحث بريطاني — وظيفة hreflang وcanonical. استخدم عناوين لكل منطقة بعناوين أساسية ذاتية وإشارات hreflang متبادلة.
• سؤال عرض العملة — أي سعر يظهر — يحتاج آلية مستقلة: صفحات مناطق في URL أو geo-IP أو إعداد حساب أو منتقي منطقة. لن يغيّره hreflang.

حتى بعد ضبط استهداف المنطقة، قد تجمع Google الصفحات ذات اللغة الواحدة إذا كانت شبه متطابقة عدا العملة، لأن المحتوى ليس مختلفًا بما يكفي. تتناول إرشادات تعدد المناطق الحالة صراحة، مثل تشابه محتوى example.de/ وexample.com/de/: اختر نسخة مفضلة للمحتوى المتشابه أو المكرر على عناوين مختلفة باللغة نفسها، واستخدم rel="canonical" وhreflang لتقديم عنوان اللغة أو المنطقة الصحيح. فإذا لم تختلف صفحات التسعير إلا في الرقم فميّزها معنويًا أو تقبّل جمعها، وعالج العملة كمسألة عرض. ويعتمد Bing وسم content-language أكثر من hreflang، فتختلف معالجته الدولية.

الخيط التقني الجامع

تعكس كل هذه الحالات تعارضًا واحدًا: عادات هندسة منتجات SaaS — بناء كل شيء كتطبيق صفحة واحدة، وإنشاء URL لكل شيء، والإطلاق السريع ثم إضافة التدويل — تصطدم بحاجة محركات البحث إلى عناوين ثابتة وقابلة للزحف وغير مكررة ومحددة النطاق. غلاف التطبيق هو SPA في مواجهة إزالة التكرار، وانفجار freemium هو إنشاء عنوان لكل شيء في مواجهة ميزانية الزحف، وفوضى المناطق هي التدويل المتأخر في مواجهة hreflang وcanonical.

وفي كل حالة يكون الحل الدائم واحدًا: قرار معماري مبكر — عرض الواجهة العامة على الخادم، وإبعاد التطبيق عن المجال القابل للزحف، وتحديد نطاق العناوين الدولية عمدًا — بدل المعالجة بعد وجود العناوين. هذا هو SEO التقني لمواقع SaaS: ليس كتاب قواعد آخر، بل تطبيق الكتاب العادي ببصيرة على شكل موقع محدد.

ملخص الذكاء الاصطناعي

خلاصة مركزة للنسخة المتقدمة:

• لا توجد خوارزمية SaaS. خط الزحف ← العرض ← الفهرسة ← الترتيب نفسه؛ المختلف شكل البنية التقنية.
• أغلفة التطبيقات خطر تكرار لا مجرد اختفاء. قد تجمع Google المسارات ذات HTML شبه المتطابق ويعرض canonical خاطئًا.
• يفصل جدار الدخول بين SSR وCSR. تحتاج الصفحات العامة إلى SSR/SSG/hydration، ويمكن أن تبقى واجهة المنتج الخاصة CSR؛ وعدم تنفيذ زواحف الذكاء الاصطناعي لـJavaScript حجة إضافية.
• العرض الديناميكي موضع خلاف. يجيزه Bing، بينما يعده Patrick وميول Google حلًا التفافيًا؛ فالأفضل SSR/SSG الحقيقي.
• النطاق الفرعي للوثائق مقابل المجلد مقايضة لا عقوبة. النطاق الفرعي «موقع» مستقل بميزانية زحف منفصلة وخاصية مستقلة في Search Console، ولا تنتقل إليه السلطة تلقائيًا.
• ينشئ freemium تنقلًا متعدد الأوجه ومساحات عناوين لا نهائية. الحل مصادقة أو robots.txt مبكرًا، لا noindex لكل صفحة؛ فهو لا يوفر الزحف.
• الخطأ الكلاسيكي: الحجب في robots.txt مع noindex، فيختفي الوسم عن Google. ضعه في HTML الخادم أو ترويسة HTTP لا عبر JavaScript.
• يستهدف hreflang اللغة والمنطقة لا العملة. تحتاج العملة آلية مستقلة، وقد تُجمع الصفحات الإقليمية شبه المتطابقة.

الوثائق الرسمية

هذه هي المصادر الأولية وراء الأنماط التقنية الخاصة بـSaaS، وهي تحكم موقع SaaS كما تحكم أي موقع آخر.

Google — JavaScript والعرض

• فهم أساسيات SEO لـJavaScript — مراحل الزحف والعرض والفهرسة، وتأخر طابور العرض، وروابط <a href> الحقيقية، وتوجيه History API، وحجة العرض من الخادم.
• إصلاح مشكلات JavaScript المتعلقة بالبحث — إرشاد History API ومعالجة soft 404 في التطبيقات الموجهة لدى العميل.
• العرض على الويب (web.dev) — إطار فريق Chrome/Google لمقايضات CSR/SSR/SSG/hydration.

Google — ميزانية الزحف والعناوين منخفضة القيمة

• تحسين ميزانية الزحف — سعة الزحف × طلب الزحف، و«المخزون المتصور»، ولماذا يوفر حجب المساحات منخفضة القيمة في robots.txt الميزانية، لا noindex.
• ما تعنيه ميزانية الزحف لـGooglebot (Gary Illyes، 2017) — القائمة الأصلية لفئات العناوين منخفضة القيمة التي يطابقها امتداد freemium.

Google — noindex وrobots.txt

• حظر الفهرسة باستخدام noindex — آلية noindex وشرط robots.txt الذي يربك إعداد صفحات تطبيقات SaaS.
• مقدمة robots.txt — قرار حظر الزحف كليًا مقابل السماح بالزحف مع noindex.

Google — النطاقات الفرعية وتعدد المناطق

• أسماء المواقع في بحث Google — تأكيد أن النطاق الفرعي «موقع» مستقل، بخلاف المجلد الفرعي.
• إدارة المواقع متعددة المناطق واللغات — حالة التكرار الإقليمي باللغة نفسها، مثل example.de/ وexample.com/de/.
• إبلاغ Google بالنسخ المترجمة من الصفحة (hreflang) — آلية hreflang الأساسية للغة والمنطقة لا العملة.
• ما تحديد عنوان URL الأساسي؟ — «إشارة لا قاعدة»، وخصوصًا مع معاملي ?region= أو ?currency=.

Bing / Microsoft

• سلسلة bingbot: JavaScript والعرض الديناميكي والإخفاء — موقف Bing من عرض JavaScript وتأييده العرض الديناميكي بوصفه غير إخفاء، حيث يختلف عن رأيي.
• سلسلة bingbot: تعظيم كفاءة الزحف — إطار Bing لكفاءة الزحف المطبق مباشرة على امتداد عناوين freemium.

اقتباسات من المصادر

تصريحات مسجلة من Google وBing وممثلي Google، إضافة إلى كتابتي الأصلية. يربط كل مصدر لمحرك بحث بالمقطع المقتبس مباشرة.

Google — noindex وشرطه المتعلق بـrobots.txt

• “Google will drop that page entirely from Google Search results, regardless of whether other sites link to it.” (الترجمة العربية): «ستحذف Google تلك الصفحة بالكامل من نتائج بحث Google بصرف النظر عن ارتباط مواقع أخرى بها.» انتقل إلى الاقتباس
• “For the noindex rule to be effective, the page or resource must not be blocked by a robots.txt file, and it has to be otherwise accessible to the crawler.” (الترجمة العربية): «لكي تكون قاعدة noindex فعالة، يجب ألا يحجب ملف robots.txt الصفحة أو المورد، ويجب أن يكون متاحًا للزاحف بغير ذلك.» انتقل إلى الاقتباس

Google — النطاقات الفرعية بوصفها «مواقع» مستقلة

• “Google Search does not support site names at the subdirectory level.” (الترجمة العربية): «لا يدعم بحث Google أسماء المواقع على مستوى المجلد الفرعي.» (وهذا يؤكد أن النطاق الفرعي يُعامل بوصفه «موقعًا» مستقلًا.) انتقل إلى الاقتباس

Google — التكرار متعدد المناطق

• “If you provide similar or duplicate content on different URLs in the same language as part of a multi-regional site (for instance, if both example.de/ and example.com/de/ show similar German language content), pick a preferred version and use the rel="canonical" element and hreflang tags to make sure that the correct language or regional URL is served to searchers.” (الترجمة العربية): «إذا قدمت محتوى متشابهًا أو مكررًا على عناوين URL مختلفة باللغة نفسها ضمن موقع متعدد المناطق، فاختر نسخة مفضلة واستخدم عنصر rel=canonical ووسوم hreflang لضمان تقديم عنوان اللغة أو المنطقة الصحيح للباحثين.» انتقل إلى الاقتباس

John Mueller من Google — النطاق الفرعي مقابل المجلد الفرعي (عبر Search Engine Journal)

• “In general, we see these the same.” (الترجمة العربية): «عمومًا، نرى الاثنين بالطريقة نفسها.» اقرأ التغطية
• “I would personally try to keep things together as much as possible.” (الترجمة العربية): «سأحاول شخصيًا إبقاء الأشياء مجتمعة قدر الإمكان.»
• “if you’re like ‘well I don’t care either way’ then I would just keep it within the same site.” (الترجمة العربية): «إذا لم تكن تهتم بأي الخيارين، فسأبقيه ببساطة داخل الموقع نفسه.»

Fabrice Canel من Microsoft Bing (عبر Search Engine Land)

• “Less is more for SEO. Never forget that. Less URLs to crawl, better for SEO.” (الترجمة العربية): «الأقل أفضل لـSEO. لا تنس ذلك أبدًا. كلما قلت عناوين URL المطلوب زحفها كان ذلك أفضل لـSEO.» انتقل إلى الاقتباس

Bing — JavaScript والعرض الديناميكي

• “bingbot is generally able to render JavaScript.” (الترجمة العربية): «يستطيع bingbot عمومًا عرض JavaScript.» انتقل إلى الاقتباس
• “As long as you make a good faith effort to return the same content to all visitors, with the only difference being the content is rendered on the server for bots and on the client for real users, this is acceptable and not considered cloaking.” (الترجمة العربية): «ما دمت تبذل جهدًا حسن النية لإرجاع المحتوى نفسه لجميع الزوار، مع اقتصار الفرق على عرضه في الخادم للروبوتات وفي العميل للمستخدمين الحقيقيين، فهذا مقبول ولا يعد إخفاءً.» انتقل إلى الاقتباس

أنا — عن خطر تكرار غلاف التطبيق (من دليل SEO لـJavaScript في Ahrefs)

• “With app shell models, very little content and code may be shown in the initial HTML response. In fact, every page on the site may display the same code, and this code may be the exact same as the code on some other websites.” (الترجمة العربية): «في نماذج غلاف التطبيق قد تظهر كمية ضئيلة جدًا من المحتوى والشفرة في استجابة HTML الأولية، وقد تعرض كل صفحة في الموقع الشفرة نفسها، بل الشفرة نفسها الموجودة في مواقع أخرى.»
• “This can sometimes cause pages to be treated as duplicates and not immediately go to rendering. Even worse, the wrong page or even the wrong site may show in search results.” (الترجمة العربية): «قد يؤدي ذلك أحيانًا إلى معاملة الصفحات كمكررات وعدم انتقالها فورًا إلى العرض؛ والأسوأ أن صفحة خاطئة أو حتى موقعًا خاطئًا قد يظهر في النتائج.»
• “Any kind of SSR, static rendering, and prerendering setup is going to be fine for search engines.” (الترجمة العربية): «سيكون أي إعداد لـSSR أو العرض الثابت أو العرض المسبق مناسبًا لمحركات البحث.»
• عن العرض الديناميكي: “This is a workaround and, to be honest, I never recommended it… It’s definitely cloaking.” (الترجمة العربية): «هذا حل التفافي، وبصراحة لم أوصِ به قط… إنه بالتأكيد إخفاء.»
• “JavaScript XHR requests eat crawl budget, and I mean they gobble it down. Unlike most other resources that are cached, these get fetched live during the rendering process.” (الترجمة العربية): «تلتهم طلبات JavaScript XHR ميزانية الزحف فعلًا؛ فبخلاف معظم الموارد المخزنة مؤقتًا، تُجلب هذه مباشرة أثناء عملية العرض.»

ثلاثة قرارات تقنية لمواقع SaaS في مخططات تدفق

هذه الأسئلة الثلاثة تتكرر في كل تدقيق تقني لموقع SaaS تقريبًا.

أ. هل تحتاج هذه الصفحة إلى عرض من جهة الخادم؟

س1. هل يحتاج شخص غير مسجل الدخول إلى العثور على الصفحة في البحث؟ (صفحات التسويق والتسعير والمقارنة والوثائق والمدونة والميزات)

• نعم ← يجب أن يوجد المحتوى في استجابة الخادم. استخدم SSR أو التوليد الثابت أو hydration، لا العرض الكامل لدى العميل. مكان المحتوى والعناوين والأسعار في HTML الأولية.
• لا ← تابع.

س2. هل هي واجهة المنتج الفعلية داخل التطبيق ولا تُفتح إلا بعد الدخول؟

• نعم ← لا أهمية لـSEO؛ فلن تزحف إليها Google، وCSR الكامل مناسب.
• لا / غير متأكد ← عاملها افتراضيًا كصفحة عامة واعرضها على الخادم. الخطر هو تسرب CSR الشبيه بالتطبيق إلى الواجهة العامة.

ب. هل نضع الوثائق على نطاق فرعي أم مجلد فرعي؟

س1. هل تفرض منصة الوثائق (Mintlify / ReadMe / GitBook / إلخ) نطاقًا فرعيًا أو نطاق طرف ثالث؟

• نعم ← استخدم النطاق الفرعي؛ فلا عقوبة ترتيب. ثم انتقل إلى قائمة النظافة أدناه.
• لا، لديك حرية الاختيار ← تابع.

س2. ما الأهم: توحيد السلطة أم عزل الوثائق؟

• توحيد السلطة / أبسط ربط داخلي ← مجلد فرعي (/docs/)، وهو الخيار الأنظف عند الحرية.
• عزل ميزانية الزحف / استقلال المنصة / ملكية فريق الوثائق للأدوات ← نطاق فرعي (docs.example.com). خيار سليم؛ فـGoogle «تراهما بالطريقة نفسها».

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

ج. كيف نبقي عناوين التطبيق والتجربة ولوحة المعلومات خارج Google؟

س1. هل تريد وقف زحف المساحة كلها لتوفير الميزانية، أم إبقاءها خارج الفهرس فقط؟

• وقف زحف المساحة ← ضعها خلف المصادقة، وهو الأفضل، أو احظرها في robots.txt. تقبّل أن عنوانًا محجوبًا مرتبطًا خارجيًا قد يظهر بلا مقتطف.
• إبقاء صفحة قابلة للزحف خارج الفهرس ← استخدم noindex، وتأكد من أنها غير محجوبة أيضًا في robots.txt حتى يرى Google الوسم.

س2. هل الصفحة معروضة بـJavaScript كغلاف تطبيق؟

• نعم ← ضع noindex في HTML المعروض من الخادم أو ترويسة HTTP، لا في وسم تحقنه JavaScript؛ فالوسم المعتمد على العرض هش.

لا تجمع الأداتين على عنوان واحد. الحجب في robots.txt مع noindex هو خطأ SaaS الكلاسيكي؛ إذ يخفي الحظر noindex عن Google، وقد يتسرب العنوان إلى النتائج.

النماذج الذهنية

1. خط واحد وبيئة تقنية مختلفة. لا توجد خوارزمية SaaS. الزحف ← العرض ← الفهرسة ← الترتيب مطابق لأي موقع. عندما تضعف صفحة تقنيًا، حدّد مرحلة الخط العادي التي تفشل فيها — هل زُحفت أم عُرضت أم فُهرست أم قُدمت؟ — ثم أصلحها.

2. جدار الدخول هو الحد بين SSR وCSR. يجب عرض الصفحات العامة السابقة للدخول على الخادم، ويمكن أن تكون واجهة المنتج الخاصة بعد الدخول CSR كاملة لأن Google لا تزحف إليها. مشكلة غلاف التطبيق كلها تسرب أنماط CSR عبر هذا الحد.

3. غلاف التطبيق يعني خطر التكرار، لا الاختفاء فقط. أسوأ نتيجة ليست صفحة فارغة، بل جمع Google صفحات مختلفة كمكررات لأن HTML الخادم لكل مسار هو الغلاف نفسه، ثم إظهار الصفحة الخطأ. يصعب اكتشاف «الفهرسة الخاطئة» أكثر من «عدم الفهرسة».

4. امتداد عناوين freemium هو تنقل متعدد الأوجه باسم آخر. اللوحات وخطوات التجربة وصفحات المستخدم القابلة للمشاركة هي نسخة SaaS من فئات URL منخفضة القيمة. أصلحها معماريًا مقدمًا بالمصادقة أو robots.txt، لا بـnoindex لكل صفحة بعد وجودها، لأنه لا يوفر ميزانية الزحف.

5. أداة واحدة لكل هدف، والأدوات تتفاعل. يوقف robots.txt الزحف لا الفهرسة، ويوقف noindex الفهرسة لكنه يحتاج إلى الزحف كي يُرى. الجمع بينهما على عنوان واحد عكسي؛ حدد الهدف ثم اختر أداته.

6. يجيب hreflang عن «أي منطقة؟» لا «أي سعر؟». استهداف المنطقة وظيفة canonical وhreflang. وعرض العملة آلية منفصلة مثل geo-IP أو إعداد الحساب أو منتقي المنطقة. خلطهما خطأ شائع، وقد تُدمج الصفحات الإقليمية شبه المتطابقة رغم ذلك.

SEO التقني لمواقع SaaS — ورقة غش

الأنماط الأربعة الخاصة بـSaaS في لمحة

noindex مقابل robots.txt — اختر أداة لكل هدف

العرض — أين يلزم SSR وأين يكون اختياريًا؟

ما يجب وما لا يجب في JavaScript

• افعل: روابط <a href> حقيقية، وتوجيه History API، والعرض من الخادم أو المسبق، وnoindex في HTML الخادم أو ترويسة HTTP.
• لا تفعل: تنقل onClick، أو توجيه أجزاء #، أو حقن noindex عبر JS في غلاف تطبيق، أو افتراض أن الإطار «يتولى SEO»، أو الاعتماد على العرض الديناميكي مع إمكان SSR الحقيقي.

خرافات ينبغي إنهاؤها

• «يتولى موقع React/Next/Vue لدي SEO تلقائيًا.» ← يرفع السقف ولا يحقق الحد الأدنى.
• «ترتيب النطاقات الفرعية أسوأ.» ← لا عقوبة؛ إنها مقايضة زحف وسلطة.
• «يوفر noindex ميزانية الزحف.» ← لا؛ ما تزال الصفحة تُزحف لقراءة الوسم.
• «الحجب في robots.txt مع noindex أكثر أمانًا.» ← العكس؛ يخفي الحظر الوسم.
• «يحل hreflang التسعير متعدد العملات.» ← هو للغة والمنطقة لا العملة.
• «العرض الديناميكي إصلاح قياسي آمن.» ← موضع خلاف؛ يؤيده Bing ولا أؤيده أنا، ففضّل SSR الحقيقي.

يعرض البحث صفحة SaaS خاطئة لعدة مسارات

العرض: تُعرض المسارات العامة صحيحًا للمستخدم، لكن البحث يجمعها أو يختار صفحة أو canonical غير متوقع. السبب المرجح: استجابات الخادم الأولية تحمل غلاف التطبيق نفسه، ولا يصل المحتوى المختلف إلا بعد JavaScript، فتبدو الصفحات الخام مكررة. الإصلاح: انقل النص الرئيسي والعناوين وcanonical والتنقل القابل للزحف إلى SSR/SSG. قارن HTML الخام والمعروض عبر مجموعة المسارات، ثم تأكد من أن كل استجابة أولية مختلفة ومتسقة ذاتيًا.

لا يُحترم noindex المحقون عبر JavaScript

العرض: تظهر صفحة مجاورة للتطبيق في البحث رغم أن DOM في المتصفح يحتوي لاحقًا على noindex. السبب المرجح: لا يضاف التوجيه إلا بعد العرض لدى العميل وقد يتأخر أو يُتخطى أو يتأثر بسلوك JS/noindex المبلغ عنه. الإصلاح: ضع noindex في HTML الأولية أو ترويسة HTTP X-Robots-Tag، وأبق العنوان قابلًا للزحف، وافحص الاستجابة المجلبة في Search Console بعد إعادة الزحف.

يظهر عنوان موسوم بـnoindex بلا مقتطف

العرض: يظل عنوان محجوب في robots.txt ظاهرًا كنتيجة عارية بلا مقتطف رغم وجود noindex. السبب المرجح: تمنع قاعدة robots Google من جلب الصفحة ورؤية noindex. الإصلاح: حدد الهدف؛ إن وجب خروج العنوان من الفهرس فاسمح بالزحف حتى يُعالج noindex المعروض من الخادم. وإن وجب ألا تُزحف المساحة أصلًا، فاستخدم المصادقة أو الحجب المقصود مع فهم أن الاكتشاف الخارجي قد يكشف العنوان.

تُدمج صفحات التسعير الإقليمية أو تظهر في السوق الخطأ

العرض: تتبادل عناوين تسعير إنجليزية متشابهة أماكنها أو تُدمج أو لا تخدم المنطقة المقصودة. السبب المرجح: علاقات hreflang/canonical ناقصة أو متعارضة، أو لا تختلف الصفحات إلا بالعملة. الإصلاح: امنح كل عنوان إقليمي canonical ذاتيًا وhreflang متبادلًا كاملًا ورموزًا صحيحة ومحتوى إقليميًا ذا معنى. عالج العملة بمنطق الموقع أو الحساب أو المنتقي المنفصل، وتحقق من المجموعة كاملة.

قائمة فحص التنفيذ التقني لمواقع SaaS

غلاف التطبيق العام والعرض

• يظهر محتوى التسويق والتسعير والمقارنة والمدونة والوثائق العامة في HTML الأولية عبر SSR/SSG/العرض المسبق.
• تستخدم التنقلات والروابط الداخلية عناصر a href حقيقية.
• تظهر نية canonical وrobots في الاستجابة الأولية ولا تتغير بعد hydration دون قصد.
• لا تعيد المسارات المختلفة غلافًا متطابقًا مع تأجيل المحتوى الفريد كله إلى XHR.
• تفصل المصادقة واجهة المنتج الخاصة عن شرط العرض العام.

مضيف الوثائق وملكيتها

• اختيار المجلد أو النطاق الفرعي قرار أدوات وزحف وسلطة، لا افتراض عقوبة ترتيب.
• يُتحقق من نطاق الوثائق الفرعي ويُراقب كخاصية مستقلة في Search Console.
• يربط تنقل التسويق وتذييله بالوثائق، وتعيد الوثائق روابط سياقية مفيدة.
• للوثائق ذات الإصدارات قواعد canonical أو تمييز صريحة، بلا تكرار قديم منفلت.

مساحة عناوين freemium والحسابات

• تُحصر عناوين اللوحات وخطوات التجربة وملفات المستخدم والمشاركة قبل الإطلاق.
• تتطلب المسارات الخاصة المصادقة، وتستخدم مساحات الزحف غير البحثية قواعد robots مقصودة.
• لا يُستخدم noindex للتحكم في ميزانية الزحف.
• لا يُحجب أي عنوان في robots.txt بينما يُتوقع أن يكشف توجيه noindex.

صفحات SaaS الإقليمية

• تشير العناوين الإقليمية إلى نفسها كـcanonical وتسرد شركاء hreflang متبادلين برموز لغة ومنطقة صحيحة.
• للعملة آلية مستقلة؛ ويُستخدم hreflang لاستهداف اللغة والمنطقة فقط.
• تتضمن الصفحات الإقليمية باللغة نفسها معلومات سوقية ذات معنى إذا كان المقصود فهرستها منفصلة.

أدوات SEO التقني لمواقع SaaS

• فاحص HTML الخام مقابل المعروض — قارن HTML الأولية والمعروضة لاكتشاف تكرار الغلاف والمحتوى والروابط المفقودة وتغير robots/canonical بعد hydration.
• مختبر robots.txt — اختبر مجموعات التطبيق واللوحة والتجربة والمشاركة والأصول والصفحات العامة مقابل القواعد الخاصة بالروبوتات.
• returntag — ازحف المجموعة الإقليمية لاكتشاف مشكلات وسم الإرجاع والإشارة الذاتية وحالة الهدف وcanonical والرمز وx-default.
• فحص عنوان URL في Google Search Console — قارن المحتوى المجلوب والمعروض وإشارات canonical والفهرسة، واطلب التحقق بعد تغييرات العرض أو noindex.
• فهرسة الصفحات وإحصاءات الزحف في Google Search Console — راقب عناوين التطبيق والاستبعادات وأنماط الزحف لكل مضيف وسلوك نطاق الوثائق.
• سجلات الخادم وزاحف خام/معروض — قس طلبات الروبوتات في مساحات freemium وقارن خرج القالب قبل JavaScript وبعده.

اختبار تكافؤ التحويل إلى SSR/SSG

الاختبار: بعد تحويل قالب عام، مرر مسارات ممثلة عبر Render Gap وقارن HTML الخام بين المسارات، وكذلك الخام بالمعروض لكل مسار. النتيجة المتوقعة: يوجد المحتوى والعناوين والروابط وcanonical وتوجيهات robots المقصودة في الاستجابة الأولية، ولم تعد المسارات تشترك في غلاف لا يمكن تمييزه. تفسير الفشل: ما يزال hydration أو جلب البيانات يتحكم في المحتوى الأساسي أو يعيد كتابة إشارات SEO. نافذة المراقبة: فور النشر لكل قالب متغير. مشغّل التراجع: تراجع إذا فقدت الاستجابات الخام المحتوى، أو تطابقت المسارات، أو تعارض الخرج المعروض مع خرج الخادم.

اختبار noindex من جهة الخادم

الاختبار: اجلب استبعادًا مقصودًا بلا عرض، وافحص robots meta أو X-Robots-Tag، واختبر العنوان في مختبر robots.txt. النتيجة المتوقعة: يوجد noindex في الاستجابة الأولية ويسمح robots.txt بالزحف اللازم لقراءته. تفسير الفشل: ما يزال التوجيه معتمدًا على JS أو مخفيًا خلف حجب الزحف. نافذة المراقبة: فور النشر وبعد انتشار CDN/التخزين المؤقت، ثم تأكيد حالة Search Console بعد الزحف. مشغّل التراجع: أوقف الطرح إذا أضاف القالب المشترك noindex للصفحات العامة أو أزاله من الاستبعادات.

اختبار مساحة زحف freemium

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

اختبار المجموعة الإقليمية

الاختبار: تحقّق من العناوين الإقليمية المنشورة باستخدام returntag وافحص canonical على الصفحة مع مجموعة hreflang المكتشفة. النتيجة المتوقعة: يشير كل عنوان قابل للفهرسة إلى نفسه، ويعيد الشركاء الإشارة، وتنجح الأهداف، وتصح رموز اللغات. تفسير الفشل: المجموعة ناقصة أو تمر بتحويلات/أخطاء أو تناقض اختيار canonical. نافذة المراقبة: فور النشر وبعد أي تغيير لغة أو نطاق. مشغّل التراجع: أوقف العنوان الإقليمي الجديد عن المجموعة إذا كسر التبادلية أو أشار أساسيًا إلى لغة أخرى دون قصد.

موارد تستحق وقتك

كتاباتي ذات الصلة

• JavaScript SEO: دليل شامل — المصدر المتعمق لقسم غلاف التطبيق: فشل تجميع التكرار، وSSR والعرض الثابت والمسبق، وسبب عدم توصياتي بالعرض الديناميكي، وكيف تلتهم طلبات XHR ميزانية الزحف.
• إطلاق النمو عبر SEO المؤسسي لمواقع SaaS — دليلي الكامل لـSaaS والمقال الأصل: محتوى يقوده المنتج، وصفحات «مقابل» والأدوات المجانية، ومشكلات JavaScript والزحف على النطاق المؤسسي.
• متى ينبغي أن تقلق بشأن ميزانية الزحف؟ — الدليل العام وراء قسم عناوين freemium: كثرة الزحف لا تعني ترتيبًا أفضل، لكن الصفحات غير المزحوفة لا ترتب.
• دليل المبتدئين إلى SEO التقني — موضع هذه المسائل في الصورة الأوسع.

محاضراتي

• فوضى SEO المؤسسي (SMX Advanced، من فترة عملي في SEO التقني لدى IBM) — سلاسل التحويل وتعارضات canonical وقوائم JavaScript غير المرئية للزواحف وراء مواقع SaaS والمؤسسات الواقعية. ينطبق إخلاء مسؤوليتي: هذا فهمي لا حقيقة مقدسة.

من أرجاء المجال

• فهم أساسيات SEO لـJavaScript — Google Search Central — الوثيقة الأولية لمراحل الزحف والعرض والفهرسة وحجة SSR.
• العرض على الويب — web.dev — إطار فريق Chrome لمقايضات CSR/SSR/SSG/hydration.
• تحسين ميزانية الزحف — Google Search Central — السعة × الطلب ولماذا يوفر robots.txt، لا noindex، الميزانية.
• حظر الفهرسة باستخدام noindex — Google Search Central — آلية noindex وشرط robots.txt وراء تعارض SaaS.
• إدارة المواقع متعددة المناطق واللغات — Google Search Central — إرشاد التكرار الإقليمي باللغة نفسها وراء صفحات التسعير.
• John Mueller من Google: متى تستخدم نطاقًا فرعيًا أم مجلدًا؟ — Search Engine Journal — إطار «نراهما بالطريقة نفسها» وراء قرار الوثائق.
• سلسلة bingbot: JavaScript والعرض الديناميكي والإخفاء — Bing Webmaster Blog — تأييد Bing الرسمي للعرض الديناميكي حيث يختلف عن رأيي.
• البوابات الخمس للبنية التحتية وراء الزحف والعرض والفهرسة — Search Engine Land — عبارة Fabrice Canel عن أن الأقل أفضل مطبقة على امتداد URL.

اختبر نفسك: SEO التقني لمواقع SaaS

خمسة أسئلة عن الأنماط التقنية الخاصة بمواقع SaaS. اختر إجابة لكل سؤال ثم تحقق.

سجل التغييرات