اختبار A/B عند الحافة لـSEO

الخلاصة — يعني اختبار A/B عند الحافة إجراء اختبار تقسيم على شبكة CDN لديك — الشبكة التي تقع أمام موقعك — بدلًا من إجرائه في المتصفح أو على خادمك. يقرر سكربت صغير عند الحافة أي نسخة من الصفحة يحصل عليها كل زائر، قبل وصول الصفحة إليه. وهذا خبر جيد فعلًا لتحسين محركات البحث: ترى Google HTML حقيقيًا لا تبديلًا بجافاسكريبت. المهم هو الاتساق — لا تجعل Google ترى نسخة مختلفة عن المستخدمين، ولا تترك الاختبار يعمل إلى الأبد. الاختبار مسموح؛ أما إظهار شيء مختلف لـGoogle عن الناس فهو إخفاء، وهو مخالف للقواعد.

ما هو اختبار A/B عند الحافة

يُسند اختبار A/B عند الحافة النسخ ويعدّلها في طبقة التسليم، بدل أن يضطر تطبيق الأصل إلى إنشاء كل اختلاف. Evidence for this claim Cloudflare Workers can execute code and modify requests or responses at the network edge. Scope: Cloudflare Workers; other edge platforms have different runtimes and controls. Confidence: high · Verified: 2026-07-14 Cloudflare: Workers overview تسمح Google باختبار المواقع، لكنها تحذر من الإخفاء وتوصي بتجارب مؤقتة ومضبوطة. Evidence for this claim Google permits website testing, warns against cloaking, and recommends appropriate canonicals or temporary redirects and limited test duration. Scope: Google Search guidance for website testing; it applies regardless of whether assignment occurs at the edge or origin. Confidence: high · Verified: 2026-07-14 Google: Website testing and Search

يعرض اختبار A/B النسخة A لبعض الزوار والنسخة B لزوار آخرين، حتى تقيس أيهما يؤدي أفضل. أما اختبار A/B عند الحافة فيعني فقط أن اختيار النسخة التي ستُعرض يحدث على شبكة CDN لديك (Cloudflare أو Akamai أو Fastly أو أداة مثل Optimizely أو VWO تعمل عند الحافة)، لا في متصفح الزائر أو على خادم الويب الخاص بك.

يمكن إجراء الاختبار في ثلاثة مواضع، وهذا مهم جدًا لتحسين محركات البحث:

1. من جهة العميل — تبدّل JavaScript المحتوى في المتصفح بعد تحميل الصفحة. يسهل إعداده، لكن قد لا ترى Google التغيير أبدًا لأنها لا تنتظر دائمًا JavaScript المتأخرة.
2. من جهة خادم الأصل — ينشئ خادم تطبيقك النسخة المختارة ويرسلها بوصفها HTML حقيقيًا.
3. عند الحافة — تنشئ شبكة CDN النسخة المختارة أو تعيد كتابة HTML الحقيقي قبل أن يصل الطلب إلى خادمك. وهذا يقدم فائدة SEO نفسها الموجودة في المعالجة من جهة الخادم (تحصل Google على HTML حقيقي)، مع سرعة أكبر ومن دون نشر للكود.

لماذا تكون الحافة مكانًا أكثر أمانًا للاختبار (لتحسين محركات البحث)

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

القاعدة الوحيدة: لا تعرض لـGoogle شيئًا مختلفًا عما تعرضه للناس

تقبل Google اختبار A/B تمامًا — وتقول ذلك في وثائقها. لكنها لا تقبل الإخفاء: أي عرض محتوى مختلف عمدًا لمحركات البحث عما تعرضه للمستخدمين الحقيقيين بهدف التلاعب بالترتيب. والحيلة كلها في اختبار آمن عند الحافة هي التأكد من أن Googlebot يرى نسخة شرعية ومتسقة من الصفحة — من النوع نفسه الذي يمكن لأي مستخدم حقيقي الحصول عليه — لا «نسخة للروبوت» خاصة.

يمكن لشيئين أن يخرقا هذه القاعدة عرضًا عند الحافة:

• ملفات تعريف الارتباط. تتذكر معظم اختبارات الحافة النسخة المسندة إلى الزائر باستخدام ملف تعريف ارتباط. ولا تحتفظ Googlebot عادة بملفات تعريف الارتباط، لذلك قد يُعاد إسناد نسخة مختلفة إليه عشوائيًا في كل زيارة. لا يعني ذلك أنك تحاول الغش، لكنه قد يبدو فوضويًا لـGoogle.
• إعادة التوجيه إلى عنوان URL ثانٍ. إذا أرسل اختبارك الزوار إلى عنوان URL مختلف قليلًا (مثل ?variant=b)، فقد تتعامل Google معه كصفحة مستقلة وتفهرس العنوانين.

يمكن إصلاح الأمرين، وتشرح علامة Advanced الطريقة بالضبط — إضافة إلى مدة تشغيل الاختبار بأمان، وما إذا كان «إعطاء الروبوتات النسخة العادية» اختصارًا ذكيًا أم فخًا.

الخلاصة — يقدم اختبار A/B عند الحافة HTML للنسخ أو يعيد التوجيه من طبقة عامل CDN قبل أن يرى الأصل الطلب أصلًا. وبما أن المحركات تحصل على HTML حقيقي (لا تبديل JS من جهة العميل)، فهذه أكثر البيئات أمانًا للاختبار — لكنها تنطوي على مجموعة مخاطر خاصة بالحافة. قسمه إلى نمطين: إعادة كتابة HTML على عنوان URL نفسه (الخطر: لا تحتفظ Googlebot عادة بملفات تعريف الارتباط، لذلك قد يعرض التقسيم المعتمد على ملفات تعريف الارتباط نسخة عشوائية جديدة في كل زحف) وإعادة التوجيه إلى عنوان URL لنسخة (الخطر: التباس المحتوى المكرر والوسم الأساسي). الإصلاحات: اجعل حركة الروبوتات والطلبات التي لا تحمل ملفات تعريف ارتباط حتمية، واجعل rel=canonical في عنوان النسخة يشير إلى الأصل، واستخدم 302 لا 301 أثناء التشغيل، وأزل الاختبار فور اختيار الفائز. قاعدة Google هي «الاختبار مسموح، والإخفاء غير مسموح» — والإخفاء يتعلق بالنية وعدم التكافؤ، لا بأن «روبوتًا رأى النسخة B مرة». سأغطي ماهية SEO عند الحافة بإيجاز هنا — فمقال SEO عند الحافة العام في هذه المجموعة يتولى استعراض المنصات؛ أما هذا المقال فيتناول مخاطر الاختبار الخاصة.

