بعد ربط الدومين بـCloudflare، أهم خطوة ليست تشغيل كل خيارات السرعة والحماية، بل ضبط إعدادات Cloudflare لووردبريس بحيث تحمي الموقع وتقلل الحمل بدون كسر تسجيل الدخول أوWooCommerce أوJavaScript. في 2026 تعتمد Cloudflare أكثر على Cache Rules وConfiguration Rules بدل الشروحات القديمة المبنية على Page Rules، كما أن SSL/TLS وCompression وRocket Loader تحتاج قرارات مختلفة حسب إعداد الخادم والقالب والإضافات.

الإعداد الآمن يبدأ بثلاث قواعد: استخدم Full (strict) متى كان Origin Certificate صالحًا، لا تطبق Cache Everything على المحتوى الديناميكي بدون استثناءات، ولا تفعّل Rocket Loader أوMinification أوAPO وتفترض أنها تحسن كل موقع قبل اختبار Frontend وCheckout وwp-admin.
إعداد Cloudflare بدون كسر WordPress

قبل الإعداد: تأكد أن الموقع مرتبط بـCloudflare بصورة صحيحة

إذا لم يتم تغيير Nameservers أوDNS Records بصورة صحيحة فلن تمر الزيارات عبر Proxy الخاص بـCloudflare. ابدأ من دليل ربط WordPress مع Cloudflare ثم عد إلى هذه الصفحة لضبط السرعة والكاش والحماية.

DNS: الفرق بين Proxied وDNS Only

السحابة البرتقالية Proxied تعني أن الطلب يمر عبر شبكة Cloudflare وتستطيع الاستفادة من CDN وCache وWAF وRules والخصائص الأخرى المتاحة لخطة حسابك. DNS Only تعني أن Cloudflare يجيب عن DNS لكن الترافيك يتجه إلى Origin مباشرة بدون Proxy.

استخدم Proxied عادة لسجل A/AAAA/CNAME الخاص بالموقع عندما تريد خدمات Cloudflare.
لا تحول سجلات البريد MX إلى Proxy؛ Cloudflare DNS يتعامل معها بصورة مختلفة عن Web traffic.
راجع CNAME الخاصة بخدمات خارجية قبل تحويلها إلى Proxied لأن بعض المزودين يحتاجون DNS Only.
لا تغيّر Records غير مفهومة أثناء إصلاح مشكلة سرعة؛ DNS خطأ قد يوقف الموقع أوالبريد بالكامل.

SSL/TLS: اختر Full (strict) متى كان ذلك ممكنًا

Cloudflare توصي حاليًا باستخدام Full أوFull (strict) لتأمين الاتصال إلى Origin، وتصف Full (strict) بأنه الخيار الأفضل أمنيًا متى كان الخادم يقدم شهادة صالحة وغير منتهية وتطابق Hostname. في هذا الوضع يكون الاتصال مشفرًا من الزائر إلى Cloudflare ومن Cloudflare إلى الخادم مع التحقق من شهادة Origin.

المصدر الرسمي: Cloudflare Full (strict) documentation.

متى لا تفعّل Full (strict) مباشرة؟

إذا كان Origin لا يقبل HTTPS على 443 أوشهادته منتهية أولا تطابق الدومين، قد ينتج خطأ 526. أصلح الشهادة أولًا بدل الرجوع إلى Flexible كحل دائم. Flexible قد يسبب Redirect Loops في WordPress إذا كان الموقع يفرض HTTPS من الخادم أوالتطبيق.

إذا كان لديك Mixed Content أوNot Secure راجع حل مشكلة SSL وNot Secure في ووردبريس بدل تغيير Encryption Mode عشوائيًا.

Always Use HTTPS وAutomatic HTTPS Rewrites

Always Use HTTPS يفيد في توجيه HTTP إلىHTTPS من Edge، لكن لا تنشئ طبقات Redirect متكررة بلا داعٍ بين Cloudflare وNGINX وWordPress وPlugin SSL. راجع سلسلة التحويل النهائية وتأكد أن HTTP→HTTPS يحدث مرة واحدة بدون Loop.

