تحسين محركات البحث على Cloudflare Workers

TL;DR — Cloudflare Workers هي برامج صغيرة تعمل على شبكة Cloudflare، أمام موقعك الحقيقي. يمكن للـ Worker إضافة إعادة توجيه، أو إصلاح وسم meta، أو حقن وسم canonical بينما تمر الصفحة — دون لمس نظام إدارة المحتوى الخاص بك أو انتظار المطورين. هذه الصفحة هي النسخة العملية على مستوى الكود من فكرة Edge SEO الأوسع: كيف تقوم بذلك فعليًا على Workers تحديدًا. القاعدة الوحيدة التي لا يمكنك كسرها: أي شيء يغيّره الـ Worker، يجب أن يغيّره لـ Google وللزوار الحقيقيين بنفس الطريقة. إظهار شيء مختلف لـ Google هو cloaking.

ما هو Cloudflare Worker بعبارات بسيطة

إذا كان موقعك على Cloudflare، فإن كل طلب من زائر (أو من Googlebot) يمر عبر شبكة Cloudflare قبل أن يصل إلى خادمك الفعلي. Worker هو سكربت صغير يمكنك تشغيله عند تلك النقطة في المسار. يرى الطلب الوارد والاستجابة الصادرة، ويمكنه تغيير أي منهما. Evidence for this claim Cloudflare Workers run code on Cloudflare's network and can inspect or modify requests and responses. Scope: Cloudflare Workers request handling. Confidence: high · Verified: 2026-07-14 Cloudflare Workers: How Workers works

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

ما الذي يستخدمه الأشخاص في Workers لتحسين محركات البحث

• عمليات إعادة التوجيه — إرسال عناوين URL القديمة إلى عناوين جديدة عند الحافة، حتى لو كانت بالآلاف.
• إصلاح أو إضافة الوسوم — حقن وسم canonical، تصحيح العنوان، إضافة hreflang، إدراج بيانات منظمة — كل ذلك دون تعديل مصدر الصفحة.
• إعادة كتابة الترويسات — إضافة أو إصلاح أشياء مثل X-Robots-Tag.

القاعدة التي لا يمكنك كسرها

أيًا كان ما يفعله الـ Worker الخاص بك، يجب أن يفعله للجميع. إذا أظهرت لـ Googlebot صفحة مختلفة عما يراه الشخص الحقيقي — للتلاعب بالترتيب — فهذا cloaking، وهو مخالف لقواعد Google. Evidence for this claim Google defines serving materially different content to search engines and users to manipulate rankings as cloaking and a spam-policy violation. Scope: Google Search spam policy; legitimate personalization is context-dependent. Confidence: high · Verified: 2026-07-14 Google: Spam policies — cloaking النمط الآمن بسيط: طبق نفس المنطق على كل طلب، بغض النظر عن من يطلبه. (مركز Edge SEO يغطي هذه القاعدة بعمق — هذه الصفحة تفترض أنك تفهم المفهوم بالفعل وتريد دليلًا عمليًا خاصًا بـ Cloudflare.)

الطريقتان لإيذاء نفسك

معظم قصص “Cloudflare أضر بتحسين محركات البحث” ليست بسبب كود الـ Worker على الإطلاق:

1. إعداد حظر البوتات. يمكن لوضع Bot Fight Mode في Cloudflare حظر أو تحدي Googlebot عن طريق الخطأ. إذا لم يتمكن Google من جلب صفحاتك، فلا شيء آخر يهم.
2. الارتباك في التخزين المؤقت. لدى Cloudflare أكثر من نوع واحد من التخزين المؤقت، وإذا كنت لا تعرف أي واحد تلمسه، فقد يبدو التغيير الذي نشرته وكأنه “لا يظهر”.

تريد الكود الفعلي — معالج fetch، مثال HTMLRewriter، جدول إعادة توجيه KV — بالإضافة إلى تفاصيل التخزين المؤقت وحظر البوتات؟ انتقل إلى علامة التبويب Advanced.

الخلاصة — لا يرى Cloudflare Worker سوى الطلبات التي تطابق المسار المُهيأ له، ويعترض كل طلب في معالج fetch واحد، حيث تقوم بثلاثة أشياء بالتسلسل: إعادة كتابة الطلب، وإعادة كتابة ترويسات الاستجابة، وإعادة كتابة نص الاستجابة عبر HTMLRewriter. هذه هي الآلية الحقيقية وراء “حقن canonical” أو “إصلاح العنوان” — وهي تحتاج إلى أن تكون idempotent، ومُختبرة ضد الاستجابات المفقودة، والمكررة، وغير HTML، وليس فقط المسار السعيد. عمليات إعادة التوجيه على نطاق واسع تعيش في KV (بحث سريع بالمفتاح) أو D1 (علائقي)؛ تغطي Bulk Redirects/Rules المجموعات الصغيرة بشكل أبسط، وأنا أفضّل عمومًا عمليات إعادة التوجيه على مستوى الحافة على مستوى الخادم — ولكن اختر مالكًا واحدًا لكل URL، نظرًا لأن إعادة توجيه Worker، وإعادة توجيه Bulk Redirect، وإعادة توجيه الأصل يمكن أن تعمل جميعها على نفس المسار. ثلاثة أشياء مختلفة تشترك في كلمة “cache” — Workers Cache API (caches.default)، وذاكرة التخزين المؤقت لحافة Cloudflare، و Cache-Control الأصلية — والخلط بينها هو السبب المعتاد لـ “الوسم الخاص بي لم يظهر”؛ شخّص التقادم حسب مفتاح التخزين المؤقت، والطبقة، وTTL، والإبطال بدلاً من التخمين. إرشادات Google الخاصة بـ ETag / If-None-Match / 304 قابلة للتطبيق مباشرة على Worker الذي يملك الاستجابة. خط التمويه: منطق متطابق لكل طالب. أكثر جرح ذاتي خاص بـ Workers هو Bot Fight Mode، الذي يعمل خارج WAF Ruleset Engine، لذا فإن قواعد “السماح” العادية لا تصل إليه. أرسل كل تغيير يؤثر على SEO مع بيانات إصدار مسجلة، وتراجع مُختبر، و شرط إيقاف — ثم تحقق باستخدام GSC URL Inspection و CF-Cache-Status.

ما هي هذه المقالة (وما ليست)

هذا هو الرفيق العملي على مستوى الكود لمركز SEO على الحافة. يمتلك المركز التعريف العام، وجدول مقارنة المنصات (Workers، Akamai، Fastly، Lambda@Edge، Vercel، Netlify)، وقرار Snippets-vs-Workers، و المعالجة الكاملة لقاعدة التمويه. لن أعيد اشتقاق أي من ذلك هنا. هذه الصفحة تتعمق مستوى واحدًا في Cloudflare Workers تحديدًا — وقت التشغيل الذي يعمل عليه worker هذا الموقع نفسه، المُوصَّل عبر run_worker_first في wrangler.toml — مع واجهات برمجة تطبيقات حقيقية بدلاً من التلويح باليد “الحوسبة الطرفية يمكنها حقن الوسوم”.