ما المختلف فعلًا في الاختبار عند الحافة

يمكن لعامل الحافة توجيه الاستجابة أو تحويلها قريبًا من الزائر، وهذا يغير موضع الإسناد لكنه لا يغير منطق التجربة الأساسي. Evidence for this claim Cloudflare Workers can execute code and modify requests or responses at the network edge. Scope: Cloudflare Workers; other edge platforms have different runtimes and controls. Confidence: high · Verified: 2026-07-14 Cloudflare: Workers overview تعتمد سلامة البحث على تقديم نسخ اختبار شرعية باستمرار، لا على استهداف زواحف البحث بمحتوى مختلف جوهريًا. Evidence for this claim Google permits website testing, warns against cloaking, and recommends appropriate canonicals or temporary redirects and limited test duration. Scope: Google Search guidance for website testing; it applies regardless of whether assignment occurs at the edge or origin. Confidence: high · Verified: 2026-07-14 Google: Website testing and Search

اختبار A/B عند الحافة حالة استخدام لـSEO عند الحافة: فأنت تنفذ التقسيم وإعادة كتابة HTML (أو إعادة التوجيه) في عامل CDN — Cloudflare Workers أو Akamai EdgeWorkers/EdgeKV أو Fastly Compute أو تكاملات Optimizely وVWO عند الحافة/من جهة الخادم — قبل وصول الطلب إلى الأصل. وتصف SearchPilot SEO عند الحافة بأنه “any SEO changes that are made after the HTML is created by your CMS or origin server before it is served to the user,” (ترجمة) «أي تغييرات في SEO تُجرى بعد إنشاء HTML بواسطة نظام إدارة المحتوى أو خادم الأصل وقبل تقديمه للمستخدم.» وتوضح النقطة الأساسية: “They appear to all users and googlebot as server side HTML changes, so there are no risks or downsides from an indexation point of view.” (ترجمة) «تظهر لكل المستخدمين ولـgooglebot كتغييرات HTML من جهة الخادم، لذلك لا توجد مخاطر أو سلبيات من ناحية الفهرسة.» تلك هي الفائدة الأساسية — الحافة مكان آمن للاختبار لأن المحركات تحصل على HTML حقيقي، مثلها مثل جهة الأصل.

فلماذا يوجد هذا المقال أصلًا إذا كانت الحافة آمنة؟ لأن موضع الاختبار آمن، أما طريقة التقسيم عند الحافة فهي موضع فخاخ SEO. اثنان منها يكادان يكونان فريدين لهذا النمط، وتتجاهلهما مقالات «اختبار A/B وSEO» العامة عادة.

موقف Google الفعلي: الاختبار مسموح، والإخفاء غير مسموح

قل ذلك بوضوح، لأن نصف الخوف المحيط باختبارات SEO في غير محله. تدعم Google صراحة اختبار A/B والاختبار متعدد المتغيرات وتنشر أفضل ممارسات له. والخط الذي ترسمه هو الإخفاء، الذي تعرفه سياسة البريد المزعج لديها بأنه “presenting different content to users and search engines with the intent to manipulate search rankings and mislead users.” (ترجمة) «عرض محتوى مختلف للمستخدمين ومحركات البحث بنية التلاعب بترتيب البحث وتضليل المستخدمين.» انتبه إلى نية التلاعب وعدم التكافؤ بين المستخدمين والمحركات — لا إلى «أن روبوتًا رأى نسخة في وقت ما». وتعيد Optimizely صياغة الفكرة لعملائها: “Google encourages constructive testing and does not view the ethical use of testing tools such as Optimize to constitute cloaking.” (ترجمة) «تشجع Google الاختبار البنّاء ولا تعد الاستخدام الأخلاقي لأدوات الاختبار مثل Optimize إخفاءً.»

الحد الفاصل العملي الذي تقدمه Google في وثيقة الاختبار مباشر: “Don’t show one set of URLs to Googlebot, and a different set to humans.” إذا احترم اختبارك عند الحافة ذلك — بحيث يكون الجميع، بمن فيهم الروبوتات، مؤهلين للنسخ الشرعية نفسها التي تُقدم باستمرار — فأنت في الجانب الصحيح من السياسة.

نمطا الاختبار عند الحافة (ومخاطرهما المختلفة)

أبقِ هذين النمطين منفصلين في ذهنك، لأن كلًا منهما يفشل بطريقة مختلفة ويحتاج إلى إصلاح مختلف.

النمط 1 — إعادة كتابة HTML على عنوان URL نفسه عند الحافة

يبقي العامل عنوان URL نفسه (/product/123) ويبدّل عنوانًا أو زر دعوة إلى إجراء أو تنسيق عرض السعر — إذ يعيد HTML Rewriter كتابة الاستجابة أثناء مرورها. هذا هو نموذج Cloudflare Workers «اختبار A/B بالوصول المباشر إلى عنوان URL نفسه»، وتقول وثائقهم إنه “Choose a group and set the cookie (50/50 split)” (ترجمة) «اختر مجموعة واضبط ملف تعريف الارتباط (تقسيم 50/50).» للزائر الجديد.

الخطر الخاص بالحافة: ملفات تعريف الارتباط. تقول Google ذلك مباشرة — “Googlebot generally doesn’t support cookies. This means it will only see the content version that’s accessible to users with browsers that don’t accept cookies.” (ترجمة) «لا تدعم Googlebot ملفات تعريف الارتباط عادة. وهذا يعني أنها لن ترى إلا نسخة المحتوى المتاحة للمستخدمين الذين لا تقبل متصفحاتهم ملفات تعريف الارتباط.» تحفظ كل تطبيقات الحافة تقريبًا المجموعة في ملف تعريف ارتباط حتى يبقى الإنسان العائد في المجموعة نفسها (ومثال Akamai EdgeKV يفعل ذلك بالضبط: “Client bucket selection will be persistent via a cookie value to ensure a client is locked to the same URL on subsequent visits” (ترجمة) «يظل اختيار مجموعة العميل ثابتًا عبر قيمة ملف تعريف ارتباط لضمان تثبيت العميل على عنوان URL نفسه في الزيارات اللاحقة.»). لكن Googlebot لا يحمل ذلك الملف، لذلك قد يدخل في عملية الاختيار العشوائي عند كل زحف ويقع في مجموعة مختلفة عن المرة السابقة. هذا ليس إخفاءً خادعًا — لكنه يعني أن Google قد تفهرس نسخة متقلبة وغير متسقة من عنوان URL نفسه بمرور الوقت. إنه النظير الأكثر خفاءً والنابع من بيئة الحافة لمشكلة «نعرض للروبوتات شيئًا آخر عمدًا»، وهو أهم ما جاء هذا المقال لشرحه.