Automatic HTTPS Rewrites يمكن أن يساعد في بعض الموارد المختلطة، لكنه ليس بديلًا عن تصحيح URLs القديمة داخل قاعدة البيانات أوالقالب عندما يكون الموقع نفسه ينتج HTTP links.

Cache Rules هي الأساس الحالي بدل شروحات Page Rules القديمة

Cloudflare توثق Cache Rules كالنظام الحالي لتحديد ما هو Eligible for cache وما الذي يجب Bypass، وتسمح بتحديد Edge TTL وBrowser TTL وCache Key وشروط مبنية على Hostname وPath وCookies وغيرها. إذا كان لديك Page Rules قديمة فلا تنسخها حرفيًا؛ راجع Migration behavior وترتيب القواعد.

المصدر الرسمي: Cloudflare Cache Rules.

قاعدة مهمة: لا تستخدم Cache Everything على WordPress كاملًا بدون استثناءات

Cloudflare تحذر في توثيق Cache Everything من أن تخزين HTML ديناميكي قد يجعل زائرًا يحصل على معلومات غير مخصصة له. الخطر أكبر في WooCommerce ومواقع العضويات والLogin، لأن Cart وAccount والمحتوى الشخصي يتغير حسب المستخدم.

استبعد /wp-admin/ وwp-login.php من HTML caching.
في WooCommerce استبعد Cart وCheckout وMy Account والصفحات الشخصية.
راجع Cookies التي تدل على مستخدم مسجل أوCart session قبل Edge caching للHTML.
لا تCache صفحات تحتوي Nonces أوForms شخصية بدون فهم سلوكها.
اختبر بحسابين مختلفين ونافذة خاصة، وليس كAdministrator فقط.

ترتيب Cache Rules مهم

Cache Rules في Cloudflare قابلة للتراكم، وإذا ضبطت قواعد متعددة نفس الخاصية فالقيمة في آخر Rule مطابقة هي التي تنتصر. لذلك Rule واسعة في آخر القائمة يمكن أن تلغي Bypass كنت تظن أنه يحمي Checkout. راجع ترتيب القواعد بعد كل إضافة.

المصدر الرسمي: Order and priority for Cache Rules.

Browser Cache وEdge Cache: لا تخلط بينهما

Edge Cache TTL تحدد المدة التي يحتفظ فيها Cloudflare بالنسخة على Edge، بينما Browser Cache TTL تؤثر على Cache لدى متصفح الزائر. رفع Browser TTL للAssets versioned مثل CSS/JS/images قد يكون مناسبًا، أما HTML الديناميكي فلا تعامل معه كملف static لمجرد أنه يمر عبر CDN.

Purge Cache: متى تستخدمه؟

بعد تعديل CSS أوTemplate أوبيانات تظهر من Edge، استخدم Purge للعنصر أوالمسار المستهدف إذا كان ذلك ممكنًا بدل Purge Everything كل مرة. مسح الكاش بالكامل يزيل Hot cache ويجعل Origin يستقبل موجة Requests جديدة حتى يعاد بناء النسخ.

Cloudflare WordPress Plugin: هل تحتاجها؟

Cloudflare لديها Plugin رسمية على WordPress.org، وتستخدم لإدارة بعض الإعدادات وPurge والتكامل مع Automatic Platform Optimization (APO). لا تحتاج Plugin فقط لأن DNS يعمل عبر Cloudflare؛ ثبتها عندما تحتاج الوظائف التي تقدمها بالفعل.

المصدر الرسمي: Cloudflare WordPress Plugin.

APO: Edge caching للـHTML مع تكامل WordPress

Automatic Platform Optimization تهدف إلى تخزين HTML الخاص بموقع WordPress على Edge بدل اقتصار CDN على Static Assets. هذا قد يقلل TTFB للزوار البعيدين عن Origin، لكنه يحتاج اختبارًا دقيقًا مع صفحات ديناميكية وWooCommerce وCache Plugin الموجودة على الخادم.