ملاحظة قبل الكود: Google ليس لديها وثائق خاصة بـ Cloudflare Workers. الإرشادات الرسمية التي تحكم هذا (سياسة التمويه، التخزين المؤقت HTTP، زحف CDN) هي عامة وتنطبق على أي تنفيذ على الحافة. أفضل قول ذلك بوضوح بدلاً من التلميح إلى أن مستند Google موجود وهو غير موجود.

كيف يقع Worker في مسار الطلب/الاستجابة

Worker هو نص برمجي بدون خادم يعمل على V8 isolates. كل طلب يتم توجيهه إليه يدخل عبر معالج fetch. Evidence for this claim A Cloudflare Worker receives HTTP requests through a fetch handler. Scope: Cloudflare Workers handlers. Confidence: high · Verified: 2026-07-14 Cloudflare Workers: Fetch handler “موجَّه إليه” يقوم بعمل حقيقي في هذه الجملة: لا يرى Worker سوى الطلبات التي تطابق المسار أو النطاق المخصص المُهيأ له — كل شيء آخر لا يصل إلى معالج fetch على الإطلاق. حيث يمكن أن يتطابق مساران مع نفس URL، يأخذ النمط الأكثر تحديدًا الأسبقية، لذا قبل أن تثق في سلوك Worker لـ URL معين، تأكد من أن المسار يطابقه فعلاً وتحقق من الإصدار المنشور الذي يعمل على ذلك المسار (بيئات Wrangler والطرح التدريجي تعني أن الإصدار الذي يخدم حركة المرور ليس دائمًا الذي في محررك). داخل المعالج يمكنك القيام بثلاثة أشياء مميزة، بالترتيب:

1. إعادة كتابة الطلب قبل أن يذهب إلى أصلك.
2. إعادة كتابة ترويسات الاستجابة في طريق العودة.
3. إعادة كتابة نص الاستجابة — عبر HTMLRewriter.

إليك الشكل الأدنى:

export default {
  async fetch(request, env, ctx) {
    // 1. (optionally) inspect/modify the request
    const response = await fetch(request);   // hit the origin

    // 2. rewrite headers
    const headers = new Headers(response.headers);
    headers.set("X-Robots-Tag", "index, follow");

    // 3. rewrite the body with HTMLRewriter (see next section)
    return new Response(response.body, { ...response, headers });
  },
};

فريق SALT.agency، الذي صاغ مصطلح “edge SEO” بناءً على أبحاث Cloudflare Workers، بنى أدواته كسلسلة فلاتر — فلتر طلب، وفلتر استجابة، وفلتر نص. هذا هو نفس النمط ثلاثي المراحل؛ لقد سموه فقط. إبقاء هذه المراحل الثلاث منفصلة في ذهنك يحافظ على وضوح Worker.

إعادة كتابة HTML باستخدام HTMLRewriter

HTMLRewriter هو محلل HTML الدفق من Cloudflare، وهو الواجهة البرمجية الفعلية وراء كل حيلة “حقن وسم”. Evidence for this claim Cloudflare HTMLRewriter provides selector-based handlers that can transform streamed HTML elements. Scope: Cloudflare Workers HTMLRewriter API. Confidence: high · Verified: 2026-07-14 Cloudflare Workers: HTMLRewriter يمكنك تسجيل معالجات عناصر .on(selector, handler)، ويحصل المعالج على getAttribute / setAttribute، وprepend / append، وsetInnerContent، وreplace. نظرًا لأنه يدفق، فأنت لا تخزن المستند بأكمله في الذاكرة.

حقن أو إصلاح وسم canonical

class CanonicalHandler {
  constructor(url) { this.url = url; }
  element(el) { el.setAttribute("href", this.url); }
}

const rewriter = new HTMLRewriter()
  .on('link[rel="canonical"]', new CanonicalHandler("https://example.com/preferred/"));

return rewriter.transform(response);

إذا لم تكن الصفحة تحتوي على canonical على الإطلاق، فقم بإرفاق معالج بـ head وappend واحد بدلاً من تعديل وسم موجود. في كلتا الحالتين، تذكر الدرس من جانب canonicalization: rel=canonical هو تلميح، وليس أمرًا — يتيح لك Worker تعيينه بشكل متسق عبر منصة بأكملها، لكن Google لا تزال تقرر.

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

• لا يوجد canonical موجود — يحتاج المعالج الخاص بك إلى اكتشاف الحالة المفقودة وappend واحد إلى head، وليس تجاهل link[rel="canonical"] الذي لا يطابق شيئًا.
• يوجد canonical مكرر أو تالف بالفعل — قرر ما إذا كنت تزيل الوسم الشارد أو تترك إعادة الكتابة لإضافة وسم ثانٍ (الأخير خطأ حقيقي، وليس حالة حافة — الوسوم canonical المكررة مشكلة شائعة يسببها المرء لنفسه).
• استجابة غير HTML — مسار API، أو صورة، أو استجابة إعادة توجيه تمر عبر نفس Worker لا ينبغي تشغيلها عبر HTMLRewriter على الإطلاق؛ قم بتقييد التحويل إلى المسارات وأنواع المحتوى التي تحققت منها فعليًا.
• تشغيل التحويل مرتين على نفس الاستجابة (إعادة محاولة، fetch متداخل) — تأكد من أنه لا يعيد إضافة وسم ثانٍ.

إضافة أو تصحيح بدائل hreflang

نفس الآلية، مدفوعة من الإعدادات. تقوم بإلحاق link[rel="alternate"] واحد لكل لغة إلى head. إذا كانت البدائل الخاصة بك لكل لغة وعلائقية، فإن هذا الإعداد ينتمي إلى D1؛ إذا كان بحثًا مسطحًا، فإن KV كافٍ. النقطة هي أن HTMLRewriter يحقنها بشكل متطابق لكل طالب — فأنت لا تتفرع على وكيل المستخدم.

حقن بيانات JSON-LD المنظمة

new HTMLRewriter().on("head", {
  element(head) {
    head.append(
      `<script type="application/ld+json">${JSON.stringify(schema)}</script>`,
      { html: true }
    );
  },
});

حدود وحدة المعالجة المركزية التي تؤثر عند التوسع

ادعاء منافس واحد أود أن أعترض عليه هو “أقل من مللي ثانية، بدون قيود.” السقف الحقيقي هو وقت وحدة المعالجة المركزية: 10 مللي ثانية على الخطة المجانية، 30 مللي ثانية على المدفوعة (وقت الحائط في انتظار fetch لا يُحتسب — وقت وحدة المعالجة المركزية يُحتسب). بالنسبة لإعادة الكتابة النموذجية لن تلاحظ ذلك أبدًا. بالنسبة لتمريرات HTMLRewriter الثقيلة على صفحات كبيرة جدًا، فهو قيد حقيقي يجب التصميم حوله، وليس تخويفًا.

عمليات إعادة التوجيه على الحافة: KV مقابل D1 مقابل القواعد