النمط 2 — إعادة توجيه عند الحافة إلى عنوان URL لنسخة

هنا يعيد العامل توجيه /product/123 برمز إعادة توجيه مؤقت إلى عنوان URL مستقل — /product/123?v=b أو /product/123-b. والآن لديك عنوان URL مختلف فعلًا يمكن للمحركات اكتشافه وفهرسته بمفرده.

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

إصلاح النمط 1: اجعل الزواحف حتمية

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

توثق Cloudflare آلية صالحة لذلك: “Enable Passthrough to allow direct access to control and test routes.” يتيح Passthrough للجميع — الروبوتات وضمان الجودة وأصحاب المصلحة — الوصول باستمرار إلى /control/* أو /test/* بدل إعادة الاختيار العشوائي في كل طلب لا يحمل ملف تعريف ارتباط. وهذه هي الأداة الموثقة رسميًا لمنح الزواحف نسخة متسقة من دون ابتكار مسار خاص بالروبوت.

يتجاوز نموذج SearchPilot الأمر كله بالتقسيم على مستوى مختلف: فهو يضع نسخة واحدة لكل صفحة لجميع المستخدمين ومحركات البحث، ولا يعرض نسخًا متباينة للصفحة نفسها. لذلك لا يُعد ذلك إخفاءً ولا ينشئ نسخًا مكررة. فهم يقسمون الصفحات حتميًا (تعرض الصفحة المعينة النسخة نفسها للجميع) بدل تقسيم المستخدمين عشوائيًا — وهي فلسفة عكس تقسيم Cloudflare بالملف 50/50، وملف مخاطر SEO مختلف حقًا رغم تسمية الاثنين «اختبار A/B عند الحافة». ويقوم هذا النهج على أن يرى Googlebot نسخة واحدة مستقرة من كل صفحة، لا نسخًا متعددة قد تسبب محتوى مكررًا.

إصلاح النمط 2: انضباط الوسم الأساسي وإعادة التوجيه

عندما يكون للاختبار عنوان URL خاص به، تنطبق عليه مباشرة ثلاث قواعد من وثيقة الاختبار لدى Google:

• اجعل الوسم الأساسي للنسخة يشير إلى الأصل. تقول Google: «“you can use the rel=“canonical” link attribute on all of your alternate URLs to indicate that the original URL is the preferred version.”» (ترجمة) «يمكنك استخدام سمة الرابط rel=“canonical” في جميع عناوين URL البديلة للإشارة إلى أن عنوان URL الأصلي هو النسخة المفضلة.» يجب أن يشير الوسم الأساسي في كل عنوان نسخة إلى عنوان URL الأصلي.
• استخدم 302 لا 301 أثناء الاختبار. تقول Google: “use a 302 (temporary) redirect, not a 301 (permanent) redirect.” (ترجمة) «استخدم إعادة توجيه 302 (مؤقتة)، لا إعادة توجيه 301 (دائمة).» يخبر 302 Google أن النقل مؤقت وأن عليها إبقاء الأصل مفهرسًا؛ أما 301 فيقول إنه دائم. احتفظ بـ301 بعد اختيار الفائز والالتزام به.
• أزل الاختبار عند انتهائه. تقول Google: “Once you’ve concluded the test, update your site with the desired content variation(s) and remove all elements of the test as soon as possible… we may interpret this as an attempt to deceive search engines and take action accordingly.” (ترجمة) «بعد الانتهاء من الاختبار، حدّث موقعك بالنسخة المرغوبة وأزل كل عناصر الاختبار في أسرع وقت ممكن… وإلا فقد نعد ذلك محاولة لخداع محركات البحث ونتخذ الإجراء المناسب.»

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

ميزانية الزحف: مشكلة تضاعف المتغيرات

يضيف اختبار A/B واحد حالة إضافية قد يراها الزاحف. أما الاختبار متعدد المتغيرات فيضاعف الحالات: فثلاثة متغيرات مستقلة بنسختين لكل منها تعطي حتى ثماني تركيبات متميزة يمكن للزاحف مواجهتها نظريًا إذا لم يكن التقسيم ثابتًا وحتميًا لكل عنوان URL. يحول التقسيم غير الحتمي عنوان URL واحدًا إلى سحابة متحركة من الحالات، وكل حالة قابلة للزحف تستهلك جزءًا من ميزانية الزحف. وهذا المنظور القائم على تراكم التبديلات غائب تقريبًا عن كتابات الاختبار وSEO، وهو سبب أهمية التقسيم الثابت والحتمي لكفاءة الزحف لا للإخفاء فقط. وتقدم إرشادات Google لعام 2024 عن CDNs وميزانية الزحف الخلفية المناسبة؛ كما يشير مقال SEO عند الحافة العام في هذه المجموعة إليها.

«اعرض للروبوتات النسخة الأصلية فقط» — اختصار أم فخ؟

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

يتحول الأمر إلى إخفاء لحظة وجود «مسار الروبوت» خصيصًا لإظهار واقع مختلف لمحركات البحث عن الواقع الذي يحصل عليه المستخدمون الحقيقيون — وهذا نص Google حرفيًا: “Don’t show one set of URLs to Googlebot, and a different set to humans”. لذا فالصياغة الصحيحة هي: اعرض للزواحف النسخة الحتمية نفسها التي تقبل أن يراها أي مستخدم دائمًا — لا مسارًا خاصًا بالروبوت بُني للتهرب من التدقيق. ولا يكون فحص وكيل المستخدم لإخراج الروبوتات من الاختبار آمنًا إلا لأنك وحّدت صدفةً نسخة حقيقية واحدة؛ وليس تقنية آمنة عامة.

ما مدة تشغيل اختبار عند الحافة؟

لا تقدم Google عددًا محددًا من الأيام. لكنها تحذر من إبقاء عناصر الاختبار فترة تجعل «الاختبار» يتحول خفية إلى حالة الموقع الدائمة من دون إعلان فائز — وهذه هي عبارة «أزل كل عناصر الاختبار في أقرب وقت ممكن» مرة أخرى. وقد تحدث John Mueller من Google عن ذلك: لا بأس بالاستمرار في تشغيل تجارب جديدة واحدة تلو الأخرى، لكن ترك اختبار واحد يعمل بلا نهاية حتى يصبح الصفحة الدائمة الفعلية يبدأ في الظهور كأنه لم يعد اختبارًا حقًا. (تُنقل ملاحظات Mueller هنا عبر تغطية صناعية لندوة Google Webmaster Central، لا عبر وثيقة Google أولية — فاعتبر الصياغة إعادةً للمعنى.) كما أشار Mueller إلى أن تشغيل اختبار A/B أثناء ترحيل موقع يربك إشارات إعادة التوجيه التي تحتاجها Google للتعرف إلى الترحيل بوضوح، لذلك تجنب تداخلهما.

وتضع Optimizely، وهي تعيد قول Google لعملائها، قاعدة إرشادية: “If you are running an experiment for an unnecessarily long time, Google may interpret this as an attempt to deceive search engines and take action accordingly.” (ترجمة) «إذا كنت تجري تجربة لمدة طويلة بلا داعٍ، فقد تفسر Google ذلك محاولة لخداع محركات البحث وتتخذ الإجراء المناسب.» وعند نشر الفائز، تقدر Optimizely أن إعادة التوجيه 301 تحمل “a small loss of link equity (around 10%)” (ترجمة) «خسارة صغيرة في قيمة الروابط (نحو 10%).» — وهذا رقم Optimizely وقاعدة تقريبية، لا رقمًا أكدته Google، فتعامل معه على هذا الأساس.

إرشادات Bing أقل تفصيلًا — اجعل الافتراضي قواعد Google

لا تملك Bing صفحة مخصصة لاختبار A/B عند الحافة/CDN بتفصيل صفحة Google. لكنها تملك معيارًا عامًا للإخفاء يقوم على محتوى متكافئ جوهريًا — “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” (ترجمة) «ما دمت تبذل جهدًا حسن النية لتقديم المحتوى نفسه لجميع الزوار، وكان الاختلاف الوحيد أن المحتوى يُصيَّر على الخادم للروبوتات وعلى جهاز العميل للمستخدمين الحقيقيين، فهذا مقبول ولا يُعد إخفاءً.» — وملاحظة تقول إنه عند “significant structural changes, we recommend hosting each version on separate URLs, or split URL testing,” (ترجمة) «تغييرات بنيوية كبيرة، نوصي باستضافة كل نسخة على عناوين URL منفصلة، أو إجراء اختبار تقسيم العناوين.» مع استخدام IndexNow حتى ترى Bing عناوين النسخ سريعًا. وبما أن معيار Bing متوافق مع Google، فطبق قواعد Google للوسم الأساسي و302 والمدة بوصفها الافتراضي المحافظ على المحركين.

موضع هذا المقال في المجموعة

هذا المقال رفيق خاص بالاختبار لمقال SEO عند الحافة العام في هذه المجموعة — فذلك المقال يتولى استعراض المنصات (ما العوامل الموجودة وما الذي يمكنك فعله عند الحافة)، أما هذا فيتناول مخاطر اختبار التقسيم فقط. وتعتمد آليات الوسم الأساسي والمحتوى المكرر في النمط 2 على الأفكار نفسها الموجودة في التعمقين الخاصين بالوسم الأساسي والمحتوى المكرر، بينما تتصل زاوية ميزانية الزحف بمادة الزحف وميزانية الزحف — وكلها موجودة في مواضع أخرى من الموقع.

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

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

• اختبار A/B عند الحافة يجري اختبارات التقسيم في طبقة عامل CDN (Cloudflare Workers وAkamai EdgeWorkers وFastly Compute وحافة Optimizely/VWO)، بحيث تُقدم HTML النسخة أو عمليات إعادة التوجيه قبل الأصل. تحصل المحركات على HTML حقيقي، لذلك فالحافة مكان آمن للاختبار — وأكثر أمانًا بكثير من اختبار تبديل JavaScript من جهة العميل.
• موقف Google: الاختبار مسموح؛ الإخفاء غير مسموح. ويُعرّف الإخفاء بـنية التلاعب وعدم التكافؤ بين المستخدمين والروبوتات — لا بأن «روبوتًا رأى النسخة B مرة».
• نمطان، وخطران. (1) إعادة كتابة HTML على عنوان URL نفسه: لا تحتفظ Googlebot عادة بملفات تعريف الارتباط، لذلك قد يعيد التقسيم المعتمد على ملفات تعريف الارتباط إسنادها إلى نسخة مختلفة في كل زحف، فينتج محتوى مفهرسًا غير متسق. (2) إعادة التوجيه إلى عنوان نسخة: التباس المحتوى المكرر والوسم الأساسي.
• الإصلاحات. اجعل حركة الروبوتات والطلبات التي لا تحمل ملفات تعريف ارتباط حتمية (النسخة نفسها لكل عنوان URL دائمًا؛ ونمط «passthrough» لدى Cloudflare مثال). اجعل rel=canonical في كل عنوان نسخة يشير إلى الأصل. استخدم 302 لا 301 أثناء التشغيل. أزل الاختبار فور اختيار الفائز.
• تقسيم الصفحات مقابل تقسيم المستخدمين. يتجاوز تقسيم الصفحات الحتمي على طريقة SearchPilot مشكلة ملفات تعريف الارتباط تمامًا؛ أما التقسيم العشوائي للمستخدمين بملفات تعريف الارتباط (أمثلة Cloudflare/Akamai) فيحتاج إلى بديل حتمي.
• ميزانية الزحف تتراكم مع الاختبارات متعددة المتغيرات — فالمتغيرات المستقلة الكثيرة تضاعف الحالات القابلة للزحف ما لم يكن التقسيم ثابتًا وحتميًا.
• «اعرض للروبوتات النسخة الأصلية» آمن فقط إذا كانت تلك النسخة فعلًا ما تريد فهرسته — فالأمان يأتي من الاتساق والشرعية، لا من اكتشاف الروبوت.
• المدة: لا حد ثابتًا، لكن لا تجعل الاختبار حالة دائمة، وتجنب تشغيله أثناء الترحيل. إرشادات Bing أقل تفصيلًا — فاجعل الافتراضي قواعد Google.

ما نمط اختبار الحافة الذي تشغله — وما إصلاحه؟

تعود معظم مشكلات SEO في اختبارات الحافة إلى سؤالين: هل يغير الاختبار عنوان URL، وهل نسخة الزاحف حتمية؟ اتبع المسار لتجد الإصلاح المنطبق عليك.

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

إرشادات من المصادر الأولية لمحركات البحث وبائعي المنصات.

Google

• أفضل ممارسات اختبار A/B للبحث — إرشادات الوسم الأساسي و302 والمدة وملفات تعريف الارتباط التي يعتمد عليها المقال كله.
• سياسات البريد المزعج — الإخفاء — تعريف الإخفاء (نية التلاعب وعدم التكافؤ).

Bing / Microsoft

• اختبار A/B لأداء أفضل لمحرك البحث باستخدام IndexNow وMicrosoft Clarity — ملاحظة Bing المختصرة عن اختبار A/B؛ عناوين منفصلة للتغييرات البنيوية وIndexNow حتى تُرى.
• سلسلة bingbot: JavaScript والعرض الديناميكي والإخفاء. يا للعجب! — معيار Bing للإخفاء القائم على «المحتوى المتكافئ جوهريًا بحسن نية».

بائعي CDN ومنصات الاختبار

• Cloudflare Workers — اختبار A/B بالوصول المباشر إلى العنوان نفسه — مثال ملف تعريف الارتباط 50/50 ونمط «passthrough» للوصول المتسق إلى النسخة.
• Akamai — بناء اختبار A/B باستخدام EdgeWorkers وEdgeKV — تقسيم ثابت بملف تعريف ارتباط عند الحافة (ومن اللافت غياب سياق SEO والروبوت في الوثيقة).
• Optimizely — اختبار A/B وتحسين محركات البحث — إرشادات البائع التي تعيد قواعد Google لعملائه.

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

تصريحات مسجلة من Google وBing وبائعي المنصات. كل رابط من روابط Google وBing وCloudflare رابط عميق يقفز إلى المقطع المقتبس في صفحة المصدر.

Google — أفضل ممارسات اختبار A/B

• “Don’t show one set of URLs to Googlebot, and a different set to humans.” (ترجمة) «لا تعرض مجموعة من عناوين URL لـGooglebot ومجموعة مختلفة للبشر.» الانتقال إلى الاقتباس
• “Googlebot generally doesn’t support cookies. This means it will only see the content version that’s accessible to users with browsers that don’t accept cookies.” (ترجمة) «لا تدعم Googlebot ملفات تعريف الارتباط عادة. وهذا يعني أنها لن ترى إلا نسخة المحتوى المتاحة للمستخدمين الذين لا تقبل متصفحاتهم ملفات تعريف الارتباط.» — الاقتباس المحوري لاختبار الحافة. الانتقال إلى الاقتباس
• «“you can use the rel=“canonical” link attribute on all of your alternate URLs to indicate that the original URL is the preferred version.”» (ترجمة) «يمكنك استخدام سمة الرابط rel=“canonical” في جميع عناوين URL البديلة للإشارة إلى أن عنوان URL الأصلي هو النسخة المفضلة.» الانتقال إلى الاقتباس
• “use a 302 (temporary) redirect, not a 301 (permanent) redirect.” (ترجمة) «استخدم إعادة توجيه 302 (مؤقتة)، لا إعادة توجيه 301 (دائمة).» الانتقال إلى الاقتباس
• “Once you’ve concluded the test, update your site with the desired content variation(s) and remove all elements of the test as soon as possible… we may interpret this as an attempt to deceive search engines and take action accordingly.” (ترجمة) «ما إن تنهي الاختبار، حدّث موقعك بالنسخة المرغوبة وأزل عناصر الاختبار كلها بأسرع ما يمكن… وإلا فقد نعد الأمر محاولة لتضليل محركات البحث ونتصرف بناءً على ذلك.» الانتقال إلى الاقتباس

Google — الإخفاء (سياسة البريد المزعج)

• “Cloaking refers to the practice of presenting different content to users and search engines with the intent to manipulate search rankings and mislead users.” (ترجمة) «يشير الإخفاء إلى تقديم محتوى مختلف للمستخدمين ومحركات البحث بنية التلاعب بترتيب البحث وتضليل المستخدمين.» الانتقال إلى الاقتباس

Bing / Microsoft

• “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.” (ترجمة) «ما دمت تبذل جهدًا حسن النية لتقديم المحتوى نفسه لجميع الزوار، وكان الاختلاف الوحيد أن المحتوى يُصيَّر على الخادم للروبوتات وعلى جهاز العميل للمستخدمين الحقيقيين، فهذا مقبول ولا يُعد إخفاءً.» الانتقال إلى الاقتباس
• “If you’re creating significant structural changes, we recommend hosting each version on separate URLs, or split URL testing.” (ترجمة) «تغييرات بنيوية كبيرة، نوصي باستضافة كل نسخة على عناوين URL منفصلة، أو إجراء اختبار تقسيم العناوين.» الانتقال إلى الاقتباس

Cloudflare Workers — مثال العنوان نفسه

• “Enable Passthrough to allow direct access to control and test routes.” — الطريقة الموثقة لمنح الزواحف (وضمان الجودة وأصحاب المصلحة) نسخة متسقة بدل اختيار عشوائي بملف تعريف ارتباط. الانتقال إلى الاقتباس

Akamai — مثال EdgeKV

• “Client bucket selection will be persistent via a cookie value to ensure a client is locked to the same URL on subsequent visits.” (وثيقة Akamai وثيقة هندسة تحويل خالصة — ومن المفيد ملاحظة أنها لا تتضمن أي تأطير لـSEO أو الروبوت أو الزاحف؛ فهذا منظور تضيفه أنت.)

Optimizely — إرشادات البائع لعملائه

• “Google encourages constructive testing and does not view the ethical use of testing tools such as Optimize to constitute cloaking.” (ترجمة) «تشجع Google الاختبار البنّاء ولا تعد الاستخدام الأخلاقي لأدوات الاختبار مثل Optimize إخفاءً.»
• “If Google determines that the variation of your page is substantially different from the original in scope and content, then they may construe this change as cloaking.” (ترجمة) «إذا قررت Google أن نسخة صفحتك تختلف اختلافًا جوهريًا عن الأصل من حيث النطاق والمحتوى، فقد تعتبر هذا التغيير إخفاءً.» (هذه عبارات Optimizely لعملائها، وهي تعيد قراءة البائع لسياسة Google — فاعتبرها إرشادًا من البائع لا سلطة مستقلة. كما أن خسارة «نحو 10% من قيمة الروابط» في 301 قاعدة تقريبية لدى Optimizely وليست رقمًا أكدته Google.)

SearchPilot — منهجية تقسيم الصفحات

• “When doing SEO A/B testing, there is only one version of the page. We are not showing different versions of the same page to users or Google. This isn’t cloaking and doesn’t create any duplicate versions of the same page.” (ترجمة) «في اختبار A/B الخاص بـSEO، لا توجد إلا نسخة واحدة للصفحة؛ فلا نعرض للمستخدمين أو لـGoogle نسخاً متباينة من الصفحة ذاتها. وليس هذا إخفاءً، كما أنه لا ينشئ نسخاً مكررة منها.» (SearchPilot بائع اختبار من جهة الخادم/عند الحافة يصف منهجية تقسيم الصفحات الخاصة به؛ ويُقتبس هنا بوصفها مقارنة منهجية مع التقسيم العشوائي بملفات تعريف الارتباط.)

قائمة فحص SEO لاختبار A/B عند الحافة

نفذ ذلك قبل إطلاق اختبار عند الحافة يمس صفحات مفهرسة:

• تعرف أي نمط تشغله: إعادة كتابة HTML على العنوان نفسه، أم إعادة التوجيه إلى عنوان نسخة.
• الطلبات التي لا تحمل ملف تعريف ارتباط حتمية. تُسنَد Googlebot (التي لا تحتفظ عادة بملفات تعريف الارتباط) إلى النسخة نفسها لكل عنوان URL — لا إلى اختيار عشوائي جديد.
• إذا كان الاختبار على عنوان نسخة، يحمل كل عنوان نسخة rel=canonical يشير إلى عنوان الأصل.
• إعادة التوجيه أثناء الاختبار 302 لا 301. (يستخدم 301 للفائز فقط بعد الاختبار.)
• النسخة التي تراها الزواحف شرعية وتمثيلية ويسعدك فهرستها — وليست مسارًا خاصًا بالروبوت لإخفاء التجربة.
• لا تستخدم فحص وكيل المستخدم لإظهار شيء مختلف للروبوتات عن المستخدمين الحقيقيين بهدف التهرب من التدقيق.
• في الاختبار متعدد المتغيرات، يكون التقسيم ثابتًا وحتميًا لكل عنوان URL حتى لا تضاعف الحالات القابلة للزحف.
• توجد نهاية محددة: نقطة لاختيار الفائز وخطة لإزالة كل أدوات الاختبار سريعًا (لا اختبار يعمل بوصفه الحالة الدائمة الفعلية).
• لا يتداخل الاختبار مع ترحيل موقع (فذلك يربك إشارات إعادة التوجيه).
• لا تمنع قواعد WAF / الروبوت في CDN لديك Googlebot أو تحول مسارهما خفية قبل تشغيل عامل الاختبار.
• تحققت في فحص عنوان URL/السجلات من النسخة التي تحصل عليها Googlebot فعلًا.

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

1. الاختبار مسموح؛ والإخفاء غير مسموح. تشجع Google اختبار A/B والاختبار متعدد المتغيرات. ليس الخطر في الاختبار، بل في معاملة الروبوتات والمستخدمين معاملة غير متكافئة (بنية التلاعب)، أو ترك الاختبار يعمل حتى يصبح الموقع الدائم فعليًا. اربط كل قرار بهذه القاعدة.

2. نمطان، وإصلاحان.

• إعادة كتابة HTML على العنوان نفسه → الخطر هو الزحف غير المتسق (تقسيم بملف تعريف الارتباط مع Googlebot التي لا تحتفظ به). الإصلاح: نسخة حتمية للحركة التي لا تحمل ملف تعريف ارتباط.
• إعادة التوجيه إلى عنوان نسخة → الخطر هو المحتوى المكرر/التباس الوسم الأساسي. الإصلاح: وسم أساسي يشير إلى الأصل + 302 أثناء التشغيل.

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

4. تقسيم الصفحات مقابل تقسيم المستخدمين. يتجاوز تقسيم الصفحات الحتمي (نسخة واحدة لكل صفحة، للجميع) مشكلة ملفات تعريف الارتباط بالكامل. أما التقسيم العشوائي للمستخدمين بملفات تعريف الارتباط فيحتاج إلى بديل حتمي للزواحف. يسمى كلاهما «اختبار A/B عند الحافة»، لكن ملف المخاطر مختلف جدًا.

5. الحالة القابلة للزحف = ميزانية الزحف. تكلف كل حالة متميزة يمكن زحف عنوان URL إليها جزءًا من الميزانية. يضيف اختبار A/B حالة واحدة؛ ويضاعف الاختبار متعدد المتغيرات الحالات ما لم يكن التقسيم ثابتًا وحتميًا لكل عنوان URL.

6. جهة العميل < جهة خادم الأصل ≈ الحافة (من حيث ظهور SEO). قد تفوّت محركات البحث تبديلات JavaScript من جهة العميل. أما جهة خادم الأصل والحافة فكلتاهما تقدمان HTML حقيقيًا — والحافة تنفذ ذلك بسرعة أكبر وقبل الأصل، لكن على حساب فخاخ ملفات تعريف الارتباط وإعادة التوجيه السابقة.

اختبار A/B عند الحافة — ورقة غش

النمطان

قواعد إعادة التوجيه أثناء الاختبار

«اعرض للروبوتات النسخة الأصلية» — آمن أم لا؟

• آمن: الأصل تمثيلي فعلًا وهو ما ستفهرسه على أي حال؛ فالهدف هو الاتساق.
• غير آمن: مسار خاص بالروبوت بُني ليعرض للمحركات واقعًا مختلفًا عن المستخدمين → إخفاء.

حقائق سريعة

• لا تحتفظ Googlebot عادة بملفات تعريف الارتباط → التقسيم بملف تعريف الارتباط وحده غير موثوق للروبوتات.
• الوسم الأساسي تلميح لا توجيه → قد تفهرس النسخ البنيوية الكبيرة العنوانين على أي حال.
• لا حد ثابتًا لـالمدة، لكن لا تجعل الاختبار حالة دائمة؛ ولا تشغله أثناء الترحيل.
• لا تملك Bing صفحة مخصصة لاختبار A/B عند الحافة — اجعل قواعد Google هي الافتراضية.
• قاعدة Optimizely التقريبية «خسارة نحو 10% من قيمة الروابط في 301» قاعدة للبائع، وليست رقمًا من Google.

خرافات وأخطاء اختبار الحافة التي ينبغي تجنبها

هذه أكثر الفخاخ شيوعًا — وبعضها خرافات متكررة على نطاق واسع تستحق التصحيح:

• «الاختبار خطر بطبيعته/مخالف للقواعد». لا. تشجع Google اختبار A/B والاختبار متعدد المتغيرات البنّاء. الخطر في التنفيذ لا في فعل الاختبار.
• «إذا استبعدت الروبوتات من الاختبار كليًا فأنا آمن». هذا صحيح جزئيًا فقط. عرض أصل ثابت للروبوتات مقبول إذا كان ذلك الأصل فعلًا النسخة التي ستفهرسها. أما بناؤه على أنه «اكتشاف روبوت للتهرب من التدقيق» فيبدو إخفاءً نموذجيًا — عرض واقع مختلف للمحركات عن الواقع الذي يراه المستخدمون.
• «التقسيم بملف تعريف الارتباط مناسب — هكذا تفعل تقنيات الإعلان اختبارات A/B دائمًا». ليس في SEO. تقول Google صراحة إن Googlebot لا تحتفظ عادة بملفات تعريف الارتباط، لذلك تتصرف المنظومة المبنية للبشر بملف تعريف الارتباط وحده على نحو غير متوقع لدى الزواحف ما لم تضف بديلًا حتميًا.
• «إعادة التوجيه 301 إلى الفائز تشبه 302 أثناء الاختبار». لا. يقول 302 إن النقل مؤقت (أبقِ الأصل مفهرسًا)، ويقول 301 إنه دائم. استخدم 301 بعد الالتزام بالفائز فقط.
• «يضمن الوسم الأساسي ألا تفهرس Google عنوان النسخة». لا. الوسم الأساسي تلميح. فإذا اختلف محتوى النسخة اختلافًا كبيرًا عن الأصل، فقد تتجاهله Google وتفهرس العنوانين — ولهذا تنتمي التغييرات البنيوية الكبيرة إلى تقسيم صفحات لا إلى عنوان نسخة لكل مستخدم.
• «تحمل اختبارات الحافة والأصل من جهة الخادم والعميل خطر SEO نفسه». لا. قد تفوّت المحركات تبديلات JS من جهة العميل تمامًا؛ بينما تقدم الحافة والأصل HTML حقيقيًا. وتضيف الحافة مخاطرها الخاصة (روبوتات عمياء عن الملفات، وإعادة توجيه لعناوين النسخ، وتخزين CDN المؤقت وتفاعلات WAF) التي لا توجد في اختبار العميل البسيط.
• «لا مشكلة في اختبار حافة يعمل أشهرًا ما دام ما يزال اختبارًا». هذا محفوف بالمخاطر. فالاختبار الذي يظل يعمل حتى يصبح الصفحة الدائمة الفعلية — من دون إعلان فائز — هو ما تحذر Google من أن يبدو محاولة لخداع المحركات. اختتمه، واختر فائزًا، وأزل الأدوات.
• «تغطي وثائق بائع CDN زاوية SEO للاختبار». عادة لا. فمثال Akamai الرسمي لـEdgeKV واختبار A/B لا يتضمن، مثلًا، أي تأطير لـSEO أو الروبوت أو الزاحف. منظور SEO شيء تضيفه أنت؛ ولن تقدمه وثائق المنصة.

اعرف أي نسخة يحصل عليها الزاحف فعلًا

الفكرة كلها هي جعل الطلب الذي لا يحمل ملف تعريف ارتباط (وهو السلوك المعتاد لـGooglebot) يُسنَد إلى نسخة متسقة. إليك كيفية فحص ما تقدمه حافتك عند غياب ملف تعريف الارتباط.

الجلب كعميل لا يحمل ملف تعريف ارتباط (shell / curl)

# No cookie sent — this is closest to how Googlebot hits you.
# Run it a few times: the variant should be the SAME every time (deterministic),
# not a fresh 50/50 roll.
for i in 1 2 3; do
  curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
    https://example.com/product/123 | grep -o 'data-variant="[^"]*"'
done

# Show the response headers too — look for Set-Cookie (bucketing),
# Vary, and any redirect (302 good / 301 bad while testing).
curl -sI -A "Googlebot" https://example.com/product/123

رصد إعادة توجيه إلى عنوان نسخة وحالتها (shell)

# -L follows redirects; -w prints the chain of status codes.
# A live test should show 302, never 301.
curl -sIL -o /dev/null \
  -w "%{http_code} -> %{redirect_url}\n" \
  https://example.com/product/123

فحص النسخة المقدمة والوسم الأساسي في وحدة تحكم DevTools (جاهز للـbookmarklet)

الصق هذا في وحدة تحكم المتصفح على الصفحة قيد الاختبار — أو احفظه كـbookmarklet (javascript: + الجسم) لفحص أي صفحة بنقرة واحدة:

// What variant am I seeing, and does the page canonical to the control?
(() => {
  const variant = document.querySelector('[data-variant]')?.dataset.variant
    ?? 'no data-variant attr found';
  const canonical = document.querySelector('link[rel="canonical"]')?.href
    ?? 'no canonical';
  const hasCookie = /(?:^|; )ab_bucket=/.test(document.cookie);
  console.log({ url: location.href, variant, canonical, hasCookie });
})();

تأكيد التقسيم الحتمي (تعبير نمطي فوق سجلات الحافة)

إذا سجل العامل المجموعة المسندة لكل طلب، فسيستخرج هذا الطلبات التي لا تحمل ملف تعريف ارتباط ومجموعاتها حتى تؤكد أن العنوان نفسه يُسنَد دائمًا إلى النسخة نفسها:

# Match log lines with no ab_bucket cookie, capture URL + assigned variant.
# Group by URL: every URL should show ONE variant, not a mix.
grep -vE 'ab_bucket=' edge.log \
  | grep -oE '"(GET|HEAD) [^"]+".*variant=[AB]' \
  | sort | uniq -c | sort -rn

إذا أظهر أي عنوان URL كلًا من variant=A وvariant=B في طلبات لا تحمل ملف تعريف ارتباط، فالتقسيم لديك غير حتمي للزواحف — أصلح ذلك قبل أن تفهرس Googlebot هدفًا متحركًا.

أدوات تشغيل اختبارات الحافة وفحصها

• Cloudflare Workers — إعادة كتابة HTML على العنوان نفسه ونمط «passthrough» الموثق للوصول المتسق إلى الأصل/الاختبار.
• Akamai EdgeWorkers + EdgeKV — تقسيم عند الحافة بإسناد ثابت بملف تعريف ارتباط (أضف ضوابط SEO الخاصة بك؛ فالوثائق لا تقدمها).
• Fastly Compute — حوسبة الحافة لنمطي إعادة الكتابة وإعادة التوجيه نفسيهما.
• Optimizely / VWO (تكاملات الحافة/الخادم) — منصات تجارية للتجارب يمكنها العمل عند الحافة بدل جهة العميل.
• SearchPilot — اختبار A/B لـSEO من جهة الخادم/عند الحافة، مبني على تقسيم صفحات حتمي (نسخة واحدة لكل صفحة للجميع)، ويتجاوز مشكلة ملف تعريف الارتباط.
• Google Search Console — فحص عنوان URL — افحص كيف زحفت Googlebot عنوان URL قيد الاختبار ورسمته، وأي نسخة رأتها.
• تحليل ملف سجل الخادم — الحقيقة بشأن أي نسخة حصلت عليها الزواحف الحقيقية، وكم مرة، وما إذا كانت الطلبات التي لا تحمل ملف تعريف ارتباط تصل باستمرار.
• curl / وحدة تحكم DevTools — فحوص يدوية سريعة للنسخة المقدمة عند غياب ملف تعريف الارتباط، والوسم الأساسي، وحالة إعادة التوجيه (راجع علامة Scripts).
• IndexNow — بروتوكول دفع Bing/Yandex حتى تُرى عناوين النسخ سريعًا إذا كنت تجري اختبار تقسيم عناوين URL (المسار الذي توصي به Bing للتغييرات البنيوية).

تدقيق حتمية تقسيم الحافة للزواحف

Review this edge A/B test implementation. First classify it as:
A. Same-URL HTML rewriting, or
B. Redirect to a separate variant URL.

Then trace assignment for: a normal first visit, a returning visitor with a cookie,
Googlebot without a cookie across repeated crawls, and a request whose cache key is reused.
Return:
1. Every source of randomness or unstable assignment
2. Whether the same URL can show a crawler different indexable versions over time
3. Whether cache keys mix control and variant responses
4. For redirected variants, the redirect status and canonical relationship
5. User-agent branches that show bots content users cannot receive
6. A deterministic replacement and a repeat-request test plan
7. The cleanup required when the test ends

Do not assume crawlers retain cookies. Do not call a test safe merely because bots receive
the control; verify that control is genuinely available to users and is the intended
indexable version. Do not invent CDN settings or experiment data.

Worker/middleware code, routes, cache configuration, and test design:
[PASTE INPUT]

مراجعة اختبار مقترح لعنوان نسخة

Check this edge redirect test for temporary-test hygiene. Verify that the variant URL
canonicalizes to the control, the redirect is temporary, internal links and sitemaps do
not multiply the test URLs, crawler assignment is stable, and an end date/winner-removal
plan exists. Return pass/fail per condition and the smallest safe correction.

Inputs:
[PASTE REDIRECT RULES, HEAD OUTPUT, CANONICALS, AND TEST WINDOW]

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

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

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

مداخلاتي

• How Search Works (SlideShare) — شرحي للزحف والرسم والفهرسة والترتيب؛ خلفية مفيدة لفهم سلوك Googlebot عندما تزحف من دون الاحتفاظ بملفات تعريف الارتباط. (يظل تنبيهي المعتاد قائمًا: “This is my understanding of systems… not going to be 100% complete or accurate.”)

من أرجاء الصناعة

• أفضل ممارسات اختبار A/B للبحث (Google Search Central) — الوثيقة المرجعية: الوسم الأساسي و302 والمدة وملفات تعريف الارتباط/Googlebot.
• Cloudflare Workers — اختبار A/B بالوصول المباشر إلى العنوان نفسه — مثال ملف تعريف الارتباط 50/50 ونمط «passthrough» للوصول المتسق إلى النسخة.
• بناء اختبار A/B باستخدام EdgeWorkers وEdgeKV (Akamai) — تقسيم عند الحافة ثابت بملف تعريف ارتباط (ملاحظة: لا تأطير لـSEO في الوثيقة).
• اختبار A/B وتحسين محركات البحث (Optimizely) — إرشاد البائع الذي يعيد قواعد Google؛ ومصدر قاعدة «نحو 10% من خسارة قيمة الروابط في 301».
• ما هو اختبار A/B لتحسين محركات البحث؟ (SearchPilot) — منهجية تقسيم الصفحات مقابل المستخدمين وسبب قولهم «هناك Googlebot واحد فقط».
• SEO واختبار SEO عند الحافة (SearchPilot) — سبب ظهور تغييرات الحافة للمستخدمين وGooglebot كتغييرات HTML من جهة الخادم.
• اختبار A/B لأداء أفضل لمحرك البحث باستخدام IndexNow وMicrosoft Clarity (Bing Webmaster Blog) — ملاحظة Bing عن اختبار A/B وإرشادات IndexNow.

اختبر نفسك: SEO لاختبار A/B عند الحافة

خمسة أسئلة سريعة عن إجراء اختبارات تقسيم عند الحافة من دون الوقوع في مشكلات SEO. اختر إجابة لكل سؤال، ثم تحقق.

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