لا تفعل APO ثم تضيف Cache Everything Rules لنفس HTML بدون فهم التفاعل بين الطبقات. حدد من المسؤول عن Page Cache، وكيف تتم Purge عند تحديث Post/Product.

Compression: Brotli وZstandard وGzip

Cloudflare تدعم حاليًا Gzip وBrotli وZstandard لتسليم أنواع محتوى نصية وفق الخطة وAccept-Encoding والRules. لذلك الشرح القديم الذي يقول «فعّل Brotli دائمًا من زر واحد» لم يعد يعكس كل سيناريوهات المنصة.

المصدر الرسمي: Cloudflare Content Compression.

Auto Minify: لا تجعل Minification مزدوجة

إذا كانت Cloudflare تصغّر HTML/CSS/JS بينما LiteSpeed أوWP Rocket أوBuild process يقوم بالعملية نفسها، فقد تضيف تعقيدًا بدون مكسب واضح. اختر طبقة واحدة عند الإمكان وقارن الملفات قبل وبعد، خصوصًا عند وجود Combine/Delay/Defer من Plugin أداء أخرى.

Rocket Loader: اختبر JavaScript قبل الاعتماد عليه

Rocket Loader تؤخر JavaScript لتحسين Rendering، لكن Cloudflare نفسها توصي بتعطيلها وإعادة الاختبار إذا ظهرت مشاكل JavaScript أوjQuery. WooCommerce، Checkout، Consent managers،Page Builders وInteractive widgets تستحق اختبارًا صارمًا قبل تركها مفعلة.

المصدر الرسمي: Cloudflare Rocket Loader documentation.

اختبار Rocket Loader بصورة صحيحة

اختبر Add to Cart وتغيير Quantity.
اختبر Cart Drawer وMini Cart.
اختبر Checkout validation وبوابة الدفع.
اختبر Login/Register.
اختبر Elementor/slider/menu/mobile navigation.
راجع Browser Console للأخطاء.
قارن INP قبل وبعد بدل الاكتفاء بأن الصفحة «تبدو أسرع».

Early Hints وProtocol optimizations

Cloudflare توفر خصائص تحسين Protocol/Delivery متعددة تختلف حسب الخطة والوقت. فعّل أي ميزة بعد قياس أثرها، ولا تجمع عشر Optimizations في مرة واحدة لأنك لن تعرف أي تغيير حسّن النتيجة أوكسرها.

HTTP/2 وHTTP/3

استخدام البروتوكولات الحديثة يساعد في نقل الموارد، لكن لا يعوض عن DOM ضخم أوJavaScript ثقيل أوصور LCP كبيرة. Network optimization طبقة من خطة الأداء وليست الخطة كلها.

Image Optimization: لا تدفع Cloudflare لإصلاح Media Library سيئة

Cloudflare توفر حلول Image Optimization تختلف حسب الخطة، لكن الأصل يظل رفع صور بأبعاد وحجم مناسبين. تخزين نسخة محسنة على Edge لا يبرر رفع Hero image بآلاف البكسلات إذا كانت ستظهر بعرض صغير.

WAF وSecurity Rules

Cloudflare يمكن أن تقلل Requests الضارة قبل وصولها إلى WordPress، لكن Rule شديدة قد تمنع REST API أوadmin-ajax أوWebhooks أوPayment callbacks. استخدم Managed Rules عند توفرها، وراجع Security Events قبل إنشاء Blocks واسعة على Country أوASN أوUser-Agent.

Rate Limiting: حماية نقاط حساسة بدون حظر العملاء

Rate Limits مفيدة لمسارات مثل Login أوEndpoints تتلقى Abuse، لكن حدودًا منخفضة على WooCommerce AJAX أوREST قد تسبب 429 للمستخدم الحقيقي. راقب Requests الفعلية قبل اختيار threshold.

Bot protection وتأثيرها على SEO والأدوات

لا تحظر كل Bot غير معروف لأن الموقع يتعرض لـAI crawlers أوSEO tools. فرق بين Search engine bots الموثقة، أدوات المراقبة التي تحتاجها، Scrapers، وAbusive traffic. قاعدة خاطئة قد تمنع Search Console validation أوPayment provider أوUptime monitor.