أفضل عادةً أن تكون عمليات إعادة التوجيه على الحافة (مستوى CDN) بدلاً من وجودها على الخادم — فهي تخفف العمل عن الأصل وتُطبق قبل إنشاء الصفحة على الإطلاق. على وجه التحديد في Cloudflare، في دليلي في Ahrefs حول عمليات إعادة التوجيه لتحسين محركات البحث أوضحت أن لديك عدة خيارات: عمليات إعادة توجيه مفردة أو جماعية، قواعد إعادة التوجيه، قواعد الصفحات، أو Workers مع أزواج مفتاح-قيمة — أو Worker يعدل الرؤوس لإضافة إعادة توجيه.

بالنسبة لجدول مدفوع بواسطة Worker، KV هو الموطن الطبيعي: بحث مفتاح سريع ومتسق في النهاية حسب URL.

export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    const target = await env.REDIRECTS.get(url.pathname);   // KV namespace
    if (target) return Response.redirect(target, 301);
    return fetch(request);
  },
};

استخدم D1 عندما تكون عمليات إعادة التوجيه علائقية (SQL لكل لغة، لكل مقطع تريد الاستعلام عنه). واعرف متى يكون Worker مبالغًا فيه: لمجموعة صغيرة وثابتة من عمليات إعادة التوجيه، فإن عمليات إعادة التوجيه المجمعة أو قواعد إعادة التوجيه من Cloudflare أبسط ولا تتطلب أي كود على الإطلاق. لا تقم ببناء Worker KV يدويًا لخمسين عملية إعادة توجيه.

اختر مالكًا واحدًا لعنوان URL معين ولا تدع إعادة توجيه Worker أو إعادة توجيه Bulk أو قاعدة إعادة توجيه أو إعادة توجيه من الأصل تنطبق جميعها على نفس المسار — فهي أنظمة منفصلة يمكن لكل منها أن يعمل على نفس الطلب، وعندما يتطابق أكثر من واحد، فأنت تتصيد أخطاء الأولوية بدلاً من إعادة توجيه نظيفة. قبل إضافة إعادة توجيه في أي مكان، تحقق مما إذا كانت هناك إعادة توجيه موجودة بالفعل لهذا المسار في الأنظمة الأخرى، واختر الطبقة بناءً على تعقيد المطابقة (1:1 بسيط مقابل قائم على الأنماط)، والحجم، ومن يحتاج إلى المراقبة أو التراجع عنها — إعادة توجيه Worker تعيش في الكود والسجلات الخاصة بك؛ بينما تعيش إعادة توجيه Bulk أو قاعدة في لوحة التحكم وهي أسهل لغير المطور لتدقيقها أو التراجع عنها.

التخزين المؤقت: ثلاثة أشياء مختلفة، اسم واحد مربك

هذا هو القسم الذي تتجاهله صفحات المنافسين، وهو الذي يولّد أكبر قدر من الارتباك حول “لماذا لم يظهر تغييري”. ثلاث طبقات منفصلة تشترك في كلمة cache:

• Workers Cache API — caches.default و caches.open(). هذا مخزن مؤقت قابل للبرمجة بنطاق Worker تقرأه وتكتبه في الكود.
• ذاكرة التخزين المؤقت الطرفية لـ Cloudflare — ذاكرة التخزين المؤقت لشبكة CDN التي تخدم أصولك. وهي متميزة عن Cache API.
• Cache-Control من الأصل — الرؤوس التي يضبطها أصل الخادم (أو Worker الخاص بك)، والتي تؤثر على كل ما سبق وعلى ما يفعله Googlebot.

اخلط بينها وستقسم أن تغييرًا لم يُنشر بينما هو في الواقع يُقدَّم من طبقة لم تقم بمسحها.

عندما لا يظهر تغيير حقيقي، لا تخمّن — شخّص المشكلة طبقة بطبقة:

1. مفتاح التخزين المؤقت. ما سمات الطلب التي تحدد ما إذا كان طلبان يصلان إلى نفس الإدخال المخزن مؤقتًا (URL، وأحيانًا الرؤوس أو ملفات تعريف الارتباط إذا كان مفتاح التخزين المؤقت يتضمنها)؟ إعادة كتابة تختلف بناءً على شيء غير موجود في مفتاح التخزين المؤقت يمكن أن تخدم النسخة الخاطئة.
2. أي طبقة خدمت الاستجابة. تحقق من CF-Cache-Status (HIT/MISS/EXPIRED/DYNAMIC) لمعرفة ما إذا كانت ذاكرة التخزين المؤقت الطرفية أجابت على الإطلاق، أم أن الطلب وصل إلى Worker الخاص بك.
3. الموقع/الحالة. ذاكرة التخزين المؤقت لـ Cloudflare موزعة عبر مراكز البيانات — المسح أو النشر الجديد لا يبطل بالضرورة كل موقع طرفي فورًا.
4. TTL والقاعدة التي ضبطته. تأكد مما إذا كانت قاعدة تخزين مؤقت، أو رأس Cache-Control من أصل الخادم، أو رأس ضبطه Worker نفسه هو ما يتحكم في TTL.
5. الإبطال. هل مسحت عنوان URL المحدد، أو مسحت كل شيء، أو اعتمدت على انتهاء صلاحية TTL؟ إدخال Cache API المملوك لـ Worker (caches.default) يحتاج إلى delete() صريح خاص به — مسح ذاكرة التخزين المؤقت لشبكة CDN لا يلمسه.

ما يفعله Googlebot مع ETag / If-None-Match / 304

إذا كان Worker الخاص بك يولّد الاستجابة أو يعيد كتابتها، فهو يملك رؤوس التخزين المؤقت — مما يعني أن إرشادات التخزين المؤقت HTTP لشهر ديسمبر 2024 من Google قابلة للتنفيذ مباشرة بالنسبة لك. تدعم Google التخزين المؤقت الاستدلالي HTTP عبر ETag/If-None-Match و Last-Modified/If-Modified-Since، وتوصي بشدة بـ ETag لأنه أقل عرضة للأخطاء، وتقول إنه عندما يتطابق ETag الخاص بالزاحف، يجب أن يعيد خادمك 304 Not Modified بدون نص. يمكن لـ Worker الذي يولّد الاستجابة تنفيذ ذلك بالضبط: حساب ETag، ومقارنته بـ If-None-Match، والاختصار إلى 304 بنفسه — مما يوفر الحوسبة ويعطي Googlebot إشارة سريعة وقابلة للتخزين المؤقت.

مقايضة max-age لإعادة الزحف

تقول Google أيضًا إنه يجب التفكير في ضبط Cache-Control: max-age لمساعدة الزواحف على تحديد موعد إعادة الزحف. المشكلة بالنسبة لـ Worker يعيد كتابة HTML: max-age عدواني على صفحة تغيّرت للتو علاماتها المحقونة عبر Worker يمكن أن يؤخر رؤية Googlebot للتحديث الذي نشرته للتو. لا تضع عمر تخزين مؤقت طويلًا على HTML مُعاد كتابته وتنساه.

حدود التمويه (cloaking)، مطبقة على Workers

القاعدة الصارمة، بمصطلحات Workers: شغّل نفس المنطق لكل طالب. سياسة البريد العشوائي من Google تعرّف التمويه (cloaking) بأنه تقديم محتوى مختلف للمستخدمين ومحركات البحث للتلاعب بالترتيب، وتحديدًا تشير إلى إدراج نص أو كلمات مفتاحية فقط عندما يكون الطالب محرك بحث.

بعض التوضيحات، لأن الناس يبالغون في التصحيح هنا:

• فحص User-Agent ليس تمويهًا تلقائيًا. تسجيل حركة مرور الروبوتات، أو تقديم استجابة مخزنة مؤقتًا بشكل أسرع لأي عميل، أمر مقبول. الخط الفاصل هو اختلاف المحتوى بناءً على هوية الطالب، بهدف التلاعب بالترتيب.
• اختبار A/B بتقسيم الصفحات على Workers مقبول. تقسيم المستخدمين حسب URL ومعاملة كل طالب بنفس الطريقة أمر مشروع. التقسيم حسب من يسأل — روبوت مقابل إنسان — ليس كذلك.

مثال عملي على النمط الآمن: بوابة المعاينة الخاصة بهذا الموقع هي Worker تُرجع خطأ 404 لأي مسار /preview/ ما لم يطابق ملف تعريف ارتباط سرًا. تُرجع هذا الـ 404 للجميع بدون ملف تعريف الارتباط — بما في ذلك Googlebot. هذا هو الشكل الآمن تمامًا: لا يخفي شيئًا عن الروبوتات ويُظهر شيئًا آخر للمستخدمين؛ بل يطبق قاعدة واحدة بشكل موحد.

ولا تعتمد على خطوة ما قبل العرض الخاصة بالروبوتات فقط حتى لو بنيتها بشكل نظيف على Workers. لقد وصف Google العرض الديناميكي بأنه حل مؤقت وليس حلاً طويل الأمد; أي Worker يعرض مسبقًا للروبوتات فقط يرث هذا الإهمال.

كيف يمكن لـ Worker أن يحجب Googlebot أو يبطئه عن طريق الخطأ

هذه هي الطريقة الأكثر خصوصية بـ Workers لإطلاق النار على قدمك، وعادةً لا تكون في كود الـ Worker الخاص بك.

وضع Bot Fight Mode يعمل خارج محرك القواعد

Bot Fight Mode (وSuper Bot Fight Mode) يمكن أن يُنتج نتائج إيجابية خاطئة ضد الزاحفين الشرعيين، بما في ذلك Googlebot. الفخ: يتم تقييم Bot Fight Mode على خط أنابيب منفصل عن محرك قواعد WAF، لذا فإن قواعد “السماح” أو “التخطي” المخصصة العادية في WAF لا تتجاوزه. إذا كان Bot Fight Mode يتحدى Googlebot، فلا تصلحه بقاعدة سماح — بل يجب عليك تغيير أو تعطيل الوضع نفسه. (تحقق من الآليات الحالية مقابل وثائق Cloudflare Bot Fight Mode و Super Bot Fight Mode قبل الاعتماد عليها — منتجات الروبوتات تتغير.)

نمط القاعدة المخصصة للروبوتات الموثقة

تكشف Cloudflare عن حقل cf.client.bot ونمط السماح للروبوتات الموثقة حتى تتمكن من السماح للزاحفين المعروفين بأنهم جيدون في قواعدك المخصصة — مفيد لجانب WAF، على الرغم من (كما هو مذكور أعلاه) أنه لا يصل إلى Bot Fight Mode.

شبكة CDN نفسها محايدة إلى إيجابية

لتوضيح الأسطورة: Cloudflare-كـ-CDN لا تضر بـ SEO. عمل Google الخاص لعام 2024 Crawling December يلاحظ أن Google تزيد معدل الزحف عندما تكتشف CDN — ولكن CDN يمكنها أيضًا حجب Googlebot عن طريق الخطأ عبر قواعد WAF/الروبوتات، وأن 503 أفضل من صفحة وسيطة للتحقق من الروبوت. الخطر هو Worker أو إعداد روبوتات تم تكوينه بشكل خاطئ، وليس البنية التحتية.

التحقق مما تلقاه Googlebot فعليًا

بعد أي نشر لـ Worker، تأكد مما حصل عليه الزاحف فعليًا — لا تفترض:

• GSC URL Inspection → Test Live URL. يجلب الصفحة كما يراها Google ويعرض HTML المعروض، لذا يمكنك التأكد من أن canonical/hreflang/JSON-LD المحقون موجود فعلاً.
• تحقق من CF-Cache-Status بجانب HTML. HIT / MISS / EXPIRED يخبرك ما إذا كنت تنظر إلى استجابة Worker جديدة أو مخزنة مؤقتاً — أسرع طريقة لاكتشاف “التغيير الذي لم يظهر” والذي هو في الحقيقة مشكلة طبقة تخزين مؤقت.
• اجلب كـ Googlebot مباشرة. اطلب باستخدام وكيل مستخدم Googlebot وقارن — لكن تذكر أن مطابقة السلسلة لا تثبت شيئاً عن الهوية؛ تحقق من Googlebot الحقيقي عبر DNS عكسي + أمامي مقابل نطاقات Google المنشورة (انظر تبويب Scripts).

نظافة النشر الخاصة بـ Workers

نجاح wrangler deploy يخبرك أن السكربت تم شحنه — لكنه لا يخبرك أن Googlebot يحصل على المخرجات المعروضة الصحيحة. تعامل مع كل تغيير Worker يؤثر على SEO كإصدار بسجل، وليس مجرد دفع:

• حدد نطاق مساراتك. لا تشغل Worker على /* افتراضياً. طابقه مع المسارات التي يحتاجها في أنماط المسارات في wrangler.toml حتى لا يتمكن خطأ من إسقاط موقعك بالكامل.
• تحقق من الحدود الحالية قبل أن تعد بالقدرة. حدود وقت CPU، وعدد الطلبات الفرعية، وحجم السكربت تختلف حسب الخطة وتتغير بمرور الوقت — تأكد من صفحة حدود Cloudflare الحالية قبل تصميم إعادة كتابة حول سقف معين، بدلاً من الاعتماد على رقم متذكر.
• سجل بيانات الإصدار للإصدار. نموذج الإصدارات والنشر من Cloudflare يتتبع إصدار المصدر، وتاريخ التوافق، والروابط، والمسارات لكل نشر — لاحظ أي إصدار نشط على أي مسار حتى يكون ادعاء “الـ Worker يفعل X” قابلاً للتحقق مقابل ما هو منشور فعلاً، وليس ما في محررك.
• قم بالإصدار والتراجع باستخدام بيئات Wrangler. انشر إلى بيئة تجريبية، وطرح تدريجياً بالنسبة المئوية، واحتفظ بالقدرة على العودة إلى الإصدار السابق فوراً.
• استخدم سجلات محددة النطاق لمراقبة الطرح — مع وضع حدودها في الاعتبار. سجلات Workers وتتبع السجلات من Cloudflare يمكن أن تدعم تصحيح أخطاء الطرح التدريجي، لكن السجلات تُعيّن وتُحتفظ بها لفترة محدودة — تعامل معها كدليل محدد للطلبات التي التقطتها، وليس سجلاً كاملاً لكل زيارة زاحف.
• حدد شرط إيقاف واختبر التراجع قبل أن تحتاجه. قرر مسبقاً أي سلوك ملاحظ (معدل خطأ، استجابة خاطئة في فحص عشوائي، انخفاض معدل الزحف) يوقف الطرح، وتأكد من أن مسار التراجع يعمل فعلاً بدلاً من افتراض أنه سيعمل.
• امسح ذاكرة التخزين المؤقت كجزء من النشر. بما أن ثلاث طبقات تخزين مؤقت قيد اللعب، اجعل مسح/إبطال ذاكرة التخزين المؤقت خطوة صريحة في شحن إعادة كتابة، وليس فكرة لاحقة.

ملاحظة عن Bing، وشيء استشرافي

Bing ليس لديه إرشادات خاصة بـ Cloudflare/الحافة أيضاً. لكن لأن نشر Worker فوري بينما الزحف ليس كذلك، فإن IndexNow هو الاقتران الطبيعي — أطلقه لحظة شحن جدول إعادة توجيه أو تغيير علامة مدفوع بـ Worker حتى يعيد Bing (ومحركات أخرى مشاركة) الزحف بسرعة. ويستحق نظرة: Cloudflare شحنت توحيداً مفروضاً على الحافة كميزة منتج (“Redirects for AI Training”) — زواحف تدريب الذكاء الاصطناعي الموثقة تحصل على 301 إلى عنوانك الأساسي بتبديل واحد. إنه تباين مفيد مع منطق التوحيد اليدوي في Worker الخاص بك، وتذكير بأن “تقديم شيء مختلف للزواحف عن المستخدمين” هو نمط شككت Microsoft علناً فيه في ميزات Cloudflare الأخرى لزواحف الذكاء الاصطناعي — فحص جيد لأي Worker مشروط بالبوت.

للصورة الأوسع — مقارنة المنصات، Snippets مقابل Workers، زوايا قائمة التطوير والحوكمة — عد إلى مركز SEO على الحافة.

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

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

• تحسين محركات البحث على Cloudflare Workers = تنفيذ تحسين محركات البحث التقني على بيئة تشغيل V8-isolate الخاصة بـ Cloudflare. إنه التنفيذ على مستوى الكود الخاص بـ Workers لمفهوم SEO على الحافة العام — راجع هذا المحور للحصول على التعريف ومقارنة المنصات وعمق التمويه.
• يرى العامل (Worker) فقط ما يطابقه مساره. تكوين المسار/النطاق والأولوية يحددان الطلبات التي تصل إلى معالج fetch على الإطلاق — تأكد من المسار والإصدار المنشور قبل الثقة في سلوك العامل لعنوان URL.
• معالج fetch واحد، ثلاث مراحل: إعادة كتابة الطلب، إعادة كتابة رؤوس الاستجابة، إعادة كتابة نص الاستجابة. تتم إعادة كتابة النص عبر HTMLRewriter — الآلية الحقيقية لحقن canonical، وإصلاح hreflang، أو إضافة JSON-LD. اجعل إعادة الكتابة قابلة للتكرار واختبرها ضد الاستجابات المفقودة والمكررة والتالفة وغير HTML، وليس فقط المسار السعيد.
• عمليات إعادة التوجيه: KV للبحث السريع عن المفاتيح، D1 للتكوين العلائقي، Bulk Redirects/Rules للمجموعات الثابتة الصغيرة. يفضل باتريك عمليات إعادة التوجيه على مستوى الحافة على مستوى الخادم — ولكن اختر مالكًا واحدًا لكل عنوان URL؛ يمكن أن تعمل إعادة توجيه العامل، وBulk Redirect، وقاعدة إعادة التوجيه، وإعادة توجيه الأصل على نفس المسار.
• ثلاثة مخابئ تشترك في كلمة واحدة: Workers Cache API (caches.default)، وذاكرة التخزين المؤقت على حافة Cloudflare، وCache-Control من الأصل — الخلط بينها يسبب “تغييري لم يظهر.” شخّص ذلك حسب مفتاح التخزين المؤقت والطبقة وTTL والإبطال بدلاً من التخمين.
• إرشادات Google الخاصة بـ ETag/If-None-Match/304 للتخزين المؤقت (ديسمبر 2024) قابلة للتنفيذ مباشرة: يمكن للعامل الذي يملك الاستجابة أن يختصر إلى 304 بنفسه؛ لكن max-age العدواني يمكن أن يؤخر إعادة الزحف لصفحة تغيرت للتو.
• قاعدة التمويه: منطق متطابق لكل طالب. فحص UA ليس تلقائيًا تمويهًا؛ اختلاف المحتوى حسب هوية الطالب للتلاعب بالترتيب هو كذلك.
• أكبر خطر ذاتي: Bot Fight Mode يعمل خارج محرك قواعد WAF، لذا فإن قواعد السماح العادية لا تصل إليه — يجب عليك تغيير الوضع نفسه.
• انشر بعناية: تحقق من حدود الخطة الحالية قبل الوعد بالتوسع، وسجل بيانات تعريف الإصدار (تاريخ التوافق، والارتباطات، والمسارات) لكل إصدار، واستخدم سجلات محدودة النطاق (مأخوذة بعينات، وليست سجلاً كاملاً) لمراقبة الإصدار، واضبط شرط إيقاف مع تراجع مُختبر قبل أن تحتاجه.
• تحقق باستخدام GSC URL Inspection (Test Live URL) ورأس CF-Cache-Status؛ وراقب حدود وحدة المعالجة المركزية (10 مللي ثانية مجانًا / 30 مللي ثانية مدفوعة) على عمليات إعادة الكتابة الثقيلة.

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

لا توجد وثائق تحسين محركات البحث الخاصة بـ Cloudflare Workers من Google أو Bing — الإرشادات الحاكمة عامة. المصادر الأولية الأكثر فائدة مقسمة بين محركات البحث (السياسة/التخزين المؤقت) و Cloudflare (واجهات برمجة تطبيقات وقت التشغيل).

Google (ينطبق على أي تنفيذ على الحافة)

• سياسات البريد العشوائي — التمويه — الحد الصلب الذي يجب أن يحترمه أي منطق عامل.
• الزحف ديسمبر: التخزين المؤقت HTTP (2024) — ETag / If-None-Match / 304 / max-age، قابل للتنفيذ مباشرة لعامل يملك الاستجابة.
• الزحف ديسمبر: شبكات CDN والزحف (2024) — كيف تؤثر شبكة CDN على معدل الزحف وكيف يمكن لقواعد الروبوتات حظر Googlebot.
• العرض الديناميكي (مهمل) — لماذا يرث عامل ما قبل العرض الخاص بالروبوتات نمطًا مهملاً.
• نظرة عامة على زاحفي Google وجالبي البيانات — وكلاء المستخدم ونطاقات IP المنشورة للتحقق.

Cloudflare (بيئة التشغيل)

• HTMLRewriter — واجهة برمجة تطبيقات محلل HTML المتدفق.
• Cache API — caches.default / caches.open().
• كيف تعمل الذاكرة المؤقتة — Cache API مقابل ذاكرة التخزين المؤقت الطرفية.
• المسارات والنطاقات — مطابقة المسارات، والأولوية، والطلبات التي تستدعي Worker فعليًا.
• عمليات إعادة التوجيه المجمعة — نظام إعادة التوجيه بدون كود الذي قد يتعارض أو يتداخل مع إعادة توجيه Worker.
• حدود Workers — الحدود الحالية لوحدة المعالجة المركزية، والطلبات الفرعية، وحجم السكربت؛ وهي حساسة للخطة والتاريخ، لذا تحقق منها مباشرة بدلاً من الاعتماد على رقم محفوظ.
• الإصدارات وعمليات النشر — النشر المُصدَّر/التدريجي والتراجع.
• سجلات Workers — سجلات الاستدعاء، والتتبع، وحدود أخذ العينات والاحتفاظ بها.
• Bot Fight Mode / Super Bot Fight Mode — إعدادات الروبوتات التي يمكنها حظر Googlebot.
• السماح بحركة مرور الروبوتات التي تم التحقق منها — نمط القاعدة المخصصة cf.client.bot.

Bing — لا توجد صفحة edge/Workers؛ IndexNow هو الاقتران المناسب لإعادة الزحف الفوري بعد النشر.

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

تصريحات مسجلة. كل رابط Google هو رابط عميق يقفز إلى المقطع المقتبس.

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.” (ترجمة) «يشير التمويه إلى ممارسة تقديم محتوى مختلف للمستخدمين ومحركات البحث بقصد التلاعب بترتيب البحث وتضليل المستخدمين.» — Google Search Central، سياسات Google لمكافحة المحتوى المزعج في بحث الويب. الانتقال إلى الاقتباس
• “Inserting text or keywords into a page only when the user agent that is requesting the page is a search engine, not a human visitor” (ترجمة) «إدراج نص أو كلمات مفتاحية في صفحة فقط عندما يكون وكيل المستخدم الذي يطلب الصفحة محرك بحث، وليس زائرًا بشريًا» — مُدرج كمثال على التمويه. الانتقال إلى الاقتباس

Google — التخزين المؤقت HTTP (الزحف ديسمبر 2024)

• “Google’s crawling infrastructure supports heuristic HTTP caching as defined by the HTTP caching standard, specifically through the ETag response- and If-None-Match request header, and the Last-Modified response- and If-Modified-Since request header.” (ترجمة) «البنية التحتية للزحف من Google تدعم التخزين المؤقت الاستدلالي لـ HTTP وفقًا لمعيار التخزين المؤقت لـ HTTP، وتحديدًا من خلال رأس الاستجابة ETag ورأس الطلب If-None-Match، ورأس الاستجابة Last-Modified ورأس الطلب If-Modified-Since.» الانتقال إلى الاقتباس
• “We strongly recommend using ETag because it’s less prone to errors and mistakes (the value is not structured unlike the Last-Modified value).” (ترجمة) «نوصي بشدة باستخدام ETag لأنه أقل عرضة للأخطاء والسهو (القيمة غير منظمة على عكس قيمة Last-Modified).» الانتقال إلى الاقتباس
• “If the ETag value sent by the crawler matches the current value the server generated, your server should return an HTTP 304 (Not modified) status code with no HTTP body.” (ترجمة) «إذا تطابقت قيمة ETag التي أرسلها الزاحف مع القيمة الحالية التي أنشأها الخادم، فيجب أن يعيد الخادم رمز الحالة HTTP 304 (غير معدل) بدون نص HTTP.» الانتقال إلى الاقتباس
• “While not required, consider also setting the max-age field of the Cache-Control header to help crawlers determine when to recrawl the specific URL.” (ترجمة) «على الرغم من أنه غير مطلوب، فكر أيضًا في تعيين حقل max-age في رأس Cache-Control لمساعدة الزواحف في تحديد موعد إعادة الزحف إلى عنوان URL المحدد.» الانتقال إلى الاقتباس

Google — التقديم الديناميكي (مهمل)

• “Dynamic rendering was a workaround and not a long-term solution for problems with JavaScript-generated content in search engines.” (ترجمة) «كان التقديم الديناميكي حلاً مؤقتًا وليس حلاً طويل الأمد لمشاكل المحتوى المُنشأ عبر JavaScript في محركات البحث.» الانتقال إلى الاقتباس

أنا — حول عمليات إعادة التوجيه على مستوى الحافة

• “I typically prefer to have redirects on the edge (CDN-level) over having them on the server.” (ترجمة) «أفضل عادةً أن تكون عمليات إعادة التوجيه على الحافة (مستوى CDN) بدلاً من أن تكون على الخادم.» — من دليلي في Ahrefs، 11 أنواع من عمليات إعادة التوجيه وتأثيرها على SEO. مأخوذ من مقالتي المنشورة؛ الصياغة مني ولكن تحقق من العبارة الدقيقة مقابل الصفحة الحية قبل اعتبارها اقتباسًا صريحًا.

Cloudflare / SALT.agency — لماذا Workers لعمليات إعادة التوجيه

• “we needed to implement simple redirects, which should be easy to create on the majority of platforms but wasn’t supported” (ترجمة) «احتجنا إلى تنفيذ عمليات إعادة توجيه بسيطة، والتي يجب أن تكون سهلة الإنشاء على معظم المنصات ولكنها لم تكن مدعومة.» — Igor Krestov وDan Taylor، الغوص في SEO التقني باستخدام Cloudflare Workers (مدونة Cloudflare). مأخوذ عبر تلخيص منشور مدونة Cloudflare، وليس مؤكدًا كسلسلة فرعية دقيقة — أعد التحقق مقابل الصفحة الحية قبل استخدامه كاقتباس صريح.

أي أداة للمهمة؟

“أحتاج إلى إضافة عمليات إعادة توجيه.”

• مجموعة صغيرة وثابتة (عشرات قليلة، بدون منطق)؟ → عمليات إعادة التوجيه المجمعة من Cloudflare أو قواعد إعادة التوجيه. بدون Worker، بدون كود.
• آلاف عمليات إعادة التوجيه المرتبطة بعناوين URL؟ → Worker + KV للبحث.
• عمليات إعادة توجيه علائقية (حسب اللغة، حسب الشريحة، مبنية على استعلامات)؟ → Worker + D1.
• تحتاج إلى إعادة توجيه وإعادة كتابة الرؤوس في نفس المرور؟ → Worker (لا يمكن للقواعد القيام بالأمرين معًا).

“أحتاج إلى حقن أو إصلاح وسم (canonical، hreflang، title، JSON-LD).”

• → Worker مع HTMLRewriter. لا يوجد منتج Cloudflare بدون كود لإعادة كتابة الجسم بشكل تعسفي؛ هذه مهمة Workers.

“انخفض زحف Googlebot بعد إضافة Cloudflare.”

• اشتبه أولاً في Bot Fight Mode / Super Bot Fight Mode، وليس في الـ Worker الخاص بك. تحقق مما إذا كان يتحدى Googlebot — وتذكر أن قاعدة السماح في WAF لن تصلح ذلك؛ بل يجب عليك تغيير الوضع نفسه.
• ثم تحقق من القواعد المخصصة في WAF وما إذا كان يتم تقديم 503/صفحة وسيطة للروبوتات.
• فقط بعد ذلك قم بمراجعة كود الـ Worker ونطاق المسار.

“الوسم الذي حقنته لا يظهر.”

• تحقق من CF-Cache-Status. هل هو HIT/EXPIRED؟ أنت ترى استجابة مخزنة مؤقتًا — امسح الطبقة الصحيحة (Workers Cache API مقابل ذاكرة التخزين المؤقت الطرفية) وأعد الاختبار.
• هل هو MISS وما زال غير صحيح؟ الآن المشكلة في منطق الـ Worker أو نطاق المسار. تأكد باستخدام GSC URL Inspection.

“هل يجب أن أقوم بالعرض المسبق للروبوتات فقط على Worker؟”

• → لا. هذا هو العرض الديناميكي، الذي أوقفته Google. فضّل العرض من جانب الخادم (SSR) أو العرض الثابت المطبق على الجميع.

قائمة فحص Cloudflare Workers لتحسين محركات البحث

قبل نشر Worker لإعادة الكتابة

• المسار محدد النطاق للمسارات التي يحتاجها في wrangler.toml — وليس /* بشكل تلقائي — وتأكدت من الإصدار المنشور الفعلي النشط على هذا المسار.
• يطبق الـ Worker منطقًا متطابقًا على كل طالب (بدون فرع محتوى بين روبوت وإنسان).
• معالجات HTMLRewriter قابلة للتكرار ومختبرة ضد وسم مفقود، ووسم موجود مكرر/تالف، واستجابة غير HTML — وليس فقط المسار السعيد.
• بالنسبة لعمليات إعادة التوجيه، اخترت الأداة الصحيحة: Bulk Redirects/Rules (صغيرة/ثابتة)، أو KV (مفتاح URL على نطاق واسع)، أو D1 (علائقية) — وتأكدت من عدم وجود نظام إعادة توجيه آخر يملك عنوان URL هذا بالفعل.
• تم التحقق من حدود الخطة الحالية (CPU، والطلبات الفرعية، وحجم البرنامج النصي) مباشرة، وليس من الذاكرة.
• Cache-Control على HTML المعاد كتابته ليس عدوانيًا لدرجة تؤخر إعادة الزحف إلى الصفحات المتغيرة.
• يتم تسجيل بيانات تعريف الإصدار (تاريخ التوافق، والارتباطات، والمسارات) للإصدار، مع مسار تراجع مُختبر وشرط توقف محدد للطرح.

التحقق من التخزين المؤقت

• تعرف أيًا من الطبقات الثلاث (Workers Cache API / ذاكرة التخزين المؤقت الطرفية / Cache-Control الأصلي) التي تتعامل معها.
• إذا كان الـ Worker يملك الاستجابة، فإنه يضبط ETag صحيحًا ويمكنه الاختصار إلى 304.
• مسح/إبطال التخزين المؤقت هو خطوة صريحة في النشر.

وصول الروبوتات

• Bot Fight Mode / Super Bot Fight Mode لا يتحدى Googlebot (تم التحقق منه مباشرة — قاعدة السماح في WAF لا تتجاوزه).
• قاعدة مخصصة للروبوتات الموثوقة (cf.client.bot) موجودة إذا كنت تعتمد على جانب WAF.
• تحصل الروبوتات على 503، وليس صفحة تحقق وسيطة، عندما تحتاج إلى إبطائها.

التحقق بعد النشر

• GSC URL Inspection → Test Live URL يؤكد أن الوسم المحقون موجود في HTML المعروض.
• تم التحقق من CF-Cache-Status (HIT/MISS/EXPIRED) لتعرف ما إذا كنت ترى نسخة مخزنة مؤقتًا.
• تم إرسال IndexNow (Bing/آخرون) إذا تم نشر جدول إعادة توجيه أو تغيير وسم للتو.
• تمت إدارة الإصدارات عبر بيئات Wrangler مع مسار تراجع مُختبر.

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

1. معالج واحد، ثلاث مراحل. كل Worker هو معالج fetch، وكل ما تفعله يقع في واحدة من ثلاث مراحل بالترتيب: أعد كتابة الطلب ← أعد كتابة ترويسات الاستجابة ← أعد كتابة نص الاستجابة (HTMLRewriter). حدد موقع ما تغيّره في هذا التسلسل قبل كتابة أي سطر.

2. “التخزين المؤقت” ثلاثة أشياء، وليس شيئًا واحدًا. Workers Cache API (caches.default) ≠ ذاكرة التخزين المؤقت الطرفية لـ Cloudflare ≠ Cache-Control الأصلي. عندما لا يظهر تغيير “لا يظهر،” اسأل أي طبقة تنظر إليها فعليًا قبل لمس الكود.

3. اختبار التمويه: الهوية مقابل المنطق. التفرع بناءً على من يسأل لتغيير المحتوى = تمويه. تطبيق نفس المنطق على الجميع — حتى لو كان هذا المنطق يفحص UA لأغراض التسجيل أو السرعة — أمر جيد. اسأل: “هل سيحصل المستخدم الحقيقي على نفس ما حصل عليه Googlebot؟”

4. ترتيب اللوم عند انخفاض الزحف. Bot Fight Mode ← قواعد WAF ← كود الـ Worker ← نطاق المسار. تعمل إعدادات الروبوتات على خط أنابيب لا تصل إليه قواعد السماح الخاصة بك، لذا اشتبه بها أولاً.

5. العامل (Worker) يملك الاستجابة — وبالتالي يملك دلالات التخزين المؤقت. إذا كان العامل (Worker) الخاص بك يُنشئ أو يعيد كتابة المحتوى، فهو مسؤول عن ETag و304 وmax-age. هذه قدرة (اختصار مسار 304 بنفسك) ومسؤولية (الإفراط في التخزين المؤقت يؤخر إعادة الزحف).

Cloudflare Workers SEO — ورقة الغش

اختر أداة إعادة التوجيه

الطبقات الثلاث للتخزين المؤقت

واجهة برمجة تطبيقات معالج HTMLRewriter

• getAttribute / setAttribute — قراءة/تعيين سمة وسم (مثلًا، href للكنوني)
• prepend / append — إضافة ترميز داخل عنصر (مثلًا، وسم داخل head)
• setInnerContent — استبدال محتويات عنصر
• replace — تبديل العنصر بالكامل

حقائق سريعة

• حد وحدة المعالجة المركزية: 10 مللي ثانية مجانًا / 30 مللي ثانية مدفوعًا (فترات انتظار fetch بساعة الحائط لا تُحتسب).
• التمويه (Cloaking) = اختلاف المحتوى بناءً على هوية الطالب للتلاعب بالترتيب — وليس “العامل قرأ وكيل المستخدم.”
• وضع مكافحة الروبوتات (Bot Fight Mode) يعمل خارج محرك قواعد WAF — قواعد السماح لا تصل إليه؛ غيّر الوضع.
• تحقق من تغيير العامل: GSC اختبار عنوان URL المباشر + ترويسة CF-Cache-Status.
• توصي Google بـ ETag؛ تطابق ETag → إرجاع 304 بدون محتوى.

تحقق مما حصل عليه Googlebot فعليًا — بعد نشر العامل

الجلب كـ Googlebot والمقارنة (سكربت شل)

# Fetch as a normal browser
curl -sS -A "Mozilla/5.0" https://example.com/page/ -o user.html -D user.headers

# Fetch as Googlebot's UA
curl -sS -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  https://example.com/page/ -o bot.html -D bot.headers

# The bodies should be identical — a diff is a cloaking red flag
diff user.html bot.html && echo "identical (good)"

# Check what cache layer served it
grep -i "cf-cache-status" bot.headers   # HIT / MISS / EXPIRED

تأكيد Googlebot الحقيقي (يمكن تزوير سلاسل UA بسهولة) — DNS عكسي ثم أمامي

# 1) Reverse DNS the IP from your logs — must end in googlebot.com / google.com
host 66.249.66.1
# 2) Forward DNS that hostname back — must resolve to the same IP
host crawl-66-249-66-1.googlebot.com

إذا فشل أي فحص، فهذا ليس Googlebot. ويمكنك أيضًا المطابقة مع نطاقات googlebot.json ranges.

اقرأ الوسوم المُحقنة من HTML المُقدَّم (وحدة تحكم DevTools)

// Paste into the browser console on the live page to confirm your Worker's injection
[...document.querySelectorAll('link[rel="canonical"]')].map(l => l.href);
[...document.querySelectorAll('link[rel="alternate"][hreflang]')]
  .map(l => `${l.hreflang} -> ${l.href}`);
[...document.querySelectorAll('script[type="application/ld+json"]')].map(s => s.textContent);

حد أدنى من ETag / 304 داخل Worker

export default {
  async fetch(request, env, ctx) {
    const res = await fetch(request);
    const body = await res.text();
    const etag = `"${await sha1(body)}"`;               // your hash of choice
    if (request.headers.get("If-None-Match") === etag) {
      return new Response(null, { status: 304 });        // no body, per Google's guidance
    }
    const headers = new Headers(res.headers);
    headers.set("ETag", etag);
    return new Response(body, { ...res, headers });
  },
};

أدوات لبناء والتحقق من Workers SEO

• Wrangler — واجهة سطر الأوامر من Cloudflare لتطوير Workers وإصدارها ونشرها (تحديد النطاق، البيئات، التراجع، الأسرار). هنا تعيش صحة النشر.
• HTMLRewriter — محلل HTML المدمج للتدفق؛ واجهة برمجة التطبيقات لإعادة كتابة كل النصوص.
• Workers KV / D1 — التخزين لجداول إعادة التوجيه والإعدادات (KV لعمليات البحث بالمفتاح، D1 لـ SQL).
• GSC URL Inspection → Test Live URL — يجلب الصفحة ويعرضها كما يفعل Google حتى تتمكن من تأكيد أن canonical/hreflang/JSON-LD المحقون قد وصل فعلاً.
• ترويسة CF-Cache-Status (عبر curl -I أو DevTools Network) — تخبرك بـ HIT/MISS/EXPIRED لتعرف ما إذا كنت تنظر إلى نسخة مخزنة مؤقتًا أم استجابة Worker جديدة.
• IndexNow — أرسل إشعارًا إلى Bing ومحركات البحث الأخرى المشاركة فور نشر تغيير مدفوع بـ Worker.
• تحليل سجلات الخادم — الحقيقة الأساسية لمعرفة ما إذا كان Googlebot الحقيقي (الموثوق) يصل إلى مسارات Worker الخاصة بك على الإطلاق.

تدقيق Worker لاتساق SEO وسلوك التخزين المؤقت

Review this Cloudflare Worker fetch handler as an SEO edge change. Trace the request,
response-header, body-rewrite, redirect, and caching paths. Return:
1. Every branch based on user agent, bot status, cookie, geography, or request header
2. Whether Googlebot/no-cookie traffic can receive different indexable content or SEO tags
3. HTMLRewriter selectors that fail when a tag is missing or create duplicates
4. Redirect lookups that can chain, loop, or fall through unexpectedly
5. Each use of the Cache API, Cloudflare edge cache behavior, and origin Cache-Control—kept as separate layers
6. Cache keys that could mix variants or preserve a stale canonical/robots/header change
7. A minimal test matrix for users, verified bots, cache hit/miss, and representative URLs

Apply the same content and SEO logic to bots and users. Flag intentional personalization
for human review rather than calling it cloaking automatically. Do not invent Cloudflare
settings, bindings, routes, cache rules, or origin behavior that are not in my input.

Worker code, bindings, routes, and relevant cache/security configuration:
[PASTE INPUT]

مراجعة تغيير HTMLRewriter قبل النشر

Audit this HTMLRewriter implementation for one SEO task: [CANONICAL / HREFLANG / JSON-LD].
Check whether it handles existing, missing, and duplicate elements; produces valid absolute
URLs or JSON; applies to the intended route cohort; and behaves identically for every
requester. Then return corrected code plus raw-response and rendered-response tests.

Do not add product, organization, locale, URL, or schema facts that are not supplied.

Code and expected per-route output:
[PASTE INPUT]

اختبر نفسك: Cloudflare Workers SEO

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

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

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

• 11 نوعًا من عمليات إعادة التوجيه وتأثيرها في SEO (Ahrefs) — خيارات إعادة التوجيه على Cloudflare، ولماذا أفضل إعادة التوجيه على مستوى الحافة على مستوى الخادم.
• دليل المبتدئ لـSEO التقني (Ahrefs) — أين تتناسب تغييرات الحافة في الصورة الأوسع.
• مشكلات JavaScript في SEO وأفضل الممارسات (Ahrefs) — جانب العرض، ذو صلة بأي إغراء للعرض المسبق على الحافة.

تحدثي

• اضبط SEO التقني وسرعة الصفحة والأمان (مقابلة Marketing Speak) — حيث أشرح استخدام Cloudflare Workers لإعادة الكتابة قبل أن يرى المستخدم الصفحة، وتفريغ إعادة التوجيه إلى CDN. نص مقابلة منطوقة؛ تعامل مع الصياغات المحددة كإعادة صياغة وليس كاقتباسات حرفية.

من حول الصناعة

• الغوص في SEO التقني باستخدام Cloudflare Workers — Igor Krestov (SALT.agency) وDan Taylor على مدونة Cloudflare؛ أصل نمط سلسلة التصفية (طلب/استجابة/نص).
• ما هو SEO على الحافة؟ (Search Engine Land) — المفهوم الذي يغطيه المحور الأصلي لهذه المقالة، بصيغة طرف ثالث.
• SEO على الحافة (Dan Taylor) — من الشخص الذي صاغ المصطلح من أبحاث Cloudflare Workers.
• HTMLRewriter (وثائق Cloudflare) — المرجع الأساسي لواجهة برمجة التطبيقات لإعادة كتابة النص.
• كيف تعمل الذاكرة المؤقتة (وثائق Cloudflare) — يفصل Cache API عن التخزين المؤقت على الحافة.
• إعادة التوجيه للتدريب على الذكاء الاصطناعي (مدونة Cloudflare) — فرض التوحيد القياسي على الحافة كميزة منتج، تباين مفيد مع تنفيذه يدويًا في Worker.

تعمق / جانبيًا

• SEO على الحافة — المحور الأصلي: المفهوم العام، مقارنة المنصات، Snippets مقابل Workers، قاعدة التمويه بالكامل.

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