Cloudflare وWordPress REST API

إذا كنت تستخدم Headless integrations أوWooCommerce أوApps أوMCP/Agents، REST API جزء من وظيفة الموقع. لا تضع Challenge على /wp-json/ بالكامل بدون تحديد من يستخدمها. حماية API تكون بالمصادقة والصلاحيات وRate controls المناسبة، لا بمنع endpoint عميانيًا.

Cloudflare وWooCommerce

WooCommerce هي أكثر حالة تحتاج حذرًا في الكاش. Static Assets والصفحات العامة قد تستفيد من Edge، لكن Cart وCheckout وMy Account وحالة المستخدم لا يجب أن تتلقى HTML شخص آخر.

استبعد مسارات Cart/Checkout/Account من Edge HTML cache.
راجع WooCommerce session/cart cookies.
اختبر إضافة منتج ثم الانتقال بين صفحات cached.
اختبر كوبون وشحن وضريبة وبوابة دفع.
تأكد أن Webhooks وPayment callbacks لا تتلقى Challenge غير مقصودة.
لا تطبق «Cache Everything» عالميًا ثم تعتمد على Purge عند الشك.

Cloudflare وwp-admin

لوحة الإدارة ديناميكية ولا تحتاج Edge page caching. إذا أصبح wp-admin بطيئًا فالمشكلة غالبًا PHP/Database/Plugins/HTTP calls وليست CDN. لا تحاول تسريع Dashboard بـCache Everything.

Cloudflare لا تغني عن Object Cache

Edge Cache وPersistent Object Cache يعالجان طبقتين مختلفتين. Cloudflare تقلل وصول Requests أوAssets إلى Origin، بينما Redis/Memcached قد تقلل عمليات Database داخل WordPress للRequests التي وصلت إلى PHP. لا تعتبر أحدهما بديلًا تلقائيًا للآخر.

Development Mode ومتى يفيد

Development Mode مفيد أثناء تعديلات قصيرة عندما تريد تجاوز Cache مؤقتًا ومشاهدة تغييرات Frontend بسرعة. لا تترك الموقع بلا Cache لأيام لأنك نسيت وضع التطوير، ولا تستخدمه بدل Purge مستهدف في العمل اليومي.

Origin Server: Cloudflare لا تصلح خادمًا بطيئًا

إذا كان TTFB من Origin سيئًا للRequests غير المخزنة، CDN قد تخفي المشكلة في Cache Hit فقط. اختبر wp-admin وCheckout وCache MISS وحدد PHP/Database bottleneck.

لخطة WordPress نفسها راجع دليل تسريع ووردبريس.

كيف تعرف أن Cloudflare Cache تعمل؟

افحص Response Headers مثل cf-cache-status على Request مناسب. HIT وMISS وDYNAMIC وغيرها يجب تفسيرها في سياق نوع الصفحة والRule الحالية. لا تحاول تحويل كل URL إلى HIT؛ الصفحات الديناميكية الصحيحة قد تكون DYNAMIC أوBypass عمدًا.

Cache HIT ليس هدفًا بحد ذاته

هدف الكاش تقليل Latency وOrigin load بدون تقديم بيانات قديمة أوشخصية. إذا حققت HIT على Checkout فهذا غالبًا فشل في التصميم، وليس نجاح Performance.

خطأ 520/521/522/523/524/525/526: لا تعالجها كلها بنفس الطريقة

521 غالبًا يعني أن Origin يرفض الاتصال أوغير متاح.
522 يرتبط بمهلة الاتصال مع Origin.
524 يعني أن Cloudflare اتصلت بالخادم لكن Origin لم يرسل Response في الوقت المطلوب.
525 يتعلق بفشل SSL handshake بين Cloudflare وOrigin.
526 يظهر مع Full (strict) عندما لا تستطيع Cloudflare التحقق من شهادة Origin.

ابدأ من Logs وOrigin health وSSL mode قبل تعطيل Cloudflare بالكامل. إذا كانت المشكلة 504 داخل WordPress نفسه راجع تشخيص 504 Gateway Timeout.

ترتيب الإعداد الذي أوصي به

تأكد من DNS وProxy state.
اضبط Origin certificate وFull (strict) إن كان ممكنًا.
ثبت Redirect HTTP→HTTPS بصورة واحدة واضحة.
راجع WAF/Security بدون Rules واسعة.
اترك Cache الافتراضي أولًا وقس الأداء.
أضف Bypass للصفحات الديناميكية قبل أي HTML edge caching.
فعّل/اختبر APO أوCache Rules إذا كان هناك سبب واضح.
راجع Compression وMinify مع Cache Plugin الحالية.
اختبر Rocket Loader منفردة.
اختبر WooCommerce/Login/Forms.
راجع Headers وCloudflare Analytics وOrigin logs.

إعدادات لا أنصح بنسخها من موقع آخر

Edge TTL نفسها لكل موقع.
Cache Everything expression جاهزة بدون تعديل.
Rate limit thresholds.
Country blocks.
Rocket Loader ON دائمًا.
JS Delay/Defer متزامن من Cloudflare وPlugin Cache.
Browser Cache طويل لHTML.
WAF exclusions واسعة لمجرد حل 403.
SSL Flexible كحل لمشكلة شهادة Origin.

Checklist بعد كل تعديل Cloudflare

Homepage تعمل من نافذة خاصة.
wp-admin وLogin يعملان.
REST API المطلوبة تعمل.
Cart وCheckout وMy Account غير مخزنة HTML بصورة غير صحيحة.
Forms ترسل.
Payment callbacks لا تُحظر.
JavaScript console نظيفة من الأخطاء الجديدة.
cf-cache-status منطقي حسب الصفحة.
Origin load لم يزد بصورة مفاجئة.
Core Web Vitals قورنت قبل وبعد وليس Score لحظية فقط.

أسئلة شائعة

هل Cloudflare تحسن سرعة WordPress تلقائيًا؟

CDN وEdge caching وCompression قد تقلل Latency والحمل في سيناريوهات كثيرة، لكن لا تصلح Plugin بطيئة أوDatabase Query ثقيلة أوJavaScript ضخم على Origin.

هل أستخدم Full أمFull (strict)؟

إذا كان Origin يقدم شهادة صالحة ومطابقة للدومين، Cloudflare توصي بـFull (strict) كخيار أكثر أمانًا. لا تستخدمه قبل إصلاح شهادة Origin إذا كانت غير صالحة.

هل أفعّل Rocket Loader؟

اختبرها. إذا حسنت Rendering بدون كسر Scripts اتركها، وإذا ظهرت مشاكل JavaScript أوjQuery فCloudflare نفسها توصي بتعطيلها وإعادة الاختبار.

هل أحتاج Cloudflare Plugin؟

ليس لمجرد استخدام DNS/CDN. هي مفيدة عندما تحتاج تكامل WordPress مع Purge/APO وإعدادات محددة.

هل Cloudflare Cache مناسبة لـWooCommerce؟

نعم للAssets وصفحات عامة وفق قواعد صحيحة، لكن لا تخزن HTML الشخصي لـCart/Checkout/My Account أوجلسة عميل على Edge بدون استثناءات دقيقة.

بعد ضبط SSL وCache Rules، لا تعتبر إعدادات Cloudflare وحدها نهاية العمل الأمني. عند الحاجة إلى مراجعة الحسابات والصلاحيات والملفات والنسخ وWAF ضمن خطة واحدة، انتقل إلى فحص أمان ووردبريس وتقوية الموقع.

الخلاصة

أفضل إعدادات Cloudflare لووردبريس ليست Preset واحدة. اضبط SSL/TLS بصورة صحيحة، استخدم Cache Rules الحديثة، افصل Static/Public content عن الصفحات الديناميكية، وتجنب تكرار Minification/JS optimizations بين Cloudflare وCache Plugin. في WooCommerce خصوصًا، صحة Session وCheckout أهم من رفع نسبة Cache HIT. غيّر إعدادًا واحدًا في كل مرة، اختبر، ثم انتقل للخطوة التالية.